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