Jump to navigation Jump to search



Occasionally a user finds a bug while using some Wikimedia-related product or project. Sometimes it's in MediaWiki, sometimes it's in a MediaWiki extension, sometimes it's somewhere else entirely. Rather than sitting quietly and not telling anyone about the bug, these users will sometimes take the time to report it in the appropriate venue, Bugzilla. And then it sits. Sometimes for a few minutes, sometimes for a few years. Sometimes commented on and poked and prodded, sometimes left completely quiet. This can be a very frustrating experience for users and most of them simply forget about the bugs and move on.

Bugs are ideas. They're ideas about how software should work. People should take great caution when marking bugs as resolved to avoid killing good ideas.

The cost of the noise switching back and forth between bug and enhancement far outweighs any benefit. Nearly every bug filer doesn't care what you call a particular ticket. Bug filers are concerned with seeing the underlying issue properly resolved.

BRD applies to wontfixing any bug. An out-of-nowhere wontfix resolution is a bold action; expect reversion and discussion.

Unsorted thoughts

Nemo says...

"Low" and "Lowest" priority are good indicators of thing with high impact and low cost which are of interest to the community. Also for WMF engineers: when they look for something interesting and useful to do outside their work, lowest priority is the obvious candidate. :) Highest priorities are evil emergencies, normal priorities the usual boring stuff we have to do as mandated by someone, lowest all the fun. :)


Bug summaries should be short and descriptive. They should include the component name, particularly if the bug involves a MediaWiki extension. A bug summary such as "Contact form doesn't work" is far less useful than a bug summary such as "MobileFrontend's contact form doesn't work". Oftentimes the bugs will be reported (in IRC channels, in e-mail, etc.) by referencing the bug's ID and bug summary, not including the stored component name. This makes it very important that the bug summary be as useful as possible.

Bugs bugs bugs[edit]

This section is an attempt to list some of the oldest bugs in Bugzilla in a more sensible format than obscure Bugzilla queries. It's unclear what the best format to accomplish this goal is, so a few different formats may be tested and tried.


  • bugzilla:1999 — add MediaWiki: footer message
  • bugzilla:2679 — put category links above edit window when previewing
  • bugzilla:3185 — Page move rollback should not leave a redirect
  • bugzilla:3753 — Option to hide rows from Special:Contributions where the edit is the most recent to a page
  • bugzilla:4127 — Token to suppress table of contents autonumbering
  • bugzilla:4469 — Provide per-namespace site notices
  • bugzilla:5984 — Edit preview doesn't let you preview cite.php footnotes.
  • bugzilla:12681 — moving new messages bar out of content area


  • bugzilla:27699 — Review and deploy TimedMediaHandler extension (timed media handler) to Wikimedia wikis
  • bugzilla:22215 — Review SignWriting MediaWiki Plugin extension code and commit it to SVN
  • bugzilla:37992 — Review and deploy Drafts extension to Wikimedia wikis
  • bugzilla:35144 — Autolink to new Gerrit / Git changesets and SHA-1 commits


  • bugzilla:27311 — Add a "create a page" interface to MediaWiki core
  • bugzilla:40346 — Convert some MediaWiki user preferences into JavaScript gadgets (tracking)
  • bugzilla:33886 — to support for microdata and rdfa, allow <a> tags so external links can have ref/rel attributes

By wiki family[edit]

FIXME: bugzilla:38994

  • Wikipedia
  • Wiktionary
  • Wikibooks
  • Wikinews
  • Wikiquote
  • Wikisource
  • Wikiversity
  • Wikivoyage
  • Wikidata
  • MediaWiki

See also[edit]