aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEvan Klitzke <evan@eklitzke.org>2017-08-07 14:24:17 -0700
committerEvan Klitzke <evan@eklitzke.org>2017-08-08 13:42:13 -0700
commit13b1e9a1625b320b8e32360e1b4d9f3e1216ad25 (patch)
tree0fbb9d7ee7073e5981a441ddb4e22cf9b36c4b8c
parent2507fd55568b361080e9127f40584af2df64f76e (diff)
downloadbitcoin-13b1e9a1625b320b8e32360e1b4d9f3e1216ad25.tar.xz
Capitalize bullet points in CONTRIBUTING guide
English grammar dictates that these bullet points should be capitalized. This also makes the capitalization style consistent with the rest of the document, e.g. the "Decision Making Process" section.
-rw-r--r--CONTRIBUTING.md12
-rw-r--r--test/functional/README.md2
2 files changed, 7 insertions, 7 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index f5d63517b1..4e67af6278 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -170,13 +170,13 @@ judge the general consensus of contributors.
In general, all pull requests must:
- - have a clear use case, fix a demonstrable bug or serve the greater good of
+ - Have a clear use case, fix a demonstrable bug or serve the greater good of
the project (for example refactoring for modularisation);
- - be well peer reviewed;
- - have unit tests and functional tests where appropriate;
- - follow code style guidelines;
- - not break the existing test suite;
- - where bugs are fixed, where possible, there should be unit tests
+ - Be well peer reviewed;
+ - Have unit tests and functional tests where appropriate;
+ - Follow code style guidelines;
+ - Not break the existing test suite;
+ - Where bugs are fixed, where possible, there should be unit tests
demonstrating the bug and also proving the fix. This helps prevent regression.
Patches that change Bitcoin consensus rules are considerably more involved than
diff --git a/test/functional/README.md b/test/functional/README.md
index 96fe0becce..44efda33d3 100644
--- a/test/functional/README.md
+++ b/test/functional/README.md
@@ -90,7 +90,7 @@ on nodes 2 and up.
- Implement a (generator) function called `get_tests()` which yields `TestInstance`s.
Each `TestInstance` consists of:
- - a list of `[object, outcome, hash]` entries
+ - A list of `[object, outcome, hash]` entries
* `object` is a `CBlock`, `CTransaction`, or
`CBlockHeader`. `CBlock`'s and `CTransaction`'s are tested for
acceptance. `CBlockHeader`s can be used so that the test runner can deliver