Roadmap/Archive

All Wikimedia sites are currently running the MediaWiki 1.3 branch. 1.3.x is now stable and should only be receiving bug fixes. 1.4.x is in beta-testing, while new features go in 1.5.x. See MediaWiki feature list for a brief overview of functionality and MediaWiki User's Guide for documentation.

For information on the release procedure, see MediaWiki release cycle.

To be done
Add your name next to any of these items if you want to complete that task.


 * "Overflow" credits page -- if the number of people who've worked on a page is greater than some limit, show credits on a separate page. --Evan 18:40, 21 May 2004 (UTC)
 * Finish Special:Import.
 * Update all the language files with new stuff (update translations in mediawiki namespace first, dump them to php & merge them afterwards)
 * It might be wise to fix up Snok's parser cache and enable it on the live site.
 * db load balancing? (not really needed for 1.3, but would be very nice to have with the two db's we have)
 * Category ui might need more thought- category lists might get very long. Separate page was suggested.
 * Categories need more work in general re scaling, bug fixes
 * Show the user some info in case of merging other people's edits, maybe a diff or a message and a link to one
 * Unicode support for EasyTimeline
 * All Skins are missing edit links for the first heading, an idea is to move the section edit/whatever click stuff to js (see also 1.4, move prefs to js)
 * The first section edit link was removed. Why? Don't know.

Version 1.4
As of 3 December 2004, v1.4 is in pre-beta testing at test.wikipedia.org and the first beta is available for download.

To be done
Add your name next to any of these items if you want to complete that task.


 * Database schema redesign
 * User:Brion VIBBER
 * Implement FileReplacement, i.e. a way to semi-protect pages
 * E-Mail notification on changed pages and/or user pages -> moved to 1.5
 * finished, see Enotif. Tom Gries -> moved to 1.5
 * In the long term (post 1.3) it might be nice to have a general way to deal with schema changes, involving automatic detection of missing fields and tables, based on a single schema specification. The specification could then be used for both installing and updating. (The Typo3 CMS has got this feature. Perhaps get in contact with their developers and ask for help or code sharing.)
 * We have code in WordPress for this, functions and schema. Matt 17:53, 3 Nov 2004 (UTC)
 * move most prefs to generated css/js, esi caching
 * Gwicke
 * Wikimedia Commons to store commonly used resources like images
 * To be able to rename Image: and Media:
 * Move all category page code to a CategoryPage.php file, modelled after ImagePage.php
 * User:JeLuF
 * Why not just make the category function a template like embedable item?


 * Make it easier to edit the templates used on a page (e.g. combobox of templates on edit screen).
 * Custom namespaces, so we can manage the help in localized Help: namespaces on Meta

If 1.4 will include a schema redesign, maybe we should call it 2.0. -- Tim Starling 05:57, 3 May 2004 (UTC)
 * If it breaks API's (like the extension API), there's a clear vote in favor. If not it's a bit cloudier, but the cur/old merge thing is probably a *big enough* schema change to merit it, yeah.  --Baylink 00:05, 15 Feb 2005 (UTC)

Version 1.5+

 * E-Mail notification (EN) on changed pages and/or user pages see Enotif. --Tom Gries mail 07:23, 12 Dec 2004 (UTC)
 * E-Mail address authentication (EA) see Eauthent. --Tom Gries mail 07:23, 12 Dec 2004 (UTC)

To be done

 * Authentication
 * local database of the wiki (default)
 * Suggestion I: LDAP Authentication
 * by Ryan Lane
 * Suggestion II: Web server Authentication, and PHP/Pear::Auth. that solves the problem with LDAP authentication because if your webserver can LDAP/PAM whatever
 * by Bill Clark
 * Suggestion III: Authentication drivers which you can change and get user's name and password from i.e. forum databases

Instead of implementing one or the other, it may be better to include both since including both would allow users to authenticate to more than one domain and/or type of server (AD, openLDAP, Sun Directory server, etc). Just using the web server may not allow this. further comments on this


 * Take a look at a friendlier installer, the one by the Dotclear blog solution. Being a good one, it is also being used by the Plume CMS. [[User_talk:Vrykolaka|Reply to Vrykolaka]] 15:21, Feb 3, 2005 (UTC)