Talk:How to report a bug

Merge

Should this be merged to Bugzilla and subpages? --Nemo 09:03, 12 July 2012 (UTC)

Translation

This page is now linked from How to contribute. Should it be translated? Bugzilla is English-only, only m:Requesting wiki configuration changes makes sense in all languages because our projects are multilingual and most of the work is on the wiki itself, while a good bug might be "only" a one-line request in the right place with a good link to consensus. --Nemo 18:22, 24 December 2012 (UTC)

Automatic search is more beginner-friendly

I would remove the part about searching: weak-hearted users might start crying when they see the advanced search interface of Bugzilla. Even the standard one is crappy; fortunately there is now an automatic search happening when one enters the summary, and that works fairly well, so the guide should focus on that instead. --Tgr (talk) 21:42, 19 January 2013 (UTC)

Screencast

Tracked in Bugzilla
Bug 54606

I plan to produce a basic screencast about how to report a bug at bugzilla.wikimedia.org. Bugzilla for Humans is a good source of inspiration but this one will be short and focusing on the path to get your first bug reported. If it's good then we can create other screencasts focusing on other areas.

Rough script (still in progress):

1. Why are you filing a bug: to get is solved. Help us help you...
2. Register...
3. Find the right place. But don worry, we know it's messy...
4. From all those fieldds only the first comment can't be changed. Descriptive, reproducible...

Changes Needed for New Guided Bug Entry Form

(For more information see bugzilla:36762 or try the guided form.)

Notes on changes: The Before you do anything section on the page right now is replaced with step 2 of this process. The overall order of the process as it appears has changed

The Description tab used to contain several parts, but has been changed to instead be separated into 4 separate parts.

The "Attachment" step now occurs after the form itself.

A summary of process changes is Summary moved to below product Component comes after summary Severity moved to happen after Expectations Description had all it's parts moved up to their own section Attachment comes after the process is complete.

The new order is below

1.Ensure you are logged in, if not, log in. If you do not have an account, make one and log in.

2. Check if the bug has already been reported

There will be a box, use it to search for your issue before submitting a new one

3. File the report

1) Product

What product the issue was in

2) Summary

"How would you summarize the issue in one sentence?

Good example: Changing gender does not update the preferences; Bad example: Problem with wikipage"

3) Component

"In which area does the issue occur? If you are unsure, just use "General/Unknown". You could also use the same component as similar bugs you found when searching above, or you could read the list of component descriptions."

4) Intention

What were you trying to do (and why)?

5) Sets to reproduce

What did you do? Describe how to reproduce the problem, so another person could follow your steps.

What happens when you try again?

Does it happen more than once (if you have time to test)?

6) Results

What happened?

7) Expected Results

What were your expectations instead?

8) Severity

How serious is the problem?

Use Enhancement/Feature to request a new feature

9) URL(Optional)

Is there a web address where the problem can be seen?

10) Web Browser(Optional)

Which web browser do you use to visit internet pages?

11) Additional Information(Optional)

Do you have any additional information? Anything which may be relevant, such as the skin you were using (does the bug still occur with a different skin?), or anything special about your computer's configuration. A screenshot which shows the problem, or any information longer than a few lines, such as a HTML testcase, debug log file or stack trace, should be added using the Add an Attachment link on the bug report, after it is filed.

3. Submit your report by pressing the Submit Report button. That's it! Thank you very much! You will be notified by email about any progress that is made on fixing your bug or feature request.

Please be warned that a lot of bug reports get filed - it may take quite a while to get around to yours. You can help the process by making sure your bug report is complete and easy to understand, and by quickly replying to any questions which may arrive by email.

If you feel like trying to write a software patch to fix the problem yourself, read the information on developer access and how to use Git/Gerrit.

When to report a bug

It might also be good to have guidance on when to report a bug. E.g., suppose I have a bunch of TODO items for an extension, or there are some known glitches. If it's an unpopular extension, I usually just list those on the extension page or its talk page, e.g. Extension_talk:PureWikiDeletion#To_do_list, because I figure it's unlikely anyone else will want to comment or fix the bug. Also, only certain extensions are listed in the drop-down in Bugzilla, so it's harder to search for stuff pertaining to those.

On the other hand, whenever I anticipate making a change to the core, I always file a bug so that I can put the bug number in the commit summary. I do this even when I know I'm imminently about to submit the patch. That way, there's another place for discussion besides Gerrit (since Gerrit sucks). I'm not sure if that's considered a best practice, though.

It would be nice, by the way, to have a checkbox that says "This is a low importance bug". That would save the bug wrangler some time, would it not? Leucosticte (talk) 01:02, 30 November 2013 (UTC)

Reporting performance issues

Very often, users complain about performance issues. It's usually extremely hard to get them to provide meaningful or actionable information in such cases. We need to produce, or simply link, an easy tutorial for producing the most suitable kind(s) of one-size-fits-all report of use in such cases. When it comes to the many things like

• opening the profiler (Firefox) or the beloved developer tools (Chromium), or Firebugs or whatever,
• picking profiling/network/timeline tabs,
• running profiling (e.g. the JavaScript CPU profile in Chromium) in the correct way,
• picking the right visualisation method (e.g. Flame Chart in Chromium 29+ or whatever),
• and finally – most importantly – exporting in a meaningful way (screenshot? copy and paste? HTML export in some way? HAR? some other magical format? export button anyooooooooooone?!)...

there are simply too many points where reporters can get lost and waste hours of their time to no avail, not having the slightest idea of what they or the devs are looking for. I hope someone can help by giving pointers. --Nemo 12:13, 16 February 2014 (UTC)

User stories

Rather often, bugzilla reports contain (or demand from the reporter) a user story in the form "As a X I want to do Y so that Z". In some cases that's quite a burden to produce for reporters and may be unreasonable, but – as I said earlier, apparently not here – the method must be documented. There seems to be no generic mention of user stories anywhere on this wiki, only the two tangential Epics and User Stories and Manual talk:Coding conventions/PHP#Interview, narrative, lessons-learned approaches.

Awjrichards, can you add one line (one bullet), probably under point 5.4 ("This can include"...), mentioning user stories as a tool and including one link to any online resource suitable for introducing the average bug reporter/MediaWiki user/wikimedian to what a user story is and how to try and write one for their own bug report? It would also have been useful for the GSoC student I'm mentoring. --Nemo 18:34, 11 August 2014 (UTC)

Nemo I did a quick edit. Is that what you were looking for? Also, I'm not really clear on how the translate stuff works, so I didn't add any translate tags around my changes. Help in this regard is appreciated :) --Arthur Richards (talk) 20:34, 11 August 2014 (UTC)

Yes, that's useful; no need to worry about translate markup yourself. Do you think the en.wiki article is good enough as a guide on how to write a user story? (It doesn't look too bad, but it focuses on history and different points of views; something more directly consumable might be useful.) --Nemo 10:54, 22 August 2014 (UTC)