Meta

[MRoth1910]

#34239 (comment)

If this would be the expectation all the time (or at least that the contribution has to be somewhat germane to what someone might wish to accomplish with a feature/what needs to not be broken in adding it), then I would personally have a much more enjoyable experience trying to contribute either by reporting bugs or offering feature requests or apparently pointing out that there are unexpected knock-on consequences of design decisions.

The moderation should have been applied much earlier as soon as it got into "your workflow is wrong, your idea is bad": not helping!

And frankly it is simply true that if one person contributes, they're probably not the only one struggling.

I will never forget discovering that only one person spoke up, belatedly, because the macOS devs did not say "we cannot have multiple instances". It has fundamentally altered my workflow for the past 3.5 years, and it causes a lot of problems. I am not going to let go people telling me here and on the forums that we were wrong, particularly people who don't know anything about macOS, and that is another manifestation of the same problem. I can't code, but I like the product enough to say "hey, there's this thing not working/worth considering adding or tweaking", and I'm not the only one soured by the experience, particularly since I see that a lot of useful suggestions are just going to languish even with 5.0 on the horizon.

[MarcSabatella]

Regarding the linked issue, for the record, at no time did anyone suggest the idea was bad. On the contrary, from the very beginning every single person posting agreed it was a fine idea. I simply wanted to clarify that the workaround was actually much simpler than what was originally described, and the OP should have then edited the description accordingly and left it at that. If the moderation was to have been applied earlier, it could have been at that point.

On the other hand, by not locking a thread prematurely, it allows an opportunity for the OP and anyone else reading the thread later to learn a more efficient workflow, and the vast majority of people naturally appreciate that sort of help - it's one of the great things about the MuseScore community. But indeed, there are always those who take such suggestions personally and respond accordingly, and moderation could also be used to curtail the backlash. Or, we could all be better with self-discipline in keeping GitHub discussion focused on the actual issue at hand and not delving into unrelated matters or personal attacks.

The stated ideal for issues is that the original description should describe all relevant aspects of the issue clearly and accurately, and if so, there should be no need for further discussion. The goal being that a designer or developer should be able to look at the issue description and understand everything there is to know in order to start working on it - they shouldn't have to read through a discussion to fully comprehend the issue. When the issue description is not clear, or contains factual errors (as this one did), then the purpose of discussion should be to improve the clarity and/or accuracy of the issue description, so that the OP (or a moderator, if the OP is unwilling/unable) can edit the issue accordingly. In such cases, it is also best to add a note to the description that says "updated based on the subsequent discussion" so that the future designer/developer knows they don't need to read the discussion. Or the discussion can simply be deleted if it seems of no historical value.

Anyhow, the bottom line is, if an issue description is unclear or inaccurate, then it is absolutely appropriate for people to chime in with clarifying/correcting information, so the OP can then update the issue accordingly (or in some cases, close a bug report and open a new feature request). If they happen to learn something new in the process that can help them, great, but if not, no harm done.