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(a)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:
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_princ…
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l