First Bug Day

My first Bug Day is this Tuesday! We will be working on “stale bugs,” specifically bugs that have not had changes for over a year (excluding enhancements). There are 259 bugs , and it’s unfortunate that there are so many bugs that haven’t been addressed, but I wouldn’t say it’s surprising that there are so many open bugs that are so old — actually it’s pretty understandable. Developers can only spend so much time bug fixing before it becomes their job. Also, developers may not be inclined to elicit more information from reporters if their bug description is not immediately clear. That’s why it’s important to triage bugs. In general you can get more relevant information for reporters so they’ll be more inclined and more able to fix bugs. Also, triaging old bugs is important because it allows us to close issues that are not relevant anymore, e.g. bugs on features that don’t exist anymore, and helps revive old issues that still exist but don’t have any attention on them.

I enthusiastically encourage anyone even vaguely interested in participating in open source to participate in this Tuesday’s Bug Day. This will also be my first Bug Day, so we’d be learning together. You don’t need to be on IRC during the whole event, but you will need a Bugzilla account to help. Like the Triage Guide says, you can test opening reports to see if the problem still persists. If there is not enough information to retest, leave a comment asking for the information. Don’t forget to CC yourself on the report, so you can follow up. I will be on the channel during the event (nick: valeriej) so please say hi and ask any questions you may have. Also, please share this with anyone you think would be interested in participating.

Here’s on example of a report I worked on, I tested this issue, “RSS feed isn’t pulling from correct article history”. The initial report was in 2009. I have Outlook, so I tried to replicate Jenny’s set up to see if I got the same results. She didn’t explicitly link to the feed that she subscribed to, so I tried the links that Jure posted in Comment 1. Importing those links into Outlook did not replicate the same issues Jenny posted, so my comment lists what I did. With these steps Jenny could replicate my steps and see if she still has the issue. But, since this report is so old, she may come back and say she doesn’t have this issue anymore or worked around it somehow. It is also likely that she may not answer at all, which is what actually happened. After about 6 weeks of no response, I closed the report as WORKSFORME. Because I don’t know of an actual patch that fixed this problem, I can’t call it FIXED. The report can be REOPENED later if Jenny, or someone else, comes back reporting this same problem.

Wikimedia Internship – First Week

I started my OPW internship at Wikimedia on Wednesday January 2nd. I didn’t have any set plans to start, so I started triaging ‘stale’ bugs. First, what is bug triaging? I didn’t know what it was a month ago, and I’m still figuring it out. MediaWiki’s Bug Management page on Triaging says:

Bug triage refers to assuring quality of bug reports in Wikimedia Bugzilla…. The main job of triagers and the Bugsquad is to help users and developers in Bugzilla. Triaging a bug report involves making sure that the bug report

  • has enough information for developers and makes sense
  • has not already been reported before (checking for duplicates)
  • is filed in the correct place (product and component)
  • has sensible “Severity” and “Priority” fields
  • is versioned correctly

For me, that means asking bug reporters questions to get the information developers need, testing reports to see if I can confirm them or if they’re still viable in newer versions, and judging the a  bug’s priority. Currently I have not had much experience in finding duplicate reports. 

I mentioned earlier that I have been going through ‘stale’ reports. Stale reports are bug reports that are were filed over so many months ago. For example I’ve been looking at reports that are 1 year old. I’ve been looking at old reports because Andre, Wikiemedia’s Bug Wrangler and my mentor, is busy triaging new reports. When I was applying, I offered to work on something that “would be nice to have, but [he] doesn’t have the time to do.” And I’m sticking with that philosophy. I work on the old bug reports because very few people are, and the more I can get people to look at them, or even close them, the better.

Besides triaging bug reports I’ve been reading wiki pages. Lots and lots of wiki pages. I knew next to nothing about the extensions MediaWiki has and almost every time I open a bug report, I have to open up a wiki page to learn about something new. i feel like I’m spending too much time reading about extensions or bug histories (or a number of other things), so I don’t get to work on as many bug reports as I would like. I mentioned this to Andre and my other mentor Quim (he’s also the administrator for Wikimedia’s Outreach Program for Women). Andre said that he sometime’s feels that way, too. I’m glad it isn’t just me. Quim’s advice was to have a concrete goal for any tasks that I undertake. Instead of “triage old bugs,” which is unfocused and difficult to call complete, I could traige 1 year old+ bugs of the Drafts extension. I’m working on implementing that advice.

Overall I’m very excited to be participating in this internship. It’s very engaging, and I’m learning so much about Wikimedia’s numerous projects, MediaWiki (especially MediaWiki) and working on an open source projects. My next post will talk about how I will Be Bold.