-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add code review in GovPress page #1193
Conversation
✅ Deploy Preview for laughing-payne-b9fbd2 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
src/govpress-unit/code-review.md
Outdated
--- | ||
|
||
|
||
GovPress follows [the same process for software development](https://playbook.dxw.com/tech/how-we-do-development/) as the Tech Team. However, developers in the Tech Team work on a small number of long-running projects, with relatively large teams. In GovPress we work on a very large number of small projects, with small teams, so we have a slightly different emphasis on how we write code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
relatively large teams
- well, large (~8-15) if you include other dxw discplines, but not usually more than three devs on a project 😅
|
||
All developers are expected to undertake code review. Unless a PR only includes documentation, or similar, you should _always_ test the changeset locally. If it is not clear how to do this, ask the PR author using the **Request changes** feature in GitHub, or similar. | ||
|
||
PRs should not be held up unnecessarily, so if you have questions about the changeset, or small requests, be clear to tell the author if your comments are non-blocking. Your main role is to prevent bugs appearing on live systems, and to minimise the amount of technical debt in our repositories. If your suggested changes do not achieve either of those aims, they should not block a merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PRs should not be held up unnecessarily, so if you have questions about the changeset, or small requests, be clear to tell the author if your comments are non-blocking. Your main role is to prevent bugs appearing on live systems, and to minimise the amount of technical debt in our repositories. If your suggested changes do not achieve either of those aims, they should not block a merge.
Feels relevant in the general tech team guidance too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple more in addition to the above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really good summary of the way we should be working 👍 Thanks!
Thanks folks, this has been a very good example of code review working well :) I'll squash these commits before merge |
This page describes some details in the GovPress code review workflow that are slightly different to the general Tech Team workflow, or where we feel it is important to emphasise particular practices.
ed45885
to
0d4b881
Compare
This page describes some details in the GovPress code review workflow that are slightly different to the general Tech Team workflow, or where we feel it is important to emphasise particular practices.