Somewhat related... would there be benefit in labeling PRs [1] to group them for people to more easily identify changes they may be more comfortable in reviewing?
For example, I've submitted several Elasticsearch related PRs that are awaiting review (and would be relatively happy trying to review similar), but I'd be less confident in reviewing something related to Hadoop, for example. Such labels would allow people to quickly filter for things related to the areas in which they're interested/confident to review. Of course, this would need someone to add labels to existing PRs and maybe a request for people to add them to new PRs could be part of the PR template? [1] https://docs.github.com/en/github/managing-your-work-on-github/managing-labels Cheers, Chris Sampson On Thu, 25 Mar 2021, 20:47 Joe Witt, <joe.w...@gmail.com> wrote: > Got ya > > On Thu, Mar 25, 2021 at 1:36 PM Otto Fowler <ottobackwa...@gmail.com> > wrote: > > > > > https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features > > What I mean is, beyond the GitHub settings it has, if it offered PR > pruning > > ( if that were possible ). > > Seems silly that everyone has to roll their own. > > > > On Thu, Mar 25, 2021 at 3:05 PM Joe Witt <joe.w...@gmail.com> wrote: > > > > > Otto > > > > > > I'm not clear on what you mean. But here we're talking about our > > > communities usage of Github in particular as a convenient vehicle to > > > support contributions. The ASF/Git (gitbox) is a different animal. > > > > > > Thanks > > > > > > On Thu, Mar 25, 2021 at 12:02 PM Otto Fowler <ottobackwa...@gmail.com> > > > wrote: > > > > > > > > What would be nice is if this could be part of the ASF official .yml > for > > > git > > > > > > > > On Thu, Mar 25, 2021 at 2:42 PM Joe Witt <joe.w...@gmail.com> wrote: > > > > > > > > > Team, > > > > > > > > > > We've discussed it in various forums but I want to formally move to > > > > > taking action on our PR situation. As of a couple hours ago we had > > > > > 280 or so open PRs. Many many many of these are quite old (two or > > > > > more years). These aren't just abandoned PRs because they were not > > > > > good enough to be clear. There are actually a lot of good and > > > > > interesting things in here. I think though we simply cannot keep > up > > > > > with the PRs that come in. The most difficult appear to be less > about > > > > > fixing bugs and more on adding features. Anyway, we clearly get a > lot > > > > > of PRs and we clearly close a lot of PRs but many remain > unaddressed. > > > > > Other communities such as Apache Spark [1],[2] have provided an > auto > > > > > close mechanism. It is intended to keep the PR queue tidy and not > > > > > just go endlessly without a response. > > > > > > > > > > I am planning to implement the same with a 180 day > auto-stale/closure > > > > > using the same github/ci workflow [3] based on github action [4]. > You > > > > > can see the results of this here [5]. > > > > > > > > > > If someone disagrees please share a workable alternative that > doesn't > > > > > leave the PRs or those that submitted them hanging indefinitely > which > > > > > you are willing to implement. > > > > > > > > > > [1] > > > > > > > > > http://apache-spark-developers-list.1001551.n3.nabble.com/Handling-stale-PRs-td8015i20.html#a9684 > > > > > [2] > > > > > > > > > http://apache-spark-developers-list.1001551.n3.nabble.com/Closing-stale-PRs-with-a-GitHub-Action-td28477.html > > > > > [3] > > > > > > > > > https://github.com/apache/spark/blob/master/.github/workflows/stale.yml > > > > > [4] https://github.com/marketplace/actions/close-stale-issues > > > > > [5] > > > > > > > > > https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed+label%3AStale > > > > > > > > > > Thanks > > > > > Joe > > > > > > > > >
