Staying 3digit with open issues
-
@rainova I agree that issues from before 2.5 should be deleted. I also agree with your tag suggestion. Where I disagree is deleting issues that don't have those tags. There are issues like https://github.com/triplea-game/triplea/issues/10018 that are no brainer fixes which we can clean up (I already put in a PR to fix that one). I think with that strategy, a lot of the noise in the queue will be reduced.
-
When talking about "deleting issues" please don't delete open and closed issues concerning rules issues or incorrect handlings of certain game situations. Those usually are independent of the versioning - as long as those are not fixed.
-
@magicstyck said in Staying 3digit with open issues:
@rainova I agree that issues from before 2.5 should be deleted.
You are not agreeing with him: his/her proposal was to "delete" (I assume he/she means to close) only the error reports, not whatever issue.
-
@rainova said in Staying 3digit with open issues:
How about we delete all
Error Reports relating to versions earlier than 2.5?@Cernel I'm agreeing with the above statement.
-
@rainova
I am not an expert with the github issues organization, but I fully agree that we have way to many and there seem to be hundreds of duplicates. It is unfortunate that there is also no check for duplicates built in.
As a solution, I would also vote for closing some old ones (without looking for the detail) and reorganizing the rest. Whether this has to be 2.5 I don't know.
As stated, I do not know what is possible here and would not want to create a lot of manual work for anyone. I would volunteer to do some checks, but I would want to have an aligned plan on what to do first. -
@cernel said in Staying 3digit with open issues:
You are not agreeing with him: his/her proposal was to "delete" (I assume he/she means to close) only the error reports, not whatever issue
I suggest to close (delete was too rough) all error reports before 2.5, give tags to some of the rest and then close all those without tags, too.
The tags I mentioned above were my starting set; looks likeno brainerandrules issueare reasonable, too.With the given delevopment capacity, we can't get much done - so let's focus on what we can.
Would you agree with this approach? Which further should we take into account.
-
We now have 998 open issues. We still can avoid it - the issues 10073 10064 10063 10062 are fixed (by PR 10084) and can be closed.
I can't - probably don't have the rights. Who can and volunteers? -
@rainova @Panther @ubernaut
Maybe you can work together as a similar topic was raised in https://forums.triplea-game.org/topic/3121/triplea-development(btw: Thanks RaiNova!)
-
@frigoref however i can help
-
@rainova said in Staying 3digit with open issues:
We now have 998 open issues. We still can avoid it - the issues 10073 10064 10063 10062 are fixed (by PR 10084) and can be closed.
I can't - probably don't have the rights. Who can and volunteers?Has 10084 been merged ?
Edit
Ok just checked and it was 3 days ago. I'll close the above issues referencing 10084 -
@beelee said in Staying 3digit with open issues:
I'll close the above issues referencing 10084
Thank you, @beelee
-
@frigoref Happy to help, of course.
-
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!
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