@rogercooper said in Terms: Nation - Resolved -:

As there is really no perfect term, we might as well leave it as "player".

To one extent I disagree, as "player" is the name for something else, eg: Bob and Jill are playing a game, Bob is playing as the allies and Jill is playing as the axis. We then have "player" meaning two different things on which context.

But... the code is pretty consistent about using "player" to mean playable nation/faction/power. Multiplayer came along later, which is when/where 'player' comes in with the more common understanding to mean the people playing the game (the players), as opposed to the roles they are playing. That's why the code got the terminology wrong, in a single player game, the players are "US" "UK" etc... in a multiplayer game the other/more common meaning comes into conflict. TripleA does not label the alliances to the user anywhere, so we've managed to get away with not needing a decided external name for this concept. That means internally to the code (and map XML) player will retain a pretty well defined meaning, and what is called a "Node" will always be a bit misnamed/weird.

@cernel I would suggest to add an infinite=true flag.

eg:

<option name="attemptsPerTurn" infinite="true"/>

@prastle The engine remembering your choice is expected, so by some argument, it's an improvement (feature request). By another, the user expectation is there and the game has different behavior, it also removes the user's selection, by that token it's a broken UX and is a bug.

are we doing something wrong?

The game UI should make that very obvious, it should generally not allow you to do something wrong.

Otherwise, my opinion is to track this as a bug ticket so it gets fixed and we make the behavior consistent.

1b works if it is formalized. The 'bottleneck' comment should not be misconstrued please, it's more a matter of looking at
the process flow. One process being considered (1a) has a direct intake to bug tracker, while 1b has an intake to forum and output to bug tracker. The conversion from forum post to bug tracking ticket will not be immediate nor 1:1, by definition a bottleneck as we will be waiting for humans to do something (and no matter how diligant or fast, that will introduce some delay into the process). Whether it is a big impact or not is another and important matter. The impact will be inconsistent, we need to design this process so that this will not become a problem and we will not see a process break down.

How does 1b break down? what do we need to avoid/solve?

• appropriate culture of 'always do something' not instilled. For example, in: https://forums.triplea-game.org/topic/920/some-help-me-please/3, the "your internet is not avaialble" warning message was misconstrued and reported as an error itself. A response of 'ya, that is normal, just close it and continue' is an example of where we do not have that culture. No UI notification should ever be routinely ignored, and secondly the warning message is clearly not helpful in its current form. So the action item is to either remove it or fix it, but we can't just say "yeah, that was your problem", because it was not the users problem, it was our poor design and lack of time/labor for code development (which is compounded by really high overhead processes and high overhead code).

• potentially times of low capacity, people get busy; If we have only 3-5 people moving tickets, and 2 or 3 of them happen to coincide by being away and/or busy at work or what not, then we'll have pretty limited capacity and forum posts would build up. Dev's would jump in for these situations, but that is then reducing time available for devs to code, and it's hard to then justify having the extra reporting step.

• we simply lose track if something has been moved and do not get around to it. This report: https://forums.triplea-game.org/topic/957/pbem-pbf-combat-move-check-box/8 is potentialy an example, the reported bug has not made it into tracker. With more time, the post will fall from the top and would be unlikely to ever be fixed.

For this process, the success and failure metrics I would choose would be (so these are numbers that we should work to optimize and track to know that we are doing well):

1. number of forum posts that are handled without needing a ticket. Sometimes questions just need to be asked. (We would need to be sure to count this metric very conservatively, most user reports should result in some action, even if the 'system is working as intended', if a user can't figure out what that intent is, it may as well not be working).
2. number of forum posts that result in a bug tracking ticket or are de-duped against an already open ticket. If the ratio of this number to the total number of posts start to drop, then we are falling behind
3. the amount of time between when a forum post is opened and when a bug report is created
4. number of bug reports (forum or github issue, any kind of report) that is filed in the wrong place
5. number of github bug tracking tickets missing important information

@Lsg123 that message is saying that TripleA cannot connect to internet. You should not be able to connect to lobby, and map downloads etc.. would not work.

I opened this ticket to improve the messaging there so it's more clear, this message is meant to be helpful so you don't get a "ConnectionUnavailableException" when you actually try to connect to lobby or download maps: https://github.com/triplea-game/triplea/issues/3608

DanVanAtta created this issue in triplea-game/triplea

open Internet check screen is confusing #3608

@prastle I like the thinking, I'm not sure i"d go as far as abbreviations for each column, but I think that is what I"m used to speaking as opposed to what is better. IMO this is a great feature request thread to spin up, how to rename/update columns. I was thinking "waiting for players" could be shortened. On the other hand, I'm not too bothered by it, "waiting" might seem confusing if you are brand new to the game, and the players that have seen it then know that the truncated "waiting for.." is "waiting for player". On the other hand, maybe "waiting" will be just as obvious to new players. I think the topic gets a bit surprisingly involved, but we really only need to toss out suggestions and then decide which ones are the top considerations and then pick between them (Ron is deciding vote if deadlocked).

For this topic, a code change went through that will hide the started column for non-moderator players. It's kind of an interesting compromise for now. I learned/read from DOET (design of everyday things, great book!), that you really want every UI component to be used in every interaction. If it is only mods that use started column, then only they need to see it (ideally we'd make that configurable, but it's a bit more effort than we have to spare at the moment to go that step).

I think this topic might be settled for the moment otherwise. EV column was removed and 'bot' column was removed as well. (note; bot's are still forced to have 'automated host' in comments - I found that interesting running across that in the code, so we can still be sure a bot is not masquarading as non-bot).

Thank you @Frostion , @Cernel for the dialog. We are talking in circles a bit, but I do think we are at least talking from a common point of view now. TripleA is pretty complex and it's interesting to think it is a half dozen people running this with a larger community.

The thing that I have a hang up over, just a problem I can't see how to solve, if we ask for bug reports as a bug report in forum, it will always fall on someone to move it to the official tracker. Maybe that is good, and if someone then sees that happen a few times and they themselves become a more active volunteer, then they'll cut bug tickets directly into the tracker. Really, it's how do we want this designed?

I like the mention that the old tracker and new are pretty different. That is a good important thing to keep in mind and the fact it's easier to see/add/update tickets in github issues is significant. The old tracker, I would have supported that being for absolutely just the devs, I still can't figure out how to mark tickets as fixed in it

I think we have two decisions to make:

1. Do we encourage users to go directly to bug tracker, or forums? There are in-game links, help menu, lobby message that direct users to report bugs directly to bug tracker. We could update those, but overall it's a process/flow question. I think we have two realistic answers here:
   a) let's encourage bug reports to go directly to bug tracker
   b) encourage bug reports to go to forums, encourage experienced users to user tracker (github issues) directly

2. Do we merge 'help' + 'bug' categories? If we go with 1a, then it probably makes sense to do this. If we go with 1b, it will make complete sense do keep the bug category.

If we can formalize a way that 1b works, that would be best from a labor perspective. People that are experienced and hanging around the forums can add their labor which saves from dev efforts (we want devs coding). At the same time, repeating myself here, we do not want the forum admins/moderator volunteers to be a bottleneck either, which makes me think this might be a risky idea. That has me leaning towards 1a, and then combining the help and bug report categories, which is effectively a "we'll help you here if you're not sure, but the official bug reports go elsewhere"

Sidenote: i'm heading out of town for a couple weeks and will not be able to follow up. It is just as well IMO, I think i've exhausted my thinking about this and have hit a brickwall. It's hard to balance getting new users onboarded, bug reports going where we want, using available talent and labor, and it being clear and simple.

I do really appreciate we are working through what has been a contentious issue : ) I think we'll get this solved for real. While migrating there was a lot of updates for old bug tracker to new, that was a dev only effort, and we had a big split before in the different groups within TripleA. We're now a more united community IMO, so it seems appropriate that we're now dealing with, okay, this was how 'devs' dealt with bugs, how should TripleA as a full holistic community deal with them?

@prastle So like if you hover it shows the full value from the table cell? Would be a decent feature IMO, same for columns titles.

I think there is one point that is getting in the way, whether bugs need to get into the bug tracker or if it's sufficient to just list them on forums. As far as that goes, this project always has had a bug tracker and always needed bugs to get into the tracker.

The old bug tracker I think we collectively keep forgetting about, but it's always been around and still is even: https://sourceforge.net/p/triplea/bugs/?source=navbar

As far as it goes whether devs should use or need bug tracking software, it's a debate I never thought I would have necessarily. As is, forums is not set up to be a bug tracker, and that does not work for development.

There are lots of online resources about software project management and how a bug tracker fits into a software project (a bug tracker is one of a few central project tracking components, up there with source code management software):

• https://www.softwaretestinghelp.com/benefits-of-bug-tracking-systems/
• https://www.getdonedone.com/use-issue-tracking-software/
• https://techbeacon.com/pros-cons-defect-tracking

@prastle That's a bug, it's reported now: https://github.com/triplea-game/triplea/issues/3729, we should have reported that some time ago (but at least we have done so now). Hard to say much more at this time.

DanVanAtta created this issue in triplea-game/triplea

open Moderator Toolbox freezes when checking "ghosted" games #3729