The MetaBrainz ticket tracker (which, incidentally, received a long-needed upgrade recently – thanks, Gentlecat!) is an important tool for all of our projects. It collects all kinds of bug reports, feature requests and other tasks to be done and makes sure none are forgotten.
One of its auxiliary features is the possibility for users to vote for a ticket, to indicate which tickets they consider particularly important. (There are only upvotes; you can’t vote against a ticket.) This may factor in when MetaBrainz employees decide on which tickets to tackle next, although there are other factors as well such as the complexity and the impact of a particular issue.
In the past, who voted for which tickets has been private, mostly because that is the default setting in JIRA, the ticket tracker software used. Only administrators can see the list of voters for a ticket; regular users just see the number of votes.
Now, we have decided to change that: In the future, all logged-in users will be able to see who voted for a ticket. This should not be sensitive information; whoever expressed their support for a ticket by commenting on it instead of (or in addition to) voting already was in the public eye. Still, it is a policy change. We’ve therefore decided to wait two weeks before implementing the new privileges, in order to give everybody the chance to remove any votes that they don’t want to be known with. The ticket tracker provides a list of all tickets that you have voted for.
MetaBrainz Blog 
What about making ticket VOTING public available for everyone logged in MB (instead of the separate login in JIRA)? Or maybe for everyone with a minimum level of edits?
Would be nice if this come true:
«This may factor in when MetaBrainz employees decide on which tickets to tackle next».
BTW: Your link doesn’t work for “+currentUser%28%29”, I see this result:
https://tickets.metabrainz.org/browse/OTHER-265?filter=-4
I fixed the link (I hope).
Regarding your other snarky comments: The number of votes is taken into account; and the separate account for the ticket tracker is not an intentional hurdle, it is just not easy to implement a single sign-on for all MeB services (there is a ticket for it, OTHER-16). You are of course fully entitled to not believe me, and to always assume the worst intentions.
You really believe my comment is “snarky” if the 3 top voted issues are all more then 4½ years old? The “OTHER-16” ticket is over 6 years old.
Of course “not so easy to implement” is always an argument. But making “ticket votes public” to let even more people see the influence of voting seems a little bit strange to me. Or would it change the dev’s queue if 100 or 1’000 or 10’000 people vote for a specific issue?
BTW: The link isn’t fixed (at least in FireFox it results in https://tickets.metabrainz.org/browse/STYLE-336?jql=voter%20%3D%20currentUser() )
I’ll leave you to your the-world-is-so-bad sentiments, then. Too bad that you are forced to use MusicBrainz, and prevented from fixing all those tickets yourself.
And I’m using Firefox, too.
@chirlu:
(Ich schreibe Dir diese Antwort bewusst in Deutsch, damit es keine Missverständnisse durch meine englische Übersetzung gibt.)
Seit Jahren versuchen die Entwickler Monat für Monat Verbesserungen ins MusicBrainz-System zu bringen. Als Ausstehender kann man kaum nachvollziehen, warum einzelne Issues gelöst werden, andere jahrelang liegen bleiben.
Der wirklich störende Punkt ist jedoch der:
Irgendwie verliert Ihr “Entscheider” immer mehr den Bezug zur normalen Basis. Als jüngstes Beispiel könnte man den frustrierten Beitag von Fab77 nehmen (https://community.metabrainz.org/t/your-system-is-archaic/179781). Statt ihm aufzuzeigen, worauf er achten müsste oder Verbesserungsvorschläge in Aussicht zu stellen, putzt ihn der MBCM @Freso als “Troll” runter. Wir wissen beide, wozu das führt.
Ich behaupte, dass die allermeisten Benutzer einfach mal ihre CD bei MB hinzufügen möchten oder nach Informationen zur eigenen CD inkl. einem Frontcover suchen. Wenn das aber schon zur unüberwindbaren Hürde wird, darf man davon ausgehen, dass solche Benutzer niemals eine “Beziehung/Relationsship” oder den Unterschied zwischen “Werk/Work” und einer “Veröffentlichung/Release” verstehen.
Sucht Ihr wirklich den Puls der Leute, dann reicht es einfach nicht eine Elite von Ja-Sagern zu hegen und pflegen. Habt Ihr mal gezählt, wieviele Leute im Forum aktiv mitmachen?
Wieviele hingegen erfassen regelmässig unzählige Edits und würden sich über Verbesserungen wie in der Top-Voted-Liste nicht nur freuen, sondern könnten dadurch etliche Stunden Zeit gewinnen?
Du kannst mich gerne einen Miesepeter und Schlechtmacher schimpfen. Wenn Du ehrlich zu Dir selber bist, weisst Du, dass Verbesserungen hauptsächlich durch Zuhören und Kompromisse erzielt werden. Mit Verbesserungen meine ich solche, die für die breite Masse etwas bringen, das kann rein nur schon mit Design- oder eben mit Codenanpassungen erfolgen.
Dieser neueste Versuch nach “Öffentlichkeit” verbirgt leider nur kurzfristig das grosse, immer noch nicht gelöste Problem hinter MusicBrainz: Zu wenig Leute entscheiden darüber, was für die breite Masse wichtig und nützlich ist. Kritik wird im Keime erstickt, meistens sogar auf persönlicher Ebene.
Schnippische Antworten wie “lös die Tickets doch selber” verbergen einen weiteren schwelenden Konflikt: Ihr nehmt Kritik immer gleich persönlich. Es geht (mir) nicht um Deine Person oder gar Deine Entwickler-Fähigkeiten. Ich würde mir nie ein Urteil anmassen, ich kenne weder Dich noch Deine abgelieferte Codequalität.
Es geht viel mehr darum, dass Ihr mit dem heutigen Blogeintrag einmal mehr genau soviel Mit-Entscheidung abfragt, wie das Resultat keine Rolle spielt.
Ob irgendjemand für oder gegen die Veröffentlichung der Anzahl Stimmen zu Tickets ist?
Völlig egal, es hat absolut keinen Einfluss.
Warum fragt Ihr nicht: Welches der Top 10-Tickets sollen wir bis Ende Juni 2017 lösen?
Of the top 5 voted issues, MBS-4501 has been started already (the database is now able to deal with multiple tracklists for a release, but the move to the new server delayed adding the actual UI for it), and MBS-1801 has been looked into for a while and the devs have researched different ways of doing it (not sure what’s the current status on it, but it hasn’t been ignored). The tickets dealing with the cover art are tricky, since the cover art goes straight to the IA (so it’s not trivial to, say, store an image “hidden” until a replacement vote has passed). Don’t get me wrong, we want all of these too (I personally really want MBS-1801) but this calendar year we’ve had very little development going on, mostly because of all the server issues plus the server move. The little work we’ve had towards features by the paid developers (the volunteers will obviously decide what they’re willing to volunteer their time towards) have mostly gone towards big issues like MBS-4501 and MBS-1801, actually – it’s just they’re big issues, so there’s little to show for it yet.
For some people, it might be frustrating to see the voting feature on the bug tracker, but see no indication that your vote really counts (or if so, how much). I totally understand that. At the same time, quantifying that relationship (between vote-count and prioritization) is hard. If somebody has a suggestion for how to do that, I’d like to hear it.
So:
If you’re interested in how issues are being prioritized in MeB, you can follow the weekly dev meetings (or read @Freso‘s write-ups in the forums).
If you’re interested in seeing an issue become higher-priority, you have some options.
* You could champion a specific ticket or set of tickets. Some issues need an advocate, somebody to help find consensus or identify road blocks.
* You could get involved in development.
* You could (at least in theory) look into crowd-funding a bounty for a particular issue.
Meanwhile:
Making votes ‘un-anonymous’ on the issue tracker is one tiny step towards a more open development process.
> Welches der Top 10-Tickets sollen wir bis Ende Juni 2017 lösen?
Of the top 10 most voted on tickets, 6 are long resolved, 1 is almost there (MBS-4501 – the database changes were included in the last schema change release, so “only” UI changes need to be made), 1 has had a lot of developer hours spent on it this year (though unfortunately it didn’t lead anywhere yet 😦 – MBS-1801, as @reosarevok already mentioned), 1 is mostly out of our hands (MBS-4635), leaving the last one, MBS-1735, which would certainly be doable, but also requires a schema change (and for last schema change release, the main paid MBS developer was working on MBS-4501 as already mentioned).
If we look at the tickets with 20 or more votes, only 11 out of 29 are open, and most of those 11 are either already being worked on (MBS-4501, MBS-1801, OTHER-16), out of our hands (MBS-4635, MBS-4641, OTHER-16), and/or too large/complex to be actionable at this point (MBS-1159, MBS-211).
By the end of 2017, we would like to have finished MBS-4501 and MBS-1801 and made some more progress towards OTHER-16 at least.
> But making “ticket votes public” to let even more people see the influence of voting seems a little bit strange to me.
The number of votes have always been completely public. Nothing is changing in that regard. What’s changing is that people are able to see who cast the votes.
@Freso: Would it not be more accurate to list the “Top (38) OPEN issues” (not including the closed one, solved years ago?) like https://tickets.metabrainz.org/issues/?jql=votes%20%3E%3D%2010%20and%20Status%20%3D%20open%20ORDER%20BY%20votes%20DESC ?
I don’t think that anyone is waiting for already closed issues .-)
ATTN: It’s not possible to remove votes from resolved issues (including rejected issues), so you’re not actually giving the users the chance to do anything here. Just want to set the record straight.
That’s true. Hmm, I guess if someone has old, locked votes that they want to remove, they should mail support.
This has now been implemented. Logged-in users can click on the vote count to see a list of who voted.