...

<to be described :  possible link we can use: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request>

PR Coding Best Practices

When submitting a PR keep in mind these principles:

Contribution Guidelines

1. All commits must include the authors full name and email address
2. All commits must contain a meaningful commit message.
   
   1. A meaningful commit message holds in the first line a summary of the commit and in the body (beginning on the third-line) an explanation what was changed and why it was done.
   2. Remember that the future this commit message is most probably the only source of information why a change was committed to the code base.
3. If the commit fixes a reported issue, the summary line should hold the issue number and title "[NETBEANS-XXX] Maven pom.xml file corrupted after inserting dependecies" for example.
4. A Pull Request can consist of multiple commits. These commits should group the changes into meaningful entities. Fixup commits should be squashed into the base commit they fix.
5. For contributors: Be prepared to be asked questions about your PR.
   
   1. A reviewer might have questions and you should be able to answer why you did a fix in a certain way and why it is save and appropriate.
   2. Remember that the review sometimes takes as long, as creating a patch in the first place.
   3. Good commit messages help as they anticipate questions.
6. For reviewers: Keep in mind that the contributor wants to fix a problem and put effort into it. So be polite and focused.
7. Don't change code, that is correct and works.
   
   1. Consider a simple loop. In many cases you can switch between for-loop, for-each-loop and stream construct. All are valid solution, don't change the code if it is not broken.
   2. An improvement is a different case. For example a try-with-resource construct is in general more correct, than the try-finally construct many developers fail to implement correctly.
   3. Constructs leading to warnings from the javac are also good candidates for simple fixes.
8. Run unittests and, if you introduce new feature/fixes, add unittests. So before you start your work, check that unittests for the module you are working on run correctly and after you are done still do. If unittests fail, fixing these would be good addition to the codebase (it would be good to use a separate commit for this)
9. Keep your PRs up-to-date. When the PR can't be merged directly, it can happen, that changes are introduced into the codebase, that conflict with your PR, you should then update it accordingly.
10. Follow the coding conventions of the file. Your code should match that style and not stand out. For new files, please follow the code conventions for the netbeans code base: https://netbeans.org/communi ty/guidelines/code-conventions.html
11. Try
12. Please submit an issue to JIRA (https://issues.apache.org/jira/projects/NETBEANS/summary) explaining your setup (platform, tc.), why your PR is needed and a case to reproduce, if possible.
13. In the code, try to be concise and right to the point. Just modify whatever needs to be modified to solve the issue at hand.If your code is complex: submit a unit test as well.
14.  add comments for the most complex parts.
15. Try to keep the code readable, maintainable, easy to debug and performant.
16. When submitting a PR start your commit message with NETBEANS-XYZ, where XYZ is the issue number. By doing so your PR will be automatically associated to the JIRA issue.
17. After submitting a PR, NetBeans committers will review it for approval before being finally merged. This may take some time, so please be patient.

Streaming API considerations

...