Annoying large bugs
From MediaWiki.org
This page lists complex problems or needs that will require more than a quick fix and bother many users. If you're going to dig into one of these, you should probably discuss your approach with other developers on IRC or the mailing lists.
- request queue for migrating or creating repositories in Git/Gerrit
- "this "request on wiki" thing is hitting its limits of scaling. If you know of anyone who's looking for a nice weekend project...coming up with a simple request queue for this would be awesome." - Chad.
- Picture of the Year contest extension
- Needed by May 2012
- see mailing list discussion for specifications
- make frequently updated special pages update themselves automatically
- [http://lists.wikimedia.org/pipermail/mediawiki-l/2012-May/039238.html "An extension that manages all templates...
It could be like a library of templates, only now they can be easily imported to other wikis."]
- Global user preferences
- architecturally very important (if not critical) to a number of projects
- As far as I remember, the backend for this is largely completed, it just needs a sensible UI
- Andrew Garrett writes:
- I tried to implement this when I completely refactored the preferences system in 2009. It was eventually reverted in r49932. The main blocker was basically considering a way to decide which preferences would have their values synchronised. A UI would need to be developed for that and you'd need some extensive consultation on that fact.
- If you were to implement this, you could potentially use my original implementation as a guide, though it is reasonably "in the guts" of MediaWiki so you'd have to be reasonably confident "code diving" into unfamiliar software packages.
- Moving categories / members
- Discussed endlessly; needs to be properly implemented; move support, etc. should already be there; just needs schema support and some software tweaks?
- HTML e-mail support
- Requires some design expertise, but it'd be nice to have MediaWiki e-mails stop looking as though they're from 1995, especially as they're much more visible nowadays with ENotif (email notifications) enabled on Wikimedia wikis
- Fix user renames to be less fragile and horrible
- Lots of breakages from renames of users with a lot of edits; old accounts need to be fixed in a sensible way and new borkages need to be properly prevented
- Let users with zero edits rename themselves
- Global user renaming
- Currently a completely brutal process; needs a sensible implementation
- Group similar pages in watchlist
- Possibly a gadget? Make it easier for editors to sort through their watchlists.
- See en:User:Js/watchlist.js
- Database layer should automagically add GROUP BY columns on backends that need them (PostgreSQL)
- Will improve the MediaWiki installation and maintenance experience for all MediaWiki installations on PostgreSQL, SQL Server, Oracle, SQLite, or any other non-MySQL database.
- Needs some database experience
- Add user preference to deactivate/delete user account
- might be possible to piggyback on the HideUser functionality that already exists in MediaWiki core
- Add a read-only API for CentralNotice
- Add OAuth
- Add a music notation wikimodule
- At least one person says "God help the person who tries to properly resolve this bug." A discouraging situation. More info at the meta page on music markup and an October 2011 technical conversation. Preventing LilyPond being a DoS vector is the key issue.
