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 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
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 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, 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 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)
 * 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?!)...

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.

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)

Use wiki-id on a non-wiki site
Why should I trust a non-wiki site with my wiki-id? And: my first login just failed. -DePiep (talk) 21:46, 20 July 2015 (UTC)

Suggestion
I'm also going to mention this on Phab itself: since there is no interface translation in Phab yet, this guide may also be used to understand what the different fields are actually about. In order to do so, each translation needs to also present the original name of the field in English next to its translation. --151.42.97.134 11:26, 23 May 2016 (UTC)
 * Thoughts, User:AKlapper (WMF)? --Elitre (WMF) (talk) 14:41, 24 May 2016 (UTC)
 * Makes sense to me (however I have no influence on the content of translations). :) --AKlapper (WMF) (talk) 15:27, 24 May 2016 (UTC)
 * You can mark the original names as variables so that they (more likely to) be included untranslated in translations. /André Costa (WMSE) (talk) 08:25, 13 June 2016 (UTC)

Reporting language
Unless I'm misremembering there is a requirement that bug reports are done in English on Phabricator. It would be good to add a line about that (ideally with a link to a motivation). This becomes especially important for anyone who arrives to a translated version of this page. If the language restriction has been lifted then that would also be good to mention. /André Costa (WMSE) (talk) 08:28, 13 June 2016 (UTC)
 * Do you only refer to reports about bug specifically, or about any tasks? I'm not aware of such a requirement and I would not agree that any tasks must be in English - for example I've seen WMUA tasks in Ukrainian and I don't see a problem with that. It strongly depends on the audience of the task, and I agree that it could be helpful to mention to "please write in English". --AKlapper (WMF) (talk) 09:26, 13 June 2016 (UTC)
 * I just realized that the text is there just not displayed on the (English) base page so consider my request/comment withdrawn.
 * When WMSE set up #WMSE-communication we were explicitly told that all tasks needed to be in English (which probably played a part in the phabricator not becoming something we used much internally). If this is not the case then that would be great. /André Costa (WMSE) (talk) 10:16, 13 June 2016 (UTC)
 * Any reference to that statement? I'm curious if I said that in my past life or such. :D --AKlapper (WMF) (talk) 11:08, 13 June 2016 (UTC)


 * You need English when people who do not know your language need to take action on your tasks. If you want any chance that a dev looks at a bug you're reporting, that bug report needs to be in English (as a lingua franca chosen on technical grounds, that's it). But if you are talking about an internal project like one a chapter may manage, where no actions need to be taken by anyone else, then there is just no point in using English if you don't want/need to. --Elitre (WMF) (talk) 11:16, 13 June 2016 (UTC)
 * I pinged Ainali who handled this. We'll see if he remembers.
 * . I definitely agree =) /André Costa (WMSE) (talk) 11:29, 13 June 2016 (UTC)
 * That statment was made here by User:Qgil-WMF. Ainali (talk) 12:10, 13 June 2016 (UTC)

how to pay for specific bugs to get fixed
I searched this page and others to find ways to pay code bounties for developers to fix specific bugs on MediaWiki. I found this bounty to connect phabricator (MediaWiki's bug tracking tool) to bountysource but no traction on that bounty for two years. What other methods/sites can we use to pay developers to fix specific mediawiki bugs? Goal: fix the create a book error [https://phabricator.wikimedia.org/T88638 Generation of the document file has failed. ]
 * See Professional development and consulting. --AKlapper (WMF) (talk) 15:17, 27 August 2016 (UTC)
 * Thanks, I pinged pedia press guys. I'll report back. --DennisDaniels (talk) 16:05, 27 August 2016 (UTC)