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)

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)