Hey Nicholas, Thanks for bringing this up. There are a few dimensions to this... one is that it's actually precedurally difficult for us to close pull requests. I've proposed several different solutions to ASF infra to streamline the process, but thus far they haven't been open to any of my ideas:
https://issues.apache.org/jira/browse/INFRA-7918 https://issues.apache.org/jira/browse/INFRA-8241 The more important thing, maybe, is how we want to deal with this culturally. And I think we need to do a better job of making sure no pull requests go unattended (i.e. waiting for committer feedback). If patches go stale, it should be because the user hasn't responded, not us. Another thing is that we should, IMO, err on the side of explicitly saying "no" or "not yet" to patches, rather than letting them linger without attention. We do get patches where the user is well intentioned, but it is a feature that doesn't make sense to add, or isn't well thought out or explained, or the review effort would be so large it's not within our capacity to look at just yet. Most other ASF projects I know just ignore these patches. I'd prefer if we took the approach of politely explaining why in the current form the patch isn't acceptable and closing it (potentially w/ tips on how to improve it or narrow the scope). - Patrick On Mon, Aug 25, 2014 at 9:57 PM, Matei Zaharia <matei.zaha...@gmail.com> wrote: > Hey Nicholas, > > In general we've been looking at these periodically (at least I have) and > asking people to close out of date ones, but it's true that the list has > gotten fairly large. We should probably have an expiry time of a few months > and close them automatically. I agree that it's daunting to see so many > open PRs. > > Matei > > On August 25, 2014 at 9:03:09 PM, Nicholas Chammas ( > nicholas.cham...@gmail.com) wrote: > > Check this out: > > https://github.com/apache/spark/pulls?q=is%3Aopen+is%3Apr+sort%3Aupdated-asc > > We're hitting close to 300 open PRs. Those are the least recently updated > ones. > > I think having a low number of stale (i.e. not recently updated) PRs is a > good thing to shoot for. It doesn't leave contributors hanging (which feels > bad for contributors), and reduces project clutter (which feels bad for > maintainers/committers). > > What is our approach to tackling this problem? > > I think communicating and enforcing a clear policy on how stale PRs are > handled might be a good way to reduce the number of stale PRs we have > without making contributors feel rejected. > > I don't know what such a policy would look like, but it should be > enforceable and "lightweight"--i.e. it shouldn't feel like a hammer used to > reject people's work, but rather a necessary tool to keep the project's > contributions relevant and manageable. > > Nick >
