As a Stallmanian Jihadist with minimal coding skills, I try to help the people developing the Free Code software I use or test, by being a squeaky wheel and reporting bugs and UX deficiencies in the Issues on their code forge. So I was horrified to discovered that one of the things that contributes to maintainer burnout for some people developing software in the open is the emotional labour of triaging Issues (see Nolan Lawson’s classic blog post, ‘What it eels like to be an open-source maintainer’). While there are a number of things maintainers can do to mitigate this, there are also things we, the communities using the software, can do to help.
Firstly, there’s a lot we can do to make the Issues we report easier to triage. I try to include in as much detail as I can about what other software I’m using (eg OS, web browser if it’s a web app), what I was doing when the problem occurred to me, what I expected (or wanted) the software to do, and what it actually did. This helps the people triaging to recognize whether my Issue is a bug report or a feature request, and whether it’s already been reported, or related to a known bug or other work-in-progress. If I’m making a feature request, before reporting an Issue I try to find out whether there’s a web forum or chat room, and if there is I propose it there first.
But what if the people doing the time-consuming technical work on a software project didn’t have to triage Issues at all? Anyone can learn to do this. No advanced technical skills are required to tag an Issues as ‘feature request’, close duplicates with a quick message to the reporter linking to the existing Issue, talk the reporter through their problem to get enough details for the developers to reproduce it, and so on. With enough knowledge of the project team, it’s not that difficult to assign an Issue to the developer working on the part of the code it affects.
If they have a community member reliably doing this, developers working on Free Code can turn off Issue notifications, knowing that an agreed method will be used to draw their attention to Issue that are worth their time. This massively reduces both the actual labour and the emotional labour of dealing with Issues, freeing up time and energy they can put into improving the code. It also boosts the morale of everyone involved in the project, from the developers who can focus on scratching their itches, to the Issue triage volunteers who feel good about contributing, to the Issue reporters who get timely responses to their Issues.
One way to make it easier for non-coders to become Issue Triage ninjas, would be to define and document a standardized methodology that can be widely adopted across Free Code projects, regardless of what code forge they use. Things like a standardized set of tags, and a list of conditions for closing bugs and advice on what to put in closing message (if any) for each one.