project management / issue tracker advice
Don't try to minimize the amount of open issues in your issue tracker! Issues are *contributions* from users, telling you about problems that you were not aware of yet - they're not pests to get rid of.
Closing issues without either solving them or a good(!) reason why they won't be fixed - for *any* reason, including stalebots - will just sour people on your project. They won't tell you that; they'll just stop showing up. And the issue still won't be fixed.
Instead, treat your issue tracker like a priority queue: accept that you're never going to get to zero, accept that some issues will remain open a long time because they are not urgent, and find a good way to order the list by your criteria of importance.
Work on things as time permits, in order of importance, communicate this to users, and establish a good rhythm of bugfixes that users are happy with even if *their* specific bug isn't fixed yet.
There are a lot more useful thoughts on this topic in this article: https://apenwarr.ca/log/20171213
project management / issue tracker advice
project management / issue tracker advice
@joepie91 An important thing I learned from my testing class is that incidents and issues are different. Maybe the problem is that we call these issue trackers, when they are actually used to report incidents.
project management / issue tracker advice
@csepp @joepie91 That is actually kinda what it boils down to a lot on public issue trackers.
The linked post does go into (a lot) more detail, and the one one of the stances it makes abundantly clear is that projects need triage.
Large projects need people who look at the incident report and hash out the details, do some tagging, link and merge(?) duplicates, and so on and turn the incident report into an issue in the process that ends up at a person who sees the actual issue and can fix that issue ideally without further information at all.
TL;DR: Thank you for bringing the term incident report and the distinction in regards to issues to my attention, this will make communicating these matters so much easier.
project management / issue tracker advice
project management / issue tracker advice
@joepie91@social.pixie.town I always had a policy of trying to include at least one of the issues that had fallen into a low priority, and had aged severely, in every release. It's notable how doing so can re-engage users that feel like they've been ignored.
re: project management / issue tracker advice
@pink Huh, I think that's a great policy!
project management / issue tracker advice
@joepie91 meanwhile the Gnome people: "lmao we don't care, we're not doing this for users we're pursuing our vision, contribute (but only if you 100% agree with us otherwise we'll reject your contribution) or shut up"
...sorry I'm still pissed at the thing I posted about earlier 😒
@joepie91 well said. plus if have a hybrid "FOSS or paid-premium" model then you can also use "whos paying us?" as a dimension to prioritize issues
re: project management / issue tracker advice
@joepie91
looks at https://phabricator.wikimedia.org/
cries