Talk:Wikimedia Blog/Drafts/Bug Days

Writing down the suggestions I had just now in our voice/video chat:

• I suggest that, before posting this blog entry, Andre and Valerie post a blog entry explaining how to report a bug -- it'd be great if that blog entry also gave a quick explanation of how a bug gets fixed. Feel free to link to the video explaining how a bug gets fixed. People like "behind the scenes" details that "lift the curtain" on our processes.
• Give a concrete example of a specific bug that a volunteer found (even if it was not during a Bug Day) and how fixing it improved the lives of Wikimedia users.
• Talk about benefits -- how these activities can improve Wikimedia users' lives and experiences.

Hope this helps! Sharihareswara (WMF) (talk) 16:31, 5 February 2013 (UTC)

Outline

The outline looks good to me. One thing I'd recommend is to avoid duplicating the mw:How to report a bug page: it's a good, step-by-step how-to, and it's enough to point to it. I feel a blog post should rather be an opportunity to convey similar messages with sentences (you've started to do this). For example, I'd remove all links to bugzilla search (those belong in a how-to). Focus on the 3-4 main messages you want to convey and expand on those. For example, in this blog post, you have more room to explain the rationale behind reproducibility, whereas in the how-to you need to be more concise to keep the steps shorts.

I imagine that the following topics could be the main talking points (each of them covered in 1-2 paragraphs, and each introduced by a header), but feel free to add or remove:

• Reproducibility of the issue: why do we need the issue to be reproducible? (elaborate on the fact that we can't fix something we can't identify)
• Looking for duplicates: why does this matter? (elaborate on the fact that it will save the reporter's time if someone else has already done the job for them, and it will also save time for people who triage and fix bugs, which is better for everybody who wants bugs fixed in the end)
• Write a good report: what does a good report contain? (elaborate on what kind of information helps developers investigate and fix the bug, and why)
• Don't worry: In most cases, a misfiled or incomplete bug report is better than no report at all, because people who fix bugs can still follow up with the person who reported the issue. So, if the user is unsure about filing in the right component, or about what bits of information are relevant to the issue, they shouldn't sweat it too much: we can help them improve on the report.

These are all merely suggestions. Overall, the goal is to explain to people why they should do these things (answer: if they want the issue fixed, they need to help us help them), instead of just telling them to do them (which is what we do on the how-to page). Hope this helps :) guillom 14:02, 13 February 2013 (UTC)

I hope I succeeded in combining the two approaches of explaining how to do something in a more friendly tone and explaining how doing this will help get their issue fixed. Thanks for the help! Valeriej (talk) 20:00, 26 February 2013 (UTC)

Some ideas/comments on current draft

• Maybe once mention "software mistake ("bug")" instead of "bug" only, and maybe what a "bug" is not (e.g. wrong content in a Wikipedia article or so)? Just to make sure people get a basic idea what Bugzilla is for.
• "changes to your bug through email": Personally I'm picky ("bug" is a software mistake, and "bug report" the report about it), but I understand that it's easier to shorten it, and many people do that. :)
• "the original report may be from an older version of MediaWiki": I'd add "(the wiki software behind Wikipedia and other wikisites)" here. Wouldn't expect that people know what MediaWiki is, if they are "just" Wikipedia users.
• "Does the error seem to be with MediaWiki itself?": -> with the MediaWiki software itself?
• "If the problem doesn't seem to be with the MediaWiki software, you can also file the bug in": -> ...but with the configuration of a Wikimedia wikisite, you should file the bug in"
• "Bugzilla should bring up possible duplicates": -> I'd switch to "brings up" here (and cross fingers that Bugzilla works reliably)
• "Check your settings to see and update what changes trigger an email." link to https://bugzilla.gnome.org/userprefs.cgi?tab=email ?

--AKlapper (WMF) (talk) 15:40, 19 February 2013 (UTC)

I need to go through and make sure I changed what you suggested. I think I covered some of these with links to other pages, but it would be more helpful to the reader if they didn't have to go to many other pages. Thanks! Valeriej (talk) 20:00, 26 February 2013 (UTC)

Another review

Some small potential improvements, corrections, ideas etc. on part 1

• "A bug is an error"
  • -> A software bug is an error
    • Done

• "help developers reproduce the bug, which allows her"
  • -> plural vs. "her"?
    • Chose plural

• "should create a HOWTO take a screenshot page and link"
  • -> just link to http://en.wikipedia.org/wiki/Screenshot ?
    • Done

• "but be sure to remove personal or identifying information."
  • -> but be sure to remove private information as Bugzilla is a public place.
    • Combined with original sentence

• "you can log in or register with Bugzilla"
  • -> Wikimedia Bugzilla (and link to https://bugzilla.wikimedia.org/ )
    • I linked to it earlier in the post, "Wikimedia's bug tracker", should I move the link the this instance of Bugzilla?

• "NOTE: Bugzilla will display your registered email to logged in users"
  • -> As your email address will be visible to other logged in users, consider
    • Done

• "so you can forward Bugzilla emails from a secondary account to your primary account"
  • I think I'd even drop that part of the sentence. It's an interesting idea though.
    • Done. Now the first part of the sentence seems out of place. I may remove it.

• "If you do not find a duplicate report, you can go on to filing a new bug."
  • I'd add something here along the lines of "But filing duplicates is no problem and nothing bad. Better to report a second time than not at all."
    • Done: "You may end up filing a duplicate report, and that's ok. It's better to report a second time than not at all."

• "choose a product"
  • -> choose a so-called product which means a software project ?
    • Hmm, not sure about this: "These products represent software projects, and it can be tricky to choose the right one."

• "If you're still not sure,"
  • ...or are in a hurry
    • Done

• "However, bug triagers can move misfiled reports to the right product and component."
  • --> However, bug triagers will move misplaced reports to the right product and component, so do not worry."
    • Done

• "Be specific in writing your summary. (Needs elaboration, something like "...")"
  • -> Vague generic summaries like "Does not work" or "Feature request" are not helpful to get a quick idea what your report is about.
    • Done

• "Other information you will want to include is a description of the expected behavior when you follow your steps and a description of what actually happens. Also consider attaching a screenshot" and "Here you list your steps to reproduce, what you expect to happen, and then what actually happens. You can also list other details like what browser you're using if it seems like it is relevant to the report. Clicking the 'Add an Attachment' button below the description will allow you to attach a file, e.g. a screenshot" feel a bit duplicated, ** maybe remove the first occurrence or shorten it?
  • Let me reread and get back to this change.

• "Check your user preferences in Bugzilla"
  • -> link to https://bugzilla.wikimedia.org/userprefs.cgi
    • Done

• And somewhere at the end I'd stress again that mistakes happen, that reports do not have to be great and perfect at the beginning and that there is always somebody to help and improve them. Better to get improvable reports than no reports at all because people are scared to do something wrong.
  • Done

--AKlapper (WMF) (talk) 14:56, 12 March 2013 (UTC)

Thanks for all your suggestions! I really appreciate it.