PR Labels

[stevenyoungs]

Hi @Nick-Hall
Is there any documentation on how you are using the new (I think) labels

• Status: New
• Status: Pending

and how a PR moves from New to Pending?

Also gives me an excuse to try out Github Discussions

[Nick-Hall]

No documentation yet.

I'm just trying out a new system that will help progress pull requests more quickly.

The idea is that a new PR, or a PR moved from draft to review, will be labelled as "Status: New". Then, after 3 weeks for an enhancement or 1 week for a bug, the status will move to "Status: Pending". This will be a signal to me to review the PR. I'll then review the feedback as usual and make a decision. I'll either reject or approve the PR or perhaps continue the conversation. This may be to ask a question of the developer, or maybe to start a design review, or maybe I need more time to research the topic. So there may be a status of "Status: Design review" for example. A PR that has advanced to "Status: Approved" may still require further testing. Finally we may have a "Status: Complete" to indicate that a PR is ready to merge.

I've also added a "Type" and "Category" to the labels.

There are no policy changes. I'm just trying to make things easier.

As usual feedback is welcome.

[stevenyoungs]

Thanks for the comprehensive explanation. It seems sensible and if it reduces your workload then even better.
What is clear is that there is now quite a backlog of PRs for you to process

[Nick-Hall]

There are 29 "Status: Pending" PRs which I intend to review as soon as possible. I'll also consider closing the very old draft PRs.

[QuLogic]

You may want to use a project board for this.

[hgohel]

@Nick-Hall If a new PR has reviews (especially approvals) from other developers, is there a possibility to fast-track the 1-week/3-week wait period?

[Nick-Hall]

Yes, but only under limited circumstances, such as:

• Translation changes that are approved by the relevant language reviewer.
• Updates to code related to packages if approved by the maintainer.
• Certain administration tasks.
• Documentation enhancements and corrections.
• PRs submitted close to a release. I will often merge simple fixes just before I release a new version.
• Emergency bug fixes.

Otherwise we like to give all developers a chance to comment.