From acc95a705cc1321f22b5994f78eba3149942f2ee Mon Sep 17 00:00:00 2001 From: Diego Ruiz <12065321+d-ruiz@users.noreply.github.com> Date: Tue, 13 Sep 2022 14:12:37 +0200 Subject: [PATCH] Create PULL_REQUEST_CHECKLIST.md (#1482) * Create PULL_REQUEST_CHECKLIST.md * Update PULL_REQUEST_CHECKLIST.md * Update PULL_REQUEST_CHECKLIST.md Co-authored-by: Carlos Ruiz --- PULL_REQUEST_CHECKLIST.md | 40 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 PULL_REQUEST_CHECKLIST.md diff --git a/PULL_REQUEST_CHECKLIST.md b/PULL_REQUEST_CHECKLIST.md new file mode 100644 index 0000000000..73d9992942 --- /dev/null +++ b/PULL_REQUEST_CHECKLIST.md @@ -0,0 +1,40 @@ +# Pull Request Checklist + +## Follow the project code guidelines. + +Please read carefully the [Contributing to Core](https://wiki.idempiere.org/en/Contributing_to_Trunk) guidelines before starting the development. + +This is a list of the common issues, standards and guidelines when contributing to iDempiere's core. Following all the recommendations will make the merging process smoother for everyone involved. + +## Description + +Please ensure that information in JIRA is sufficient, it must contain a natural language description of the changes proposed, when relevant is important to add information about how to test and the possible collateral effects that the ticket can impact. + +Please include here the link to the corresponding JIRA ticket in the description, this helps with navigating back and forth between JIRA and GitHub. + +## Run the unit tests. + +* Make sure the changes you want to commit pass all the core unit tests. +* If the new code does not pass a unit test because the unit test was wrong, fix the unit test in the same pull request. +* If you're adding something new, please add the corresponding unit test. + +You can learn more about unit tests in iDempiere with this [video](https://www.youtube.com/watch?v=bO71gw3is5I). + +## Checklist: + +- [ ] My code follows the code guidelines of this project +- [ ] My code follows the best practices of this project +- [ ] I have performed a self-review of my own code +- [ ] My code is easy to understand and review. +- [ ] In hard-to-understand areas, I have commented my code. +- [ ] My changes generate no new warnings +- [ ] New and existing unit tests pass locally with my changes +- [ ] I have added unit tests that prove my fix is effective or that my feature works +- [ ] Any dependent changes have been merged and published in downstream modules +- [ ] I have checked my code and corrected any misspellings +- [ ] I have made corresponding changes to the documentation as follows: +- - [ ] New feature (non-breaking change which adds functionality): I have created the New Feature page in the project wiki explaining the functionality and how to use it. If relevant, I have committed sample data to the core seed to have usable examples in GardenWorld. +- - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected): I have documented the change in a clear way that everyone in the community can understand the impact of the change. +- - [ ] Improvement (improves and existing functionality): This documentation is needed if the improvement changes the way the user interacts with the system or the outcome of a process/task changes. If it is just, for instance, a performance improvement, documentation might not be needed. +- [ ] The changed/added documentation is in the project wiki (not privately-hosted pdf files or links pointing to a company website) and is complete and self-explanatory. +