This is the final of the 3 topics that I’ll add, and it covers off how we’d like to manage PRs through the pipe to merged and released.
Here’s a drawing of the process, my attempt to help visualise the steps in the process:
As you can see it’s a 6 step process, from creating the PR through to merging it.
Some things to note in it that are new:
Use of labels
We would like to create a set of labels specifically to be used for PR management. Here is the full list:
pr-wip - use when you’ve created a PR but it isn’t ready to go through the process yet.
pr-no-review - use when your PR doesn’t require a code review or testing (e.g. Transifex branches required for releases).
pr-no-test - use when your PR doesn’t impact on functionality and doesn’t require any front end testing.
pr-test-ready - use when your PR has been reviewed and is ready for testing.
pr-ready-to-go - use when your PR has been reviewed and tested and is ready to be merged.
aus review - (existing) use when you want the AU team to look at your PR at any point in the process.
Obviously, as you move your PR along the process you remove these labels when they are no longer relevant.
Use of entry and exit criteria for each step
You can clearly see as you create and move things through the pipeline exactly what you need to do, who is involved, and what is required to be able to move it to the next step. It’s up to you as someone developing code on the platform to make sure you follow these steps, and ensure that they’re being following by others. It makes it easy for us non-devs to also understand where things are at and whether we need to look at something or not. Win-win!
OK, so now it’s over to you all for comment. Ping @MyriamBoure @sigmundpetersen @lin_d_hop @Matt-Yorkley @sstead @NickWeir @Kirsten @enricostn @sauloperez. I’ll give this more time for comment, and will look to implement the results of our discussion into GitHub in the week commencing November 6 alongside of making other changes to the labels