Trello for strategic bugs?


#1

The problem of bugs that stay stale or seemingly ignored is not unique to Team Stonehearth. It’s a systemic issue you see across software development of all stripes, and it’s largely because some bugs fall into a Technical Debt category that don’t make sense to fix tactically (“Work Smart”, “Fix It Right” etc).

So the problem becomes one of visibility / ticket upkeep at scale (small team vs. hundreds/thousands of ticket updates). Meaning, if the community had enough visibility into root case, commonality between seemingly disparate bugs, and the team’s plans for solving those strategically, then it would reduce a lot of status checking churn or feelings of abandonment.

Does it make sense to leverage Trello for bugs that will be fixed in a more strategic manner?

If in Discourse you grouped strategic bugs into meaningful high level categories, you could then track those categories in Trello much the same way that you track feature roadmap items today. You could also mark these categories as “blocked waiting on feature X, or Alpha X, etc”. Once closed, it would make bulk closing of tickets easier too, “Filter by X Label. Mark all as Resolved”.

Thoughts?


#2

Dwarf Fortress eventually started using a bug tracker, mostly fan-driven at first.

http://www.bay12games.com/dwarves/mantisbt/my_view_page.php

It was very useful for players but bugs are . . shall we say a much more fundamental gameplay experience in Dwarf Fortress than they are here. I think the difference with Radiant having a professional team instead of a single self-taught auteur probably makes a public bug tracker less necessary, though I hope they have one internally.

The only real downside to it is that I used to play a new game of DF about every six months. I don’t do that anymore. I get the itch, I check the bug tracker, I go “oh THAT’s why I stopped, yup, still a problem”, I play Stonehearth instead :stuck_out_tongue:


#3

They do have an internal bug tracker. It has been show in some livestreams in fact.
We try to address crashes and bugs that greatly impact playability first of all. But as the team has stated some times, they focus on developing the content of the next Alpha, then switch on bug fixing the related bugs that have just appeared.

They can’t fix all the bugs, since sometimes developing or improving the game changes the code in a way that makes those bug no longer applicable, and there’s no time to check/fix them all in an Alpha.

But they do add them to their internal database once they detect the issue here in the forum, and they know it’s pending to fix at some point. In Discourse we started using tags to at least sort the reports by game area, and had to add also the other sub-categories under Support to clean the results when searching.

I think you shouldn’t be bulk closing the bug reports… we merge the ones that are similar enough in order to have all the information in one place, but to close them it’s better to have confirmation from people that they aren’t experiencing the issue in the new build, that has to be one by one.

I’m not sure how they decide which bugs or in which order to fix them (the regular ones, not the game breaking ones).
That is up to them. Maybe we can suggest other items for the “Bug Fixes and Performance” section of the Trello board, that correspond to the tags in the Discourse (or other meaningful high level categories you would like to see, @megashub)?


#4

Absolutely. On the same page here. Love that approach.

They can’t fix all the bugs, since sometimes developing or improving the game changes the code in a way that makes those bug no longer applicable, and there’s no time to check/fix them all in an Alpha.

But they do add them to their internal database once they detect the issue here in the forum, and they know it’s pending to fix at some point.

Yep. That’s kinda what I meant by calling them ‘strategic bugs’ and/or technical debt items. They’re things that will get resolved one way or the other as a result of future work.

I think you shouldn’t be bulk closing the bug reports… we merge the ones that are similar enough in order to have all the information in one place, but to close them it’s better to have confirmation from people that they aren’t experiencing the issue in the new build, that has to be one by one.

Sure. That’s fine too. dev processes are highly unique to the needs of each project and team, and are also highly opinionated, and there’s a lot of value in that. When I said ‘close’, I should have probably just stayed more general and said ‘manage/maintain/update’.

Maybe we can suggest other items for the “Bug Fixes and Performance” section of the Trello board, that correspond to the tags in the Discourse (or other meaningful high level categories you would like to see, @megashub)?

Bingo. That’s what I was trying to articulate. :slight_smile: Thanks for talking this through with me so we can be on the same page.