Request For Comment: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
((Imported from MoinMoin))
(please rename to RequestForChange (Imported from MoinMoin))
Line 1: Line 1:
[[Image:Alert.png]] '''Note to page editors:''' please rename to [[Request For Change|RequestForChange]] (can't do this anymore). [[Delete When Cooked|DeleteWhenCooked]]. -- [[User:Shepard|Shepard]] 13:03, 03 November 2006 (UTC)

----


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



Revision as of 13:03, 3 November 2006

Alert.png Note to page editors: please rename to RequestForChange (can't do this anymore). DeleteWhenCooked. -- Shepard 13:03, 03 November 2006 (UTC)



This will be a page that will give the exact steps to make a Request for 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 Change(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 my proposal to start discussion, this NOT official or an RFC itself! Simply and idea we can start with to expand on or change.

The only two formats well suited to discussions like RFCs are the mailing list and forum, other formats are good for announcements or simple discussions but for a formal decision process we need a way to write and respond to detailed, verbose arguments and keep them in one place. And from a lot of the comments I’m seeing the mailing list is why many people are staying away so I think we should move RFC/RFV over to the forum. The drawback is that it’s a flat discussion so things can’t divide into multiple tangents, however this could also benefit the discussion by keeping things on topic. And if something really needs to be focused on you can quote what was said earlier. The other big benefit is if we can get polls running in the forum we can easily setup votes over the minutiae that bogs down RFC’s. The last bennefit to this is the structure of the forum makes it so any forum moderator can eliminate or control people abusing the process, greatly reducing the need and responsibility of the Style Council Secretary to police and guide RFC discussions. In fact other than cross postin RFV's to the blog the Style Council Secretary is barely needed.

The Process:

  1. First a question on how to do something is raised in the forums or IRC. For whatever reason there is no solution or there is no consensus and the wiki doesn’t define how to proceed.
  2. At this point somebody floats a simple proposal or solution to the issue and posts it in a new forum just for MusicBrainz changes (PFCs, RFCs, RFVs). This gives people the possibility to see if anybody else is interested in making such a change, others can respond with their own proposals or point out that a solution already exists or can be built upon. This will be called a Proposal for Change. The thread would begin with "PFC: {my idea for solution}" and would be a rather informal idea or proposal. If it's as simple as adding some trivial text to an existing wiki page the Proposal can end here.
  3. If people show interest in this change and nothing like it has been done in the past the proposer creates an official RFC. At the same time they would also create a wiki page to document the RFC as it's currently proposed.
  4. Now people can debate and discuss the specifics of the RFC and how it should work. Being in the forums anybody can participate, you can logon in a coffee shop, or wifi point and make a quick post, whatever. You don't need to worry about spamming the mailing list with multiple emails of every little thought you have on the subject, hopefully making the process more inviting, more light-hearted, and less strict.
  5. As the discussion goes forward the proposer would update the wiki to reflect changes they’ve made to the original RFC; that way people new to the discussion can read the wiki and have a good idea how things currently stand. Others can possibly edit the wiki but the edits should be minor. There is the possibility of freezing the wiki to keep any changes from being made till the proposer chooses to do so.
  6. If needed the forum could open polls to get consensus on simple ideas to see what the majority of the community wants.
  7. Finally as the RFC solidifies and discussions die down any last minute changes can be made to the wiki and the RFC would be submitted as an RFV.
  8. Now any dissenting opinions can make a counter argument on why they think the proposal should not be added to MusicBrainz and the proposer can defend why they chose to do what they did.
  9. Finally the Style "Elder" can look at the RFV and any vetoes and decide to add the change or discard it.
  10. a. If added, the Wiki page becomes the official document how the changes work or if the RFC is a change to an existing document, the wiki can be attached for reference on how changes were arrived at. b. If rejected the proposal can forgotten or restarted in a different form.

To address the problems with the current process the following rules should be followed:

  • The proposer is making a change by themselves but will find the process easier if they consider themselves spokesperson for the majority of people wanting the change, and are willing to change the proposal to fit needs of others.
  • Post the existence of the RFV on the MusicBrainz blog, and possibly leave a message of the RFC and RFV in the mb-users mailing list to let everybody know that a formal change is being made.
  • Everybody should be able to make their voice heard but there is the possibility of abuse by outsiders. I'm not sure if we want to leave this forum open to the public or restrict it to registered editors or even registered editors with 50-100 edits to their name.
  • I think there should be time limits to the RFC to encourage people to get involved and to keep things moving. For example:
    • A PFC must exist for a week but is very informal compared to the RFC/RFV.
    • An RFC must exist for at least 2 weeks before moving to RFV unless it's very minor (probably not an RFC in this case) or unanimous.
    • An RFV must exist for at least a week before acceptance.

This means the minimum time a change can be in discussion is a month. Plenty of time for people to throw in their $.02. On the other hand:

    • If an RFC bogs down on one issue and goes over a month that issue will be put to a simple majority vote, and will move on.
    • If an RFV bogs down it has 2 weeks for debates then be submitted to the elder.

In my opinion we should be able to enact changes faster than the US government or we have some serious bureaucracy issues to work out.

  • If the change requires programming changes developers need to be involved in the discussion, however developers are in short supply right now. I can't see a solution other than to encourage developers to be more proactive in reading about changes than average users. I certainly don't want to force you guys to be involved but it's hard to tell who has the time or abilities to be involved in the discussion. Hopefully making RFC's more visible will help solve this problem anyway.
  • All official discussions only take place in the forum. You can talk about the issue anywhere but until it's in the forum people involved in the discussion shouldn't have to know what was said. This will avoid people hunting down three threads of a discussion in different places, and will avoid posts such as "Well WE decided to do it like this on the blog". But if something said on the mailing lists or chat is relevant definitely add the idea to the forum for discussion and implementation there. Don’t expect people to have to read through the outside discussion to stay informed and involved.
  • Last we need a method of finishing up the RFV. Either the style elder needs to give a yes or no that is final no matter what anybody says, or we need to put things to a vote that is final no matter what anybody says. A vocal minority shouldn’t hinder the rest of the community that is more willing to accept changes.

A few final words:

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. The MusicBrainz today may be 100% different from MusicBrainz next year; if it's not perfect first time through we'll fix it and get it second time through.