Contributions to this project can be made using pull requests to this GitHub repository:

https://github.com/guildai/tensorflow-patterns

For more information on creating pull requests see About pull requests on GitHub help.

This contribution policy has been adapted from C4.1 - Collective Code Construction Contract to meet the needs of this project.

Goals

The goals of this contribution policy are:

  • To maximize the scale of the community around the project by reducing the friction for new contributors

  • To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain

  • To support diversity of the contributions to the project

  • To enforce collective ownership of the project

Design

Preliminaries

  • This project uses the git distributed revision control system.

  • This project is hosted on GitHub.

  • This project uses the project issue tracker on GitHub to record all issues.

  • A Maintainer is a person who merges patches to the project. Maintainers are not developers – their job is to enforce process.

  • Maintainers have commit access to the repository.

  • A Contributor is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem.

  • Contributors don’t have commit access to the repository unless they are also Maintainers.

  • Everyone without distinction or discrimination has an equal right to become a Contributor under the terms of this policy.

Licensing and Ownership

  • The project uses the Creative Commons Attribution 4.0 International license.

  • All contributions to the project source code (“patches”) use the same license as the project.

  • All patches are owned by their authors. There is no copyright assignment process.

  • The copyrights in the project are owned collectively by all its Contributors.

  • Each Contributor is be responsible for identifying themselves in the project Contributor list.

Patch Requirements

  • Maintainers and Contributors must have a GitHub account and should use their real names or a well-known alias.

  • A patch should adhere to the project methodology.

  • A patch must not include non-trivial code from other projects unless the Contributor is the original author of that code.

  • A patch commit message should consist of a single short (less than 50 character) line summarizing the change, optionally followed by a blank line and then a more thorough description.

  • A Correct Patch is one that satisfies the above requirements.

Development Process

  • To request changes, a user should log an issue on the project GitHub issue tracker.

  • The user or Contributor should write the issue by describing the problem they face or observe.

  • The user or Contributor should seek consensus on the accuracy of their observation, and the value of solving the problem.

  • Thus, the release history of the project should be a list of meaningful issues logged and solved.

  • To work on an issue, a Contributor must fork the project repository and work on their forked repository.

  • To submit a patch, a Contributor must create a GitHub pull request back to the project.

  • A Contributor may directly send a pull request without logging a separate issue.

  • To discuss a patch, people may comment on the GitHub pull request, on the commit, or elsewhere.

  • To accept or reject a patch, a Maintainer must use the GitHub interface.

  • Maintainers must merge correct patches from other Contributors rapidly.

  • The user who created an issue should close the issue after checking the patch is successful.

  • Maintainers should ask for improvements to incorrect patches and should reject incorrect patches if the Contributor does not respond constructively.

  • Any Contributor who has value judgments on a correct patch should express these via their own patches.

Project Administration

  • The project founders should act as Administrators to manage the set of project Maintainers.

  • A new Contributor who makes a correct patch should be invited to become a Maintainer.

  • Administrators may remove Maintainers who are inactive for an extended period of time or who repeatedly fail to apply this process.

  • Administrators should block or ban “bad actors” who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others.

Contributors