Most needed bug fixes
-
Is there likely to be any fixes for the following limitations (bugs):
#1645 - sub combat with destroyer not resolved in correct order
#10032 - can't post to axisandallies.org
Lobby games for Global 1940 don't convert units from UK_Pacific to British
#8202 - unique key duplicated bugNow, I understand that #1645 is not easy (I myself have had a go) but surely #8202 needs a bit more attention.
Regarding doing a regression for #10032 perhaps a new generally available release can be put out.
-
I am surprised this did not get a bigger response.
I'm thinking we should use a github project to track problems. We could have a column for the higher impact problems.
For "most needed", how are we quantifying that? The 'urgent' label & 'regression' lable indicate items that need to be fixed with priority or that we should try very much to fix before releasing.
-
@lafayette said in Most needed bug fixes:
I am surprised this did not get a bigger response.
I'm thinking we should use a github project to track problems. We could have a column for the higher impact problems.
For "most needed", how are we quantifying that? The 'urgent' label & 'regression' lable indicate items that need to be fixed with priority or that we should try very much to fix before releasing.
We have some topics / issues that you can give the headline "most needed" or already have a similar title. Either rules related, game play related, PBF related, PBEM related... and so on.
Usually those topics are discussed by always the same handful of people and then many of them unfortunately evaporate by time without being resolved.
In most cases there is a Github-issue which gives details. Or, if not, at least a forum discussion here.
For example you must have missed the discussions on this forum and on axisandallies .org concerning #10032, that in the end @redrum (Thanks a lot!) took care about. Now we are waiting for a commonly usable release.
(See https://forums.triplea-game.org/topic/3124/nodebb-1-17-and-later-breaks-pbf-compatibility)So the problem IMHO is not another category or project or list - though a Github project to track problems might make some sense of course - , the problem is still manpower as well as time, interest and motivation to resolve those issues.
Manpower and time - for sure - seem to be the biggest problems.
-
@panther said in Most needed bug fixes:
So the problem IMHO is not another category or project or list - though a Github project to track problems might make some sense of course - , the problem is still manpower as well as time, interest and motivation to resolve those issues.
The fact that we have no trivial way to find these, I feel is a problem.
The 'major' label somewhat helps: https://github.com/triplea-game/triplea/issues?q=is%3Aopen+is%3Aissue+label%3AMajor
In part, how do we systematically keep track of this? Forum discussions are good things, but they do not take the place of a bug tracker or a bug queue. Asking someone to go through pages of discussion to try and vet out what the problem is, if it is still a problem, adds to the labor problem (notably if it takes 30 minutes just to read the description of a bug, that is 30 minutes that are not available for solving the problem).
Having a well curated list of bugs, where we ensure there is are repro steps, a save game to repro, would make fixing the bugs efficient. That list would make finding and tracking those bugs efficient as well. This is speaking to the state today where it is high overhead to fix problems partly due to the inefficiencies of the above.
Additionally, forum discussions are too free-form, we really want fairly rigid: "Do this in the game, step by step, click by click, see X, it should do Y instead". That would set up a developer to tackle a problem in short order and avoid the often back and forth of "where are you looking? where? oh, there? wait, where? which map? Which version? I'm not seeing it yet.. what else did you click? Oh, okay, I finally now have a save game to reproduce this and can now start working on this problem." Nota bene, we cannot fix any bug until we have reproduced the problem, so we require the explicit steps and a save game from someone..
Hence, the two problems of general issue management, and resolving those issues, do have a relation. Having really good issue management makes issue resolution far easier (and reduces waste (eg: the wrong fix) and reduces round trip communications to identify the problem (round-trip communication is sometimes necessary, but very costly).
-
@panther said in Most needed bug fixes:
I do want to respond to these sentences a bit more directly (I appreciate the points being raised).
Usually those topics are discussed by always the same handful of people and then many of them unfortunately evaporate by time without being resolved.
This is part of the point. Discussions kind of dwindle away. Bug tracker helps resolve this. If the end outcome is discussion without a proper bug being sent, this pattern would repeat itself. I think this having been a pattern is evidence that detailing bugs & expecting them to get fixed from forum discussions has limited success.
In most cases there is a Github-issue which gives details. Or, if not, at least a forum discussion here.
Indeed, though these are not quite easy to find and are not systematically triaged. I think that is the heart of where we can improve more easily. Having easier to find problems would help with new developers looking for meaningful start projects. The additional benefits would be in terms of efficiency of resolving the problems.
For example you must have missed the discussions on this forum and on axisandallies .org
I think this is a good example & evidence of why forum discussions are not scalable and just not good for bug reporting. I do not read 'axisandallies.org'. We do have another problem where developer time is split between different and redundant communication channels.
Forums is I think a great place for discussion. It is not bug tracking software. In the project history source forge bug tracker was used and maintained by a few developers with a lot of process opacity. That was not sustainable, as is any task where only a few people maintain a given system and not a team. Now, many years later, we are very exposed to the bug trucker (github issues), and we have a possibility to very easily distribute the management of that queue to a team (that are not all developers)
We have tried tracking bugs in forums before as well. It did not work well. It is a hard stance then that forums is for discussions, 'issues' is for tracking bugs (use the right tools for their correct purposes). The only gray area is how many different places should 'discussions' occur (currently we have like 4 places for that, which is not great. But 'bugs' and problems are to be tracked officially in one place. The bug queue is the source of truth for the state of bugs, not discussion threads on forums).
-
Let me at first assure you that we don't have any dissent. You and me we 'suffer' from the same problems , sometimes from different viewpoints, sometimes from the same point of view.
I would be totally fine with only Github as place for discussing and keeping track of issues.
But you won't convince the majority of players to deal with Github. This is why forum discussion takes place additionally. In the past others and me have created issues from other users' forum topics after validating them.
Now in order to finally get an issue resolved you sometimes need to fire from all channels. The Github issue is not enough to attract someone to resolve it? Well maybe an additional forum topic would help?
A Github issue and a forum topic are not enough to attract someone to resolve the issue? So let's see how the discussion on axisandallies .org goes... and ... finally someone helped out.
Now, that's in short the history of #10032.Maybe you should sometimes read axisandallies .org as this forum represents an interesting TripleA PBF-userbase. And you would for sure realize some more feedback than by the usual handful of interested users on TripleA .org (including me being part of both communities).
I think Github issues went well until some point in the past where the "Report to TripleA" feature was prioritized. From that time on the bug queue got flooded with cryptic, redundant and hard to follow issues, understandable and discussable only for a few of us. User created - understandable - issues disappeared in the mass and got out of sight. Today you won't hardly see any new user created issue - even me I wondered about the sense of creating another issue there that won't be noticed or dealt with by anyone. There are enough interesting issues sleeping in the list. Many of them "most needed", "urgent" or "major".
-
@panther Sorry, I should not have opened the debate of where we keep track of bugs. It is not a debate. The problem is that our tracking of bugs within the bug tracker is not super effective.
I'll try to respond directly to a few comments:
I would be totally fine with only Github as place for discussing and keeping track of issues.
Discussion of a problem is actually not fully welcome in the problem report. Discussion of how to fix is sometimes needed, but ideally we can re-consolidate the work item and re-summarize it. We want ideally items to shrink in size as progress and as learnings are made. For example, if we have a list of 5 items identified, we would split those 5 items into individuals tasks (possibly cards on a project board). Then as each one is completed, we close them. Thus as we make progress, the scope of work shrinks. Contrast this with a single issue where the discussion consumes multiple pages, items identified, overhead to know what is open & what is not, an generally the scope of the task/issue grows as we work on it.
At core though, how do we more effectively track our issues? There are some problems to solve there, the question of "which problems are open" and "which problems are most pressing" should be trivial to answer by looking at the bug queue.
Now in order to finally get an issue resolved you sometimes need to fire from all channels.
I don't think I agree with this necessarily. The example I think coincided with Ron stepping in to help & Roi made some efforts there. The spreading of the discussion and progress of that issue into forums I think made at least me lose track of its current state.
Maybe you should sometimes read axisandallies .org as this forum represents an interesting TripleA PBF-userbase. And you would for sure realize some more feedback than by the usual handful of interested users on TripleA .org (including me being part of both communities).
I generally agree, I do not have the bandwidth though. I generally need to try and spend less time in forums as this is almost a full time job.. Ideally we would people able to well curate problems and help gather and consolidate this feedback. I simply am stretched thin.
I think Github issues went well until some point in the past where the "Report to TripleA" feature was prioritized. From that time on the bug queue got flooded with cryptic, redundant and hard to follow issues, understandable and discussable only for a few of us.
That is not necessarily a problem as those issues have a lot of the information we would want and need for any kind of problem report. You can use this link to filter the problem reports out:
https://github.com/triplea-game/triplea/issues?q=is%3Aissue+is%3Aopen+-label%3A"Error+Report"+Many error reports represent cases where the game crashed. These are arguably more important than many other issues.
Today you won't hardly see any new user created issue - even me I wondered about the sense of creating another issue there that won't be noticed or dealt with by anyone. There are enough interesting issues sleeping in the list.
There is a bit of a unvirtuous cycle here. Many issues sleeping are not actionable. They have no repro attached to them, no save game, unclear what the fix should be, or have so much discussion the overhead to approach the issue is beyond a reasonable amount of time. Basically unless I, or any other dev, can read in an issue in under about 5 minutes, repro it by loading a save game and see the problem in another 5 minutes, and have a clear idea of what the fix should be, without those pieces the issue will continue to sleep. I'd suggest that is why those issues are sleeping. We do not have the capacity to spend time as developers to build up repro cases for every problem reported, we will focus on the ones where we can attack them effectively because they have clear & concise problem descriptions. Anything where we cannot do that, we likely should resolve as a sleeping issue only hurts us.
Many of them "most needed", "urgent" or "major".
How are you finding these? I see only 3 listed as 'major'.
The suggestion to use a project helps as we can classify items more easily. We can add items as 'cards', a very lightweight item and avoids adding another issue.
issues disappeared in the mass and got out of sight.
This was a criticism and a problem well before we had the ability to report errors from in-game. I think it is cyclic logic that makes this a compounding problem: "we will not create well made problem reports because the existing problem reports are not being solved. The existing problem reports are not being solved because the overhead to entry is too high and the cost to create a repro case further makes fixes prohibitive"
-
@panther said in Most needed bug fixes:
But you won't convince the majority of players to deal with Github. This is why forum discussion takes place additionally.
That is not the goal per-say. A user who posts in forums, "this is broken", is not worth a developer to look at when they can instead work more effectively on a problem where someone has taken the time to detail the steps to reproduce the problem. Many projects auto-close any & all issues if that diligence is not done.
If players want to interact directly with the bug queue, it is approachable. Having a form for a bug report does help at least ensure the right questions are asked. Without that, the forum postings often are vague and require lots of back and forth, "what exactly were you doing? which map? etc.." Which is even worse in some ways than having a poorly filled in problem report.
Basically the bottom line, forums is great for discussions, though it is not task tracking software. The bigger problem is also that players are not willing or able to take the time to create good problem reports, and so things like stack traces are missing and basic things like good reproduction steps. Even if this were a clean process, most players just want to play a damn game and aren't won't bother to create any kind of problem report. It is worthwhile to make that process easy, but to some extent the goal is not to have players creating perfect problem reports directly into the problem tracker (that simply will never happen).
The goal instead is at least how do we effectively use the problem tracking software. Issue tracking is a core port of software development, any tracking tool needs to give us the following information easily:
- is the problem open?
- what is the problem?
- attachments with save games or any other supporting config & files to reproduce the problem
- a clear statement of what a good fix would be
- indication of who is working on the problem
- indication of relative priority
So with the above, I should be able to view a list, easily, of high priority items that are open and that nobody else is working on. We have some of the above today, but our process is incomplete I think to be able to fully deliver on the above. Hence, the question: "what is important to work on?" My response to that question: "effective use of bug tracking software should make the answer to that trivially easy to find. The fact it is not currently means we need to use the problem tracking software more effectively such that it would be trivial to answer that question." Answering that very question is really the heart and purpose of problem tracking software.
-
Another 2 cents, it has been suggested that we attempt to have a few dedicated people to really manage the problem list. To ensure that items are concisely stated, etc, and the in-concise items, or out-of-date are cleaned up and removed from the queue.
Dev labor is very scarce, to the point where we should only be doing high ROI activities. Anything to help reduce the cost of working on problems, and the more that other people can help with that, the more we will help with the labor problem.
-
Sorry @Panther for throwing a lot of content at ya, this topic is not trivial. Though I have hijacked this thread into a bigger issue of "how do we manage our problem queue"? If we had a clear problem queue, an effective one, the answer to this question would be readily maintained and visible. I've created a new thread to discuss in detail (rather than further hijack this thread more than I already have) : https://forums.triplea-game.org/topic/3168/triplea-strategy-for-dealing-with-github-issues-problem-reports
