On one hand dropping the number of open bugs will have significant
appearance/PR improvements.
(I've seen comments saying 600+ bugs outstanding the project must not be
still alive).
But dropping 620 of 680 bugs because they're stale, but possibly still
unresolved issues probably isn't the best.
Would we tag them stale and close them, allowing them to be identified as
possibly not resolved, but with no recent activity?
We used to have weekly (ish) bug triage IRC meetings.
Though to be honest some issues never got addressed because the time
required to thoroughly investigate them and resolve and the few people
reporting them dropped their effective priority.
Thoughts?
On Mon, Sep 2, 2019 at 7:30 AM Mats Wichmann wrote:
> On 9/2/19 8:03 AM, Jonathon Reinhart wrote:
> > Note that you can subscribe to a GitHub issue without commenting. This
> > is preferred as it avoids spamming all currently-subscribed users.
> >
> > Also, I think mass/automated bug closing needs to be done very
> > conservatively. Closing an issue doesn't make the bug go away. There are
> > projects that have bots which close issues after 30 days of inactivity,
> > and I find it infuriating.
>
> I'm not a fan of the rapid/aggressive closing either, wasn't suggesting
> that. The idea of a bot is to keep there from being so much manual work
> to get the notifications sent, and the closing done. If the team prefers
> no not keep it after the prune, it can just be turned off.
>
> There are a decent number of bugs that were created over 10 years ago,
> and many in the 3-10 year range, and which, due to the migration from
> tigris, aren't really associated with people who may have reported them,
> or commented on them.
>
> The idea of commenting to keep a bug alive is to defeat the bot's idea
> of what is active (and to confirm "yes, this is still a problem"). I
> don't think subscribing to it does that.
>
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
