From 4dfbb33c40e511dbdab053916e31ab70fca2e47e Mon Sep 17 00:00:00 2001 From: Jeroen Ticheler Date: Wed, 17 Jan 2024 22:27:33 +0100 Subject: [PATCH] Update CONTRIBUTING.md Minor text edits --- CONTRIBUTING.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b1b4cc4fc5c..1bff3df03f5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,31 +1,31 @@ # Contributing -Thank you for contributing to GeoNetwork: +Thank you for contributing to GeoNetwork! * Free-software: GeoNetwork is free-software, using the [GNU GENERAL PUBLIC LICENSE](LICENSE.md). Contributions provided by you, or your employer, are required to be compatible with this free-software license. * Pull-request: GeoNetwork uses a pull-request workflow to review and accept changes. Pull-requests must be submitted against the *main* branch first, and may be back ported as required. # Pull requests -* Pull request is required, even if you have commit access, so the tests are run and other developer can check your code. +* Pull request is required, even if you have commit access, so the tests are run and another developer can check your code. * Pull requests must be applied to `main`, before being backported. -* Before merging a pull request, should be defined the following properties: +* Before merging a pull request, the following properties should be defined: - Milestone to include the change. - - Add the label `changelog` when the change is relevant to be added to the release changelog file. - - Add `backport ` to indicate when change is a bug fix or is a small improvement that may be relevant to the backport. + - Add the label `changelog` when the change is relevant to be added to the release changelog file. + - Add `backport ` to indicate when the change is a bug fix or when it is a small improvement that is relevant to be backported. -* Good housekeeping: Anytime you commit, try and clean the code around it to latest style guide. If you improve a function without comments: add comments. If you modify functionality that does not have tests: write a test. If you fix functionality without documentation: add documentation. +* Good housekeeping: Anytime you commit, try and clean the code around it according to the latest style guide. If you improve a function without comments: _add comments!!_ If you modify functionality that does not have tests: _write a test!!_ If you fix functionality without documentation: _add documentation!!_ -* History: Clean commit messages and history: avoid big commits with hundreds of files, break commits up into understandable chunks, longer verbose commit messages are encouraged. Avoid reformatting and needless whitespace changes. +* History: Clean commit messages and history. Avoid big commits with hundreds of files, break commits up into understandable chunks. Longer, verbose commit messages are encouraged. Avoid reformatting and needless whitespace changes. -* Draft: Use pull request *Draft** (or even the text "WIP") to identify work in progress. +* Draft: Use pull request **Draft** (or even the text "WIP") to identify _Work In Progress_. -* Rebase / Squash and merge: No merge commits with current branch, use Rebase or Squash and merge! +* Rebase / Squash and merge: Do not merge commits with the current branch, use Rebase or Squash and merge! -* API Change: Please identify any API change or behavior changes in commit messages. Also make sure that a [process for deprecation](PROCESS_FOR_DEPRECATION.md) of a feature is carefully dealt with. +* API Changes: Please identify any API change or behavior changes in commit messages. Also make sure that a [process for deprecation](PROCESS_FOR_DEPRECATION.md) of a feature is carefully dealt with. * Review: Review is required by another person, or more than one! Don't be shy asking for help or reviewing.