Talk:Requests for comment

Proposed RFC process
Rob Lanphier has asked that the WMF architects — namely Brion Vibber, Mark Bergsma, Asher Feldman and myself (Tim Starling) — take a leading role in accepting or rejecting RFCs, or delegating that decision as appropriate.

Along these lines, I'd like to add an header template to every RFC indicating its status as determined by one of these architects or the people to whom they delegate authority. The header would indicate not only status (mirroring the index page) but also the name of the person who chose that status.

Seeking consensus has always been a key part of my work on MediaWiki. I expect that a large part of assigning a status to an RFC will simply be to evaluate the comments of the participants, or to seek comments from specific domain experts where none have been given.

Many RFCs are just "good ideas", often attracting no comment because there is no obvious criticism of the feature at the level of detail given by the proposer. This raises the question of whether an RFC is a feature request (like a Bugzilla enhancement) or a design document. If an RFC is a design document, then we might ask for more detail about feature implementation, and close the RFC if none is given. This may lead to the closure of RFCs which have no interest or support from developers. I'm inclined to think that this is an appropriate path to take, i.e. that RFCs should be design documents, but I am interested to hear comments on the subject.

-- Tim Starling (talk) 05:22, 27 June 2013 (UTC)
 * Hi.
 * I'm not sure why you seemingly make a dichotomy between a feature request and a design document. The two are very often related and inter-connected.
 * You seem to also suggest that design documents can expire. This is probably true if surrounding circumstances change such that the idea is no longer applicable or relevant. But if a design document is still applicable and relevant and it describes a possible path forward for the future of MediaWiki, I don't see a compelling reason to scuttle it away into an archive simply because nobody has gotten around to implementing it yet. That seems unfair and counter-productive. And it has the underlying suggestion of a deadline that simply doesn't exist. --MZMcBride (talk) 05:33, 18 October 2013 (UTC)
 * Potentially the same problem can arise here that arises at, say, Wikipedia's peer review and similar venues. People are asking for others to give input, but often the others would have to study the topic in order to make informed comments, and people are busy with their own stuff. So there ends up being a backlog. Fortunately, here we have something they don't have at WP, which is wikitech-l and the other means of communication, so hopefully we can always jumpstart stalled discussions.


 * Of course, there's even more of a backlog for features that the development community has agreed should be implemented, but no one has stepped forward to implement; but that is a harder backlog to cope with than what we have here. Hopefully the community or at least the lead developers will always be willing to at least give a yay or nay on proposals, and the reasons for it. That way, one of three things can happen: a developer who wants to take the initiative to implement the changes can (1) feel free to do so, knowing that it will get merged if done according to the agreed-upon specifications; (2) have enough information to know how to revise his proposal so it will be acceptable; or (3) know that his proposal has been decisively rejected. That's really all that I would ask for from this process.


 * If someone has a good-faith intention to implement the ideas he proposes here, then I think it is fair to let him keep the proposals on the list until people respond. It's sort of like how at Wikipedia, no one thinks an article should get rejected from being a good article or featured article just because no one wanted to give input at WP:GAN or WP:FAC. If you're willing to put in the work to write a good or featured article, and you nominate articles in good faith, then it's reasonable to expect, rather than a delisting due to lack of interest, a response that gives the guidance you need to finish your work.


 * Basically, there are a couple different kinds of backlog: (1) The type of backlog we often see at bugzilla, where people make proposals they have no intent of implementing; and (2) the type where someone is actually willing to implement the changes. On Wikipedia, the way they attempt to differentiate is by only letting each editor nominate one featured article candidate at a time, on the assumption that he cannot focus on improving more than at a time to that level. That provides an incentive to nominate the most promising articles first and to put more of an effort into quickly addressing concerns people raise about the nominations, so that the nominator and the community can move on to other articles. Leucosticte (talk) 05:27, 19 October 2013 (UTC)

Process guidelines
After our disagreement at 40040, MZMcBride moved the process instructions at the top to a subpage and said they only apply for 'large' changes. I see no reason to have two processes, and if a change is small, it probably doesn't need to be an RFC. Hence, I've reverted. Superm401 - Talk 05:41, 18 October 2013 (UTC)
 * This doesn't make any sense. You're ignoring past practice here in favor of a rigid process that nobody has agreed to. While it's great to have guidelines for how to implement large changes, they're not binding and certainly not always followed or warranted. Smaller changes absolutely can still require discussion or the need to solicit feedback. Your arguments don't seem to based on anything more than an attempt to feud with me. For example, you seem to ignore that many RFCs focus on small changes. You also seem to ignore that many RFCs are not announced on wikitech-l (though more probably should be). Please stop. --MZMcBride (talk) 18:23, 18 October 2013 (UTC)

Maintaining this page
It's a pain to see this list maintained by hand. Would we like to add RFC pages to relevant categories and then automate the process using DynamicPageList? Although I believe that only page title and date of addition to category would be visible; custom comments would be lost. --Gryllida 22:31, 2 September 2014 (UTC)


 * The minor pain seems to not outweigh the major loss using DPL would show, as you identify. Jdforrester (WMF) (talk) 22:57, 2 September 2014 (UTC)

Cleanup
This page desperately needs some cleanup. Some RfCs are from 2010 or have not been touched for ages. It's hard to identify those that are actively worked on. There's already an archive page. I suggest we move those RfCs to the archive which have not been discussed for a year. Also, there are accepted RfCs that are already implemented (I guess), such as LESS or CirrusSearch. Can we move those to the archive as well? I can do the work, if some people agree on those two criteria :) Oh, and no need to say an RfC can be reactivated (moved back from the archive) if someone decides to work on the issue. --Mglaser (talk) 20:57, 14 October 2014 (UTC)
 * My plan here is to re-do the indices to be automatically updated, rather than manually updated. I think that should help a bit. --MZMcBride (talk) 20:40, 13 December 2014 (UTC)

Here's the hierarchy I'm looking at:


 * RFC – Category:Requests for comment – all RFCs
 * – Category:Open requests for comment – all open RFCs (listed at RFC)
 * – Category:Draft requests for comment – all open RFCs in draft
 * – Category:Proposed requests for comment – all open RFCs in discussion
 * – Category:Accepted requests for comment – all open RFCs that have been accepted
 * – Category:Stalled requests for comment – all open RFCs that have stalled
 * – Category:Archived requests for comment – all archived RFCs (listed at RFC/A)
 * – Category:Declined requests for comment – all archived RFCs that have been declined
 * – Category:Implemented requests for comment – all archived RFCs that have been implemented


 * Direct subpages


 * Uses of RFC


 * Category:Requests for comment members


 * Links on RFC and RFC/A: [likely soon to be broken]