Organize issue tracker for macro vision

• Mar 22, 2018 - 13:36

Hi,

I want to add some systematization to the issue tracker using "big" issues to aggregate all the related small ones. The goal is to allow each member of the community to clearly understand what issues should be fixed before the whole feature can be marked as "Done". Also, for new participants, it will be easier to search for the particular interesting issues related to big features.

The second advantage is transparent understanding of what should be done to make the 3.0 release. There are different issues related to 3.0-dev version and there is no understanding of actuality and completeness.

I suggest using [EPIC] prefix to define big features like "Tablature issues" or "Dynamic layout issues". These features may include links to the small related issues and general discussion of the feature. So that, looking at the feature description and the list of related issues makes things clear, what should be done to fix/implement this particular big feature. As an example: #270551: [EPIC] Tablature issues.

What do you think about this improvement? Will it be clear for newbies? Will it be more comfortable for top-contributors? What inconsistencies do you see while working with the issue tracker?

PS. Do we need assignment field? Was it useful and should we return it?

Comments

• Mar 22, 2018 - 16:30

I like the idea. I'd like it better if it were formally supported by the framework :-). Like, a built-in way to add or remove issues to/from the list of sub-issues, having the aggregate automatically closed when all sub-issues are, etc. I do fear some of these becoming too big/general to be useful, but we'll see.

The assigned field mostly just got misused by people submitting issues who thought it was a place to add their own name. And most of the time people never bothered assigning themselves when fixing it, and half the time they did, they either never followed through, or tried, ran into a wall, then unassigned themselves. I think the comment thread actually did a better job of telling us what we need to know. Not that it wouldn't be possible to put things into place that would make the Assigned field more valuable.

Reply

• Mar 22, 2018 - 16:38

Thanks for the feedback! I've started using epics-aggregators and tags for child issues, so linkage somehow works. I will try to keep it up to date, but it is better to support some culture among the community.

Having subtasks would improve the user experience, indeed. But for now, let's do our best with this framework :)

Reply

• Apr 4, 2018 - 13:53

I like the [EPIC] idea.

Perhaps the "Assigned" field could be replaced with a "Pull request" field that takes a GitHub URL? This serve basically the same purpose as the "Assigned" field, but would stop people assigning bugs to themselves that they don't actually plan to fix. It also make it easy to find the in-progress code.

Reply

• Apr 4, 2018 - 14:29

The problem is people don't know "assigned" means "working on it". Newbies think it means "I created the issue", and some developers might use it to mean "I plan to work on this at some point". Other developers might see that the issue has been assigned and not work on it because they assume a fix is on the way.

It's much better if we have something that points to evidence that a fix is on the way. It could be a pull request (even if it is a work in progress), or it could be labelled "Code URL" and point to the person's working branch on their personal fork.

Reply

• Apr 13, 2018 - 11:46

I've finished revising bug reports for all the issues marked with 3.0-dev version, so the issues are assigned with the relevant tags which define the topic for each particular issue. The issues also have the defined Priority (Critical, Major, Normal and Minor), so you could choose the most important ones to contribute to.
There are examples of the topics:

  • notations: the issues marked with this tag relate to the problems with positioning symbols in the layout, drawing symbols, inputting different symbols and so on. If you are interested in these particular issues, follow the "Notations" tag link.
  • layout: the issues marked with this tag relate to the problems with positioning complex elements in the layout, corrupting the whole layout. These issues are about whole score corruption, not particular elements. Follow the "Layout" tag link to solve complex issues.
  • playback: the issues marked with this tag relate to the problems with the playback of the scores and separate elements (articulations or specific note types), of how sounds are processed and produced. Follow the "Playback" link to improve the playback in MuseScore.
  • text: the issues marked with this tag relate to all text entities in the MuseScore which are lyrics, staff text, chord text, system text and so on. Follow the "Text" link to help to improve text editing experience.
  • ux: the issues marked with this tag relate to the problems with the user interface and user experience, different bugs, and inconsistencies in the interface. Follow the "UX" link to improve the user experience of MuseScore.
  • musicxml: the issues marked with this tag relate to the problems with importing/exporting scores through the MusicXML format. Follow the "MusicXML" link to help musicians convert scores to/from MusicXML format.
  • opencrash: the tag speaks for itself. Follow the "Opencrash" link to fix the crashes happen on opening scores.

More tags can be found by specific search requests in the tracker:

Reply

Do you still have an unanswered question? Please log in first to post your question.