Chapter 38. Pull Requests

Most changes to JanusGraph must be reviewed before they are committed (RTC - review-then-commit). This workflow is performed using GitHub’s pull request process. In instances where the committer deems the full process unnecessary, commit-then-review (CTR) may be employed. This should be used infrequently and only for extremely trivial changes. Changes of this sort may include:

  • Documentation typo or small documentation addition
  • Addition of a new test case

Any commit that is made following CTR shall include the fact that it is a CTR in the commit comments. Community members who wish to review CTRs may subscribe to the JanusGraph commits list so that they will see CTRs as they come through. If another committer responds with a -1, the commit should be rolled back and the formal RTC process should be followed.

Users wishing to contribute to JanusGraph should fork the JanusGraph repository and then submit pull requests using the GitHub pull request process. Every pull request must be associated with an existing issue. Be sure to include the relevant issue number in the title of your pull request and a description of what test suites were run to validate the pull request.

Pull requests commit messages should clearly describe what work was accomplished. Intermediate work-in-progress commits should be squashed prior to pull request submittal.

Pull requests must be reviewed before being merged. The JanusGraph project uses the GitHub review process to review pull requests. Non-committers are free, and encouraged to review pull requests. Their review will be non-binding, but can be taken into consideration and are still very valuable community input. The following rules apply to the voting process.

  • Two committer approvals are required to merge a pull request
  • One or more -1 votes within a change request will veto the pull request until the noted issue(s) are addressed and the -1 vote is withdrawn
  • Change requests will not be considered valid without an explanation