kindred/create
1
1
Fork 0
Code Issues 53 Pull Requests Actions Packages Projects 9 Releases 2 Wiki Activity

first draft of a process for formalizing the contribution process.

Browse Source
This commit is contained in:
sliptonic
2022-10-24 10:26:35 -05:00
committed by WandererFan
parent ec3a1838ca
commit 1e024f888d
1 changed files with 98 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

98
CONTRIBUTING.txt Normal file
View File

@@ -0,0 +1,98 @@
FreeCAD Contribution Process (FCP)
==================================
FreeCAD's contribution process is inspired by the Collective Code Construction Contract which itself is an evolution of the github.com Fork and Pull Model.
0. Status
FreeCAD is in a transition period. The following are to be regarded as GUIDELINES for contribution submission and acceptance. For historical reasons, the actual process may diverge from this process during the transition. Such deviations should be noted and discussed whenever possible.
1. Goals
The FreeCAD Contribution Process is expressed here with the following specific goals in mind:
1. To provide transparency and fairness in the contribution process.
2. To allow useful contributions to be included as quickly as possible.
3. To preserve and improve the code quality while encouraging appropriate experimentation and risk-taking
4. To minimize dependence on individual contributors by encouraging a large pool of active contributors
5. To be inclusive of many viewpoints and to harness a diverse set of skills
6. To provide an encouraging environment where contributors learn and improve their skills
7. To protect the free and open nature of the FreeCAD project
2. Fundamentals
1. FreeCAD uses the git distributed revision control system.
2. Source code for the main application and related subprojects is hosted on github.com in the FreeCAD organization, hereafter referred to as 'the platform'.
3. Problems are discrete, well-defined limitations or bugs.
4. FreeCAD uses the platform's issue-tracking system to track problems
5. Patches are sets of code changes that resolve a single problem
6. FreeCAD uses the Pull Request workflow for evaluating and accepting patches
3. Roles
1. "User": An member of the wider FreeCAD community who uses the software.
2. "Contributor": A person who submits a patch that resolves a previously identified problem. Contributors do not have commit access to the repository unless they are also maintainers. Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor
3. "Maintainer": A person who merges patches. Maintainers may or may not be developers. Their role is to enforce the process. Maintainers have commit access to the repository.
4. "Administrator": Administrators have additional authority to maintain the list of designated maintainers.
4. Licensing, Ownership, and Credit
1. FreeCAD uses the Lesser General Public License, version 2, or superior (LGPL2+) for all source code. Additional details can be found in the LICENSE file.
2. All contributions to FreeCAD SHALL use the same license as the project.
3. All contributions are owned by their authors unless assigned to another.
4. FreeCAD does not have a mandatory copyright assignment policy.
5. A Contributor who wishes to be identified in the Credits section of the application "About" dialog is responsible for identifying themselves appropriately by notifying an administrator or maintainer.
5. Contribution Requirements
1. Patches are submitted in the form of Pull Requests (PR)
2. Maintainers and Contributors MUST have a platform account and SHOULD use their real names or a well-known alias. If the platform alias differs from the account alias on the FreeCAD Forum, effort SHOULD be taken to avoid confusion.
3. A PR SHOULD be a minimal and accurate answer to exactly one identified and agreed-on problem.
4. A PR SHOULD refrain from adding additional dependencies to the FreeCAD project unless no other option is available.
5. Code submissions MUST adhere to the code style guidelines of the project if these are defined.
6. If a PR contains multiple commits, each commit MUST compile cleanly and add value to the history of the project. Checkpoint commits should be squashed.
7. A PR SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
8. A PR MUST compile cleanly and pass project self-tests on all target platforms.
9. Each commit message in a PR MUST succinctly explain what the commit achieves.
10. The PR Description MUST consist of a single short (less than 50 characters) line stating the problem (“Problem: …") being solved, followed by a blank line and then the proposed solution (“Solution: …").
11. A “Valid PR” is one which satisfies the above requirements.
6. Process
1. Change on the project follows the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
2. To request changes, a user (end user, contributor, maintainer, or administrator) logs 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. Links to the forum or other resources are permitted but the issue should be complete and accurate and should not require the reader to visit the forum or any other platform to understand what is being described.
4. Issues should strive to describe the minimum acceptable condition.
5. Issues should focus on user tasks and avoid comparisons to other software solutions.
6. The user or Contributor SHOULD seek consensus on the accuracy of their observation and the value of solving the problem.
7. To submit a solution to a problem, a Contributor SHALL create a pull request back to the project.
8. Contributors and Maintainers SHALL NOT commit changes directly to the target branch.
9. To discuss a proposed solution, users MAY comment on the platform pull request. Forum conversations regarding the solution should be discouraged and conversation redirected to the Pull Request or the related issue.
10. To accept or reject a Pull Request, a Maintainer SHALL use the platform interface.
11. Maintainers SHOULD NOT merge their own PRs except:
- in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
- If the maintainer is also the primary developer of the workbench or subsystem.
12. Maintainers SHALL merge valid PRs from other Contributors rapidly.
13. Maintainers MAY, at their discretion merge PRs that have not met all criteria to be considered valid to:
- (a) ending fruitless discussions
- (b) capturing toxic patches in the historical record
- (c) engaging with the Contributor on improving their patch quality.
14. Maintainers SHALL NOT make value judgments on correct patches.
15. Any Contributor who has value judgments on a PR SHOULD express these via their own PR.
16. The user who created an issue SHOULD close the issue after checking the PR is successful.
17. Maintainers SHOULD close user issues that are left open without action or update for an uncomfortable period.
7. Branches and Releases
1. The project SHALL have one branch (“master”) that always holds the latest in-progress version and SHOULD always build.
2. The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.
3. To make a stable release a Maintainer shall tag the repository. Stable releases SHALL always be released from the repository master.
8. Project Administration
1. The project administrators will manage the set of project Maintainers. They SHALL maintain a sufficiently large pool of maintainers to ensure their succession and permit timely review of contributions.
2. A new Contributor who has had more than one PR accepted and who clearly understands the project goals and this process SHOULD be invited to become a Maintainer.
3. Administrators SHOULD remove Maintainers who are inactive for an extended period, or who repeatedly fail to apply this process accurately.
4. The list of Maintainers SHALL be publicly accessible and reflective of current activity on the project.
5. Administrators SHOULD block or ban “bad actors” who cause stress, animosity, or confusion 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, who is offensive, and who is unable to self-correct their behavior when asked to do so by others.