| version |
|---|
0.8.0 |
This is the default CONTRIBUTING document designed for all Entities owned and maintained by the Innovate for Vegas Foundation ("Innovate for Vegas" or "foundation" or "we") subject to contribution of any kind by anyone. This file may be modified where appropriate in the form of addenda to this original document or with addenda in a CONTRIBUTING document which also references this original authoritative base, which shall not compromise the fundamental ethos of the Innovate for Vegas Foundation and its population of Contributors of Creative Works in this original form or with any addenda applied.
An Innovate for Vegas Entity ("entity") is composed of Elements ("element" or "elements") which may be an Initiative ("initiative") or a Component Project ("project" or "component" or "component project") or a plural combination thereof, and can be quantified as the sum of the time, effort, expertise, and creativity ("creative work") of those who submit their contributions to any part of any entity or its elements in any way. An entity may be composed of zero or more collections of these works located in an accessible place or places, and may include other elements such as multimedia content, visual artwork, written word, and any other relevant items ("components") stored and tracked by any means in a formal revision control system or in a less-structured tracking system, generally referred to as a Repository ("repository" or "repo"). Each of the entities and elements, stored and tracked in whichever form by whichever tools and techniques, shall adopt and be governed by the default LICENSE and CONTRIBUTOR terms of the Initiative to which each belongs, unless otherwise indicated per entity.
A Contributor is any individual person or business entity ("contributor") adding materially to a project or repository, by way of new creative work stored or otherwise included as an element of an entity ("contribution"). A contribution may be attributed to a business entity as a single contributor.
Contributions may include but are not comprehensively defined or constrained by this normative list of activities, which we include as examples creative work:
- Reporting a bug or defect
- Constructive contribution to fixing or verifying bugs or defects
- Discussing the current state of an initiative or its component projects
- Submitting a fix or other change
- Proposing new features or useful changes
- Becoming a maintainer of a project or project repository or other component(s)
- Testing entities or elements to insure they function or exist as intended
- Translating documents, including written or spoken word, into one or more additional languages
- Designing physical or mechanical items
- Building physical or mechanical items
- Creating and editing content to aid in the use or understanding of any entities as they are deployed
- Describing what our foundation intends to accomplish to others as a form of outreach and engagement with communities
- Co-creation of entities and their features with community members at large
- Any of a variety of other creative works and actions which further entity development goals
- Anything else deemed a contribution by the whole team
All contributors to any part of any entity, including but not limited to Initiatives and Component Project repositories or repository-like stores to which this CONTRIBUTING policy applies shall make any contribution in accordance with the Developer Certification of Origin which is excerpted at a point in time below (the latest version in the linked document remains authoritative for the purposes of signoff):
Developer Certificate of Origin Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
Additions or changes to a git repository ("commits"), including our repositories maintained on GitHub, must be submitted with a signoff option set, attesting to compliance with the Developer Certification of Origin policy. Submissions of creative work to any repository should include that signoff, the process documented here:
As of this writing, our InnovateForVegas organizational presence on GitHub.com is considered the single source of truth for Innovate for Vegas Foundation regarding contributions of creative works, attestation of eligibility of those contributions, and attribution of those contributions to individual or business entities as named contributors, with regard to our entities. Actual sources of software code, documentation, and similar may be stored directly within repositories, while external items may be tracked in entity repositories for the purposes outlined in this document, our policies apply regardless of actual or virtual location of the entity.
Any and all creative work contributed to this entity by any contributor must be owned by that contributor, or that contributor must possess or obtain permission from the owner of the creative work explicitly granting permission to contribute that creative work to this entity.
Any and all entities maintained by Innovate for Vegas Foundation, found directly or referenced within our GitHUb organization, shall be copyright Innovate for Vegas Foundation unless otherwise stated per entity.
Due in part to the way laws protect Copyright and License Terms as they apply to Creative Works, those works created wholly or substantially by automation, including but not limited to Artificial Intelligence tools, are not compatible with the work and efforts of the Innovate for Vegas Foundation. Creative Works not executed substantially by a human or humans cannot be contributed to any entity. Exceptions may be allowed where such works created by automation may be marked free from copyright and license, for unencumbered use, such that inclusion will not conflict with copyright and license of any specific entity.
A contributor to this entity shall make any contributions such that they comply with, and will be governed by, the selected license for the entity, irrevocably and in perpetuity. Contributor agrees to assign copyright of contributed creative work to the Innovate for Vegas Foundation, irrevocably and in perpetuity.
A particular entity will be developed with a stated license, for example the selected software coding repository default is likely the gpl-3.0 license, though lgpl-3.0 or some similar license might be appropriate in some cases. If at any time during the life of an entity, a change in license is necessary, contributors agree to such license changes and will be apprised if possible if and when such changes occur.
Visit the Choose a License Appendix for a table of licenses and basic information about them as a starting point for license research and selection.
In many case, a particular project component may not be software. Graphical assets, logos, video, audio, or other media content, written word content for marketing, documentation, etc may be contributed to any project, under a license that is more appropriate for this type of content. A common selection might be one of the Creative Commons licenses, or Open Hardware license schemes.
Visit the Choose A License non-software page for some ideas here.
In cases where one entity repository contains creative work with different applicable licenses, specific items must be associated with the specific license under which they are made available for use. Ideally, repositories can be constructed and combined to allow a simpler, single-license-per-repository approach, or will make it clear to all if multiple licenses apply and how.
Any creative work contributed to any Innovate for Vegas Entity, with copyright assigned to the Innovate for Vegas Foundation on submission, is immediately licensed back to its contributor(s) in perpetuity for any uses, including use in other initiatives or component projects making use of other license terms outside of the Innovate for Vegas Foundation. Submissions of creative work and assignment of copyright in no way limits the use by the submitter of their own work in any way, at any time.
Special care must be taken to note, the grant-back license provision applies to contributions by a submitter to the submission, not to the entire entity or its elements to which a submission is contributed. Submission of a patch, grammar edit, or language translation, for examples, does not extend the grant-back license to the original or source elements to which changes where applied and submitted, or to other elements of an entity, but only to the changes. Similarly, the submitter of original sources or entity elements maintains a grant-back license to use those contributions, but does not receive a similar grant-back provision on changes submitted to the original submission by others.
Contributors may opt to be listed in the AUTHORS file for any particular entity repository, which is intended to advertise copyright holders (thus Innovate for Vegas Foundation as well as any contributors with grant-back license, individuals still retain copyrights to contributions as they exist prior to contribution, and retain the grant-back license to the creative work contributed). Additional information is available in the Attribution section in this document.
If copyright to any contribution of creative work cannot or must not be be assigned to Innovate for Vegas Foundation, then a Contributor License Agreement ("CLA") must be provided for permanent and irrevocable license to include such creative works as contributed, in perpetuity.
As with the grant-back license provision, holders of copyright for relevant creative works licensed according to a CLA, are to be listed in an AUTHORS file indicating contributions, copyrights, and CLA references.
Contributors to this repository may be anywhere on a skills/experience spectrum. Teaching and learning are a part of the Innovate for Vegas mission and project development process, and so there may be instances where an incomplete or incorrect repository commit is attempted, a commit must be reversed, perhaps a comment updated, perhaps there was a forgotten file that needs to be added. These things happen. Learn from these and be aware that others may also be learning.
Most source code is typically authored in the development programming language of choice, with variable names, comments, and other documentation created for English-speaking developers (this may also apply to non-code projects, such as documentation, marketing materials, visual cues, audio content, etc). Be aware that some contributors may not speak English as a first language, such that spelling and grammar issues may arise. These are easily edited and are learning opportunities for all.
When possible and practical, entities (software and otherwise) should be designed to be compatible with internationalization and localization (typically i18n and l10n) norms, and should additionally be as compatible as is possible with WAI-ARIA, ADA, and any other relevant accessibility standards and practices.
At any given point in the development of any project component (repository or otherwise), there may be deviations from these ideals. For example, if a translation to a particular language is not available, if internationalization is not completed for an entire project, if WAI-ARIA compliance is not completely implemented, etc. Every effort must be made to move any project in these directions to meet these goals when possible.
When in doubt, check the CODE_OF_CONDUCT document associated with the entity of interest and with Innovate for Vegas in general. When all else fails, be a Good Person.
It is not necessary to join the Innovate for Vegas Foundation or to participate as a member of a team within this organization in order to contribute to Innovate for Vegas Entities. External contributions may be submitted using the standard GitHub Pull Request mechanism, making use of Pull Requests Templates present in a particular Entity Repository and following any requirements and suggestions therein. Pull Requests may be accepted, rejected outright, or returned for additional attention, in an iterative process which may result in acceptance or rejection.
Joining an Entity Team within the Innovate for Vegas organization using the Team features of GitHub.com is optional but encouraged where ongoing contribution and whole team participation is interesting and appealing.
Contributions of time, effort, and expertise on the part of Volunteers is generally welcome and valued. In order to provide a safe and transparent environment for all participants, those volunteers who have not yet attained the age of adulthood (18 years in the United States), shall be allowed with permission and consent from a parent or legal guardian. Contributions and participation will necessarily include some forms of interaction, virtual or in-person, and interaction with online resource, compliance with all relevant laws and regulations is required.
Proposals for new entities (whether completely new Initiatives or Component Projects of existing Initiatives, or other) are welcome from external participants with or without contribution to any Entity, and from any contributors of creative works and any Team members in keeping with the Whole Team structure of Innovate for Vegas Foundation.
The Repository is a collection of entity files, issues, discussions, team groupings, and other meta information about an Initiative, Component Project, or any other effort in the purview of the Innovate for Vegas Foundation and its members and collaborators. In many cases a Repository will hold and track software development efforts, however any Entity may be tracked using Repository tools and methods, aimed at maintaining a history of volunteer contribution and attribution across any type of Entity.
This section of the Contributing document regarding Repository practices is most likely to be altered with addenda or outright change within a particular Entity Repository to align most effectively with the particular Entity, its Teams, and associated goals and paths to reach them.
The global and nearly-universal transition to main as a preferred default branch name over the legacy master is in effect for all Innovate for Vegas Foundation repositories.
A new repository should contain at least a README.md stub (always updatable), with at least a reference to this CONTRIBUTING.md and the CODE_OF_CONDUCT.md via links in that README.md file, if there are not to be overriding versions of these files in the new repository. That is, anyone cloning a repository should be able to locate these two files, whether included in the repo clone, or referenced in the organization special community health file locations. See links in the Project Policies section below.
Each initiative and each team per component project, may choose to follow a particular project management and workflow style that suits the team and the project or project component.
All contribution to any Innovate for Vegas Entity shall follow the Agile for Volunteers methodology and principles introduced in the organization HOWTO documentation and the Agile for Volunteers Initiative.
Unless otherwise and specifically indicated with replacement files in this entity repository, this entity will adhere to the default Innovate for Vegas Foundation policies for Code of Conduct and Contributing, found at
- Code of Conduct - Innovate for Vegas Foundation
- Contributing to this Entity - Innovate for Vegas Foundation
Each Entity is or will be comprised of many Entities and Elements, many contained within repositories, others elsewhere but tracked within repositories. A consistent naming scheme helps to organize all of the Entities withing the InnovateForVegas organization on the GitHub.com platform as the number of Entities grows with time and reach.
The naming scheme in use is documented in the foundation Howto documents at
Always test your code. This is good advice anywhere and everywhere if you are a software developer (or really, if you make things of any kind, try them out and make sure they work).
While each project, each repository, and each team or group of contributors working on any of these may adopt their own Best Practices by experience, practicality, consensus, etc, it is usually best to make a choice and follow through with it, and to inform newcomers of these practices.
By default, software and other entities to the extent his is applicable, will follow Test Driven Development practices and methodologies. There are countless documents, tutorials, demonstrations, and examples in written, audio, and video form.
The bare minimum requirement is that tests be available to verify and validate an entity. While this is typically a software best practice, testing, verifying, and validating any entity, and any changes to entities over time, should be a primary concern and enabled through the design and inclusion of tests to accomplish these.
With distributed teams and schedules, voluntary time commitments and differing timelines, the use of GitFlow to organize code changes, feature changes, and other Pull Requests and Branching and whatnot, is sensible. A functional rhythm within a particular development team on a particular project component may deviate slightly from this workflow, but in order to enable easier on-boarding of new contributors of varying skill levels, the GitFlow workflow baseline is a reasonable standard.
However, GitFlow is not strictly compatible with Continuous Integration and Continuous Delivery/Deployment ideals. Using the typical CI/CD label is not always applicable.
Use of GitHub Actions (for example) to automate
- pre-commit testing as a form of Continuous Integration is reasonable in combination with GitFlow. While not strictly continuous, it comes close.
- something like Continuous Delivery may be of some use in the case of library code or other shared resources, but is still not strictly continuous in the GitFlow context.
- something like Continuous Deployment is unlikely to be useful during active development, especially if a given project or component are released for general use
It is more likely that a CI/CD pipeline will be useful if a project has been released for wider use (private testing, public beta, full public release), to automate releases which address and fix issues and bugs, and which follow a version release cycle.
There has been much written and said about the compatibility of GitFlow (or most branching strategies) with CI/CD practices, there is likely to be discussion about this per project.
Note that because a project may be made up of multiple repositories, not all code repositories on GitHub.com, some care must be taken to construct a monorepo if that is the desired strategy. Use of Git Submodules and Subtrees is one possibility, multi-repo tools in general should be adopted as needed per project.
Since there may be so much variation in different types of projects and project components, best practices and the better judgment of participants and contributors shall take precedence, so long as the best interests of the Innovate for Vegas Foundation and its overarching goals are a guide (for example, enable and encourage others to spend time contributing to projects, not trying to reverse engineer how they are supposed to build and deploy).
Useful commit messages are helpful in the near term, and throughout all time.
We will generally follow the advice found at Conventional Commits and ask the same of all contributors.
Version numbers can be confusing once software is released, especially if there are different versions used for testing, release, etc.
We follow the specifications for Semantic Versioning.
We may also follow the specifications for Zero Versioning where pre-release and very early iterations of any component project warrant this approach. As any component project or initiative as a whole becomes viable for deployment or public release or similar, Semantic Versioning is the baseline scheme to follow.
Unless there is a specific need for coding projects, the basic services available on the GitHub.com platform for issue tracking and discussion can be used. The creation and use of a GitHub Issue Template per project component is left to the project component maintainer(s) to author as needed.
Because many contributors will not be using GitHub.com for their (non-software or other) contributions, and since it is not common for a casual person to even have a GitHub account, other means will be needed and employed where necessary, with project maintainers making best efforts to track issues, bugs, and fixes.
The Innovate for Vegas Foundation believes completely and totally in the notion that contributors of creative works, with as liberal a definition of "creative works" as can be imagined, shall receive attribution for their time, effort, and creativity.
Where applicable, and where contributions are material and where the contributor has rights to contribute their creative work, attribution shall be made anywhere it is reasonable and useful to do so, including, but not limited to, an AUTHORS file within a repository, in project and component documentation, using attribution schemes on GitHub.com and with other similar tools and platforms, in any InnovateForVegas.org website content, any related website content, and elsewhere. This is not an exhaustive nor comprehensive description of accomplishing this intent, rather an indication that this intent is of the utmost priority.
Wherever creative works and attribution can be added to a CV or used to indicate real world experience for the purposes of career development or job placement, the Innovate for Vegas Foundation will always provide references and detail based on all available attribution information. Thus we will ask that contribution of creative works be properly and correctly attributed throughout a project lifecycle.
Note that GitHub (and GitLab, and less specifically but without causing any issues, git itself) supports several ways to attribute participation:
GitHub et al. also support AUTHORS and CONTRIBUTORS files per repository, which enable explicit inclusion of (by convention):
- AUTHORS File Copyright Holders and other legally responsible parties. For example, if you contribute to a project on behalf of a company or other entity, with permission, that company or entity would be listed in the AUTHORS file. Since copyright of the creative works in the Innovate for Vegas Foundation organization on GitHub, and elsewhere, is assigned to Innovate for Vegas Foundation, but individual contributors might retain copyright on their own original contributions outside of the organization project repositories (and elsewhere), Authors may include all or some of CODEOWNERS contributors.
- CONTRIBUTORS File Any and all contributors to a project repository, including testers, collaborators, and any others who directly or indirectly enabled a particular project repository to become more valuable, useful, etc, and who would like attribution (opt-in).
Some may wish to obscure their email address(es), to enable this GitHub provides a noreply email address which may be used in place of a public email address for commit attribution and in other places listed above.
For example, the original author of this file, Dan Hugo, with GitHub username DanHugoDanHugo, could be referred to in commits, AUTHORS, and other places on the GitHub.com platform, as one of
- DanHugoDanHugo [email protected]
- DanHugoDanHugo [email protected]
The former is provided by GitHub to obscure a public email address, the latter is the default GitHub email address for user DanHugoDanHugo.
For more information please visit:
Contribution of creative work to any Innovate for Vegas Initiative, Component Project or any Repository is made without warranty, express or implied. This is in keeping with the nature of the license(s) which apply to the initiatives which the Innovate for Vegas Foundation pursues with its cohort of volunteers, up to and after the release and/or deployment of those initiatives and components of those initiatives.
All participation in any aspect of contribution of creative work, and in the activities surrounding those contributions, whether virtual or in-person gatherings and work sessions, written correspondence, code comments, commit comments, issue reports and comments, project and repository discussions hosted on GitHub.com or elsewhere, or anything attached in any way to the Innovate for Vegas Foundation, shall adhere to the published CODE_OF_CONDUCT, available where you found this CONTRIBUTING document. The default Code of Conduct document for our organization is always available here:
Code of Conduct - Innovate for Vegas Foundation
The Innovate for Vegas Foundation reserves the right to reject submissions and to refuse participation in any case where submissions do not adhere to the requirements stipulated in this document or in this document plus any addenda as applicable to a particular Entity or Element.
The Innovate for Vegas Foundation reserves the right to refuse participation and submissions in any case where an individual or any party violates the Code of Conduct of this organization, or otherwise creates an unsafe environment for anyone participating in any way as part of our organization and its efforts and endeavors.
Further, the Innovate for Vegas Foundation reserves the right to reject any contribution of creative work which does not include an attestation sign-off, or does not comply with copyright assignment policies nor with a current CLA in place with copyright holder(s). This rejection may be temporary until such time as attestation is corrected, copyright assignment is agreed upon, or a CLA applicable to the contribution of a creative work can be implemented.
This original, base CONTRIBUTING document has been composed by and for the Innovate for Vegas Foundation by Dan Hugo.
Please find the revision controlled version of this document with history in the GitHub.com Innovate for Vegas Foundation organization top-level repository at CONTRIBUTING.md.
Any Innovate for Vegas Foundation Entity, including any Initiative or Component Project, may provide Addenda to this document within a local version of a CONTRIBUTING document, which will refer to this original as a basis. The CONTRIBUTING document so amended shall govern contributions to that Entity.
This document is published with Copyright held by the Innovate for Vegas Foundation.
This document is made available under the license of the repository in which is found, and under the Creative Commons Attribution-ShareAlike 4.0 International License (cc-by-sa-4.0), whichever license if most compatible with the use of the document to enable other Initiatives and Organizations.