History:Proposal Process Suggestion

From MusicBrainz Wiki
Status: This Page is Glorious History!

The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.


The Future RFC Process:

This is my proposal to start discussion for solve the issues found on the RequestForComment page. 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.

Discussion

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