Managing the workload

[lontivero]

Precedents

In 2019 the Wasabi development team consisted of 5 members: adam, david, dan, max and me. The number of ideas, bugs, feature requests, questions, suggestions and comments was already a problem back then. Max was acting as a project leader organizing tasks, issues, etc. Something that was necessary because the workload was too high.

Old policy

The official policy was "be nice". That means that when someone requested something idiotic, instead of just saying "No" and closing the issue immediately, we should keep the conversation open. The same was expected for duplicates. After a while we ended up with about 600 open issues, but the problem was the trend, which is why the probot-stale robot was configured. However, the "be nice" policy also means that robots cannot be rude and we should reopen the issues that it closes.

Current situation

Currently we have 330 open issues. Many are for WW1, others for things that do not apply anymore, some are good ideas, there are also a few bad ideas, a couple of bugs, etc. The huge majority of them will never be taken by anyone, not even to close them because reading, understanding and thinking about 300 issues with their discussions and historical context is a heavily time-consuming task that doesn't add much value to the project nor the software.

Alternative (idea)

During a talk with nopara in 2019 I proposed the following: how many issues can we manage effectively? Let's say the magic number is 21. Well, in that case we should never have more than 21 open issues. Imagine we have 21 open issues and someone comes with a new one, imagine it is a bug, the key is to decide whether that new bug is more important than the already existing 21 or not. If it is, then we should accept it and close the least important of the previous 21 issues; otherwise close the new issue with a "won't fix". I think this sounds radical but the real world is harsh.

New policy

This can be described as "close fast or close first; ask later". Also known as the Microsoft way. It consists of:

Closing duplicates immediately
Closing nonsensical issues immediately without comment
Closing issues that do not help. Help us to help you or shut up.
Closing issues that are just for trolling (this kind of activity is new and pretty annoying)
Closing issues without feedback

In other words, if a Wasabi user makes a question or reports a bug and it provides a more or less clear description or a screenshot or a log fragment or manifests in any other way a sincere will to help or to be helped then accept the issue, otherwise close it.

Summary

Wasabi was maintained by an stable staff of at least 10 people as developers and an army of collaborators but that's over.

[Kruwed]

During a talk with nopara in 2019 I proposed the following: how many issues can we manage effectively? Let's say the magic number is 21. Well, in that case we should never have more than 21 open issues. Imagine we have 21 open issues and someone comes with a new one, imagine it is a bug, the key is to decide whether that new bug is more important than the already existing 21 or not. If it is, then we should accept it and close the least important of the previous 21 issues; otherwise close the new issue with a "won't fix". I think this sounds radical but the real world is harsh.

Out of all my open issues, this is the one I would pick as "most important": #11261