Post AVlStWmzn3VdVejH5E by strypey@libranet.de
 (DIR) More posts by strypey@libranet.de
 (DIR) Post #AVlStWmzn3VdVejH5E by strypey@libranet.de
       2023-05-18T01:47:04Z
       
       0 likes, 1 repeats
       
       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. 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. Firstly, 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. When reporting bugs, 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 see that it's already been reported, or whether related to a known bug or other work-in-progress. It also helps them to duplicate the bug, so they can figure out where in the code it's lurking and how to fix it.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 (eg UI, or data storage).If developers working on Free Code have a community member reliably doing this, they 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 they put into 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 set of tags, a vocabulary for describing different parts of a project's code, a list of conditions for closing bugs and advice on what to put in closing message (if any) for each one.If you like this idea and you're keen to help move it forward, it's also been posted on the Social Coding forum for discussion.