Talk:Requests for comment/Archive

People to consult with or look for a decision from

"Look for the decision from Tim Starling, Brion Vibber, Mark Bergsma." Within particular areas of MediaWiki development, aren't there sometimes other people who handle the decisions, or at least are helpful people to go to first? E.g. on database matters, people used to say to consult binasher (before he left). Can we come up with a more comprehensive list of who to talk about particular subjects? Leucosticte (talk) 06:34, 19 October 2013 (UTC)

RFC vs. going straight to Bugzilla

When is it appropriate to create an RFC, and when should one simply go straight to Bugzilla? Bugzilla is a suitable venue for discussing implementation options too, isn't it? It's also a place where people can debate whether a change should be implemented at all, or whether it should be WONTFIXed. Leucosticte (talk) 02:30, 25 October 2013 (UTC)

Leucosticte: This is a good question. I think that it's harder to embed diagrams into a wiki page, or to mark multiple people as responsible for different components of an RFC, or to properly update what's being discussed (you can edit a wikified RFC but you can't update the initial comment 0 in a Bugzilla bug). I don't have the best answer, though. Sharihareswara (WMF) (talk) 16:42, 14 January 2014 (UTC)

Calling for the question

Is there a way to call for the question? How do we close debate and make a decision? If people are ready to code, it seems undesirable that discussions remain open for years without the proposals being either accepted or rejected. Leucosticte (talk) 03:54, 27 October 2013 (UTC)

Never mind; the architecture meetings would seem to be how that's done. Leucosticte (talk) 16:44, 14 January 2014 (UTC)

would be nice to have better RFC template/formatting

It would be great if templates made it easy to get from the RFC to all relevant discussions offwiki. And I've found that documents like this are a lot easier to read if there's attention to formatting, a good Table of Contents, well-placed slots for diagrams and easy-on-the-eyes code examples, and so on. Sumana Harihareswara, Engineering Community Manager (talk) 04:55, 14 January 2014 (UTC)

Process questions

Here are some questions we might want to answer to improve our RFC process.

Is our RFC process good enough as it is?

Problem

Any changes might make the system worse (is this true?)

Solution

Don't change it

• First: is our RFC process good enough as it is?

• I suggest it could use improvement to clarify expectations for RFC writers and deciders, because people get confused and distracted without clear rules and responsibilities. I think a better RFC process would also lead to less pain for the larger MediaWiki ecology, because developers and administrators could see what transition plans for new breaking changes are. A smoother RFC process would lead to more consistent release management.--Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)

• The process seems clearer (to me anyway) now than it used to be. You write an RFC, post it to the RFC page, and if nothing seems to be happening, you make some noise on wikitech-l, try to get it added to the agenda for the next architecture meeting, etc. User:Qgil did a great job over the past few months advertising the upcoming architecture meetings, making all the pertinent info about the agendas and logistics available, getting people involved, and keeping the meetings on track, I thought. It was very helpful. Leucosticte (talk) 18:42, 14 January 2014 (UTC)

Should we just have one RFC process, or a few different processes (e.g. fast-track)

Problem

The RFC processes that should be high-priority don't get treated that way because there are low-priority RFC processes that distract from them since there is no distinction between the two (is this true?)

Solution

Fast-track high-priority RFC processes

• Should we just have one RFC process, or a few different processes (to fast-track some proposals, divide them up by core/mobile/language/UX/apps or something like that, etc.)?

• I would love for Rob Lanphier, Jared Zimmerman, Howie Fung, Alolita Sharma, Daniel Kinzler, and other folks from groups that would be affected by this kind of change to speak to this question. I suspect that we want to narrow the definition of what kind of change needs to go through the full RFC process, and what kind of change could perhaps go through an RFC-lite or fast-track RFC process.Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)

• I dunno, there's something to be said for reasonably egalitarian treatment of RFCs too. We don't want people to get discouraged by not being able to get their RFCs fast-tracked like some other people's. If we do set up a fast-track process, we should be clear about what the criteria and procedures are for the fast track, so that people don't get the impression it's some sort of cabalistic system in which the proposals of those with rank, pull, connections, seniority, etc. are treated as being more equal than others. Leucosticte (talk) 18:42, 14 January 2014 (UTC)

• I agree that it would be important to treat similar RFCs from different people similarly, to retain egalitarianism. But what about substantially different kinds or sizes of RFCs, even from similar people? I absolutely agree that the criteria and procedures should be clear and public! Also, clear time expectations from the RFC process overall would help reduce the need for a fast track. Sharihareswara (WMF) (talk) 23:21, 14 January 2014 (UTC)

• Having different processes for different types of RFCs is too confusing. Steven Walling (WMF) • talk 21:03, 14 January 2014 (UTC)

• That's a good point too; the more complicated we make the process, the more daunting it gets to put forth a proposal, especially for newcomers. Leucosticte (talk) 21:18, 14 January 2014 (UTC)
• The Python community has had some success in treating informational, standards (the language itself), and meta-process PEPs differently. Sharihareswara (WMF) (talk) 23:21, 14 January 2014 (UTC)

• I think it would be nice to show everyone the complete list. They can prefer to only participate in some, but I think they should at least "read the headlines" of other potential upcoming changes. Gryllida 21:20, 14 January 2014 (UTC)

• What problem(s) do you hope to address in this section? The RFC process seems to largely work. It'd be helpful if you could explicitly define deficiencies before there's a discussion about what to change. --MZMcBride (talk) 00:29, 15 January 2014 (UTC)

Separate Inception Review from Commitment Review?

Problem

Stuff goes to commitment review before it's anywhere near ready (is this true?)

Solution

Have a review before commitment review to make sure it's ready for commitment review

• Separate Inception Review from Commitment Review?

• This is an interesting idea I ran across when I investigated Solaris: an Inception Review comes first and is a more lightweight "go ahead investigating this idea, no one is vetoing it" approval; Commitment Review is where stakeholders agree to abide by an implementation decision. (I think!) Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)
• This sounds like needless bureaucracy. Again, I think it would help if you clearly stated what problems or deficiencies you currently find with the RFC process before suggesting solutions. This is a classic issue in bug reporting where a user suggests a fix (a "solution") without describing the symptoms or the problem or what they're actually trying to do. --MZMcBride (talk) 00:31, 15 January 2014 (UTC)

Should we require that RFCs get co-sponsors in order to be considered?

Problem

RFCs that are so lame they only have one user's support waste reviewers' time

Solution

Require co-sponsors so that we know at least two people thought it was cool enough to be worth reviewing

• Should we require that RFCs get co-sponsors in order to be considered?

• Some communities have found that it helps if RFC authors find a "champion" who helps, for instance, clarify idea vs. specification vs. implementation, edit the RFC, and answer questions. Should we ignore that idea, just encourage it, or actually require it? Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)

• I suggest rejecting that idea, since I think it would probably unnecessarily impede/delay/deter/complicate users' proposing good RFCs. There doesn't seem to have been a problem with people putting forth a lot of totally bad ideas as RFC proposals. At any rate, the architects can shoot down ill-conceived RFCs just as they WONTFIX bugs, without having to waste a lot of time on them. The wiki way, as applied to this process, is to make bad RFCs easy to shoot down, rather than hard to propose. Leucosticte (talk) 18:42, 14 January 2014 (UTC)

• Considered for what? --MZMcBride (talk) 00:32, 15 January 2014 (UTC)

Should we add time limits to any part of the process?

Problem

We have a bunch of stale RFCs clogging up the queue and distracting from RFCs that actually have a chance

Solution

Acknowledge the reality of the situation and remove distractions by moving those old RFCs to archive

• Should we add time limits to any part of the process?

• I suggest that we have the following expectations:
  • We should usually aim to have an RFC moved to Approved (with implementation scheduled), Deferred, or Rejected within six months of the RFC being formally submitted.
  • If there's been NO comment from anyone other than the author 30 days after its proposal, the architecture review committee could summarily reject it for lack of interest.
  • To make "deferred" status more useful, the architecture review committee should revisit all the deferred RFCs every 18 months, just to check whether it's worth restarting discussion. Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)
  • I would support "archiving" rather than "rejecting" ignored proposals. A rejected proposal would face more of a barrier in coming back than an archived proposal. If someone brings back an archived proposal, it's a signal that there's renewed interest from at least one champion. There would be no point in bringing it back unless he intended to push for action on it. Leucosticte (talk) 18:42, 14 January 2014 (UTC)
• What problem are you trying to solve here? Please be explicit. --MZMcBride (talk) 00:32, 15 January 2014 (UTC)

Is ownership working?

Problem

Cookie-licking discourages work on RFCs

Solution

Find some way to stop cookie-licking!

• Is ownership working?

• Ideally each RFC should have one owner/author who writes it and pushes it through each step of the process. Is that happening? If not, what should we do to encourage consistent ownership? Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)

• It's probably helpful to have a primary contact or coordinator for each RFC, kinda like how bugs have people assigned to them. It helps avoid diffusion of responsibility, and lets people know whom to go to with their questions/comments. Leucosticte (talk) 18:42, 14 January 2014 (UTC)

• Or it creates an environment that encourages cookie-licking and discourages collaboration. If you want "consistent ownership," you'll need to pay someone's salary. Otherwise, volunteers are free to do what they'd like with their time. If others want to jump in and provide feedback, well, that's the entire point of the RFC process. Perhaps a clearer definition of a problem would help here. As it is, this section seems to be a solution in search of a problem. --MZMcBride (talk) 00:21, 15 January 2014 (UTC)

Could we please number RFCs?

Problem

It's cumbersome to refer to RFCs by their full names

Solution

Use numbers instead!

• Could we please number RFCs?

• It's easier to refer to RFCs by number, especially when they are confusingly similar. I don't want to bikeshed over a numbering scheme - we can borrow PHP's or Python's or the IETF's or whatever. Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)

• If we're going to do that, for simplicity, let's use positive integers, as we do with Bugzilla. Maybe we should have an interwiki link for the RFCs too, or at least a template to allow for easily linking to them (kinda like Template:Db table). However, it's probably best to stick with the current scheme, and append a number (e.g. "config database 2") as needed. Leucosticte (talk) 18:42, 14 January 2014 (UTC)
• "RFC 1" isn't nearly as helpful as "RFC/Backend storage redesign" or similar. If RFCs are poorly named, that's a separate issue. Any RFC on mediawiki.org already has a(n) unique numeric ID associated with it (the page ID) and usually more than one revision ID. I'd recommend using those if there's a reasonable use-case for obfuscating the RFC's title (I don't see one currently). --MZMcBride (talk) 00:17, 15 January 2014 (UTC)

• Oh right. "RFC X" also creates a magic link. Another point against it. --MZMcBride (talk) 00:18, 15 January 2014 (UTC)

• I think that we should potentially rename RFC to "MediaWiki Design (MWD)" or something like that, so as to avoid the highly overloaded initialism "RFC", and to make it clear that we should be doing more of these (RFC means "controversial" in Wikipedia-speak, whereas design docs are something that should more clearly be done). I think numbers might be helpful in tracking these things as we get more of them (e.g. "Config Database" and "Config Database 2"). -- RobLa-WMF (talk) 03:08, 15 January 2014 (UTC)

• Yes, I think there's a benefit in numbering for the above reasons; I prefer WMD to MWD but I am open to whatever as long as we don't use "RFC NNNN". :) --brion (talk) 19:01, 15 January 2014 (UTC

• How about Mediawiki Improvement Proposal (MIP)? I think this covers really well what the documents are: they are proposals that can be debated and they aim at improving Medawiki. I think the word 'Design' can put people on the wrong foot as it might suggest that there is always a frontend component to it, or that only 'architectects' can 'design'. In addition, we have already too many WM* acronyms :) Drdee (talk) 12:41, 16 January 2014 (UTC)

(unindent) Yes, I agree that the current name ("Requests for comment") probably isn't helping much. Whichever name is chosen, it should use sentence case. --MZMcBride (talk) 04:30, 17 January 2014 (UTC)

How do we ensure that WMF does not do all the decision-making regarding changes that affect MediaWiki generally?

Problem

WMF acts like the needs of WMF are more important than the needs of third-party wikis, when the two interests conflict (is this true?)

Solution

Solve any systemic problems that cause that

• How do we ensure that WMF does not do all the decision-making regarding changes that affect MediaWiki generally?

• I am a member of the WMF so I might not be the best person to make suggestions here -- I'd love to get input from Markus Glaser and Markus Hershberger especially as liaisons with the third-party MediaWiki administrator community, as well as engineers from Wikia and ShoutWiki or other large MediaWiki installations, and members of (for example) the Semantic MediaWiki community. Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)

• I suggest increasing representation of such stakeholders on the Wikimedia Foundation Board of Trustees, since the architects ultimately report to the board (albeit indirectly, through a chain of command). The board could reserve a few seats for third party wiki developers and system administrators. Leucosticte (talk) 18:42, 14 January 2014 (UTC)

• Fund community work on extensions and the like. IEG Comittee doesn't appear to do this currently, and I'm not sure who does. Extensions have relatively larger impact than outreach and poorly integrated tools. Gryllida 21:23, 14 January 2014 (UTC)

• A part of this could be funding community work on new software, or dedicating at least a half the Team time to implementing bugs community reported. Such big things make a difference. The two specific bugs which I reported, which I might perhaps classify as regression, come to mind — Bug 59230 - Missing thread depth setting, Bug 59231 - Missing setting for displaying or not displaying user mentions (pings). I think they're related to this question. They're community voice. How do we make sure they're implemented, and the WMF doesn't make a decision to limit thread depth or to impose username mentions habit on everyone? Gryllida 21:39, 14 January 2014 (UTC)
• Notifications: Linking a username in an Edit-Summary should trigger a notification — the change is already happening though. Gryllida 22:32, 14 January 2014 (UTC)

• Importantly I think the point is having a link to current RFCs in a prominent place each contributor can see. I didn't know of the process, until today, when I saw a message on the mailing list. Gryllida 21:39, 14 January 2014 (UTC)
• input.wikimedia.org? — please read the entire thread. Gryllida 21:39, 14 January 2014 (UTC)
• Probably by devoting a separate WMF team to user feedback. Gryllida 21:39, 14 January 2014 (UTC)
• I've updated my question above to clarify and expand on whom I'm asking for feedback! Sharihareswara (WMF) (talk) 23:08, 14 January 2014 (UTC)

• I have out-indented my thoughts; there were not really meant as a response to you, more, to the original question. Gryllida 23:51, 14 January 2014 (UTC)

• By doing it? I don't understand this section. --MZMcBride (talk) 00:21, 15 January 2014 (UTC)

• I appear to have interpreted the question generously, implying they want to go away from making decisions to something else; to shape the something else, they may want to know an answer to this question: “How do we extract ideas from community worth working on?”. Gryllida 04:41, 17 January 2014 (UTC)

Are our current how-to-write-an-RFC guidelines good enough?

Problem

The RFC guidelines are not clear, concise, concrete, correct, coherent and complete enough

Solution

Make them sail those six C's

• Are our current how-to-write-an-RFC guidelines good enough?

• I don't want us to overwhelm new RFC authors with a giant template. But it would be good to suggest that they provide, if applicable:
  • an abstract
  • links to other relevant discussions onwiki, on mailing lists, in Bugzilla, etc.
  • an explanation of the status quo
  • benchmarks
  • research into what other projects do
  • risks
  • transition plan, backwards compatibility plan, and future maintenance plan
  • open questions
  • example code
  • a photo of the creator, to help us see who we're talking with :-) Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)

• That sounds okay to me, although I think it's okay to just put the photo on the userpage. Leucosticte (talk) 04:57, 17 January 2014 (UTC)

Should we version RFCs?

Problem

People might not realize, the new RFC has been drastically changed from the one they formed a judgment about before

Solution

Specify RFC versions

• Should we version RFCs?

• In addition to a clear last-modified date, sometimes it's nice to actually say, "this is beta," "this is 1.0," "this has changed enough that it's 2.0." On the other hand, if it is that different, maybe it should be a different RFC altogether.

• We might at least note somewhere in the RFC document a brief history of the proposal, with links to the architecture minutes, e.g. "originally we proposed x, which was rejected at such-and-such meeting because of y; therefore, we modified the RFC and now we propose z."

Should we have a group of editors who help do administrative work on RFCs?

Problem

The RFCs are in crummy shape because not enough administrative work has been done consistently across all of them (is this true?) Further problem: It hasn't been specified what standards, exactly, these RFCs are supposed to meet

Solution

Organize an effort to specify standards to get that administrative work done (if there's no other lower-overhead way)

• Should we have a group of editors who help do administrative work on RFCs?

• I think it's cool that Python has a set of PEP editors who run the process and help get RFCs into shape. Does our current architectural review committee do this enough, or should we add a set of editors/coordinators? I think probably our ARC does this enough, but I figured I'd check. Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)

• Maybe we should start MediaWiki.org wikiprojects for such tasks. Thus far, this community hasn't embraced the concept as enthusiastically as Wikipedia has, but maybe the wikiprojects proposed thus far weren't compelling enough. Leucosticte (talk) 18:42, 14 January 2014 (UTC)

• What administrative work? --MZMcBride (talk) 00:22, 15 January 2014 (UTC)

Which extensions require RFCs for big changes?

Problem

There's confusion about when RFCs are necessary

Solution

Provide guidelines to clarify

• Which extensions require RFCs for bug changes?

• My vague idea: widely-used extensions that are NOT deployed on Wikimedia Foundation's very widely-used sites? Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)
• This question makes no sense. What's a "bug change"? --MZMcBride (talk) 00:23, 15 January 2014 (UTC)

• Fixed. Sharihareswara (WMF) (talk) 03:01, 15 January 2014 (UTC)

How does this process dovetail with release engineering?

Problem

Are we prioritizing RFCs to get what needs to be put in each target release, in that release? If not, how do we prioritize properly? (See above "fast track" item)

Solution

Make sure you get those items on the agenda for a meeting that's early enough that there's still time, after RFC approval, to implement the changes before the release?

• How does this process dovetail with release engineering?

• I sense that juggling which RFC to implement first will sometimes involve discussions with release engineers and release managers, but I don't know how to address that concretely. Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)
• I don't understand the use of the word "dovetail" or "release engineering" here. I've never even heard the latter term. Can you clarify what it is you're talking about in this section? --MZMcBride (talk) 00:24, 15 January 2014 (UTC)
  • What?! Surely you, of all people, have heard of release engineering aka RelEng? w:Release engineering, Wikimedia Release and QA Team, etc. This, that and the other (talk) 09:50, 15 January 2014 (UTC)
    • I agree that there's an article on the English Wikipedia. I'm not sure what makes you think I'd ever come across it previously (or the local "Release and QA" page, for that matter). Thanks for the links. :-) Greg's comment below is somewhat helpful, but generally I agree with my preliminary assessment that the wrong questions are being asked here. Or more specifically, the RFC process process isn't proceeding in a manner that suggests a positive outcome. I'm very doubtful that anything useful will come of this (very broad) discussion because actual problems with the current system aren't getting much focus. Perhaps the name ("Requests for comment") will be changed, because that's a concrete and fixable problem. Otherwise, ehh. --MZMcBride (talk) 04:36, 17 January 2014 (UTC)
• Just a note on the current state of affairs: Prioritization of what is included in MW tarballs is done by the current MediaWiki Release Managers, aka Mark H and Markus G (per the RFP we ran). Prioritization of work going out to the WMF Cluster (aka, the servers that run the WMF-hosted projects) is done by myself, Reedy, WMF product managers, and the WMF engineering managers. The WMF product managers are explicitly tasked with incorporating community input, fwiw (myself and Reedy are also pretty open to such things ;) ).

Regarding this Problem explicitly: I don't think we, as of yet, are prioritizing the RFCs to a specific MW version (eg the upcoming 1.23). This may, in fact, be an outcome of the Arch Summit, and maybe it should be. There will be important conversations to be had to align 3rd party priorities and WMF cluster/Wikipediamedia* Community priorities (these are not always the same). The biggest issue is, of course, time allotment and really out of scope for "Release Engineering" and more in scope for "that big conversation that happens within the MediaWiki community about priorities". Greg (WMF) (talk) 18:24, 15 January 2014 (UTC)

Do we feel like we have good alignment on what MediaWiki's design/engineering philosophy is?

Problem

These RFCs don't have results that align with our design/engineering philosophy (is this true?)

Solution

Make it align

• Do we feel like we have good alignment on what MediaWiki's design/engineering philosophy is?

• I think sometimes RFCs founder because different developers don't share the same core understanding of what we want MediaWiki to be (e.g., how we value backwards compatibility, architectural principles, etc.). Have the draft Architecture guidelines helped with this? To have a more coherent RFC process, should we push to get the guidelines finalized soon? Sharihareswara (WMF) (talk) 17:49, 14 January 2014 (UTC)
• Principles lays out some of this. --MZMcBride (talk) 00:52, 15 January 2014 (UTC)

"For ideas, I looked into the RFC-type processes for MediaWiki, Python (PEPs), PHP, Clojurescript, Solaris, and Joomla!, and am looking into WordPress and Drupal. Hope this is helpful." Sharihareswara (WMF) (talk) 17:51, 14 January 2014 (UTC)