Rob Lanphier has asked that the WMF architects -- namely Brion Vibber, Mark Bergsma, Asher Feldman and myself -- 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.
Please comment here or on https://www.mediawiki.org/wiki/Talk:Requests_for_comment
-- Tim Starling
Tim
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.
I'm looking forward to seeing this progress!
On Mon, Jul 1, 2013 at 10:03 PM, Tim Starling tstarling@wikimedia.org wrote:
Rob Lanphier has asked that the WMF architects -- namely Brion Vibber, Mark Bergsma, Asher Feldman and myself -- 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.
Please comment here or on https://www.mediawiki.org/wiki/Talk:Requests_for_comment
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
<quote name="MZMcBride" date="2013-07-03" time="00:16:16 -0400">
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 assume your above statement is mostly in reply to Tim's below statement:
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.
If that assumption is true, then I don't think "closing" an RFC is "trashing" it. It doesn't have to be deleted, it can simply be listed in a "Closed" section on the RFC page. If the world changes in the future (as tends to happen) then it might make sense in the future even if it doesn't now, so it could be taken up at that point.
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.
Isn't that what any specific proposal's talk: page is for? And then the appropriate mailing list, of course? (probably wikitech-l, but maybe mobile or something if it could use some specialized comments before coming to wikitech-l).
Let me know if I misunderstood you in some way. But I think your concerns aren't likely to be a concern as I don't think deletion is on the list, only moving to a "not gonna happen right now" list.
Greg
On Tue, Jul 2, 2013 at 9:16 PM, MZMcBride z@mzmcbride.com wrote:
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.
MZ you seem to be misunderstanding my point. Usually an RFC is made when the way forward is not clear and thus it is impossible (or at least would not be worthwhile spending valuable development time) to implement.
It is a black box when there is no outcome due to lack of engagement. I see this new process as bringing much needed guidance from key architects such as but not limited to: * this is clear enough to be implemented * this should never be implemented. * this could be implemented but we need to think about X, Y and Z before doing so. * this is not in our interests * you have not engaged in this RFC for a good 3 months now so I guess you lost interest
I hope this makes things clearer to you.
I endorse this message as well. We should start taking ownership and shepherding the RFCs through to either completion or rejection with good reasons. I'll be tearing myself away from mobile apps fun a little to make more time for this. :)
-- brion
On Mon, Jul 1, 2013 at 10:03 PM, Tim Starling tstarling@wikimedia.orgwrote:
Rob Lanphier has asked that the WMF architects -- namely Brion Vibber, Mark Bergsma, Asher Feldman and myself -- 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.
Please comment here or on https://www.mediawiki.org/wiki/Talk:Requests_for_comment
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 02/07/13 07:03, Tim Starling a écrit :
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.
Hello,
There is definitely an issue in feature with no follow up being considered as RFC. They should be considered draft pending approval to actually enter a RFC process which would lead to an actual implementation.
We could probably get some inspiration by looking at the IETF (Internet Engineering Task Force) process, most of it is described in RFC 2418: http://tools.ietf.org/html/rfc2418 . A 30'000 feet overview (and possibly a wrong one) is roughly:
- people having an idea form a working group the working group as clear goals and achievements expectations.
- people discuss over mailing list and draft documents which will be the base of a all group session - session issue a draft of their document - repeat
- their work is published as an RFC (which is merely a publishing process, not forming an actual standard).
- the working group is disbanded
Eventually a RFC will become a standard and all vendors are expected to implement it :-]
Applied to us, most of the RFC actually on mw.org would be more call for participants. That would lead to someone being in charge, forming a group of interested people that would have the role to formalize a document. The document would then be approved by the architects and form an actual RFC. The RFC would eventually be implemented.
Starting with a glossary and describe roles of people would be a nice first step. We could then work on writing down the process steps.
My 0,02€
wikitech-l@lists.wikimedia.org