User:MZMcBride/Bugs

Bugs!

Philosophy

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. :)

Style

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

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.

Development

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

Extensions

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

Well,

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

FIXME: bugzilla:38994

Wikipedia
Wiktionary
Wikibooks
Wikinews
Wikiquote
Wikisource
Wikiversity
Wikivoyage
Wikidata
MediaWiki