quantus/api
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

DOCS: Fix formatting (#468)

Browse Source
This commit is contained in:
Stefanie Doll
2018-12-14 11:46:51 +01:00
committed by Amaury Martiny
parent e99f17c22c
commit f4d52baa1d
1 changed files with 17 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/CONTRIBUTING.md
+17 -18
View File
@@ -9,29 +9,28 @@ A project is more like an open wiki than a standard guarded open source project.
There are a few basic ground-rules for contributors (including the maintainer(s) of the project):
. **No `--force` pushes** or modifying the Git history in any way. If you need to rebase, ensure you do it in your own repo.
. **Non-master branches**, prefixed with a short name moniker (e.g. `<initials>-<feature>`) must be used for ongoing work.
. **All modifications** must be made in a **pull-request** to solicit feedback from other contributors.
. A pull-request *must not be merged until CI* has finished successfully.
1. **No `--force` pushes** or modifying the Git history in any way. If you need to rebase, ensure you do it in your own repo.
2. **Non-master branches**, prefixed with a short name moniker (e.g. `<initials>-<feature>`) must be used for ongoing work.
3. **All modifications** must be made in a **pull-request** to solicit feedback from other contributors.
4. A pull-request *must not be merged until CI* has finished successfully.
Merging pull requests once CI is successful:
#### Merging pull requests once CI is successful:
- A pull request with no large change to logic that is an urgent fix may be merged after a non-author contributor has reviewed it well.
- No PR should be merged until all reviews' comments are addressed.
. A pull request with no large change to logic that is an urgent fix may be merged after a non-author contributor has reviewed it well.
. No PR should be merged until all reviews' comments are addressed.
.Reviewing pull requests:
#### Reviewing pull requests:
When reviewing a pull request, the end-goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:
. Buggy behaviour.
. Undue maintenance burden.
. Breaking with house coding style.
. Pessimisation (i.e. reduction of speed as measured in the projects benchmarks).
. Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
. Uselessness (i.e. it does not strictly add a feature or fix a known issue).
- Buggy behaviour.
- Undue maintenance burden.
- Breaking with house coding style.
- Pessimisation (i.e. reduction of speed as measured in the projects benchmarks).
- Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
- Uselessness (i.e. it does not strictly add a feature or fix a known issue).
.Reviews may not be used as an effective veto for a PR because:
. There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.
. It does not fit well with some other contributors' longer-term vision for the project.
#### Reviews may not be used as an effective veto for a PR because:
- There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.
- It does not fit well with some other contributors' longer-term vision for the project.
## Releases