Quick Hit: A Blog Post about Blog Posts

I have two blog posts that were published on the Wikimedia Blog.

The first is ‘How to create a good first Bug Report‘ and was published this Monday. It gives an overview of what we look for in a bug report, why, and what to expect if you want to file a bug report.

The second, ‘Help Wikimedia squash software bugs‘, talks about the bug days we’ve been running, how to find out about upcoming bug days, and how the bug days help Wikimedia.

Check them out and leave a comment here or on those posts!

( I guess this counts as my fourth blog post this week, ha ha. :) )


OPW Update

Last week I created a diagram that shows links between some Wikipedia and MediaWiki support sites. I focused on sites that users would likely look to for help on errors in the MediaWiki software that runs wikis like Wikipedia. I expected these sites to link to Bugzilla, Wikimedia’s bug tracker, somehow. Starting from a random Wikipedia article, I looked at what sites a user might follow if she was looking to identify or solve a technical issue. In the following diagram, each node is a page and each directional line represents a link from the originating page to the connecting page. Dashed links represent links that are in the sidebar of a page, and from a Wikipedia article, support sites are linked in the sidebar under ‘Interaction’.

When creating the diagram, I didn’t think the Wikipedia: About page would be helpful, so I didn’t even look at it in my initial diagram (Older version seen here).

Wikipedia has any support sites that focus on different topics. “Are You in the Right Place?” has an excellent brake down of what pages address certain topics, e.g. refer to the FAQ for editing help or a content dispute can be solved at dispute resolution. As I mentioned above, I didn’t think Wikipedia’s About Us page would be all that helpful, but I was wrong. It has a dedicated section for Feedback and Questions, which links to many support pages. It also links to Wikipedia: Bug reports and feature requests, which has info on reporting a bug, Bugzilla etiquette, linking bug reports in Wikipedia, and more.

So what does this mean? Well, one thing I’d note is how I didn’t think to look at the WIkipedia: About page. I think most users would look toward the Help page, first. That would likely lead them to ‘Help Desk’, then ‘Are You in the Right Place?’

Another thing to think about is what sort of words or phrases users would search in Wikipedia if they were looking for how to solve a problem.  I actually looked at what pages redirect to a specific page. See below:

Pages that redirect to Bugzilla: http://toolserver.org/~dispenser/cgi-bin/rdcheck.py?page=Bugzilla
Pages that redirect to Bug_tracking_system: http://toolserver.org/~dispenser/cgi-bin/rdcheck.py?page=Bug_tracking_system
Pages that redirect to Software_bug: https://toolserver.org/~dispenser/cgi-bin/rdcheck.py?page=Software_bug
Pages that redirect to Bug_reports_and_feature_requests: https://toolserver.org/~dispenser/cgi-bin/rdcheck.py?page=Wikipedia:Bug_reports_and_feature_requests

More general phrases like “bug tracker” and “bug report” lead to the ‘Bug tracking system’ page, and I would say the same holds for pages that redirect to ‘Bugzilla’ and ‘Software_bug.’ However if users search within the Wikipedia namespace, they’ll likely end up at the ‘Bug reports and feature requests page.’

All of this was really interesting to look into.


Valerie Juarez: Bug wrangler in-training

Valerie Juarez: Bug wrangler in-training

As Juarez sees it, her internship is a win-win for both her and the Foundation. “I think internships like this allow women like me opportunities to grow, gain knowledge, and connect with a community. Organizations benefit by the contributions women provide to the projects themselves and the community.”

Click here for full post

Alice Roberts profiled me and my work as an OPW Intern for the Wikimedia Foundation. She did a great job!

Mobile Uploads Testing

Image I uploaded to Wikimedia Commons using the Wikimedia Commons App.

Just a quick post! Mobile QA is testing the Commons Upload app for Android and iOS devices this week. Wikimedia Commons is a media file repository for public domain and freely licensed media.  Today I uploaded some photos to Commons using the Android app and the mobile browser. I encourage you to get the Commons App and submit some photos to commons. This will help developers get more information so they can improve the app. Join us in #wikimedia-mobile on Freenode if you have any questions or comments! Here are my contributions so far: User:Valeriej’s Contributions (Ignore my faces – I didn’t upload those using my mobile device).

Happy Testing!

Bug Days and Blog Posts

Our first bugday on January 29th over reports that had not been changed in over a year went well. There was a small turnout, but it was fun and a good learning experience. I sent out a summary to wikitech-l. We addressed about 30 of the original 250 reports (summary of bug reports acted on). This included retesting reports to see if they were still valid for newer versions that have been released. If we could not reproduce the issue or needed more information, we left comments to that effect on the reports. Since these are older reports, we planned to close them after 3 weeks of non response. I spent some time yesterday closing some of those reports. A number of the reports were closed before I checked yesterday. And all of the closed reports can be reopened if it is discovered this issue still exists.

As mentioned in the summary sent to wikitech-l, we wanted to have a clearer landing page. For the first bug day, the only source of information for the bug day was the bug management Triage page. I was able to address this with the last bugday, which was last Tuesday (2-19). We focused on open bugs in the Git/Gerrit component. I coordinated with Chad, who lead the recent update of Gerrit, and he established the focus for this bug day would be on upstream reports. I created a page listing the ‘Who,’ ‘What,’ ‘When,’ and ‘Where.’ I liked that we had a dedicated page for this bugday, because we had a number of upstream links, like release notes and the Gerrit bug tracker, that would have cluttered up the triage page. The dedicated page allows us to post more information, and after the bug day we can archive the list of reports that we acted on and associated comments.

During the bugday, we addressed about 25 of 70 reports. We didn’t close as many reports as the first bugday, but we posted status updates and linked to upstream bugs. I spent a lot of time looking for upstream bugs reports that match the problems described in our reports. I’m not very familiar with Gerrit, so I was learning as I triaged. I have not had the opportunity to submit a change, but I am looking for one.

File:Bug Life Cycle Diagram.png

I’m working on a couple of blog posts to submit to the Wikimedia blog. While drafting the posts I created a flowchart that illustrates the life cycle of a bug report. Andre helped me improve it, and I’ll be using it in my post. I welcome feedback or questions regarding the image. You can see the evolution of the image at this page of the original .svg file. There are some rendering bugs with .svg files on commons, however, so the image I’ll be using in the report and the one above is the .png version.

As for my proposal, I’ve talked with the fabulous Liz from Mozilla about their feedback channels. She  gave me a lot to think about and look over. Andre also contacted a friend at Ubuntu to learn more about their feedback channels. I’ll be creating a high level diagram of their channels, and also looking at other open source projects that were recently suggested.

I’m thoroughly enjoying the range of work I get to to do, but I think I need to be careful not to get pulled too far off-track. This post has helped center me, though.

As a side note, I just wanted to point more people to Elodieunderglass’ [GIRLS IN SCIENCE] posts. It’s not technology focused but has interesting points.

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.

New Internship and Finishing Up with Partners

I’m so excited to be accepted as an intern in Gnome’s Outreach Program for Women! I will be working with the Wikimedia Foundation! I’ll be keeping up with my project on this blog.

With my acceptance into the program comes the end of my current job. For the past year, I have been a Technology Specialist in Partners Resource Network (PRN). PRN helps parents of children with disabilities advocate for themselves and their children within the education system through education and trainings. One project I ended up being assigned was the creation of an Annual Report video put on our website. Now, I had no experience with video editing, but I was willing to learn, so I took on the assignment.

I looked at a few videos other projects have done, and I began by reading information on what equipment was needed for recording interviews. Our project has a camera, but it is an SD camera. After taking a few test videos, I knew the quality would not be good enough to upload. Thankfully, I have a Flip camera. It’s an HD camera, but it has its drawbacks. One is that video taken in poor lighting conditions can turn out grainy. Another drawback is that an external microphone cannot be connected to the camera. However, it was better than the other option.

I was working with a project director within Partners, and she wanted parent testimonials in the video, so we attempted to set up a time in the Houston office to interview parents. Later she decided interviewing parents at a conference they were having would be better.

The conference was at a hotel. They didn’t book a separate space for recording, so I had to set up on the far side of the break/lunch area. This presented a couple of problems related to the Flip camera’s drawbacks — lighting and sound. Thankfully, the hotel staff brought me a couple of lamps to help with the lighting. Cue me moving chairs and lamps and recording myself multiple times to make sure the video turned out alright. I felt silly, but everyone was attending sessions, so I was by myself most of the time.

How I conducted the parent interviews.

How I conducted the parent interviews.

I could not do anything about the sound, however. You can hear people talking during breaks or dishes being moved in some of the videos. It doesn’t ruin the videos, but they could definitely do without it.

Using Adobe Premiere 10, I ended up cutting each interview into its own video. You can view them here (I’ve only uploaded a few as of 12-17-2012, but as I upload more, I’ll add them to this playlist):


Anyway, this is one of the projects I’m finishing up before I leave Partners. It’s nice to see how the organization that I worked for helped these parents and their children.

How to Make a Dice Bag

How to Make a Dice Bag

Or more generically, “How to Make a Drawstring Bag”. But since yesterday was National Dice Day this tutorial is about making a dice bag.

– Be able to sew a straight line.
I’ve only been sewing for a few months, and I’ve made a couple of shirts, but I’m by no means an expert seamstress. I think this is a good starting project. The bags don’t have to be perfect to look good.

– Ironing
It makes it easier to pin and sew the casing if you iron the folds. It can be kind of tricky, so try not to burn your fingers!

Project Supplies - Ribbon, ruler, white pencil, pins and pin cushion, and fabric

– Fabric (I used a 12″x6″ piece)
– Ribbon (I used 3/8″) or some other string small enough to fit the casing
– Ruler
– Pins
– White pencil or some other marking tool
– Iron and ironing board
– Pinking Shears


Step 1 and 2

Step 1 and 2

1. Iron a fold of about 3/8″ on the shorter sides of the fabric. Some of my cuts of fabric weren’t straight, so I used this step to make the edges straight by making the fold straight. This means I couldn’t measure 3/8″ from the edge of the fabric. I had to eyeball what “straight” was. This fold will be sewn down and helps prevent the casing from fraying open. I didn’t do this on my first bag, and I had to hand sew it closed. It will probably fray open again, but for now it works.

2. Mark 1″ from the ironed edge. Fold and iron at the markings. The first ironed fold should fold under the new fold. That’s pretty confusing, but it should look like the image above.

An edge pinned with the smaller fold under the larger fold.

An edge pinned with the smaller fold under the larger fold.

3. Pin the fold down on both edges. I tried focus on pinning the smaller fold down.


4. lay the pinned edges together to see how the bag folds. If it looks weird, feel free to unpin and re-iron the edges. Better to do it now than regret it later!


5. Sew 7/8″ to 9/8″ from the edge. I would go as far from the edge as possible to leave more room for the casing.


6. I ironed the edges again. Sew 1/3″ to 1/4″ from the edge. I sewed as close to the edge as possible, again, to leave more room for the casing.


7. Fold the sewn edges together folded sides out. Pin the unsewn edges together.

Step 8

8. Sew 1/2″ seam from the new fold (bottom of the bag) to the first seam. I did NOT sew the whole edge together!


9. Again, I didn’t sew the whole edge. Sew from the top seam to the top of the bag.


10. Use pinking shears to and cut the excess fabric at the side seams of the bag. This stops the sides from fraying.


11. Flip bag inside out. Cut holes in the casing at the sides of the bag. (The left picture is before, the right picture is after). You should have each 4 holes (two at each side).


12. Get your ribbon. Cut a two pieces of ribbon.  The length should be  the circumference of the bag plus some. Use a safety pin to help you feed the ribbon through the casings. Tie the edge of the ribbon in a knot.


13. Feed the second ribbon through the other side of the bag and knot it.


14. Your bag should look something like this

FinalFinal with Dice

Fill your new bag with dice!

Quick Post – Making Presents

I made some dice bags!

I’m making dice bags to give out to my friends for Christmas!

My original dice bag started unraveling, so I made my own. I didn’t fold the seam under when I made the casing for the ribbon, so I think the first bag I made will unravel the same way. However, this shouldn’t happen to the bags I’m making as gifts! I fixed my initial mistake while making these, so my friends should be getting a well-made gift from me for Christmas! I made two this evening, but the next ones should go faster since I have a good idea of the measurements now. The whole project didn’t cost that much, since I’m using scrap fabric, which is half-off at the store. I hope they like them!