Let's adapt our pull request management

Tags: #<Tag:0x00007f0f22957da0> #<Tag:0x00007f0f22957b98> #<Tag:0x00007f0f22957a58>

Sure, I will work on an update of the comment :ok_hand:

Commenting or pushing any changes to the PR counts as an update. It works on GitHub PRs and GitHub issues. Since we are not using GitHub issues we will not use this feature.

The stale action is live :slight_smile: It labeled 6 PRs as stale (so not updated in the last 5 months) https://github.com/openmrs/openmrs-core/pulls?q=is%3Aopen+is%3Apr+label%3AStale

You can see the stale action logs at the actions tab. It runs as a crown job once every day. Debug output is enabled so we see why something was labeled. Example run https://github.com/openmrs/openmrs-core/runs/900729160?check_suite_focus=true

You might have already gotten an email or notification if you are subscribed to the PR. Here is an example of the current comment https://github.com/openmrs/openmrs-core/pull/2995#issuecomment-662756572 (its markdown so we can also adapt its style)

If a PR should not be closed after being labeled as stale it needs attention. That means remove the label and also review it, comment or push a change. The PR is shown like a timeline with events at specific points in time, so you can see when it was last updated. I think the bot comment does not count as an update.

A best practice for reviewers would be to sort PRs by least recently updated. So that not only newly created PRs get attention and older ones don’t get stale.

Let me know what you think. Feedback is more than welcome :slight_smile:

1 Like

I have got email notifications for the 6 pull requests. Thanks @teleivo for this initiative. :smile:

@teleivo Thanks for the thread, although the best way to reduce the number of PRs is to increase the number of potential reviewers that we the cycle time can be improved

hint hint @grace @jennifer @burke

3 Likes

@teleivo Thanks for this initiative! I’m wondering two things:

  1. Should we update our Wiki (somewhere) to describe the PR management process described in this thread?

  2. Should we maybe consider adopting something like this stale action for other OpenMRS repos?

2 Likes

This reminds me of the issue @bistenes identified with module maintenance: “Since everyone maintains everything, no one maintains anything.” We encourage everyone in the community to help manage PRs - and then we look to the same people who always do it because they have always done it. How can we go beyond encouraging “everyone” to manage PRs and instead motivate and empower specific individuals to take ownership of PR management?

I can think of a couple of ways to do this, building on some things that are already in motion:

  • One of the advantages of @bistenesmodule maintenance system is that it would actually lead to more “responsive on PRs. No old PRs collecting dust” because the module maintainers are responsible for reviewing, responding to, and closing PRs. Some module maintainers have already been identified - and are working on identifying others.

  • @burke, haven’t we also integrated PR management into our developer stages?

1 Like

Thanks @jennifer, yeah, this is a big part of what I had in mind with the module maintenance initiative.

Though to @ssmusoke’s point, which I think is important—yes, we need not only more organization, but also more potential reviewers. I’m hopeful that more mentorship, and something like a fellowship program, could help expand the pool of potential reviewers, and maybe also increase the quality of reviews generally.

Not sure if that’s what you meant @ssmusoke? But anyway that’s what stands out to me as a big opportunity.

1 Like