Clarifying Requirements / Keeping Tickets Actionable -> Getting our backlog done

[DanVanAtta]

An actionable ticket queue is important for ensuring we actually fix problems and don't spend time just prioritizing tickets that we spend all our time prioritizing. Having an endless queue of assigned items makes assignments meaningless. It's similar to that TODO list that includes cleaning the garage and attic that both never seem to get cleaned.

I think it's been an endemic project problem where the ticket queue gets out of control. Looking to the source forge queue, there are tons of tickets there, more than could ever be worked on. Long ticket queues create overhead and contribute to an even longer ticket queue ("The bureaucracy is expanding to meet the needs the expanding bureaucracy") . We also are seemingly bad about really requiring tickets to have the needed information and to be decided on how they should be fixed so that they are actionable.

I'd like to explore how we can incorporate the best practice of making all tickets actionable. If a ticket is not actionable, then we should try to make it actioanble, if never actionable, then closed (if you can't fix something, why keep it as a ticket?).

I'd suggest we do the following:

• require stale (no activity for 2 weeks) tickets to have a trailing comment indicating what needs to be done or attach a "requirements needed label"
• tickets that remain with a 'requirements needed label' are closed after some period of time if we can't clarify what needs to be done.
• tickets that we cannot reproduce that are older than 3 months are closed

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If there is something that can be done to resolve this issue, please add a comment indicating what that would be and this issue will be re-opened. If there are multiple items that can be completed independently, we encourage you to use the "reference in new issue" option next to any outstanding comment so that we may divide and conquer.

[tvleavitt]

I can test on recent versions of OS X. Easier if it's scheduled so I can set aside time on my calendar in advance, and have specific direction. How many testers do we need to keep the OS viable? Do we have a MACROS specific section / thread on the Forums?

Thomas Leavitt

On Tue, Mar 10, 2020, 10:11 PM Dan Van Atta notifications@github.com wrote:

An actionable ticket queue is important for ensuring we actually fix problems and don't spend time just prioritizing tickets that we spend all our time prioritizing. Having an endless queue of assigned items makes assignments meaningless. It's similar to that TODO list that includes cleaning the garage and attic that both never seem to get cleaned.

I think it's been an endemic project problem where the ticket queue gets out of control. Looking to the source forge queue, there are tons of tickets there, more than could ever be worked on. Long ticket queues create overhead and contribute to an even longer ticket queue ("The bureaucracy is expanding to meet the needs the expanding bureaucracy") . We also are seemingly bad about really requiring tickets to have the needed information and to be decided on how they should be fixed so that they are actionable.

I'd like to explore how we can incorporate the best practice of making all tickets actionable. If a ticket is not actionable, then we should try to make it actioanble, if never actionable, then closed (if you can't fix something, why keep it as a ticket?).

I'd suggest we do the following:

• require stale (no activity for 2 weeks) tickets to have a trailing comment indicating what needs to be done or attach a "requirements needed label"
• tickets that remain with a 'requirements needed label' are closed after some period of time if we can't clarify what needs to be done.
• tickets that we cannot reproduce that are older than 3 months are closed
• tickets that we cannot fix because we cannot test are closed. This is particularyl Mac OS problems, ideally we'd remove the mac OS specific functionality as the ROI is not favorable. (The burden to test the game on all OS is a very high one, we should not take that lightly at all).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/triplea-game/triplea/issues/6036?email_source=notifications&email_token=ABB5HAI72U2GH7X4CXTJAS3RG4MQ5A5CNFSM4LFNZHB2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IUDBYAQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB5HAM7X7LLI7XVO6ISKSTRG4MQ5ANCNFSM4LFNZHBQ .

[DanVanAtta]

@tvleavitt it's a good time to do any testing that you can. I think the current 2.0 is effectively now a RC (after 3 or 4 months now of being in a RC phase!).

[DanVanAtta]

@ron-murhammer / @RoiEXLab what do you think of adopting the OP as policy? It helps clarify what we expect and when we close tickets.

@Cernelius / @panther2 FYI, appreciate any input/thoughts that you may have.

[RoiEXLab]

I'm fine with your suggestion

[panther2]

@DanVanAtta

In principle I agree with your suggestion.

In that context allow me to add another important aspect for Keeping Tickets Actionable: That would be the willingness of a (any) developer to take care.

As you know my focus lies on playabilty with regards to rules compliance. Especially @Cernelius and me spend a lot of time in investigating and discussing original game rules and their incorporation (or not) in TripleA. We have created respective issues in the past. Some are still open, some of those are even older than 2 years. The topics behind are often very time consuming because of their complexity and because of different rulesets.

And in some cases the issue behind requires even more analysis and investigation. This is why sometimes a "requirements needed label" might be appropriate. But this extra work is only reasonable when any developer is willing to work together regarding the specific topic.

In the past issues or tickets remained "stale" or lacked action because no one with the ability to take action from a coding side was interested enough to care or maybe simply had no time to care. I don't accuse anybody here as we all have our priorities - and that is perfectly fine of course.

In other words: If any coder would say "Hey I am going to resolve that issue together with you based on your further input" I would be more than happy to move on.

(Sidenote: I have to accept (in fact I have already accepted) that some rules related issues probably never will be fixed - but the sometimes intense work behind them would not justify them to be closed at any time.)

[DanVanAtta]

That would be the willingness of a (any) developer to take care.

I would avoid assigning motive. There is a lot of value in having tasks well spelled out such that a person who wants to do development can find something and jump in. If we ensure that a single dev needs to be an expert, talks through an issue and then works on it, we're going to be lacking those kinds of tasks as well as depending completely on everyone being a rules expert.

As you know my focus lies on playabilty with regards to rules compliance. Especially @Cernelius and me spend a lot of time in investigating and discussing original game rules and their incorporation (or not) in TripleA.

This is highly appreciated. I respect this takes time. Regrettably, I can guarantee you that an actual fix takes anywhere from just as much time to 10 times long.

Perhaps we can think of it in this way, a task has multiple phases:

1. A user desire
2. A business requirement
3. A business specification
4. A technical implementation plan
5. A technical specification
6. A machine specification

EG:

1. I want the game to be faster
2. The AI is slow on large maps
3. Improve the AI to be faster on NWO, in this round, with this save game
4. Update ProPurchaseUtils in the 'findTerritories' method and update ancillerary test cases
5. Given a data state of XYZ, 'findTerritories' should return ABC
6. (machine spec is usually automated once you have a coding specification spelled out).

Here is another example of differing ways to specify a requirement:

• carriers with allied units is not implemented correctly
• given an allied carrier and carrier of same player, a fighter should be able to land on both
• here is a save, the fighter should be able to move and land on sz34, but is unable to.

In all cases it takes time to get down to the next granular level. Machines cannot invent the code they execute, it has to be specified to an incredibly precise level of details. Any gap from business requirement to machine specification must be defined by the developer.

IN essence, the close we can get to an exact requirement, the less work it takes to get to the beginning of coding. Any requirement, we need to come up with the save game, the exact scenario, we need to demonstrate the problem, see the problem, understand the code, understand surrounding code, ensure our fix is okay for all variations of the game, there are no regressions, that the game play is then changed in the way we expect.. So reading what needs to be done, is just a step one, hence why it likely always takes longer to code than it is to define requirements, and worse yet, someone always has to define requirements and any gaps fall on the developer to do and fill in.

And in some cases the issue behind requires even more analysis and investigation. This is why sometimes a "requirements needed label" might be appropriate. But this extra work is only reasonable when any developer is willing to work together regarding the specific topic.

We are getting into a chicken and egg problem:

• i see a ticket
• it requires 30 minutes to read and understand, at the end of that perhaps I may not even be able to work on it.

If on the other hand the ticket said "here is a save game, make the engine do XYZ", then I can start on that in 5 minutes.

Since none of us are full time, we might have only an hour at a time. Spending half that time to just read and maybe start coding means we're going to spin our wheels. For example, the other day it took 3 hours to figure out it was not easy to get the game engine to produce a list of territories where placements can be made. Should be simple, turns out it's not, it took a full 3 hours to figure out it's a lot of effort to even get to that change. Getting there probably would be anywhere from 5-10 hours.. Hence we are at a chicken and egg problem, there is more time needed than we have to fix everything, to even start fixing many things, we need to invest time we don't really have.

In the past issues or tickets remained "stale" or lacked action because no one with the ability to take action from a coding side was interested enough to care or maybe simply had no time to care. I don't accuse anybody here as we all have our priorities - and that is perfectly fine of course.

Usually it's low hanging fruit, the tickets that are clear and quick to fix that got fixed. Otherwise our intake process is almost broken and guarantees if a ticket is not well defined or needs a lot of effort that it'll fall into the queue and we have been in the bad habit of treating it as a LIFO (last in first out), meaning the old tickets never get done.

In part with better queue management, and tackling tickets in order, we'll have a better hope. On another side, you're right, there are competing priorities. A number of them are to still enable it so development can be faster and it doesn't take for example 3 hours to find out that something simple like getting a list of placement territories is not going to be readily available.

In other words: If any coder would say "Hey I am going to resolve that issue together with you based on your further input" I would be more than happy to move on.

I understand this sentiment. Our queue management practices are weak. The existence of a queue actually makes it harder to work on a queue. Any effort spent towards queue management would not exist if you did not have a queue to begin with. Hence, if there is something that we can't work on in the queue, or that is not well defined, we need to remove it. That should make perfect sense, if something is going to sit, it's not doing any good, and we should see why it's going to sit.

If we have tickets that need hours and hours of back and forth, then that ticket is not going to get worked on either as the level of engagement is too high. On the other hand, if that results in a 3 line statement saying "here is a save game, the engine needs to do XYZ", then it's much more likely someone will pick it up.

In essence, any ticket that has over 5 pages of text in it, we can assume it's not going to get worked on at this point, it requires too much effort to even know what to do that the ROI is poor compared to the many other things we want to do.

Furthermore, most development tends to be the 'fun' stuff, very few of us are working general bugs or maintenance (it's not rewarding, tedious, difficult, and it's not something that is particularly personally exciting).

Maybe you can think of it as a blueprint for a table. If you spend a lot of effort to really define the blueprint well, then building the table will go quickly. If the blue print is on the other hand just "build this table", and you keep coming back "no, it should be granite", "no, it should fit into this space", "no, it needs to have 3 legs and support 500 lbs of weight", and then before you even get started on it, you need to read the full history of all the furniture that needs to go into a building, some already built, before you catch the task of "build a table". And then when all is said and done, it's still going to take time to build that table no matter how well blueprinted, but if you stay clear, concise, define exact requirements, then you minimize the amount of time before construction needs to be done and reduce churn/effort during construction which maximizes the chance you'll get what you want actually done.

[DanVanAtta]

At the end of the day, TripleA needs a team of 10 for 2 years to really get to where we all want it to be; it just needs too much labor for what we have. The time to code everything is just extreme, unbelievably extreme. Vague requirements add to that time as developers must develop those requirements down to machine level requirements, needing to do that alone creates a barrier to entry and there are other low hanging fruit, strategic initiatives, and for many developers just pure personal interest to work on other things.

[DanVanAtta]

Bottom line:

• proposing here that we adopt better ticket queue management practices
• all issues we strive to leave the last comment with the needed action items summarizing what is needed or what the next steps should be
• strive to have it that work can start on any ticket in around 5 minutes by reading the last comment (and maybe first comment) on a ticket, and that there is something that can be actively done.
• if we are unable to get to that point after clarification and are unable to summarize action items needed, and are left unable to do anything; then we close the ticket to reduce the overhead of ticket queue managment and focus on what we can fix.

[DanVanAtta]

One more point of summary:

• ideally we want all tickets to have the requested fields filled in (the boilerplate question fields of version, OS, what to fix, and how to fix)
• we'd want a save game
• a concise statement that is like "the game should allow fig in sz53 to move to sz54"

IF all tickets were like that, they'd all be readily worked on (whether they are actually work on is hopefully then just a matter of time).

[panther2]

@DanVanAtta Thank you for the insights that I understand well.

While I am sure that the vast majority of the issues opened by me follow the summary stated in your last posting, I agree that keeping the issue list as small as possible is profitable.

So in order to prevent rules issues from getting lost I will continue to care for and update the list I am maintaining for example here: https://forums.triplea-game.org/topic/1549/rules-issues-with-the-triplea-engine

For this list it does not matter whether an issue is open or closed.

Or is there a better instrument for keeping track?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If there is something that can be done to resolve this issue, please add a comment indicating what that would be and this issue will be re-opened. If there are multiple items that can be completed independently, we encourage you to use the "reference in new issue" option next to any outstanding comment so that we may divide and conquer.

[DanVanAtta]

@panther2 ; sorry for a late response. I'd recommend ensuring those tickets being open and have a 'bad game-rules' labels on them to group them.

Closed tickets, unless marked as ice-box, are not going to be re-visited. I hope the ice-box tickets get revisited, but that seems more optimistic than likely (we have essentially admitted defeat on them, in essence a triage process to focus efforts on known current and newer tickets)

[panther2]

@DanVanAtta

I'd recommend ensuring those tickets being open and have a 'bad game-rules' labels on them to group them.

Alright, thanks. I will try and keep track of that.