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

More markdown formatting

Browse Source
This commit is contained in:
sliptonic
2022-10-26 10:48:13 -05:00
committed by WandererFan
parent 3022eb3a37
commit 2cacd85047
1 changed files with 73 additions and 73 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
CONTRIBUTING.md
View File

@@ -5,11 +5,11 @@ FreeCAD's contribution process is inspired by the Collective Code Construction C
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.
0. Status
## 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
## 1. Goals
The FreeCAD Contribution Process is expressed here with the following specific goals in mind:
@@ -21,7 +21,7 @@ FreeCAD is in a transition period. The following are to be regarded as GUIDELINE
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
## 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'.
@@ -30,20 +30,20 @@ FreeCAD is in a transition period. The following are to be regarded as GUIDELINE
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
## 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 Contributors. 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
## 4. Licensing, Ownership, and Credit
1. FreeCAD is distributed under the Lesser General Public License, version 2, or superior (LGPL2+). Additional details can be found in the LICENSE file.
2. All contributions to FreeCAD MUST use a compatible license.
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
## 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.
@@ -57,7 +57,7 @@ FreeCAD is in a transition period. The following are to be regarded as GUIDELINE
10. The PR message MUST consist of a single short line, the PR Title, summarizing the problem being solved, followed by a blank line and then the proposed solution in the Body. If a PR consits of more than one commit, the PR Title MUST succinctly explain what the PR achieves. The Body MAY be as detailed as needed.
11. A “Valid PR” is one which satisfies the above requirements.
6. Process
## 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.
@@ -70,26 +70,26 @@ FreeCAD is in a transition period. The following are to be regarded as GUIDELINE
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.
1. in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
2. 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) end fruitless discussions
- (b) capture toxic patches in the historical record
- (c) engage with the Contributor on improving their patch quality.
1. end fruitless discussions
2. capture toxic patches in the historical record
3. engage 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 unreasonable period.
7. Branches and Releases
## 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
## 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.