Jon Robson wrote:
This sounds great. I've always felt the RFC process was a bit of a black box of no return. I think regular triage of these and closing/progressing these is much needed and will be a hugely positive thing.
It's only a "black box of no return" in the sense that creating an RFC on mediawiki.org won't magically implement a new feature or fix an outstanding issue. The point of an RFC is to request comments (solicit feedback) about an idea or brainstorm and draft implementation details of an idea. Coding an idea is still a separate step, unfortunately.
Tim Starling wrote:
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.
I responded to this in May http://lists.wikimedia.org/pipermail/wikitech-l/2013-May/069575.html. The discussion quickly died, but I still agree with most of what I wrote there:
It may make sense to have a more standardized structure for RFCs. Or at least some better guidance on how to create an RFC. Sometimes people will forget to include background information or a clear statement of the problem and will instead skip straight into proposing solutions.
The relationship between an RFC and Bugzilla could also use consideration. For example, I prefer that a mature RFC be attached to a tracking bug in Bugzilla.
[...]
There seems to be a disagreement about the purpose of RFCs. Some people have suggested that RFCs without a clear execution path and "owner" (i.e., someone committed to implementing the idea) should be avoided. As pointed out in the current architecture guidelines, RFCs encompass ideas that:
- someone is hoping others will bring to fruition; or
- that currently lack concrete implementation details.
I don't see this as an issue. I would simply call these draft RFCs (which the current RFC setup basically does). My concern is that these draft RFCs may be damaged or destroyed if more stringent requirements are introduced.
While I can appreciate the desire to have a clear, concise, and actionable RFC for every grand idea, I think this desire misses the wiki and consensus-building components of RFCs. They're not simply "I want to and am willing to implement feature X"; requests for comment are often about soliciting input and feedback about how to approach a particular problem. Sometimes the solution isn't clear and/or feedback is needed.
The benefits I see to RFCs are that (a) they are more structured, organized, reference-able, and permanent than mailing lists discussions; and (b) they are less e-mail-y and reply conversation-y than Bugzilla comments. (This isn't to say that a well-formed RFC won't include discussion, of course.) For cases where a developer wants a discrete action item, that's the scope (broadly) of a bug report, in my opinion.
In short, I don't see a measurable advantage to trashing a lot of currently incomplete RFCs, while the disadvantage to doing so seems quite clear.
I'd also say that there's a "no place to discuss" issue that's been forming. If you try to use Gerrit for discussion, someone complains. If you try to use Bugzilla for discussion, someone else complains. The wiki is a refuge. I'd hate to see yet another person come along and say that it too can't be used for discussion.
Much like Wikipedia has millions of articles that editors can choose to work on and Bugzilla has thousands of bugs that developers can choose to hack on, is there any reason there can't be dozens of RFCs that dreamers can choose to think on? If you want to simply categorize the RFCs or re-index them, I think that's fine. But the talk of an RFC backlog and cleanup process makes me think that the goal is to do much more and I don't see what purpose is served.
MZMcBride