From f4d52baa1de027be7ff454bbb920c85ce677a60a Mon Sep 17 00:00:00 2001 From: Stefanie Doll Date: Fri, 14 Dec 2018 11:46:51 +0100 Subject: [PATCH] DOCS: Fix formatting (#468) --- docs/CONTRIBUTING.md | 35 +++++++++++++++++------------------ 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 3df749e6f2..b1290606b2 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -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. `-`) 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. `-`) 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