Volunteers to close issues? [organizational; not-bug]

[hyiltiz]

It is ironic that I opened this issue to discuss closing issues. I'll close it once we are done discussing it.

As you probably are aware, there are too many Issues in this repository and while Spacemacs is crucial to many of our daily work, it has been a few years since the new major release 0.3 was coming right around the corner but just barely out of reach. There was a community effort about half a year ago pruning all the release critical Issues to get it released but it didn't result it a release. There are issues like this #10388 that can be closed with minimal testing or require no fixing at all in the develop branch.

If we can come up with a search query to filter Issues with higher priority that is blocking the release, the community can probably help do another round of Issue Squashing Party.

[smile13241324]

Sounds like a great idea having some volunteers going through the insane amount of issues and testing which of these are actually still a problem would save us like a ton of time and of course having more people actively working on fixing issues would help us too.

Especially a problem we are seeing lately is a lot of outdated layers which require almost no programming to fix, just knowledge about the individual programming environment.

About what is to be fixed for a release, there are milestones defined in the issue list, I am not sure if they are still up-to-date, but its a good starting point.

[hyiltiz]

From the issues page, I tried filtering with Milestones, and all the currently defined and assigned milestones each returned about 10 or less Issues. I'd say that is quite manageable. The Issues that have no milestones or tags assigned probably needs help from the community instead. Is there something similar to a bot command where the community suggest tags/labels/milestones/request for closing issues via GH comments? It would be hard to find people who'd be committed for a long enough time to assign them Collaborator roles, but also hard to get help from the community from Github's Issues interface.

I am thinking about those 3rd party project management platforms that integrates with Github Issues. If they can filter or use community comment tags, such as label resolved-in-develop, label suggest-to-close etc. that would be convenient for anyone to participate.

[practicalli-johnny]

@smile13241324 if we see an issue that we thing should be closed (and we are not a maintainer), would it be useful to at-mention you or one of the other maintainers? Or would that make things harder for you?

I also suggested automating the marking of dormant issues using the GitHub Stale bot https://github.com/syl20bnr/spacemacs/issues/13271, although it looks like something has been added with https://github.com/syl20bnr/spacemacs/pull/13315

[hyiltiz]

It is discouraging if a non-resolved open Issue gets closed if the correspondents were still interested and were patiently waiting. If bots were used to manage issues, to reduce shock, they need to be carefully configured.

[cubranic]

I just had an ideal experience with the automated issue-management workflow: I got a reminder from the bot that an issue I opened over a year ago was stale and will be closed (#11817). I didn't hugely care about it, because it was for a bug that would only appear with Spacemacs in an older Emacs, and I had since upgraded so it wasn't affecting me any more. But, there was a helpful comment in my issue pointing to the report in the Ivy package that was causing the error, which I checked and saw that it's since been fixed. So I closed the Spacemacs issue too. One less -- 2,357 to go!

[cubranic]

FWIW, I find this article by Avery Penwarr on issue management hugely inspiring: "An epic treatise on scheduling, bug tracking, and triage". The main take-way point: "love, but manage, your growing bug pile" -- it's nearly inevitable with a successful large-enough project that bugs will be filed faster than they can be closed, and so there will be an ever-increasing amount of open ones. Instead, aim to review each new bug quickly and assign it to the relevant team/category.

Then when "product managers" prioritize features for the next release (this is in the context of commercial software development, but bear with me), the dev team can focus on their own bug list and just work through the important ones one bug at a time.

It's a long essay, based on an internal presentation given at Google when the author still worked there, but I'd encourage everyone to read it and try out the recommendations.

[smile13241324]

@cubranic great article :) found it very satisfying to read while I was riding the train.

We now have a bot marking stale issues which will be auto closed after a certain period if no comment is posted. I hope this helps cleaning up our issue mess.

As to offering help, we always need people reproducing issues, especially older ones. Also we are running into the issue of bitrot, for certain layers. So looking up an alternative package for supporting restructured text files and the sphinx doc generator for example would be highly appreciated. If you have found one which looks major enough to be integrated, please open an issue or a PR.

And as always reporting non working layers is also highly appreciated.

[hyiltiz]

I think the bot is doing well (it led to the close of one Issue I subscribed and let to discussions in a few others). Bravo!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!