tyler.durden
/
notepad-plus-plus
mirror of https://github.com/notepad-plus-plus/notepad-plus-plus.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update CONTRIBUTING.md 

Add info for PR regarding Function List parser.
This commit is contained in:
Don HO 2024-02-03 15:03:12 +01:00 committed by GitHub
parent bf65ba5329
commit 85af8d566d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
CONTRIBUTING.md
View File

@ -30,10 +30,11 @@ Opening an issue beforehand allows the administrators and the community to discu
5. Make your modification compact - don't reformat source code in your request. It makes code review more difficult.
6. PR of reformatting (changing of ws/TAB, line endings or coding style) of source code won't be accepted. Use issue trackers for your request instead.
7. Typo fixing and code refactoring won't be accepted - please create issues with title started with `TYPO` to request the changing.
8. Address the review change requests by pushing new commits to the same PR. Avoid amending a commit and then force pushing it. All the PR commits are squashed before merging to the main branch.
9. When creating new PR, try to base it on latest master.
10. Don't merge `upstream/master` (using git or via github sync), if your PR is based on older `upstream/master`. If you need to base it on latest `master` (e.g. to check and fix merge conflict), use commands `git fetch upstream` to get latest `master` and then `git rebase upstream/master` to rebase it onto this latest `upstream/master`.
11. Finally, please test your pull requests, at least once.
8. The PR for the enhancement of Function List parser, should also include unit test. Please refer [here](https://npp-user-manual.org/docs/function-list/#contribute-your-new-or-enhanced-parser-rule-to-the-notepad-codebase) for more information.
9. Address the review change requests by pushing new commits to the same PR. Avoid amending a commit and then force pushing it. All the PR commits are squashed before merging to the main branch.
10. When creating new PR, try to base it on latest master.
11. Don't merge `upstream/master` (using git or via github sync), if your PR is based on older `upstream/master`. If you need to base it on latest `master` (e.g. to check and fix merge conflict), use commands `git fetch upstream` to get latest `master` and then `git rebase upstream/master` to rebase it onto this latest `upstream/master`.
12. Finally, please test your pull requests, at least once.
In short: The easier the code review is, the better the chance your pull request will get accepted.