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)