Topic: Where to discuss improvement/New feature tickets

Should these be discussed in the mailing lists? The guidelines available at http://wiki.musicbrainz.org/Proposals apply to style proposals, but are unclear in relations to other tickets, such as for website improvements etc.

I'm thinking of tickets such as http://tickets.musicbrainz.org/browse/MBS-4785

Do such tickets need to go though the same RFC/RFV process like style tickets?

Moreover, could someone please explain the difference between MBS and STYLE tickets, by the look of things there's a lot of overlap.

Re: Where to discuss improvement/New feature tickets

As I see it, changes in the Style category are about the data on the website itself. How do we store the information about music efficiently and as complete as possible? MBS tickets are about the presentation of that data on the MusicBrainz website. The ticket you linked to is an example of this. If it or something similar is implemented, the data itself won't change, but it will be clearer to the user if a tracklist is a duplicate or not.
Changes to Style should be discussed on the Style mailinglist first and have to go through RFC/RFV. Tickets for MBS don't have to be discussed on the mailing list, but if you do, it would off course attract attention to the ticket and make it more likely to be developed. MusicBrainz-users is probably the most appropriate place for that.

Re: Where to discuss improvement/New feature tickets

Thanks, that makes sense.

Re: Where to discuss improvement/New feature tickets

According to your distinction, shouldn't this ticket by a style ticket?

http://tickets.musicbrainz.org/browse/MBS-2229

Re: Where to discuss improvement/New feature tickets

Yes, I think my definition needs to be refined. ;)
I believe the MusicBrainz Style project is for tickets that are in the RFC/RFV process, which is what this kind of proposals needs to go through eventually. Until then I suppose it should be in server.

Re: Where to discuss improvement/New feature tickets

That's both (maybe) a style ticket for allowing the option, + that for developing it afterwards.

Re: Where to discuss improvement/New feature tickets

Ok, so perhaps as a rough rule, if the ticket ought to be discussed through the RFC/RFV process it should be a style ticket?

Re: Where to discuss improvement/New feature tickets

Well, when that ticket was added I bet nobody thought it would need debating (guess it looked like the obvious thing to do) so it was just added as a feature request. Technically, that shouldn't need style, since it's asking for the possibility to use multiple dates on a release, and what would need it is the decision of *when* to use it (for digital stuff in iTunes and the like that changes dates per country? for CDs with the same barcode and content in different countries? if yes, always or only if the legal text in the back is also exactly the same? etc)

Re: Where to discuss improvement/New feature tickets

I don't think any "rule" here ever makes sense. It has to be done on a case-by-case basis.

The best rule-of-thumb for me is that if a server ticket's implementation requires discussion of edge cases, deeper questions of "do we want/need this complexity and what impact does it have on the dataset for end users, taggers and customers who use the structured data?" then that discussion should take place on Style and thus MAY lead to 1+ STYLE tickets. Thus the STYLE and MBS tickets can become dependent on one another.

It's natural though that the initial MBS ticket may attract discussion - although this isn't really the best place to come to a decision, if a decision is needed. The style process is the only proper, structured mechanism we have for resolving community differences - so if a ticket's implementation has trade-offs to be made, it needs to be done here.

To me this is similar to lots of governance processes in the real world. Someone wants to build a road. A company is asked to cost the road and prepare/plan for "implementation" (MBS ticket). Sometimes the road can just be built under existing resources and budgets. Perhaps it goes through existing public land with no sensitive environmental issues.

However sometimes building the road involves trade-offs and costs to other parties and there is a need for mediation and structure around making these tradeoffs. Perhaps a law change is required to allow use of the land. Perhaps building the road requires other systems to be set up to mediate use of the road (bylaws, use restrictions etc). This discussion might then need to take place in a government body whose purpose is to make decisions like this that impose winners and losers - this is like a STYLE discussion to me. Supporters and opponents of the road can argue their case. Sometimes the discussion makes it obvious that changing bylaws or guidance for the new road's use is required - this is like a STYLE ticket. But not always; perhaps the discussion comes to the conclusion that the road can be built under existing laws.

In the meantime, some or a lot of the implementation/costing/planning may have been done (MBS ticket)... but the two processes are often interdependent in any case.

Re: Where to discuss improvement/New feature tickets

Ok, so considering http://tickets.musicbrainz.org/browse/M … l-tabpanel now requires an RFC, a new style ticket should be created?

Also, is it only the user who reported the issue who can begin the RFC process?

Re: Where to discuss improvement/New feature tickets

I marked the ticket as requiring RFC as a marker for "requires Style discussion/guidelines/agreement before implementation" so don't take it too literally. I wouldn't worry about RFCs or STYLE tickets for now; the most important thing is discussion on the issues.

You need to have something formal to propose before creating an RFC, but anyone can create one. In this case it's probably best just to try and start the discussion and move towards some structure, understand what needs to change. Often such threads on the mailing list are marked "pre-RFC", e.g."Pre-RFC: MBS-2229 and multiple release events per release - what guidelines do we need and what needs to change?" or something like that.

Re: Where to discuss improvement/New feature tickets

Ok, thanks for the guidance!