OpenMpt accessibility discussion

[GoemonIshikawa]

Okay, I have logged the control state issue, though in the end I think it's best to keep it open at least until the next release in the event of any regressions.

[Saga Musix]

Okay, I have logged the control state issue, though in the end I think it's best to keep it open at least until the next release in the event of any regressions.

That's generally not how we work - if an issue is later found, the ticket can always be reopened, or be amended with another ticket. As mentioned before it's also not helpful to conflate multiple separate issues into one, such as the "steps to reproduce" in this particular example. Were these issues fixed in two different OpenMPT versions, it would be impossible to properly tell them apart on the issue tracker.

Generally we also don't retroactively create tickets for something that has already been fixed: The issue tracker is not a complete list of bugs or changes in the software. All user-facing changes are documented in History.txt instead.

[GoemonIshikawa]

Okay, I have logged the control state issue, though in the end I think it's best to keep it open at least until the next release in the event of any regressions.

That's generally not how we work - if an issue is later found, the ticket can always be reopened, or be amended with another ticket. As mentioned before it's also not helpful to conflate multiple separate issues into one, such as the "steps to reproduce" in this particular example. Were these issues fixed in two different OpenMPT versions, it would be impossible to properly tell them apart on the issue tracker.

Generally we also don't retroactively create tickets for something that has already been fixed: The issue tracker is not a complete list of bugs or changes in the software. All user-facing changes are documented in History.txt instead.

@Saga Musix Oh I understand. Yes it's just another thing that happeneds when I'm on GitHub, most to all accessibility work usually just goes in the description field and anything worked on is usually kept track and closed afterwards, but in next event I can delegate minor issues or things that require your understanding to forums and the major issues to bug tracker.

I honestly  did it like that as I thought it'd be much more easier to read for anyone looking at it as while they might look like separate issues they're really two parts of the one problem, though to be honest I should've kept it to description field as in GitHub as now that I'm seeing it, it probably isn't easy to keep track of like I'd thought.
Thanks for the heads up on the matter by the way.