Hi devs,
Right now the official strategy for handling PRs in jira issues is the one from 2012:
which is that have a “Pull Request Status” custom field to set when a PR is created for an issue or when its status changes.
The reason is that thanks to this info we send a jira filter notification every week about PRs for which committers need to answer.
The topic of this brainstorming is to decide if we want to continue doing this or if we should drop it.
Several ideas:
- This was done at a time where we were also receiving patches attached to jira issues (and not only PRs). I think nowadays, we could mandate to always receive code changes through PRs. Thus the status of proposed changes can be fully found on GitHub. Especially since there are filters than can be used:
- I have the feeling that not many committers look at the filter notification email every week and that it’s mostly useless ATM. We could decide to look more at it of course and set up a process around this.
- We now have the rule of setting an assignee to PRs. There’s still the grey area in the process about how we ensure that all created PRs have an assignee. Right now it’s a best effort I think.
- We could imagine setting up a GitHub Action to send an email every week for the “awaiting review from you or your team” status.
- Every developer has watch setup in GH to receive notifs when PRs are created (@MichaelHamann thinks that it’s automatically set if you have write access to a repo). I’ve confirmed that it’s the case for me, even for repos that I’ve never heard of/touched.
It seems to me that we should deprecate/drop the usage of the “Pull Request Status” custom field:
- Document it in the jira rules page on xwiki.org
- (optional) Check the 35 issues that have “awaiting committer feedback” in jira, see Loading... Most likely the custom field is not up to date.
See how it goes and if there’s a general problem in the future about PRs that don’t get attended to, explore idea 4).
WDYT?
Thanks