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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
