It seems like there are two dimensions to this problem. X: Should it be part of stock MediaWiki or not Y: Is it better to write features as discreet modules or spread them out the way core is currently done
The problem is when you move across X, you are forced to cross Y; If we were to start moving extensions into core, it would mean breaking up otherwise well bundled units of code into lots of tiny parts and spreading them out. But why must this be the case? Modular feature development being unique to extensions points out a significant flaw in the design of MediaWiki core. There's no reason we can't convert existing core features to discreet components, much like how extensions are written, while leaving them in stock MediaWiki. This sort of design would also make light work of adding extensions to core. - Trevor On 9/22/10 12:11 AM, Ryan Lane wrote: > On Tue, Sep 21, 2010 at 8:34 PM, Trevor Parscal<tpars...@wikimedia.org> > wrote: >> In response to recent comments in our code review tool about whether >> some extensions should be merged into core MediaWiki, or not. I would >> like to try and initiate a productive conversation about this topic in >> hopes that we can collaboratively define a set of guidelines for >> evaluating when to move features out of core and into an extension or >> out of an extension and into core. >> >> <unintended bias> >> >> Arguments I have made/observed *against* merging things into core include: >> >> 1. Fewer developers have commit access to core, which pushes people >> off into branches who would have otherwise been able to contribute >> directly to trunk, inhibiting entry-level contribution. > People can get access to core. This is a poor argument for not > integrating things into core. If this is a problem, then it is a > problem with us, and our processes, and should be fixed. > >> 2. Extensions encourage modularity and are easier to learn and work >> on because they are smaller sets of code organized in discreet >> bundles. >> 3. We should be looking to make core less inclusive, not more. The >> line between Wikipedia and MediaWiki is already blurry enough as >> it is. >> > I think this should be the case, but there are certain sets of > functionality that people expect to be installed in a default > installation. A usable editing interface is definitely one of those > things. > >> Arguments I have made/observed *for* merging things into core include: >> >> 1. MediaWiki should be awesome out-of-the-box, so extensions that >> would be good for virtually everyone seem silly to bury deep >> within the poorly organized depths of the extensions folder. > I totally agree with this to an extent. I don't think we should be > including everything and the kitchen sink, but things that make > MediaWiki simply feel broken when they are missing should be > integrated. ParserFunctions is an amazing example of this. MediaWiki > simply doesn't work without ParserFunctions. You can tell me it does, > and that people can live without it, but I refuse to believe that. We > get support issues extremely frequently that end in "install > ParserFunctions". > > I'd also like to mention that something I'm seeing in even greater > frequency now is "how do I get Vector to work like it does on > Wikipedia?" or "How do I make the sidebar collapse", or "why doesn't > my search bar work like it does on Wikipedia"? > > Why did we expend all of this effort on usability if we are going to > make it a pain to use if you aren't Wikimedia? That is very > anti-usability. > >> 2. When an extension is unable to do what it needs to do because it's >> dependent on a limited set of hooks, none of which quite do what >> it needs. > This goes back to people needing core access to add hooks. In reality, > they can send patches, or ask a dev with core access to do so. I've > had a number of hooks added this way. > >> 3. Because someone said so. >> > Agreed. This is never a reasonable argument. > >> </unintended bias> >> >> <obvious bias> >> >> I will respond to these three pro-integration points; mostly because I >> am generally biased against integration and would like to state why. I >> realize that there are probably additional pro-integration points that >> are far less biased than the three I've listed, but I am basing these on >> arguments I've actually seen presented. >> >> 1. This is a very valid and important goal, but am unconvinced and >> merging extensions into core is the only way to achieve it. We >> can, for instance, take advantage the new installer that demon is >> working on which has the ability to automate the installation of >> extensions at setup-time. > One problem I have every time I upgrade MediaWiki is extension > compatibility. Extension management in MediaWiki is simply broken. > Until we have a reasonable way to handle extension compatibility and > some reasonable means for people to upgrade extensions, this is a > painful course of action. > >> 2. This seems like a call for better APIs/a more robust set of hooks. >> Integration for this sort of reason is more likely to introduce >> cruft and noise than improve the software in any way. > This would help. > >> 3. Noting that "so-and-so said I should integrate this into core" is >> not going to magically absolve anyone of having to stand behind >> their decision to proceed with such action and support it with >> logic and reason. >> > Agreed. We need to be picky about what goes into core. > >> </obvious bias> >> >> If we are to develop guidelines for when to push things in/pull things >> out of core, it's going to be important that we reach some general >> consensus on the merits of these points. This mailing list is not >> historically known for its efficacy in consensus building, but I still >> feel like this conversation is going to be better off here than in a >> series of disjointed code review comments. >> > Well, to restate my above opinions: I think in general we don't > integrate enough into core. We create way too many extensions, even > for things that are essentially required to properly run MediaWiki. I > totally understand the want to not bloat our core software, and we > should strive to keep it lean and fast, but we also need to take into > consideration our third party users. Requiring users to install and > manage a million extensions to get basic functionality is asking a > lot. > > Respectfully, > > Ryan Lane > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
