Staying 3digit with open issues
-
How about we delete all Error Reports relating to versions earlier than 2.5?
Yes. It is one reason to launch 2.6 even, so we can delete the 2.5 error reports. It's been on my mind that adding a version label by the server onto error reports would help with this mass delete process.
How can I assign https://github.com/triplea-game/triplea/issues/10073 to myself?
We need to simply add you to the 'community' group that has 'triage' rights. I have sent you the invite.
How about the tags
Tags I think work better when they are more permanent. For example, after we close an issue, the tag is still there. Adding items to the '2.6' project I think is preferable. Issues can be assigned to projects. This way when we look at the project board, we can see the full list of issues & any additional cards (AKA tasks) added to the 2.6 project.
How can issues relating to Version 2.6 and UnitChooser be assigne to me - either automatically or by a person in the role of an issue manager?
I think there is a config that can be done such that files matching a given path can be assigned to a given individual. Being able to more automatically triage issues would seemingly be helpful so that when there are gaps in people doing the triage, it does not get to be quite so backlogged.
I think with that strategy, a lot of the noise in the queue will be reduced.
Re: Noise - correct me if wrong, the noise is largely from errors that are not de-duped, or from errors that are coming from 2.6; Errors are de-duped based on title and version. Hence an error title that changes will be noisy and if we are consistently submitting reports using pre-release, the version will keep changing.
The error reports seem noisy otherwise, but they are real problems and using seeing a game crash message that will prompt them to save & restart if they can (no matter the error, even if it is something kinda bogus and should not even be mentioned to a user, the user thinks the game crashed if the game hasn't actually crashed). So, working through the errors is a root cause fix to the noise problem.
For better de-duping, we could disallow reports for prerelease versions altogether. That would be a shame because the automatic stack trace is nice. Ideally anyone doing a prerelease error report would be required to add more commentary to an error report, presumably they are acting in a QA role and should not be just submitting a vague stack trace with error message only and walking away. Hence if we detect the problem is a prerelease version, we could require more details be given. I'd rather solve the lack of details on a prerelease via process though to see if we can enrich the experience rather than add gates.
For the error messages that keep changing, an idea is to tag various errors with an ID and then de-dupe based on the ID and version. When we de-dupe on version, de-duping only on the signifcant part of the build number might help as well (eg: 2.6 only vs 2.6.xxxx)
Those usually are independent of the versioning - as long as those are not fixed.
@Panther, I hear this, but the presence of 300 tickets actually hinders that 300+1 ticket from being fixed. We have a problem where things are getting lost in the queue, having items just hang out really helps nobody. I think we need those issues to be indexed & closed. We need some sort of compaction process I think. Worse yet, any such issue likely has pages and pages of text. To even approach the issue, someone needs to spend many minutes reading (enough that they run out of time before they even start to fix that issue, let alone any issue, and the problem then gets worse).
Do you have any ideas how we can possibly resolve this? Any ideas of how we could compact issues so that there is less content & more clarity as we solve a problem? IE: when we solve part of an issue, the overall work remaining should decrease, not increase. It should take less time to understand that (c) and (d) are a problem only when (a) and (b) are already solved, rather than spending 30 minutes to learn that (a) and (b) are solved, the discussion about that, and then only start to tackle (c) and (d) after maybe thinking they are still issues.
Hopefully that makes sense. A problem is worked on, right now the tax for anyone else increases instead of decreases. Not only do they have to trace through every mention of any part of the problem, but they need to trace through every part of the solution to then understand what is left. IMO this is broken up by decomposing problems from the start and getting it so that issues are atomic, 1 fix, 1 issue closed. In this way we start with 10 issues and then when we make progress we close a few and forget about it. I think the many-problem issues are a problem for us.
-
well I went through all my issues at git. Closed one, at least temporarily. Have 3 open. In case you're not that familiar with git, like me, you can go to your profile and then hit "Issues" up top and it'll show all the one you made.
I chose to go through my entire git history before figuring that out though lol
Anyway, made a small comment on the 3 so they could resurface for a bit.
-
@beelee all of these issues can be closed. The problem is related to the new lobby not being deployed. No code changes are necessary to fix them.
#10023 #10053 #10079 #10008 #9989 #9966
-
@magicstyck said in Staying 3digit with open issues:
@beelee all of these issues can be closed. The problem is related to the new lobby not being deployed. No code changes are necessary to fix them.
#10023 #10053 #10079 #10008 #9989 #9966
Ok I'll just reference here for why they were closed
-
@lafayette said in Staying 3digit with open issues:
@Panther, I hear this, but the presence of 300 tickets actually hinders that 300+1 ticket from being fixed. We have a problem where things are getting lost in the queue, having items just hang out really helps nobody. I think we need those issues to be indexed & closed. We need some sort of compaction process I think. Worse yet, any such issue likely has pages and pages of text. To even approach the issue, someone needs to spend many minutes reading (enough that they run out of time before they even start to fix that issue, let alone any issue, and the problem then gets worse).
Do you have any ideas how we can possibly resolve this? Any ideas of how we could compact issues so that there is less content & more clarity as we solve a problem? IE: when we solve part of an issue, the overall work remaining should decrease, not increase. It should take less time to understand that (c) and (d) are a problem only when (a) and (b) are already solved, rather than spending 30 minutes to learn that (a) and (b) are solved, the discussion about that, and then only start to tackle (c) and (d) after maybe thinking they are still issues.
Hopefully that makes sense. A problem is worked on, right now the tax for anyone else increases instead of decreases. Not only do they have to trace through every mention of any part of the problem, but they need to trace through every part of the solution to then understand what is left. IMO this is broken up by decomposing problems from the start and getting it so that issues are atomic, 1 fix, 1 issue closed. In this way we start with 10 issues and then when we make progress we close a few and forget about it. I think the many-problem issues are a problem for us.I understand that - and will think about it.
-
How can issues relating to Version 2.6 and UnitChooser be assigne to me - either automatically or by a person in the role of an issue manager?
I think there is a config that can be done such that files matching a given path can be assigned to a given individual. Being able to more automatically triage issues would seemingly be helpful so that when there are gaps in people doing the triage, it does not get to be quite so backlogged.
Who volunteers to do that?
-
@rainova Am I understanding you correctly that you are for looking for a volunteer to make a config on github? If so, what should be the exact rules you propose this volunteer should configure?
-
Just to motivate people, I took care of about 50 tonight!!
Admittedly, it was getting rid of duplicates, but hey, every bit helps!
-
@ff03k64 said in Staying 3digit with open issues:
Just to motivate people, I took care of about 50 tonight!!
Admittedly, it was getting rid of duplicates, but hey, every bit helps!
:beaming_face_with_smiling_eyes:
-
@ff03k64 Nice work. The "Out Of Memory Error"
https://github.com/triplea-game/triplea/issues/10114
seem like a lot of duplicates too. Whacking those issues into a single one would definitely help make things more manageable. Make it so one can find the unique issues easier anyway.I'm gonna try and kill some duplicates off myself soon. : )
-
@beelee Some of the issues we won't be able to fix. "Out of Memory" has too many causes to solve unless we have some specific steps of when and how it happened. Was the person running 5 instances of TripleA? How many other apps were they using? How much memory did they already have?
Beyond this, TripleA uses some silly settings like min memory for the UI windows to then spawn a new process for the actual game. So even though the UI windows need maybe 32MB of memory, we allocate potentially half a gig or more. Before this gets into more of a rant, we are probably only going to solve maybe 5% of issues that come in. We really need to do be disciplined about letting some issues go.
Thus, any issue that does not have a save game attached to it, probably can go away. The effort to attach the save game is not justifiable if that time can be used to solve an entire other issue where someone took the effort to attach the save game.
Does the issue explain clearly and concisely what the problem is? If not, the time to clarify it also likely does not justify the time when that time can be spent fixing actual other issues.
I think the 'triage' task we have before us is basically to either try and get issues into such a state, where it is clear, has the save game that reproduces the problem exactly, or we be honest and close them.
Any error reports likely will be bulk closed on the next release. We do not need to spend very much time there.
==================
For automatic triaging - those would be github actions that can parse/scan the content of an issue and then automatically assign labels.
-
@lafayette said in Staying 3digit with open issues:
Thus, any issue that does not have a save game attached to it, probably can go away.
Is it possible to have the automatic reports include a save game?
-
@ff03k64 said in Staying 3digit with open issues:
That would be a feature request..
Github issues cannot have arbitrary binary content uploaded. We would need to upload the save game file to the server and then create a link to access the save game. Disk space becomes a big consideration, a thousand or so 5MB save games really add up.
Having automatic saves after an error has happened is only a partial win as well. Often we want to see the error happening so we can walk through the code to see what it is doing and how it is winding up in a bad state. Often we can see after the fact that things are in a bad state, the question is how. For a lot of cases as well, the issue report is more about game behavior and were not automatic uploads. Not to pick on anyone, we've examples where X rule is wrong, but no save game provided that has the setup so we can quickly observe the rule as-is-today, and then observe it following any fix. Of course a developer must do the above, so perhaps it also makes more sense why having a save game at that point, ready-to-go, would save a lot of effort. We also avoid various confusions too, often it's like "which round? Which unit? What did you do exactly? You did a 'combat', where, with what?"
This I think is getting away from it though. How do we better handle issues? What is our metric of success, the pain we mitigate by solving issues, the value we provide, the time it takes from open to close, the number of issues?
Second, how do we reduce the needed labor to handle issues, let alone solve them?
Often all problems are solved simply by solving problems.. If we could solve issues then they come in, then all these questions would be "how do we better manage a ticket queue of size 0?" At that point the answer is trivial, there is nothing to manage.
Some philosophies state that important issues will keep coming up. In this vein, close all issues and keep doing so until the team is able to keep net zero issues. Only then think about the backlog, if at all, because the important items will come up. In the meantime the effort we spend now is potentially just 'work about work.' I don't want to be defeatist here, at some point we need to consider the implications when we resolve fewer issues compared to how many are coming in.
-
@lafayette said in Staying 3digit with open issues:
Some philosophies state that important issues will keep coming up. In this vein, close all issues and keep doing so until the team is able to keep net zero issues. Only then think about the backlog, if at all,
This seems a good idea to me. You'd still want to consolidate the same/similar ones into one issue or you'd just end up with a pile of them again until it's solved.
Think that would probably need to be done manually. Idk, maybe not
-
Close the lot.
Why?
On the current very stable version of 2.5.22294 I would say almost all the map related errors are caused by the players themselves, not giving themselves a decent amount of RAM or a reboot before they play a game.However, I think the forum moderators probably know the real outstanding issues and they should drive any spare dev time.
Maybe the moderators collectively should between themselves pick the top 3 issues to be fixed, get the background and saved games from the player(s) for the dev, so the dev does not have to do it.
This way when a dev has spare time he has a list of just 3 real issues, with backgrounds, they can pick one of the 3 and fix it?
https://forums.triplea-game.org/tags/thedog
https://forums.triplea-game.org/topic/3741/curated-best-top-maps-triplea-guides -
-
@thedog said in Staying 3digit with open issues:
Maybe the moderators collectively should between themselves pick the top 3 issues to be fixed, get the background and saved games from the player(s) for the dev, so the dev does not have to do it.
I like this thinking. What if the top 3 are not easily fixed? Nonetheless, having a list of clean issues ready to be worked on would go a long way, I support anything that helps move us in that direction.
As an idea to consider: The 'projects' feature could be a way to help bucket and group items. Not all items need to be issues perhaps and can instead be converted to project cards (if there is not that much to have written, if the idea is still very early, and if there has not yet been much discussion). For example, we could have a project of 'improve game rules', 'improve game stability', etc.. Perhaps we could do a 'enhancements & features' one of some sort.
-
Another idea, we could de-dupe problem reports on the 'major.minor' version instead of the also using the build number. EG: all 2.6 would be grouped together and de-duped.
Is there a way we can also improve the pre-release problems? It's disheartening to see people using prerelease, which is meant for essentially testers and just demo feedback, submitting bug reports but not following up with details. Notably, who they were that submitted the problem, how they got to the problem. EG: https://github.com/triplea-game/triplea/issues/10235
This kind of item really just clogs our queue as the problem is well known. Though, because we de-dupe based on full number, we get this brand new every time a new prerelease is downloaded and someone submits this.
-
To reduce the use of pre-release problems we could;
- have an approved list of testers/demo users who can give feedback or are flagged as such and therefore have more weight
- Feedback must include a saved game
- All feedback fields must be filled in
Otherwise it will be rejected or just have less weight
Alternatively the feedback could be awarded points automatically for its content.
Points could be awarded for each field filled in, a saved gamed etc, so the best value feedback is displayed first and least point valued, displayed last. -
A team that evaluates/classifies issues would be a good idea.
This might be useful for separating issues from non-issues.
Sometimes users think they discovered e.g. a rules related issue when it was in fact their misunderstanding of the rules. Also we can sort out problems on the user side, unrelated to the software. Just to name some examples...
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login