User:KrazyKiwi/processdraft

From MusicBrainz Wiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

RFC Process

Summary

  1. Form an ad-hoc group of users who are interested in the topic under review.
  2. Brainstorm the RFC.
  3. Nominate a person to shepherd the process, hereafter referred to as 'designated victim'.
  4. Post refined RFC to list, using template.
  5. List members should reply to the 'designated victim'.
  6. Designated victim will collate replies, and post a summarised list of the objections back to the mailing list.
  7. Any further discussion, should be sent to the designated victim for review.
  8. Designated victim will again collate replies. This summary will probably cover resolutions to some of the objections, and maybe any further objections raised by the first summary.
  9. Repeat steps 7 and 8 until either:
  • 9a. concensus is reached (the desired outcome) or, 9b. stalemate is reached
  1. If stalemate is reached, the benevolent dictator should step in and make a decision, based on the summaries of the discussion so far.

And in more detail

  1. The RFC champion (i.e., the person writing it and driving the process) should choose a small (3-5 members recommended) group of interested people to work with. While it's tempting to choose a group of yes-men (write here a little more about how to not do that)
  2. Brainstorm the RFC, in private mails, on irc, however you like. There are several aims here:
  • 2a. Refine the wording of the RFC so it is unambiguous. A lot of our guidelines are open to radically opposed interpretations and some flat out contradict each other. Check other affected guidelines and review if they need any changes to accomodate the new RFC. 2b. Figure out the likely objections, and either work out solutions to them, or reasons they can safely be discounted. That might mean taking people you are sure will disagree aside on irc or in email, and asking them if they can articulate their issues. Or it might just mean guessing. 2c. Be specific about what issues you are addressing.
  1. The group should choose someone who won't mind a temporary mail flood, is fairly aware of the issues at hand, and that you feel can be fair. The summaries posted to the list from here will be more or less steering the discussion.
  2. Your RFC at this point should be pretty well refined. Make sure you describe in detail exactly what problem(s) you are trying to solve. What may be obvious to you may not be obvious to all readers and users of the data. What is common practice on trance compilations may not be on classical anthologies.
  3. Sending replies to the mailing list results in mail floods and circular discussions. Replies should be sent (using the template?) to the designated victim instead. "I don't like it" is not a valid objection, nor is "It's against my personal vision for MusicBrainz". Circular self-sustaining arguments are avoided by not having everything go through the lists, and it also should short-circuit personal animosities.
  4. The designated victim should collate the responses received over a (short? 2 days? 1 day?) period of time. Explicit objections should be summarised into a list and posted back to the mailing list at the end of this period. It's probably valuable to highlight any particular objections that are raised multiple times.
  5. The ad hoc group should review the objections posted, and discuss. (At this point do we want to allow amendments to the rfc and extension to the timeframe?) Mailing list users can of course also reply to the points raised in the summary, either with solutions to issues raised, or further objections.
  6. Basically the same as 6. And repeat as needed.
  7. When the deadline is reached:
  • 9a. If concensus is reached, the RFC is passed automatically. This is obviously the best outcome. 9b. If the deadline is reached without agreement, the ad-hoc group can (what? withdraw it entirely, so it is an ex rfc, no longer a proposed one? we already have enough proposed guidelines confusing issues. That doesn't mean it can't be resubmitted later, maybe with changed wording, or better solutions to the problems raised.)
  1. If after a predetermined deadline the process hits stalemate the benevolent dictator should make a decision, taking into account all the posted arguments, objections and proposed solutions to those objections.

Things to figure out

An rfc template (Brian and Yllona are working on this)

How long is long enough?

  • 2 days from post to first summary? 2-3 days to next summary? 2 weeks total rfc time?

Should we dump the RFC wording, with it's baggage, for something simpler with no history? 'Change proposal' or something.