Suggestions for extensions to be integrated

Should be merged

 * CategoryTree — may be included as optional configuration variable [disablable]
 * Configure [disablable] ― every other web software system has had this since the beginning of time
 * The current Configure extension is too fragile IMO, based on editing config PHP files. I'd much rather see us work out a proper configuration database which can have a clean, safe UI written on top of it; supporting multiple wikis with cascading configuration options from global -> group -> individual site is a must. --brion 19:40, 19 August 2009 (UTC)
 * DismissableSiteNotice [disablable]
 * Was implemented, then reverted. Needs a rewrite to make it less hacky-ish before being merged back in.
 * *nod* would prefer a cleaner implementation on this. --brion 19:42, 19 August 2009 (UTC)
 * Inputbox [disablable]
 * Inputbox needs a rewrite, it's a little scary. :)
 * Got a pretty decent rewrite recently ^demon 08:23, 27 December 2008 (UTC)
 * Interwiki (at least the option to view available interwikis, see also InterwikiList) - merged in r45062, reverted in r45238 - "please continue working on it, it'd be a nice thing to have for third-party installations if the UI is cleaned up." (ref)
 * Nuke — installed on all Wikimedia wikis and is handy for non-Wikimedia users [disablable]
 * Was implemented in r41630 but reverted in r42117.
 * Poem — no disadvantages
 * Merged in r41710, then reverted in r43520
 * Should probably be &lt;nobreak> instead of &lt;poem> (&lt;nobr> is not an option because it is part of HTML)
 * Vector — maybe one could try to merge those parts which only apply to the vector-skin with the skin itself--188.22.79.199 09:06, 30 April 2011 (UTC)

Maybe

 * AntiSpoof
 * Assert Edit — Belongs in the API somewhere? Or does it?  Maybe the API obsoletes this, in which case we should leave it out (and force people to move to the API to get the benefits).
 * Yeah I guess this can be integrated into the API and just be killed out the main edit form. -- Bryan ( talk|commons ) 17:38, 22 August 2009 (UTC)
 * BackAndForth [disabled by default]
 * CheckUser — should not. There are laws in some countries forbidding logging of IPs, etc.
 * So it should be disabled by default. Soxred93 00:35, 26 January 2009 (UTC)
 * COPPA forbids collecting e-mail addresses in some circumstances that we don't accommodate (sites targeted at minors must ask for age and get parental approval if age < 13). And we don't provide any way at all for admins to comply with that.  Since when does the law of one country force us to not add a feature for everyone else?
 * What country actually forbids collecting IP addresses from being logged period? Some may require them to be discarded after a period, but CheckUser does that.
 * We already log IPs in rc anyway.
 * So this is an entirely unreasonable reason. All bulletin boards I know of, for instance, have similar functionality enabled by default, and they don't even typically allow you to purge old IPs. —Simetrical (talk • contribs) 12:41, 26 January 2009 (UTC)
 * Cite — still have some breakages and not properly handled by clauses
 * Well, neither is or  or any other XML-like tag, right? —Simetrical (talk • contribs) 12:36, 26 January 2009 (UTC)
 * ConfirmEdit
 * Duplicator — "copy" function available on most systems since the beginning of time
 * Gadgets
 * ImageMap — useful [disablable]
 * With the ability to use |link= now, probably not needed in core (see also: r41727, r41789)
 * Intersection [disablable] — a.k.a. DynamicPageList
 * Renameuser
 * Yeah, that'd be good.
 * Maybe not necessarily the current version, though; see also: 15212
 * SpamBlacklist
 * Is this actually ready to be merged? See 4459 for a request to basically rewrite it.
 * Tab0 (very simple usability helper)
 * Title Blacklist
 * TitleKey
 * Might want to merge this straight into the page table (as long as we get that easy schema upgrade ability on Wikimedia first...)
 * Validator
 * Validator is a generic parameter handling tool. As a lot of parameter handling is happening in both core and extensions, it would greatly increase simplicity and consistency, as well as add a lot of useful things such as auto documentation generation. I'm quite sure most core devs will go "we don't need this". Try it, and then tell me it's not vastly better then hard-coding all the stuff over and over again for every use-case. --Jeroen De Dauw 03:29, 8 January 2011 (UTC)
 * CharInsert — thought he was admin it was in core :)
 * How practical is this extension for core?
 * Very, especially for all languages the use special characters, but also take a look at the average Wikimedia wiki's MediaWiki:Edittools.
 * CharInsert is going to be pretty much obsoleted by the new edit toolbar, which has a much cleaner system for special chars / edittools. --brion 19:42, 19 August 2009 (UTC)
 * I'm pretty sure the implementation of this could be improved dramatically. —Simetrical (talk • contribs) 12:42, 26 January 2009 (UTC)
 * Perfect is the ememy of good? Even though it has been adopted widely, it not being perfect would prevent it from being added to core, even though no one touched it since June 2006? (14584)? siebrand 15:16, 26 January 2009 (UTC)
 * Yeah, sure. It could be cleaned up in core as well as anywhere.  Just saying. —Simetrical (talk • contribs) 02:02, 27 January 2009 (UTC)
 * WikiEditor — See discussion: 26914

Should not be merged

 * AntiBot — zomg secret
 * BoardVote — Wikimedia-specific
 * CentralAuth — not includable
 * CrossNamespaceLinks — even now it is useless
 * EasyTimeline — while it is in Perl
 * ExpandTemplates — doubtable usefulness for usual user
 * It can make finding bits of code that are buried within templates much easier. If improved, it could even create a tree of sorts. Perhaps this should be in the maybe category?
 * FixedImage — Wikimedia-specific
 * OggHandler — external dependency
 * Oversight — to be deprecated by rev_deleted
 * ParserFunctions — potential merge rejected by Tim Starling: difflink
 * SiteMatrix — Wikimedia-specific
 * SyntaxHighlight GeSHi — external dependency
 * TorBlock — needs cron
 * User Merge and Delete — causes irreversible changes (deletes users)
 * Username Blacklist — redundant to features in Title Blacklist
 * WikiHiero — too heavy
 * Maintenance — complete and utter hack, plus a security risk since a rogue admin could screw up the site with it.

Has already been merged
These extensions have been fully merged into core and disabled on WMF wikis (Special:Version):
 * DeletedContributions — r41178
 * LinkSearch — very useful – r40830
 * Newuserlog — but there should be ability to disable it for wikis like Wikia [disablable] – r40769
 * UniversalEditButton [disablable] - r41916