diff options
Diffstat (limited to 'docs/CONTRIBUTE.md')
| -rw-r--r-- | docs/CONTRIBUTE.md | 26 |
1 files changed, 13 insertions, 13 deletions
diff --git a/docs/CONTRIBUTE.md b/docs/CONTRIBUTE.md index b0b0f6ccd..07234f5a9 100644 --- a/docs/CONTRIBUTE.md +++ b/docs/CONTRIBUTE.md @@ -83,14 +83,14 @@ It is annoying when you get a huge patch from someone that is said to fix 511 odd problems, but discussions and opinions don't agree with 510 of them - or 509 of them were already fixed in a different way. Then the person merging this change needs to extract the single interesting patch from somewhere -within the huge pile of source, and that gives a lot of extra work. +within the huge pile of source, and that creates a lot of extra work. -Preferably, each fix that correct a problem should be in its own patch/commit +Preferably, each fix that corrects a problem should be in its own patch/commit with its own description/commit message stating exactly what they correct so that all changes can be selectively applied by the maintainer or other interested parties. -Also, separate changes enable bisecting much better when we track problems +Also, separate changes enable bisecting much better for tracking problems and regression in the future. ### Patch Against Recent Sources @@ -103,9 +103,9 @@ release archive is quite OK as well! ### Documentation Writing docs is dead boring and one of the big problems with many open source -projects. Someone's gotta do it. It makes it a lot easier if you submit a -small description of your fix or your new features with every contribution so -that it can be swiftly added to the package documentation. +projects. But someone's gotta do it! It makes things a lot easier if you +submit a small description of your fix or your new features with every +contribution so that it can be swiftly added to the package documentation. The documentation is always made in man pages (nroff formatted) or plain ASCII files. All HTML files on the web site and in the release archives are @@ -134,9 +134,9 @@ patch to [the curl-library mailing list](https://curl.haxx.se/mail/list.cgi?list=curl-library). Either way, your change will be reviewed and discussed there and you will be -expected to correct flaws pointed out and update accordingly, or the change -risk stalling and eventually just get deleted without action. As a submitter -of a change, you are the owner of that change until it has been merged. +expected to correct flaws pointed out and update accordingly, or the change +risks stalling and eventually just getting deleted without action. As a +submitter of a change, you are the owner of that change until it has been merged. Respond on the list or on github about the change and answer questions and/or fix nits/flaws. This is very important. We will take lack of replies as a @@ -151,14 +151,14 @@ changes merged. We prefer pull requests to mailed patches, as it makes it a proper git commit that is easy to merge and they are easy to track and not that easy to loose -in a flood of many emails, like they sometimes do on the mailing lists. +in the flood of many emails, like they sometimes do on the mailing lists. When you adjust your pull requests after review, consider squashing the commits so that we can review the full updated version more easily. ### Making quality patches -Make the patch against as recent sources as possible. +Make the patch against as recent source versions as possible. If you've followed the tips in this document and your patch still hasn't been incorporated or responded to after some weeks, consider resubmitting it to @@ -204,8 +204,8 @@ local repository: git commit [file] -As usual, group your commits so that you commit all changes that at once that -constitutes a logical change. +As usual, group your commits so that you commit all changes at once that +constitute a logical change. Once you have done all your commits and you're happy with what you see, you can make patches out of your changes that are suitable for mailing: |