Talk:Requests for comment/Decorify into extensions

Previous page history was archived for backup purposes at Talk:Requests for comment/Decorify into extensions/LQT Archive 1 on 2015-07-10.

I think this proposal is a little too vague; the premise seems to be based on the notion that a huge amount of specialized Wikimedia Foundation work is happening in core, when I find the opposite seems to be the case. Nearly all Wikimedia-specific feature development is in extensions (Cite, CentralAuth, WikiEditor, UploadWizard, ArticleFeedback, TimedMediaHandler, SocialProfile, etc), while core sees more infrastructure work to support them (eg ResourceLoader). Even highly useful general things are often done as extensions because it's preferable to develop and maintain them as modules: ParserFunctions, Gadgets, WikiEditor, a few bits in Vector, and all sorts of admin-y bits like CheckUser, RenameUser, etc.

I support the general goal of doing most feature-specific work in extensions, but that's more of a continuance of current practice than a change to it.

As we start bundling extensions with the installer soonish (probably for 1.19?) it'll also become easier to break things out that have been in core for a long time but are pretty standalone (lots of those misc reporting special pages!) or have other weird dependencies (eg Math which was finally broken out for 1.18).

If the suggestion is "keep at it", then I guess I agree; but this should probably be broken into smaller, more actionable goals:

• bundle some specific extensions with tarball for 1.19
• make sure installer can select some of those extensions by default
• make sure all those extensions actually work
• enumerate specific things to break out and start on them

Some things may require more work, such as figuring out how localization and dependencies mix in. For instance lots of people like to cite LanguageConverter as 'weird scary code' that should be broken out... but it's a dependency for several of our localizations which extend the base class and provide conversion data tables as part of the localization.

None of these things really has a deadline on it, and most of them are going to be highly independent of each other.

I'm really glad we're on the same page brion, with at the (somewhat limited) interactions with the community so far, I've seen exacly the opposite being the philosophy, and I hear a lot of people clamoring to corify all kinds of things that they consider basic to providing a fully featured product (parser functions, renameuser, deleteuser, reports, etc). While I completely agree 100% on delivering a fully features product like you I'd love to see this happen with wikimedia recognizing standout extensions out there and making them part of the distribution (like your suggestion about 1.19). I could be wrong, but it sounds like people are on a different page than this. Hence why I brought this up, as really this is a great opportunity to say "yeah, we can do this!" and it be a positive thing.

You're right I did keep things vague, I wouldn't mind if we fleshed it out, but I'm not even certain people are for this at all.

This post was posted by Ofbeaton, but signed as Quadir.

Could you link to said discussions about renameuser and deleteuser in core?

Do note that both renameuser and deleteuser actually have to do a lot with looking for usernames inside various tables. Some of these tables are built in, but extensions add new ones. And if they don't include support for those extensions, then the user rename/deletion becomes incomplete. At that level, including some rename/delete related code inside core does make sense since it would be infrastructure that allows extensions to specify what tables a rename/delete operation should go through.

I think my already linked examples of discussions to corify parserfunctions and antispam (see below) already prove that there is significant movement in some parts of the MW community to corify extensions.

But since you asked so nicely, here's renameuser (by Reedy). https://bugzilla.wikimedia.org/show_bug.cgi?id=25482

and you can bet that if people see more extensions get folded in, they will start lining up for their favorite to make it in.

I have no problems about frameworks being built so that extensions can properly extend bare functionality, and if that involves providing the proper hooks for things like custom user table lists, so much the better. Just like I see providing the means to create an extension to do watchlists is vital, but actually providing _an_ implementation in core of such is not (notice I didn't say tarball, ship one, please!).

This post was posted by Ofbeaton, but signed as Olivier Beaton.

There's some talk of bundling must-have extensions instead of core-ifing them:

• ParserFunctions https://bugzilla.wikimedia.org/show_bug.cgi?id=26261
• Anti-spam https://bugzilla.wikimedia.org/show_bug.cgi?id=9034

This post was posted by Ofbeaton, but signed as Quadir.

• Old Editor https://bugzilla.wikimedia.org/show_bug.cgi?id=28856
• Magic links https://bugzilla.wikimedia.org/show_bug.cgi?id=26207

This post was posted by Ofbeaton, but signed as Quadir.

As I said on wikitech-l, I'm generally opposed to this. I think MediaWiki has always been positioned as a fully-featured wiki engine, and should continue to evolve in that direction. If everyone else was very keen on the idea, I would consider it, but I don't see many positive comments here.