[GH ISSUES PILOT] Pull Request Guidelines

PR Guidelines

1. For changes that will need to be committed to both the release branch and master, make the initial PR against the release branch. Once that PR is merged, open the PR against master.
2. Fill out the template on your pull request https://github.com/codice/ddf/blob/master/PULL_REQUEST_TEMPLATE.
3. Create an appropriate title for the Pull Request.

   1. Include the branch name in the PR title for a non-master branch. Indicating the issue number on the title is helpful for reviewers.

      [2.13.x] DDF-9999 Good Ticket Title
      

      • If the issue originated in JIRA, use the four-digit JIRA issue number
      • If the issue originated in GitHub, use prefix the GitHub issue number with a zero. For example, "DDF-09999" Another helpful piece of information to give reviewers is to link the original master ticket (if applicable) at the top of the forwardport PR description, e.g:

      ### Forwardport of https://github.com/codice/ddf/pulls/9999
      

   2. If your PR is a work in progress (not ready to be merged or reviewed), indicate it with WIP (Work in progress).

      [WIP] DDF-9999 Good Ticket Title
      

Notes on Review Process

• For the general case, merging is gated on the following, although certain exceptions may occur. For example, if there is a problem with the CI environment then a manually performed full build and static analysis check may be substituted at the discretion of the repository maintainers.

  • Review by at least two contributors
  • Review by at least two committers
  • Successful CI
  • Successful static analysis (SonarQube/Coverity/etc.)
  • Heroing of change (details vary by ticket)

• Abbreviated review process

  • Repository metadata such as this PULL_REQUEST_TEMPLATE, the repository README, and other non-functional items may be merged without requiring CI and static analysis
  • An abbreviated review process may be in place for forward-port tickets immediately following branching and prior to branch divergence. In that case, approvals, CI, static analysis, and heroing that occur against the PR against the release branch can be considered sufficient for reviewing the PR against the master branch. It should be noted however that at least one of a CI or a hero should be performed to ensure no errors arose from version differences/oddities.

  Once the branches diverge, the process will return to normal.

  Insofar as divergence is not a function of time but of change to the parent branch, the repository maintainers will determine when abbreviated review ends.

  When abbreviated review is in effect, a note to that effect will be at the top of this template. Following is an example note:

  ##### ABBREVIATED REVIEW BETWEEN 2.13.X AND MASTER IS IN EFFECT
  _____
  

Checklist for Committers (before merging)

📓 The committer who merges the PR assumes responsibility to help address any issues introduced in the merged PR.

• Do at least two non-committer reviewers approve?
• Do at least two committer reviewers approve?
• Are there any outstanding reviews that reject the pull request? Do these reviews have critical ❗️ comments that warrant blocking it?
• Does the PR have a successful CI build?
• Does the PR address all static analysis findings or appropriately suppress them?
• Does the PR have a comment regarding the hero status?
• Did you leave a comment about why any of the above was ignored or skipped?
• Did the right documentation get added or updated (or removed)?
• Do these changes need to be highlighted on the Release Notes? (see Release Note Guidelines)
• Does the commit message have the Issue number prepended? (DDF-####)
  • For commits created to resolve GH Issues during the pilot and beyond, please prefix the issue number with a 0 until we roll over at issue #10000, ie: DDF-0####. This kludgy solution will avoid overlap with issues created in Jira.
• Does the commit message explain what & why? Git Commit Message Guidelines