Github etiquette: Is it polite to help for issue triage?

Question

I have been wandering in the issues of a particular open-source project hosted on Github for a few months, as well as related projects.

I'm not a contributor myself (except for some typos in the docs), but I now know that a handful of old issues have been addressed and can be closed. A typical example is feature requests being answered "Good idea, but we don't have time for that now" and implemented a few years later.

Is it polite/useful/good practice to add a comment in the GH issue stating that it can probably be closed?

On the one hand, it will help with triage, on the other hand, I don't want to add noise for the core devs.

Context: The project is split into a lot of repos (~15), is complex, traces back to 2014, and the main repo alone has 800 open issues, half of them being older than 2017. The project is very active, with a growing community of users and devs using it.

Answer 1

I've been in projects that would be absolutely delighted to have a volunteer come in and do scut work like that, and I've been in projects that got really quite upset when lots of old issues were resurrected when everyone was happy to just let them be dead. You, very sensibly, wish to know what kind of project yours is before sticking your head above the parapet.

Most projects have mailing lists, and in my experience those are the best places to ask nuanced questions about the tastes and conventions of a particular project. IRC and chat fora will do in a pinch, but I find I get more "off the cuff" answers, and fewer thoughtful responses reflective of a community's ethos. It's also harder to point to IRC logs later, when the inevitable out-of-step grouch starts banging on about your "vandalism".

If you were to post a message listing a few examples of the tickets that you felt you could usefully tidy up, showing how you propose to do this, and soliciting community opinion about whether this was a good idea, and were then to wait a few days, one of a few things would be likely to happen:

• Someone points out this has been asked and answered before, or
• A brief debate ensues, and the community's viewpoint emerges, or
• Nothing much happens, in which case I hold that qui tacet consentit, and you should happily press ahead.

I also note Bart's excellent aside above, which you have thoughtfully acknowledged, that this is most likely to go well when you add your proofs to each ticket, so that anyone later reading it can quickly convince themselves that a particular bug or feature request has been dealt with.

Answer 2

The answer obviously depends on the project and the best course of action can only be found by talking to the core devs / maintainers / community around the project.

There is two ways to approach this: You can (start to) go through issues and make appropriate comments, maybe with links to where / when it was implemented. Concurrently (or before) you may contact the maintainers (is there a discord / irc / e-mail / dedicated forums ... way? Use that to establish direct contact, if possible) and ask about the best way to do so. They even might give you some priviliges on the repo or issue tracker so that you can actually close issues or flag them appropriately (maybe they would want to review some decisions).

Being involved in a similar project, I shall be delighted to have such help offered. Personally I'd tell such person to go ahead and comment on the issues. And when I see that it is substantiated with a considerate eye, I shall be quick to give that person the necessary power and tools to do that properly.