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