← Team Dreamwork

Dreeamwork Pull Requests

Pull Requests

All changes to Dreamwork services/environments will be executed through pull requests in GitHub.

We work in a way similar to open source communities. We welcome pull requests from anyone, inside or outside the team. We do respectfully ask that you allow a member of Dreamwork to execute the merge.

Structure

  • Descriptions should be informative as to the reason behind the PR and/or the changes in the PR. All descriptions should include a reference to the issue in Jira that led to the pull request.
  • Pull requests should be limited in size. The purpose of pull requests is to identify defects in the code, which requires strong focus from the reviewers. After a certain size, developers simply can not focus so long. There is an ideal maximum pull request size, where any longer have developers tend to stop giving full attention and reply with “LGTM” (looks good to me).
    • Dreamwork suggests pull requests be no longer than 400 lines of code, including comments.1
    • Longer pull requests may be accepted if they can not/should not be broken into smaller chunks.
  • Dreamwork pull requests run linters during the automatic build process, including scalafmt and scalafix. If the code has not been formatted according to these tools, the build will fail and the pull request needs to be resubmitted. Most Dreamwork repositories allow you to run sbt build that will automatically run linters and tests. We recommend running this task on your branch prior to opening the PR.

Review process

On Dreamwork we have a few levels of reviews that we use here on pull requests. All comments should start with an indicator the level for the comment.

  • INFO: Indicates a comment or note that the PR author should be aware of. INFO comments do not block merging the PR, but may be addressed at the author’s discretion.
  • WARN: An issue that the reviewer has found with the PR. A WARN comment must be addressed prior to merging the PR. Whether that be answering a question, or making a change.
  • ERROR: An issue the reviewer has with the PR, this is used in conjunction with the Github “Changes Requested”. Any time this is used, the PR must not be merged until the author fixes the issue or addresses the comment, and the reviewer has accepted the outcome. If no solution can be agreed upon by the author and the reviewer, a third team member will be asked to decide between the proposed solutions. Author and reviewer will be able to state their cases, but the decision of the third party will be accepted.

Dreamwork pull requests generally require two accepted reviews prior to merging. This can be modified, mostly in the case of team members on PTO.