I added my vote against bulk close functionality. it is pretty clear from this thread that several of us are opposed to bulk close.
somehow the discussion jumped from bulk commenting to bulk close. fuck that! On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <jan....@cominvent.com> wrote: > > I gave it a shot, and it works, so with this change to githubPRs.py script: > https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs > with a comment and label with a single command. The script can also easily be > adapted to other use cases. > > Jan > > > 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan....@cominvent.com>: > > > > +1 to bulk commenting on the 274 open PRs with a standard message about the > > need for new PRs. > > We already have a "stale-closed" label in GitHub, so if we add that label > > to all the issues they can safely be closed without information loss. > > My script > > https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py > > can probably be tweaked to do these actions. It uses a python GitHub > > library and already fetches all open PRs, and allows to pass a token, so I > > guess that the token will also allow edits on behalf of the user. > > > > Jan > > > >> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <msoko...@gmail.com>: > >> > >> In this specific instance, I don't see the harm in leaving these > >> issues there since the entire repo is essentially an archival artifact > >> at this point. If we actually want to notify people that "hey your > >> issue is in a dead zone, do you want to revive it? Here's how ..." we > >> could maybe generate some emails? Although I really have no idea how > >> we would accomplish that. > >> > >> In general, I'm in favor of cleaning up / closing issues that are > >> clearly not going to be worked. > >> > >> For example in JIRA we have so many old issues that they can clutter > >> up search results, making it much harder for new contributors > >> (especially) to find "interesting" issues that might be relevant today > >> and workable. I have heard various arguments for keeping these old > >> issues: they represent an historical view of the project; "you never > >> know" maybe they become relevant again; and this idea of not annoying > >> people by arbitrarily closing their issue. These all have some > >> validity, but I we have to strike a balance. I wonder if we can > >> address them in another way. In JIRA can we keep these old issues > >> while hiding them from default searches. Can we "archive" old issues > >> in some way? Maybe there is a "Status" like Archived that is different > >> from Closed. Anything but Open! > >> > >> > >> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <md...@mdrob.com> wrote: > >>> > >>> I understand the frustrations around closing somebody’s PR as stale, but > >>> I also think that there is value in informing the contributors I this is > >>> never getting solved/fixed/looked at, if this is still important please > >>> go over there instead. > >>> > >>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcm...@gmail.com> wrote: > >>>> > >>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless > >>>> <luc...@mikemccandless.com> wrote: > >>>>> > >>>>> Could we maybe instead bulk-add a comment explaining the split and how > >>>>> to take the PR forwards if someone (in the future) has itch/time? > >>>>> > >>>>> I know we humans love to clean things up, but I think leaving such > >>>>> "unclean" things open serves an important purpose. They all had > >>>>> importance to at least one person at one point in time, and likely many > >>>>> of them are still relevant if they piqued someones curiosity to dig > >>>>> back into them. Closing them makes them harder to find for the future > >>>>> developer. > >>>>> > >>>>> I'm sure some of them are already resolved/duplicates too. If only we > >>>>> could divine which are which. > >>>>> > >>>>> > >>>> > >>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when > >>>> I see it in other trackers. Is there a rush to close these for some > >>>> reason? > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
