Request For Comment: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
((Imported from MoinMoin))
(No difference)

Revision as of 05:57, 30 June 2007

This will be a page that will give the exact steps to make a change to MusicBrainz expanding on the info provided by DonRedman in the StyleCouncil wiki page. But for now it can serve as a place for us discuss and lay out how to get the Request for Comment(RFC)/Request for Veto(RFV) process more visible to the community at large.

The Current RFC Process as it is Now:

  1. A user decides there needs to be a change to MB and makes a formal RFC. This isn't just a simple idea off the top of their head, it's a detailed proposal of what they want done. While it's ok to ask for ideas how to deal with "grey issues" there may be it should be proposed in a way that if there was no dissent to the idea it could be implemented as proposed.
  2. The RFC is put on the mb-style MailingList for comment. People can add ideas to the proposal or express dissent on why it should not be added. A wiki that lays out the RFC as currently proposed makes it easier for people just entering the debate to understand.
  3. The RFC can change to accept new ideas, as things are discussed in the mailing list.
  4. Once discussion has died down and the proposal is finalized the proposal is re-entered into mb-style as an RFV.
  5. The RFV is a chance for dissenting opinions to veto, the veto must propose reasons to veto that are as complete as the proposal itself ("I don't like it" is insufficient, there needs to be legitimate reasoning).
  6. Hopefully everybody can agree to the change if not the StyleCouncil "elder" will make the final decision to allow or reject the proposal.

Some interesting notes I learned just recently:

  • The proposal isn't for everybody to change as they see fit along the way. The proposer has ultimate authority on the proposal, however if they don’t accept the community suggestions they’re likely to have their proposal rejected. This avoids the problem of a single council member hijacking the proposal and changing it to their own purposes.
  • The elder is the final word in allowing or rejecting the proposal. This allows forward movement if some people dissent no matter what, and avoids the problem of a vocal minority stopping changes. Obviously a lot of responsibility rests on the elder’s shoulders but the current elder seems to take all opinions into consideration very well.

Problems With the Current Process That Need to be Fixed:

  • Visibility! – Being only on the mailing list restricts comments to those who can put up with the mailing list format, if it wasn't for nabble I would not be one of them, too much like spam. You may visit MB daily, making thousands of votes and edits a day but if you’re not subscribed you never know of new and upcoming change.
  • Inclusion - Similar to above. Everybody's opinion should be given, what is the best format so as not to intimidate or inconvenience people away? Do we want to restrict who can participate? Is it good to have a little complexity so only people with experience in MB are making changes? All MB users should be able to participate but what about “anonymous” who is passing through from a google search?
  • No formal structure to the RFC process – The process is poorly documented and only understood by experienced members who have watched it play out or submitted changes themselves. This wiki is an attempted solution to this.
  • No time frames - Similar to above; is the RFC process a short or long process? Obviously the discussion makes a big difference but how short is too short, how long is too long? If discussion bogs down into "Is so!" "Is not!" arguments how can we break the cycle and continue moving forward?
  • Confusion - We have many places to discuss the RFC, creating the possibility of upto 5 different discussions on the same topic to exist. Not to mention multiple threads in each of those 5 formats.
  • Finalizing - The addition of a "style elder" partially answers this but with tools like polls we could offload the heavy work to the community and possibly make the decisions 100% democratic. However is that fair to MusicBrainz as it does have to generate customers and income to stay afloat? Maybe we should we keep a final decision up to the "CEO/Elder".
  • Difficulty - I don't think any RFC that has gone through has done so smoothly. It's an incredibly painful process, and considering we're all volunteers here nobody wants to submit themselves to that pain in their free time. However this is as much to do with attitude as it is with having rules to follow; nobody wants change, even if it’s change for the better it will never make everybody 100% happy. There's nothing to do but accept the fact that nothing will ever be exactly as YOU want it to be. A harsh reality, but this is a community of people with different interests.

Tools we have to fix the problems:

The Future RFC Process:

This is just a quick new list of how the current method would be look based off some recent discussions.

  1. An issue/problem is decided it needs a solution that doesn't currently exist in any of the guidelines. The discussion about the problem influences what the solution will be and a simple idea is proposed to the community as a rough first draft proposal. This can happen anywhere on the site where people argue and discuss MusicBrainz issues. If others think proposing this is a good idea somebody (usually the person that wrote the first draft) proceeds to the actual RFC process.
    1. A wiki is made up specifying the actual Proposal as a second draft.
    2. A post is made in the MusicBrainz Blog announcing that a new RFC is out.
    3. The RFC is proposed in the MB-Style mailing list with a title along the lines of "RFC: *title*".
    1. The RFC is discussed by the community and ideas are proposed. If anybody disagrees with the RFC this is the time to explain why and offer options and alternatives. Official MusicBrainz programmers should be included in the discussion to figure out how it will be programmed into the system.
    2. The proposer modifies the RFC's wiki page as they see fit to reflect info and ideas made in discussion.
    1. When discussion has died down and all relevant issues have been addressed and most people consent with the proposal the wiki and proposal is cleaned up into a final draft and resubmitted to the mailing-list with the title "RFV: *title*".
    2. A post is made to the MusicBrainz Blog again, this time telling people that the RFC has moved to RFV.
  1. At this point any dissenting opinions can veto by submitting a detailed explanation why the proposal shouldn't go through.
    1. The style council elder makes the final decision to include the proposal or reject it.
    2. If the proposal is accepted it's wiki page is made official and any related wiki pages are updated to link and incorporate the new proposal.
    3. If it requires programming changes the proposal is programmed to be released in the next scheduled update.
  1. The Proposal goes into a "Beta" phase where people are encouraged to find and discuss odd or questionable applications for the proposal that weren't expected or discussed during the RFC phase. These special cases are entered into the wiki to give examples of how to use the proposal in tough circumstances.
  2. After awhile the beta period is closed and people are encouraged to use the new process as much as possible.

A few final words:

The above "Future RFC Process" doesn't address all issues yet, please make your own suggestions on further improvements.

This is one of the most important processes in MusicBrainz. Always keep in mind what is best for the community of people who use MB as a source of information (our customers so to speak). Remember that we editors are volunteers, we need a solution that makes things easy on us and new editors so we'll keep coming back to contribute to the site. Remember that we're volunteers but the site needs to stay afloat financially to remain online, the outcome of all this should be something that strengthens MusicBrainz as a business and service to music groups, and music lovers.

Finally remember that no matter what the outcome of this or any change done here MusicBrainz is always changing and open to change. MusicBrainz isn't 100% perfect now, nor will it ever be, the key is that we keep improving and making this site more .

  • I don't want to finish the sentence for you, as it's your thoughts on this - but would you mind finishing the above statement?  :) - DeleteWhenCooked -- BrianSchweitzer 05:57, 30 June 2007 (UTC)

Discussion

Further ideas on how the RFC process at ProposalProcessSuggestion

Please goto the forums here to discuss this so we won't have multiple discussions (see the "confusion" problem above).