~jan0sch/smederee

~jan0sch/smederee/CONTRIBUTING.md
 ..

Contribution guide

Please read this guide if you want to contribute to the project.

1. Code of Conduct

Everyone is expected to follow the Contributor Covenant Code of Conduct when discussing the project on the available communication channels. If you are being harassed, please contact us immediately at abuse@smeder.ee so that we can support you.

2. Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

3. Design

3.1 Preliminaries

  1. The project SHALL use the darcs distributed revision control system.
  2. The project SHALL be hosted on Smederee, herein called the "Platform".
  3. The project SHALL use the Platform issue tracker.
  4. The project SHOULD have clearly documented guidelines for code style. The code style is documented in the file CODINGSTYLE in the project root.
  5. A "Contributor" is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem.
  6. A "Maintainer" is a person who merges patches to the project. Maintainers are not developers; their job is to enforce process.
  7. Contributors SHALL NOT have commit access to the repository unless they are also Maintainers.
  8. Maintainers SHALL have commit access to the repository.
  9. Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract.

3.2 Licensing and Ownership

  1. The project SHALL use the AGPL 3.0 or later (see LICENSE).
  2. All contributions to the project source code ("patches") SHALL use the same license as the project.
  3. All patches are owned by their authors. There SHALL NOT be any copyright assignment process. Each Contributor SHALL be responsible for identifying themselves in the project Contributor list which is located in the file AUTHORS in the project root.

3.3 Patch Requirements

  1. Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias.
  2. A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
  3. A patch MUST adhere to the code style guidelines of the project if these are defined.
  4. A patch MUST adhere to the "Evolution of Public Contracts" guidelines defined below.
  5. A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
  6. A patch MUST compile cleanly and pass project self-tests on at least the principal target platform.
  7. A patch commit message MUST consist of a single short (less than 80 characters) line stating the problem being solved, followed by a blank line and then the proposed solution and summary of changes. The description is not limited and may span over multiple paragraphs. Please use proper English syntax, grammar and punctuation and imperative mood e.g. "add visual highlighting" instead of "[This] adds visual highlighting." or "I changed the code rendering to include visual highlighting"
  8. A patch fixing a ticket MUST include a trailing Fixes: line in the commit message that links to the ticket, for example: Fixes: https://tickets.smeder.ee/~jan0sch/smederee/123
  9. A patch fixing a regression of another patch MUST include a trailing Fixes: line referencing the other patch by its hash, for example: Fixes: 0b8e86ad1f6a182433d2f59ebf2d40b9b8931f50
  10. A patch not related to an issue SHOULD include either Reported-by: alias/name <email> or Suggested-by: alias/name <email> markers to give proper credit for people reporting bugs and suggesting features that are themselves not providing patches.
    1. If the aforementioned people did not report/suggest in public form (mailing list, forum) then they MUST be asked for permission before adding the markers.
    2. Reported-by: markers MUST ONLY be used for bugs.
    3. Suggested-by: markers MUST NOT be used for bugs.
  11. A patch MUST NOT update the CHANGELOG file because that might introduce dependencies between unrelated patches due to modification of related lines within the CHANGELOG.
  12. A "Correct Patch" is one that satisfies the above requirements.

More information about the process of reported and suggested marker usage (also called trailers) can be found in the Linux kernel development documentation.

3.4 Development Process

  1. Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
  2. To request changes, a user SHOULD log an issue on the project Platform issue tracker.
  3. The user or Contributor SHOULD write the issue by describing the problem they face or observe.
  4. The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.
  5. Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.
  6. Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.
  7. To work on an issue, a Contributor SHALL branch from the project repository (a darcs branch can be considered a fork in git nomenclature) and then work on their own repository.
  8. To submit a patch, a Contributor SHALL send the patch to the project mailing list.
  9. A Contributor SHALL NOT commit changes directly to the project.
  10. A Contributor MAY directly send a patch without logging a separate issue.
  11. To discuss a patch, people MAY comment on the mailing list using markers (trailers) as described below:
    1. Tested-by: alias/name <email> to indicate that the patch has been successfully applied and tested by the person named (in some environment).
    2. Reviewed-by: alias/name <email> to indicate that the patch has been reviewed and found acceptable.
  12. To accept or reject a patch, a Maintainer SHALL reply on the mailing list and include the Acked-by: alias/name <email> marker upon acceptance of the patch into the main branch.
  13. Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
  14. Maintainers SHALL NOT make value judgements on correct patches.
  15. Maintainers SHALL merge correct patches from other Contributors rapidly.
  16. Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.
  17. The user who created an issue SHOULD close the issue after checking the patch is successful.
  18. Any Contributor who has value judgements on a patch SHOULD express these via their own patches.
  19. Maintainers SHOULD close user issues that are left open without action for an uncomfortable period of time.

More information about the process of marker usage (also called trailers) can be found in the Linux kernel development documentation.

3.5 Branches and Releases

In darcs, each repository is a branch. Therefore what you would consider a fork in other systems like git, is considered a branch in darcs.

  1. The project SHALL have one main branch that always holds the latest in-progress version and SHOULD always build.
  2. To make a stable release a Maintainer SHALL prepare the CHANGELOG file and tag the repository. Stable releases SHALL always be released from the main branch.

TODO: Adjust releases and tagging to having multiple modules inside the mono repository.

3.5.1 Release guide

The release NAME SHALL follow the specification described in the CHANGELOG file e.g. major.minor.patchlevel prefixed with a lower case v, for example: v1.0.3.

Before releasing a new version a Maintainer SHALL update the CHANGELOG file and add the changes which are subject to the release under a section named after the release. The commit message for these changes MUST be titled "Prepare RELEASE NAME" e.g. "Prepare RELEASE v1.2.3"

A release SHALL be accompanied by an annotated tag (darcs tag --edit-long-comment NAME) that holds a description of the changes that are included in the release. This description SHOULD be same as in the CHANGELOG.

Please note that lines starting with a hash (#) are ignored by darcs therefore the sections like Added, Fixed etc. MUST be written in the alternate heading syntax of markdown. Example:

v0.2.0

Added
-----

- a
- b

Fixed
-----

- c
- d

3.6 Evolution of Public Contracts

  1. All Public Contracts (APIs or protocols) SHALL be documented.
  2. All Public Contracts SHOULD have space for extensibility and experimentation.
  3. A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this.
  4. A patch that introduces new features SHOULD do so using new names (a new contract).
  5. New contracts SHOULD be marked as "draft" until they are stable and used by real users.
  6. Old contracts SHOULD be deprecated in a systematic fashion by marking them as "deprecated" and replacing them with new contracts as needed.
  7. When sufficient time has passed, old deprecated contracts SHOULD be removed.
  8. Old names SHALL NOT be reused by new contracts.

3.7 Project Administration

  1. The project founders SHALL act as Administrators to manage the set of project Maintainers.
  2. The Administrators SHALL ensure their own succession over time by promoting the most effective Maintainers.
  3. A new Contributor who makes correct patches, who clearly understands the project goals, and the process SHOULD be invited to become a Maintainer.
  4. Administrators SHOULD remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately.
  5. Administrators SHOULD block or ban "bad actors" who break the code of conduct. This should be done after seeking a discussion. 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.

Sources and License

This Specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, see http://www.gnu.org/licenses.

This contribution guide is based upon the Collective Code Construction Contract (C4.2).