Page History

...

1. Fork the Github repository at if at https://github.com/apache/incubator-mxnet if you haven’t already
2. Clone your fork, create a new branch, push commits to the branch.
3. Coding and Documenting
   1. Consider whether documentation or tests need to be added or updated as part of the change, and add them as needed.
   Run all tests with ./dev/run-tests to verify that the code still compiles, passes tests, and passes style checks. If style checks fail, review the Code Style Guide below
   2. When adding new APIs or modifying existing APIs:
      

      1. Make sure to add/update appropriate API documentation.

      2. If adding a new API, include in the API documentation sample code that shows how to use the API.

      3. If modifying an existing API, make sure that API documentation and code samples are still accurate after your changes.

4. Open a pull request against the master branch of apache/sparkmxnet. (Only in special cases would the PR be opened against other branches.)
   
   1. The PR title should be of the form [SPARKMXNET-xxxx][COMPONENT] Title, where SPARKMXNET-xxxx is the relevant JIRA number,  COMPONENT is one of the PR categories shown at spark-prs.appspot.com and Title title may be the JIRA’s title or a more specific title describing the PR itself.
   2. If the pull request is still a work in progress, and so is not ready to be merged, but needs to be pushed to Github to facilitate review, then add [WIP] after the component.
   3. Consider identifying committers or other contributors who have worked on the code being changed. Find the file(s) in Github and click “Blame” to see a line-by-line annotation of who changed the code last. You can add @username in the PR description to ping them immediately.
   4. Please state that the contribution is your original work and that you license the work to the project under the project’s open source license.
5. The related JIRA, if any, will be marked as “In Progress” and your pull request will automatically be linked to it. There is no need to be the Assignee of the related JIRA to work on it, though you are welcome to comment that you have begun work.
6. The Jenkins automatic pull request builder will test your changes
8. If it is your first contribution, Jenkins will wait for confirmation before building your code and post “Can one of the admins verify this patch?”
9. A committer can authorize testing with a comment like “ok to test”
10. A committer can automatically allow future pull requests from a contributor to be tested with a comment like “Jenkins, add to whitelist”
After about 2 hours, Jenkins will post Jenkins will update the results of the test to in the pull request, along with a link to the full results on Jenkins.
11. Watch for the results, and investigate and fix failures promptly
    1. Fixes can simply be pushed to the same branch from which you opened your pull request
    2. Jenkins will automatically re-test when new commits are pushed
    3. If the tests failed for reasons unrelated to the change (e.g. Jenkins outage), then a committer can request a re-test with “Jenkins, retest this please”. Ask if you need a test restarted. If you were added by “Jenkins, add to whitelist” from a committer before, you can also request the re-test.
12. If there is a change related to SparkR in your pull request, AppVeyor will be triggered automatically to test SparkR on Windows, which takes roughly an hour. Similarly to the steps above, fix failures and push new commits which will request the re-test in AppVeyor.

13.  

14.  

15. As a good start 

16. When working on a large project, try to break down contributions into small logical blocks that can go into separate PRs and therefore can be merged incrementally. Avoid creating a single large PR with a huge number of changes.

17. Include an appropriate title and description for your PR. Include links to github issues that are pertinent to this PR. Use the description to inform the reviewer of any details that may be hard to infer just from looking at the code diff.

18. When adding new APIs or modifying existing APIs:

    1. Make sure to add/update appropriate API documentation.

    2. If adding a new API, include in the API documentation sample code that shows how to use the API.

    If modifying an existing API, make sure that API documentation and code samples are still accurate after your changes.
    3. are supposed to ping the dev mail list about the outage or file a JIRA regarding the flaky test
19. Changes that add new functionality or extend existing functionality should always be accompanied by unit tests that exercise that functionality.

20. When updating code that is performance sensitive, include in the PR description details on how you tested your changes from a performance standpoint.

21. Please @mention those individuals who you think might be interested in reviewing your PR or otherwise can provide meaningful feedback.

22. If you are actively working on a PR and therefore not immediately looking for feedback, include a [WIP] prefix in the title.

23. If the PR build fails, it is your responsibility to understand why it failed and fix the underlying issue. As a best practice, always ensure you can build your changes locally and that there are no lint errors before opening/updating a PR.

24. When you receive feedback for your PR, try and address the reviewer’s comments/concerns in a timely fashion. If you don’t have time to immediately address them, adding a short note to the PR about when you plan to update the PR will be helpful. Feel free to solicit help if you want others to pitch in.

...