message: Rework CONTRIBUTING (render-only)
diff: @@ -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
  @@ -43,4 +42,4 @@ This is an experiment and feedback is welcome! This document may also be subject
  ## Heritage
  -These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project: https://github.com/Level/community/blob/master/CONTRIBUTING.md
  +These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project: [https://github.com/Level/community/blob/master/CONTRIBUTING.md](https://github.com/Level/community/blob/master/CONTRIBUTING.md)
  