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 branch on the title is helpful for reviewers.

      [2.13.x] DDF-9999 Good Ticket Title

      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)

• 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 Sonarqube 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 Ticket number prepended? (DDF-####)
• Does the commit message explain what & why?  Git Commit Message Guidelines