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 bugzilla: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)

@Gryllida: 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)

This is now done. Most of the comments weren't very useful. :-) --MZMcBride (talk) 03:34, 29 December 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
  • state = alive – Category:Open requests for comment – all open RFCs (listed at RFC)
    • status = in draft – Category:Draft requests for comment – all open RFCs in draft
    • status = in discussion – Category:Proposed requests for comment – all open RFCs in discussion
    • status = accepted – Category:Accepted requests for comment – all open RFCs that have been accepted
    • status = stalled – Category:Stalled requests for comment – all open RFCs that have stalled
  • state = dead – Category:Archived requests for comment – all archived RFCs (listed at RFC/A)
    • status = declined – Category:Declined requests for comment – all archived RFCs that have been declined
    • status = implemented – Category:Implemented requests for comment – all archived RFCs that have been implemented

Thanks. As I said on template talk:RFC, the "status" options provided are fine, the rest is of little use and should be deprecated or made optional. --Nemo 09:25, 14 December 2014 (UTC)

I've cleaned up some parameters while surveying some RfC (including all the accepted ones); some template inclusions are currently looking ugly, which is good because that will encourage correction of parameters. I've also updated all the pages previously listed in Requests for comment/Archive and made that page automatic. Of course the dates look a bit silly now, because the categories are new, but the future additions will make sense. --Nemo 11:24, 14 December 2014 (UTC)

Awesome! I'm still reviewing your edits, but so far they look pretty good. I was thinking of using CategoryTree, but maybe DynamicPageList is better. It would be neat if we could strip the "Requests for comment/" prefix somehow. --MZMcBride (talk) 22:10, 14 December 2014 (UTC)

[Moved discussion from Template talk:RFC. --MZMcBride (talk) 22:02, 14 December 2014 (UTC)]

Merge "status" and "state"

I don't see a need of two very close parameters. --Nemo 22:08, 13 December 2014 (UTC)

The idea was to have a system where you could theoretically distinguish between open/abandoned and closed/abandoned. Or even possibly between open/stalled and closed/stalled. Not everybody seems to be aligned on whether an RFC is attached to an idea or to a person, so I was trying to create a system that could be both stricter now and possibly more flexible later. If you think only a status parameter is needed, that's probably fine. --MZMcBride (talk) 21:58, 14 December 2014 (UTC)

Note that there is also RFC metadata‎ and phab:tag/mw-rfcs/. Indeed, too many spaces for the little energy we currently put updating and documenting.--Qgil-WMF (talk) 12:06, 15 December 2014 (UTC)

Queries

Extended content

Direct subpages SELECT page_title FROM page WHERE page_namespace = 0 AND page_is_redirect = 0 AND page_title LIKE 'Requests_for_comment/%' AND page_title NOT LIKE '%/%/%'; Uses of {{RFC }} SELECT page_title FROM page JOIN templatelinks ON tl_from = page_id WHERE tl_title = 'RFC' AND tl_namespace = 10; Category:Requests for comment members SELECT page_title FROM page JOIN categorylinks ON cl_from = page_id WHERE cl_to = 'Requests_for_comment' AND page_namespace = 0; Links on RFC and RFC/A [likely soon to be broken] SELECT DISTINCT pl_title FROM page JOIN pagelinks ON pl_from = page_id WHERE page_namespace = 0 AND page_title IN ('Requests_for_comment', 'Requests_for_comment/Archive') AND pl_title LIKE 'Requests_for_comment/%';

Just a silly section of queries. --MZMcBride (talk) 22:04, 14 December 2014 (UTC)

Wiki page input box

Hi. I still use the wiki pages for drafting RFCs, so having the input box is really helpful to me. Otherwise, I have to do some janky copying and pasting from an existing RFC to get the infobox and formatting that I need and I'd rather not do that. The updated process documentation includes using a subpage as an option, so having the input box form accessible is nice for everyone involved.

Broadly, I think we should let developers decide whether Phabricator Maniphest task descriptions or a wiki page are better for their needs. In many cases, I think wiki pages are superior for technical documentation outlining and drafting, but we should gladly accept either form of submission. --MZMcBride (talk) 02:17, 6 April 2015 (UTC)

RfC time

At some point Tim Starling, when he basically run the RfC meetings alone, was kind enough to set them at 7 or 8 his time. Nowadays, can we get an up to date rationale for the meetings always being at 22 UTC? At m:Google Hangouts someone wrote that «Events hosted at WMF headquarters have proved to be most successful when scheduled at 15 UTC»; maybe some quick poll could be held between the interested people to see if there's any time option which stands out. Nemo 08:33, 3 December 2015 (UTC)

Importing tasks from Phabricator

This comment inspired an idea:

In Phab:T134537#2268989, @bd808 wrote:

[This incident report writeup] probably should be copied to a new page in https://wikitech.wikimedia.org/wiki/Incident_documentation as well unless you can convince @greg that we should be switching to Phab for this sort of thing.

There are many longer ArchCom-RFCs that should also be migrated to mw.org, with a short summary in Phab, and then longer writeup over here.  I would love for there to be some sort of gizmo (e.g. bot, gadget, special page) that let a person poke a button, and convert the Phab remarkup into MediaWiki markup, then post it to a named page.  It could even just use the Phab task number (e.g. post the mw markup to <https://mediawiki.org/wiki/T134537>), and then the person importing could choose to use standard page move tools to move+redirect it.

Is this something we should try inspiring a new developer (GSoC/Outreachy) to try? Alternatively, is this comment enough to nerdsnipe someone?  ;-) -- RobLa-WMF (talk) 01:39, 6 May 2016 (UTC)

One possible way to do this would be with a Tool Labs tool that could connect to the Phabricator and MediaWiki APIs. The basic parts needed:

• Get task description data via maniphest.info
• Get "transactionType": "core:comment" data via maniphest.gettasktransactions
• Create a transformation from Phabricator style remarkup to wikitext
• Use OAuth and the Action API to edit a MediaWiki page

The hard part of this stack is the markup transformation. There are various hacky ways that it could be done that would probably be good enough to cover the 80% use case. Implementing a completely faithful transformation would be a pretty deep rabbit hole to dive into. --BDavis (WMF) (talk) 15:39, 6 May 2016 (UTC)

Of course there is pandoc, but I didn't test it with Phabricator's markup as input. Nemo 16:18, 6 May 2016 (UTC)