TripleA Strategy for Dealing with (Github Issues) Problem Reports
-
This thread is to discuss how we want to handle the situation of users contacting us via github issues to report a problem and/or suggestions.
Specifically these are problems reported via: https://github.com/triplea-game/triplea/issues/new/choose (Report a Problem)
This thread is picking up from a general question of "which user-facing problems are most important?" (https://forums.triplea-game.org/topic/3128/most-needed-bug-fixes) The answer to this question should be self evident via a well managed problem tracking system (AKA: a bug tracker). This thread is to discuss how we can arrive to a situation where we have a well managed problem tracking system.
It is not negotiable for us to change bug trackers away from Github Issues, this conversation is how do we use the tools in Github in conjunction with manual processing and all of our available communication channels, as best as we can to have a well managed problem tracking system.
-
Proposal: Create a project called 'Problem Tracker'
Columns
- Triage
- Standard
- Urgent
- Being Worked On
- Done
Key Concepts
- items higher up on the column are higher priority than those below
- the top 10 items are kept in pretty strict priority order. All items below are considered roughly equivalent priority
- insertion of new items into a column generally asks "is this more important than any of the top 10 items?"
- labels applied to issues are visible on the project board and you can filter for specific labels. So for example we could have a "game rules" label, filtering the project by that label, you would see the priority of all "game rules" problems . We could have another label for example of "UI Problem", "AI Problem", etc..
- we can have problem reports go directly into the 'triage' column
Demo
As a proof of concept, I created the problem tracker project, note the description: https://github.com/triplea-game/triplea/projects
I added a few issues to give a demo of what it would look like, here is a screenshot:
Requirements to Adopt
- We would want to define the flow of items in a more formal manner and more explicitly. EG: What happens if an issue is not ready to move to a back log column?
- We would want to be formal about the project role of the person that is managing the problem board. Notably explicitly identify the role and current occupants. This could be a 'github team' where we add the problem managers, and thus we could view membership by viewing that team. Then we'd just need to the find the
poorheroic volunteers that would help here - Update the config for github issue creation to add the problem issues to the problem tracker project (relatively easy)
- Start triaging, add all problems in the issue list to this project & then start triaging & prioritize the backlog
End Result
- you could view problems by type by filtering via label (EG: interested in AI problems, good new developer starter problems, graphics problems, etc..)
- you can view open problems very readily and if they are being worked on by others
- we can see the relative priority of all problems. Simply viewing the board would tell you what are the top 10 urgent problems and the top 10 overall problems. (The urgent problems are analogous to saying "fix first" and the standard problem is saying "fix after we fix the 'fix first' problems")
-
This is looking good.
How many Back Log: Urgent items are there? If there are 10+ then there is no point in filling out the Back Log: Standard problems as they will never be actioned, as the Devs will not have the time to action them.
A Dev new to TripleA would probably still want to work on an urgent problem as it has the most impact.
-
@thedog said in TripleA Strategy for Dealing with (Github Issues) Problem Reports:
then there is no point in filling out the Back Log: Standard problems as they will never be actioned, as the Devs will not have the time to action them.
Wouldn't this logic extend to any case where we have too many 'standard' items as well?
Even if we never complete the backlog (which is something of a tautology), the value we are trying to get here is prioritization and visibility. If we stop 'filling' out items, then wouldn't we lose that benefit? Of note, we are not really 'filling' out items, simply dragging items into a column to reflect their relative priority. Part of the idea is that important items can hang around and bubble up to the top and "lesser" items would bubble down.
as they will never be actioned, as the Devs will not have the time to action them.
I disagree with this on the basis of historical experience finding and fixing release blockers. We have easily had more than 10 such tasks at given times. The statement as well that as soon as we have more than 10 items, that we will never complete those ten items, no matter how much time goes by, seems logically flawed as well (unless there is an absolute halt in all development efforts, or alternatively development efforts completely ignore the 'urgent' items and work on different items altogether)
How many Back Log: Urgent items are there?
I don't know. Completing the adoption process should answer this question after we have categorized the current items.
-
@lafayette said in TripleA Strategy for Dealing with (Github Issues) Problem Reports:
I don't know. Completing the adoption process should answer this question after we have categorized the current items.
Fair enough.
-
People should self designate. If it's "Urgent" like lobby is down and nobody can play, should be Urgent then.
Having trouble with incorrect game behavior, maybe yes, maybe no. If it's a popular Lobby Game, then I'd say Major.
Can't update my game to git or a in game problem, well yea .... it's a problem.
Not all people we'll be on board, and there's obviously room for interpretation, but if they have an option to choose from ... might be a start to sort issues a little bit.
Just a thought
-
@beelee said in TripleA Strategy for Dealing with (Github Issues) Problem Reports:
People should self designate.
That'd bee too random as I am afraid.
I would rather prefer a sort of an evaluation before a classification takes place. -
@beelee , being able to assign & change projects needs a project 'triage' permission - the public is unable to do this.
How to prioritize is for sure a bit of an art and would look differently to different people according to their objectives and their sentiment of what the project objectives are.
I would like to clarify a bit that 'urgent' only indicates "time-sensitive" (for whatever reason). The vertical position of an item indicates it's rough importance.
Responding to @TheDog :
A Dev new to TripleA would probably still want to work on an urgent problem as it has the most impact.
Funny enough, this might not be the case. Generally new developers would want to make pretty small and targeted changes to simply run through the process. This would generally start with documentation updates regarding setup & building and running code locally. From there taking on tasks that are bite-sized & very well defined would be the next likely target.
An urgent task is something time sensitive & developers try to avoid working on the same thing at the same time (at least not without being aware of it). So, someone looking to just exercise the code change process would be unlikely to want to pick up a task that needs a time sensitive execution, and where the group is waiting on the item to be completed by only them (puts quite the burden on their shoulders.
@TheDog, your point about "what if the urgent takes up all of dev time, what's the point?". I've been thinking about this a bit:
- the prioritization and organizing work should be relatively durable. Whenever there is availability, a reasonably well kept queue would then get used
- There are more benefits as well, simply having people de-dupe issues and give something of a first pass is excellent. It's much better to ask for the additional missing details sooner rather than later. Notably we want as clear-cut of a reproduction case as possible, and where that is not really clear - we likely want to filter those tickets out altogether.
-
@LaFayette
I was being a bit like a devil's advocate, but with good intentions of not wishing to waste peoples time.So your proposal for a Problem Tracker still stands, good.
