boxtec
/
bitcoin
mirror of https://github.com/bitcoin/bitcoin
4
1
Fork 0
Code Issues Projects Releases Wiki Activity

doc: Minor grammatical changes and flow improvements

Browse Source 
Grammar:

Line 49: There shouldn't be a period at the end of a phrase.

Lines 56, 57, 116, 137, and 177: Adding necessary commas

Lines 103 and 136: Run-on sentence issues fixed. 

Line 176: Fixed punctuation and added necessary conjunction

Line 178: Singular noun when it should be plural

Flow:

Line 49: Adding "for" makes it more natural. 

Line 54: Though it's not grammatically incorrect to end a sentence with a preposition in an informal document such as this, the word "followed" is much easier to understand anyway, especially for those who don't have English as their native language.
pull/18170/head
Travin Keith 5 years ago committed by GitHub
parent 36f42e1bf4
commit 7ba962276e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File

22
CONTRIBUTING.md
Unescape View File

@ -46,15 +46,15 @@ facilitates social contribution, easy testing and peer review.
To contribute a patch, the workflow is as follows: To contribute a patch, the workflow is as follows:
1. Fork repository ([only the first time](https://help.github.com/en/articles/fork-a-repo)). 1. Fork repository ([only for the first time](https://help.github.com/en/articles/fork-a-repo))
1. Create topic branch 1. Create topic branch
1. Commit patches 1. Commit patches
The project coding conventions in the [developer notes](doc/developer-notes.md) The project coding conventions in the [developer notes](doc/developer-notes.md)
must be adhered to. must be followed.
In general [commits should be atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) In general, [commits should be atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention)
and diffs should be easy to read. For this reason do not mix any formatting and diffs should be easy to read. For this reason, do not mix any formatting
fixes or code moves with actual code changes. fixes or code moves with actual code changes.
Commit messages should be verbose by default consisting of a short subject line Commit messages should be verbose by default consisting of a short subject line
@ -100,7 +100,7 @@ Examples:
qt: Add feed bump button qt: Add feed bump button
log: Fix typo in log message log: Fix typo in log message
Note that translations should not be submitted as pull requests, please see Note that translations should not be submitted as pull requests. Please see
[Translation Process](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md) [Translation Process](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md)
for more information on helping with translations. for more information on helping with translations.
@ -113,7 +113,7 @@ patch does together with any justification/reasoning. You should include
references to any discussions (for example other tickets or mailing list references to any discussions (for example other tickets or mailing list
discussions). discussions).
At this stage one should expect comments and review from other contributors. You At this stage, one should expect comments and review from other contributors. You
can add more commits to your pull request by committing them locally and pushing can add more commits to your pull request by committing them locally and pushing
to your fork until you have satisfied all feedback. to your fork until you have satisfied all feedback.
@ -133,8 +133,8 @@ before it will be merged. The basic squashing workflow is shown below.
# Save and quit. # Save and quit.
git push -f # (force push to GitHub) git push -f # (force push to GitHub)
Please update the resulting commit message if needed, it should read as a Please update the resulting commit message if needed. It should read as a
coherent message. In most cases this means that you should not just list the coherent message. In most cases, this means that you should not just list the
interim commits. interim commits.
If you have problems with squashing (or other workflows with `git`), you can If you have problems with squashing (or other workflows with `git`), you can
@ -173,9 +173,9 @@ in the future, they may be removed by the Repository Maintainer.
Refactoring is a necessary part of any software project's evolution. The Refactoring is a necessary part of any software project's evolution. The
following guidelines cover refactoring pull requests for the project. following guidelines cover refactoring pull requests for the project.
There are three categories of refactoring, code only moves, code style fixes, There are three categories of refactoring: code-only moves, code style fixes, and
code refactoring. In general refactoring pull requests should not mix these code refactoring. In general, refactoring pull requests should not mix these
three kinds of activity in order to make refactoring pull requests easy to three kinds of activities in order to make refactoring pull requests easy to
review and uncontroversial. In all cases, refactoring PRs must not change the review and uncontroversial. In all cases, refactoring PRs must not change the
behaviour of code within the pull request (bugs must be preserved as is). behaviour of code within the pull request (bugs must be preserved as is).

Write Preview
Loading…
Cancel
Save