Hi folks,
Many of us met at the Amsterdam Hackathon to discuss architecture guidelines (almost everyone with +2 in MediaWiki core, plus other knowledgeable people), and generally about the need to have more substantive conversations about MediaWiki architecture. It was a really productive discussion, and had a number of outcomes:
1. RFC review: we agreed that RFCs need more diligent review. Brion and Tim are planning to pull together the architects for regular discussions (weekly? TBD) to at least touch all of the outstanding RFCs, with the goal of clearing the current backlog of RFCs. If y'all don't see substantial movement on this in a couple of weeks, please point this out.
2. RFC use: right now, RFCs aren't used in many cases where they should be. Assuming we get into a good flow with RFCs, we can then reasonably expect people to actually write them when they're making significant changes to the MediaWiki architecture.
3. Architecture guidelines: we now have a rough beginning draft of architecture guidelines[2] we plan to use as guiding principles for RFC review. This is a document that we plan to discuss on wiki in c2 wiki style[3]. Please participate! This is a living document, which will be referenced in RFCs and responses to RFCs. We will use this mailing list to discuss the more contentious issues and generally ensure we continue to move forward refining this document.
4. A general agreement that we need to make sure that we have similar conversations at every substantial gathering of +2 developers. For example, we plan to figure something out for Wikimania.
We have raw notes from both days of meetings, available here: https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013/Architectural_princi...
Rob
[1] http://www.mediawiki.org/wiki/Requests_for_comment [2] https://www.mediawiki.org/wiki/Architecture_guidelines [3] "c2 wiki style" is with inline comments similar to the c2 Design Patterns wiki: http://c2.com/cgi/wiki?DesignPatterns
Rob Lanphier wrote:
- RFC use: right now, RFCs aren't used in many cases where they
should be. Assuming we get into a good flow with RFCs, we can then reasonably expect people to actually write them when they're making significant changes to the MediaWiki architecture.
\o/
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.
- RFC review: we agreed that RFCs need more diligent review. Brion
and Tim are planning to pull together the architects for regular discussions (weekly? TBD) to at least touch all of the outstanding RFCs, with the goal of clearing the current backlog of RFCs. If y'all don't see substantial movement on this in a couple of weeks, please point this out.
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.
MZMcBride
One of the reasons we want to get the RFC process moving again is that we've got some general agreement that it'll be necessary to do some big refactorings and internal API improvements... yes, we're thinking of seriously going for a MediaWiki 2.0.
This is going to mean actually going through and killing some old deprecated interfaces, and possibly a big maintenance/conversion effort on extensions to keep them up to date with internals changes. Some of these changes will be contentious, but necessary for making MediaWiki a better, easier to use, easier to maintain, and easier to extend framework.
Having a clearer RFC process should let us discuss these things without falling too much into bikeshedding, and most importantly make sure we come to decisions and actually implement them. Official buy-in from WMF Engineering and from core committers and reviewers is important in making this real -- and I feel like we have it.
Over the next few weeks I hope that we'll get through much of the existing RFC backlog, and then we'll be able to put bigger things on the table that move us towards 2.0.
We might think about looking at the Python PEP process, or the committer voting that Apache projects tend to do, as partial examples to follow (or diverge from, as necessary.)
-- brion
On Sat, May 25, 2013 at 3:50 PM, Rob Lanphier robla@wikimedia.org wrote:
Hi folks,
Many of us met at the Amsterdam Hackathon to discuss architecture guidelines (almost everyone with +2 in MediaWiki core, plus other knowledgeable people), and generally about the need to have more substantive conversations about MediaWiki architecture. It was a really productive discussion, and had a number of outcomes:
- RFC review: we agreed that RFCs need more diligent review. Brion
and Tim are planning to pull together the architects for regular discussions (weekly? TBD) to at least touch all of the outstanding RFCs, with the goal of clearing the current backlog of RFCs. If y'all don't see substantial movement on this in a couple of weeks, please point this out.
- RFC use: right now, RFCs aren't used in many cases where they
should be. Assuming we get into a good flow with RFCs, we can then reasonably expect people to actually write them when they're making significant changes to the MediaWiki architecture.
- Architecture guidelines: we now have a rough beginning draft of
architecture guidelines[2] we plan to use as guiding principles for RFC review. This is a document that we plan to discuss on wiki in c2 wiki style[3]. Please participate! This is a living document, which will be referenced in RFCs and responses to RFCs. We will use this mailing list to discuss the more contentious issues and generally ensure we continue to move forward refining this document.
- A general agreement that we need to make sure that we have similar
conversations at every substantial gathering of +2 developers. For example, we plan to figure something out for Wikimania.
We have raw notes from both days of meetings, available here:
https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013/Architectural_princi...
Rob
[1] http://www.mediawiki.org/wiki/Requests_for_comment [2] https://www.mediawiki.org/wiki/Architecture_guidelines [3] "c2 wiki style" is with inline comments similar to the c2 Design Patterns wiki: http://c2.com/cgi/wiki?DesignPatterns
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org