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:

project management / issue tracker advice 

@joepie91 i want to @ this so hard at Home Assistant, whom dont seem to understand this

actually i want to @ this at so many projects, holy fuck so much rage in my life has been spent at this

project management / issue tracker advice 

@joepie91 ive also bought a domain i was gonna put all of this info on, why its bad, how to do better, etc, because i want issue tracker people to know that stale bots is not something we want

project management / issue tracker advice 


still in my project todo list...

project management / issue tracker advice 

@ShadowJonathan @joepie91 oh yes fucking Home Assistant. I tried to contribute once, never again. Also bonus fuck you to all projects who automatically lock closed issues.

project management / issue tracker advice 

@joepie91 or to put it more simply: your issue tracker isn't a ticketing system. That's what drives the mentality behind stalebots from what I can tell.

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 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

Sign in to participate in the conversation

Small server part of the infrastructure. Registration is closed.