On Thu, Feb 18, 2021 at 9:58 AM Enrico Minack <mail@enrico.minack.dev> wrote:

What is the approved way to ...

... prevent it from being auto-closed? Committing and commenting to the PR does not prevent it from being closed the next day.

Committing and commenting should prevent the PR from being closed. It may be that commenting after the stale message has been posted does not work (which would likely be a bug in the action or in our config), but there are PRs that have been open for months with consistent activity that do not get closed.

So at the very least, proactively committing or commenting every month will keep the PR open. However, that's not the real problem, right? The real problem is getting committer attention.

... re-open it? The comment says "If you'd like to revive this PR, please reopen it ...", but there is no re-open button anywhere on the PR!

I don't know if there is a repo setting here that allows non-committers to reopen their own closed PRs. At the very worst, you can always open a new PR from the same branch, though we should update the stale message text if contributors cannot in fact reopen their own PRs.

What is the expected contributor's response to a PR that does not get feedback? Giving up?

I've baby-sat several PRs that took months to get in. Here's an example off the top of my head (5-6 months to be merged in). I'm sure everyone on here, including most committers themselves, have had this experience. It's common. The expected response is to be persistent, to try to find a committer or shepherd for your PR, and to proactively make your PR easier to review.

Are there processes in place to increase the probability PRs do not get forgotten, auto-closed and lost?

There are things you can do as a contributor to increase the likelihood your PR will get reviewed, but I wouldn't call them "processes". This is an open source project built on corporate sponsorship for some stuff and volunteer energy for everything else. There is no guarantee or formal obligation for anyone to do the work of reviewing PRs. That's just the nature of open source work.

The things that you can do are:
  • Make your PR as small and focused as possible.
  • Make sure the build is passing and that you've followed the contributing guidelines.
  • Find the people who most recently worked on the area you're touching and ask them for help.
  • Address reviewers' requests and concerns.
  • Try to get some committer buy-in for your idea before spending time developing it.
  • Ask for input on the dev list for your PR.
Basically, most of the advice boils down to "make it easy for reviewers''. Even then, though, sometimes things won't work out (5-6 months and closed without merging). It's just the nature of contributing to a large project like Spark where there is a lot going on.