Holden is absolutely correct - pinging relevant individuals is probably your best bet. I skim the 40-50 PRs that have activity each day and look into a few that look like I would know something about by the title, but, easy to miss something I could weigh in on.
There is no way to force people to review or commit something of course. And keep in mind we get a lot of, shall we say, unuseful pull requests. There is occasionally some blowback to closing someone's PR, so the path of least resistance is often the timeout / 'soft close'. That is, it takes a lot more time to satisfactorily debate down the majority of PRs that probably shouldn't get merged, and there just isn't that much bandwidth. That said of course it's bad if lots of good PRs are getting lost in the shuffle and I am sure there are some. One other aspect is that a committer is taking some degree of responsibility for merging a change, so the ask is more than just a few minutes of eyeballing. If it breaks something the merger pretty much owns resolving it, and, the whole project owns any consequence of the change for the future. I think it might just be committers that can reopen at this point, not sure if that changed. But you'll probably need someone's attention anyway to make progress. Without knowing specific PRs, I can't say whether there was a good reason, bad reason, or no particular reason it wasn't engaged. I think it's OK to float a PR or two you really believe should have gotten attention to dev@, but yeah in the end you need to find the person who has most touched that code really. The general advice from https://spark.apache.org/contributing.html is still valuable. Clear fixes are easier to say 'yes' to than big refactorings. Improving docs, tests, existing features is better than adding big new things, etc. On Thu, Feb 18, 2021 at 8:58 AM Enrico Minack <m...@enrico.minack.dev> wrote: > Hi Spark Developers, > > I have a fundamental question on the process of contributing to Apache > Spark from outside the circle of committers. > > I have gone through a number of pull requests and I always found it hard > to get feedback, especially from committers. I understand there is a very > high competition for getting attention of those few committers. Given > Spark's code base is so huge, only very few people will feel comfortable > approving code changes for a specific code section. Still, the motivation > of those that want to contribute suffers from this. > > In particular I am getting annoyed by the auto-closing PR feature on > GitHub. I understand the usefulness of this feature for such a frequent > project, but I personally am impacted by the weaknesses of this approach. I > hope, this can be improved. > > The feature first warns in advance that it is "... closing this PR because > it hasn't been updated in a while". This comment looks a bit silly in > situations where the contributor is waiting for committers' feedback. > > *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. > *...** 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! > > *... remove the Stale tag?* The comment says "... ask a committer to > remove the Stale tag!". Where can I find a list of committers and their > contact details? What is the best way to contact them? E-Mail? Mentioning > them in a PR comment? > > *... find the right committer to review a PR?* The contributors page > states "ping likely reviewers", but it does not state how to identify > likely reviewers. Do you recommend git-blaming the relevant code section? > What if those committers are not available any more? Whom to ask next? > > *... contact committers to get their attention?* Cc'ing them in PR > comments? Sending E-Mails? Doesn't that contribute to their cognitive load? > > What is the expected contributor's response to a PR that does not get > feedback? Giving up? > > Are there processes in place to increase the probability PRs do not get > forgotten, auto-closed and lost? > > > This is not about my specific pull requests or reviewers of those. I > appreciate their time and engagement. > This is about the general process of getting feedback and needed > improvements for it in order to increase contributor community happiness. > > Cheers, > Enrico >
