MediaWiki

Talk:Requests for comment/Archive

< Talk:Requests for comment
Latest comment: 10 years ago by Leucosticte in topic Process questions

People to consult with or look for a decision from

Latest comment: 11 years ago1 comment1 person in discussion

"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

Latest comment: 10 years ago2 comments2 people in discussion

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

Latest comment: 10 years ago2 comments1 person in discussion

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

Latest comment: 10 years ago1 comment1 person in discussion

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

Latest comment: 10 years ago56 comments9 people in discussion

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)
  • 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)

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?
  • 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?
  • 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)
  • 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)
  • 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)
  • 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)

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?
  • 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)

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?

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?

"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)

Retrieved from "https://www.mediawiki.org/w/index.php?title=Talk:Requests_for_comment/Archive&oldid=4088449"
Return to "Requests for comment/Archive" page.