Excessive Stale and WIP PR's

[PDoakORNL]

As a lower FTE percentage maintainer the PR list encourages me not to participate in the review process at all. At twenty PR's it no long possible to scan this list and get any useful information or take serious changes to a PR as something that should be attended to.

The vast majority of PR's are either draft of some sort or a reviewer that is more or less permanently opposing the PR. I think reviewers should take responsibility for the work they are blocking and close PR's they no intention actually letting it merge in the state its in a particular PR once discussion has run its course. I'm not sure we can do this currently but it's done of other projects with similar levels review and its not reasonable to expect the PR submitter to do this in most cases.

Its totally reasonable to have a draft PR for some period of time to see how it does against CI and give a preview to reviewers, but after some period of time <2 weeks? We are just making the process needlessly messy.

[brockdyer03]

As someone with several WIP PRs, I agree with this, but up to a point.

Some PRs like #5836 are partially held up by review and partially held up by a realization that the code changes are more of a bandaid than an actually meaningful rework. I think that PR could probably get closed, since it's not exactly getting done what it needs to, but on the other hand, it has code that does somewhat fix what the PR was opened for. It's a bit of a tossup.

Other PRs, like #5926, are marked with the "help wanted" tag, however I have gotten no help on it. That PR is basically complete, but I am getting errors in the GPU tests that are stopping me from marking it complete. I need help from someone else to diagnose those errors since I am not an expert in C++ or HDF5 (which seems to be the source of the error). That sort of PR should stay up.

There is, however, the more obvious case of #5823, which probably should get closed. I was relatively confident that that PR was nearly ready, but after I got a bit further I realized that I wanted to change some other stuff before I finished it. Those code changes need to wait until I am done with the rest of the bike shedding I have planned.

Another problem is that, in the case of some PRs, there are just a lot of changes that need to get reviewed, and it's hard for maintainers to make time for it. Specifically for Nexus PRs there are just not that many people that can review the code. I almost always am depending on @jtkrogel to review those, but he's often busy and doesn't have the time to review PRs with hundreds or thousands of lines of changes.

[ye-luo]

It is a bit unfortunate that we have many stale PRs. I feel the PR authors are primarily responsible for their PRs even if it is being blocked by reviewers given we have much fewer reviewers than developers. They are responsible to discuss with reviewers about the way to proceed or drop. With some discussion and action, most PRs can be settled. If the author gave up for some reason, the PR can be closed. Then anyone (any developer including reviewers) who would like to continue the work can take over by open new PR superseding the old one.

We can use github project feature to triage PRs in different stages instead of worrying a long list of PRs. I saw other projects do that.

[prckent]

Some comments and suggestions:

• I deal with the PR list by listing by sorting by "Recently updated". If a PR has not been modified since I last checked the list, I don't need to look at it. We usually only have a few active PRs.
• My assumption is that anyone who thinks they have a held-up PR will comment and start tagging people or speak up on Slack. I also remind everyone that "absence of evidence is not evidence of absence". We have seen many times that someone has been experimenting with an improved version of a PR in the background. This only becomes evident when they update the PR with a fixed/finally working version. => Please put a comment on any PR you are wondering about the status of.
• One thing I propose we do is to extend the stale issues workflow Update stale issue workflow (7 year stale, env variables) #6001 to include stale PRs. That way there will be some discussion on the status of presumed-stale PRs.

Any other suggestions?

[prckent]

Closed by #6033 . Please reopen if there are other suggestions. To reiterate, if anyone is wondering about the status of an issue or pr, put at comment, tag people etc.