Help Wikimedia squash software bugs

Translate this post

Image (1) Bug_icon_-_Noun_project_198.svg_-230x300.png for post 22739
Help us squash bugs!

Reporting a new software bug is only the first step towards fixing the issue; the sorting and prioritization steps come next, usually referred to as “triage”.
Wikimedia’s Bug Squad has started hosting bi-monthly Bug Days as a part of our QA weekly goals. During a bug day, bug triagers and developers sort bug reports, usually from a specific component or reports fitting a specific criteria. Triaging reports includes testing reports to confirm they are valid, prioritizing reports so developers can efficiently address pressing issues, and identifying and marking duplicate reports to avoid duplicated work.
Our next Bug Day is today (March 19th), and we’ll work on bug reports in Mediawiki extension > LiquidThreads. For more information on the event and how to participate, check out the event page.
We have already held three Bug Days. The first Bug Day on January 29, 2013 focused on reports that had not been changed for over a year. We retested many reports to see if they were still valid for newer versions of MediaWiki and MediaWiki Extensions. We also requested more information from reporters whose reports needed clarification. We addressed 30 reports out of about 170. Because of the recent Gerrit upgrade, our bug day on February 19, 2013 addressed bug reports in the Git/Gerrit component. Our focus was addressing upstream issues in Gerrit that may have been fixed with the update. For upstream bugs that were not fixed with the update, status reports were left on our corresponding Bugzilla reports. We addressed about 24 bug reports out of 70 open reports in Git/Gerrit. Our latest bug day focused on General/Unknown reports in the MediaWiki product, which is known to be catch-all for bug reports. 38 reports were triaged. Many were retested and confirmed, prioritized, and moved out of General/Unknown into their proper components.
You can contribute to the Wikimedia Foundation by triaging bug reports. Follow the Calendar of QA events, to keep up with upcoming Bug Days and other testing events. You can also find an announcement of upcoming Bug Days on Bug Management’s Triage page. Bug Days are not just for bug triagers; developers are welcome to join and help by ‘taking’ reports and submitting bug fixes. Fixing bugs is a great way for new volunteer developers to get started, and joining a Bug Day would be a great way to find a few bugs to fix.
Bug Days support the Wikimedia Foundation by ensuring the quality of bug reports and bringing focus to reports that may not have had attention in a while. It is difficult for developers to keep up with the number of bug reports that reside and move into Bugzilla every day. Bug Days and bug triaging can help developers efficiently address these issues.
Valerie Juarez, Bug Management Intern

Archive notice: This is an archived post from blog.wikimedia.org, which operated under different editorial and content guidelines than Diff.

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?

8 Comments
Inline Feedbacks
View all comments

LiquidThreads – debugging a killed extension? Does that make any sense?

Ahoj Kozuch! It depends on how you interpret “kill”. LiquidThreads is no longer actively maintained (means: no new features) and it’s not recommended for new deployments, but it is still used on a large number of wikis, receives new bug reports, and has developers who fix some software bugs from time to time, so I think it made sense to help these developers to have a cleaner bug database to work with.

Killed ? LiquidThreads is used in production on several wikis, including http://www.mediawiki.org and http://www.translatewiki.net . And more wikis definitely have to use it. It is much more adapted than the “native” “wiki pages with signatures”. The “native” discussion system of MediaWiki is simply not a discussion system.

Link corrected : http://translatewiki.net

Squashing bugs in MediaWiki ? OK. In LiquidThreads ? OK.
In addition to what I have said there http://diff.wikimedia.org/2013/03/18/how-to-create-a-good-first-bug-report/comment-page-1/ , here is a nasty bug in LiquidThreads. When I edit one of my messages, the time in the signature does not get changed. This is wrong. This reproducible bug occurs in http://www.mediawiki.org . Thank you for correcting this.

Speaking about bugs, this page says :
“2 Responses to “Help Wikimedia squash software bugs””
And then it lists the 5 responses, including the ones I made.
The number 2 is wrong, the correct number to display is 5.
And, by the way, the absurd capital letters in “2 Responses”, “Leave a Reply”, “Submit Comment” are incorrect and ridiculous.

Hi Nicolas,
it is standard behavior of a WordPress blog that you can see your own comments after posting them but before they are approved (i.e. counted among the total responses).
I believe the capitalization of “Leave a Reply”, “Submit Comment” etc. also comes from the standard WordPress presets.
If you need further information about how WordPress blogs work, want to ask questions about certain features or suggest changes to the software, I recommend seeking out the support documentation and forums at WordPress.com.

Hi Nicolas, feel free to report your LQT problem in bugzilla.wikimedia.org where software bugs are centrally managed. Comments on some blog post get lost and seldomly reach the corresponding developers. Thanks.