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 Phabricator
Task T56606

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)

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)

@André Costa (WMSE): 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.

@AKlapper (WMF) and Ainali: 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)

@André Costa (WMSE): 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)

@AKlapper (WMF): I pinged Ainali who handled this. We'll see if he remembers.

@Elitre (WMF): . 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 on Wikimedia?

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 Generation of the document file has failed.

@DennisDaniels: See Professional development and consulting. --AKlapper (WMF) (talk) 15:17, 27 August 2016 (UTC)

@AKlapper: Thanks, I pinged pedia press guys. They won't fix book printing bug. What's the best approach? My thinking is put up a bounty specifically for the wikimedia coders to fix the specific problem. Question is: how to manage the bounty? Bountysource requires that the bug report e.g. bugzilla, github, etc. TALKS to bountysource... phabricator does NOT talk to Bountysource... https://hackerone.com/phabricator only deals with security bugs on phabricator... https://firebounty.com/about looks like they MIGHT be of use but they are new ... --DennisDaniels (talk) 16:05, 27 August 2016 (UTC)

@DennisDaniels: I think the link I posted above offers further options when it comes to paying someone to work on certain code. :) I don't know the best approach as (to my knowledge) Wikimedia has not experimented with software bug bounties (and as far as I know currently does not plan to). Maybe you could also try to contact the Parsoid team of the Wikimedia Foundation (the OCG PDF Renderer is in their field, as far as I know) and ask for more information. --AKlapper (WMF) (talk) 12:25, 28 August 2016 (UTC)

@AKlapper: re: further options: I am in the beginning phase of what has become a longer journey than I expected. I pinged a few people I thought who would be able to help first. re: Parsoid: I pinged them via talk and will see what happens. re: bug bounties: In your opinion, how best to bring attention to this idea of using bug bounties? With millions of users and certain bugs growing OLD, how best to apply bounty funds to fix specific issues on MediaWiki? Thank you. --DennisDaniels (talk) 09:58, 29 August 2016 (UTC)

@DennisDaniels: resolving the discussion about bounties in Wikimedia is a long journey indeed. I started phab:T88265 some time ago and I don't expect a short term resolution, even if I think that this is worth investigating.--Qgil-WMF (talk) 10:30, 29 August 2016 (UTC)

@Qgil-WMF: Ok. Thanks. I'm glad that I'm not the only one interested in this. I'm not so glad that this idea has so little traction in the community. What's interesting is that bountysource COULD be a solution but phabricator and bountysource don't talk to each other and so bountysource won't take WikiMedia bugs... I've posted a bounty at bountysource to get THAT bug fixed but we'll see if there is any traction there. I just want to fix the bug that prevents me and everyone from printing books from wikipedia... That being said: put up or shut up. I will pay out of my pocket to have a 3rd party code the fix/patch. Do you know any takers? :) And, please, do you have Any advice on how to convince the senior devs that the patch is good/properly tested so I can share that with the dev? As well I would like to know time frame on how long patches are pushed out to wikipedia since the bug affects wikipedia? Many thanks for your continued assistance. 30aug2016 DennisDaniels

@DennisDaniels: I fail to reproduce the problem you'd like to see solved, see https://phabricator.wikimedia.org/T88638#2594304 . If you can still reproduce the problem, a comment in that bug report on Phabricator with exact steps to reproduce is very welcome. :) Regarding patches, any coding work would require a developer to follow the guidelines and get early feedback from maintainers (e.g. see the code review checklist on some aspects) to increase the likeliness of acceptance. That would probably require several patch iterations in Gerrit (which Wikimedia currently uses for code review)... --AKlapper (WMF) (talk) 13:20, 30 August 2016 (UTC)

@AKlapper: re: issue in question. The bug is for wikipedia. I used the wikimedia bug as a start point as I didn't want to repost the same bug... which I did anyway here My bug was closed as being a duplicate. Here is a description of the bug. This book will not print as pdf or text. Here is the video of the bug on youtube pJ7sSqIQtDI?t=55s in action. re: code review: thanks. re: coder: do you know anyone on the *pedia team that might be able to code up a fix? (trying to stay on target here! :) )

@DennisDaniels: For the records, it is not really clear if it's the "same bug" when it comes to code triggering the problem - we only know that the outcome (error message) is the same. :) I closed your task because it sounded like the focus of your task was on setting up a bounty for T88638 and we currently don't support bounties (or better: don't support bounties via creating separate tasks about other tasks). But I ignored the last line in your task your task that your task is actually about https://en.wikipedia.org/wiki/User:DennisDaniels/Books/Medical_Laboratory_Basics instead, and I am sorry for that. Hence I've reopened your task and edited it a bit. Unfortunately I cannot name anyone who has time to write a fix but the Parsoid team should know way better. --AKlapper (WMF) (talk) 18:14, 30 August 2016 (UTC)

@AKlapper: FWIW, I have posted on the Parsoid team discussion page. We'll see what comes of it... https://www.mediawiki.org/wiki/Topic:Taqe5tfp2cp6hbae Thanks for your consistent help and patience.

@DennisDaniels: You're welcome. Regarding your post, my recommendation above was to ask the Parsoid team for names of people potentially able or interested in that code area (instead of asking for bids). So personally I do not expect any team members to 'consider your offer'. Just saying, for clarification of expectations. (PS: --~~~~ adds your signature on such talk pages.) --AKlapper (WMF) (talk) 08:33, 1 September 2016 (UTC)

error in "Reporting a new bug of feature request" plus a bug

The section on "Reporting a new bug or feature request" begins with, "If you have faced a bug in a recent version and no one else appears to have reported it, then: Go to phabricator.wikimedia.org and click "Maniphest" in the side bar."

• PROBLEM WITH THESE INSTRUCTIONS: When I went to phabricator.wikimedia.org, I could not find anything matching "Mani" on that page.

• PROBLEM THAT BROUGHT ME HERE: Could someone check the "français" language link on "https://en.wikipedia.org/wiki/Julia_Cag%C3%A9"? When I did this just now, it linked to "https://fr.wikipedia.org/wiki/Beno%C3%AEt_Hamon". It should go to "https://fr.wikipedia.org/wiki/Julia_Cag%C3%A9".

Thanks, DavidMCEddy (talk) 15:49, 14 February 2017 (UTC)

Thanks for your message: re: the instructions, changes in the interface mean they need to be constantly updated... but point 2 with the direct link actually works and makes point 1 redundant.

I fixed the actual problem you reported in the source code of the article you linked. In similar cases you just want to use the the talk page for the article itself, or report to a technical savvy user/technical village pump on your wiki for faster resolution. --Elitre (WMF) (talk) 16:14, 14 February 2017 (UTC)

and after your fix, I see what I did wrong: I had [[fr:Benoît Hamon]], when I should have had fr:Benoît Hamon. Thanks, DavidMCEddy (talk) 17:41, 14 February 2017 (UTC)

Release Details

Tracked in Phabricator
Task T168186

When creating a new task or editing an existing one, there's a new field called "Release Details". What's the purpose of this field? Anyone who knows please update this page :) --Ciencia Al Poder (talk) 09:45, 17 June 2017 (UTC)

@Ciencia Al Poder: Thanks! I've filed phab:T168186 --AKlapper (WMF) (talk) 21:38, 17 June 2017 (UTC)

Sidebar?

Why isn't this page linked from the sidebar? I always look for it there. --Elitre (WMF) (talk) 10:10, 10 July 2017 (UTC)

 Done Trizek (WMF) (talk) 14:20, 10 July 2017 (UTC)

? --Elitre (WMF) (talk) 15:51, 10 July 2017 (UTC)

I now see it on fr.wp, it.wp or commons. Solved? :) Trizek (WMF) (talk) 16:19, 10 July 2017 (UTC)

Err... I was really only talking about this very wiki. --Elitre (WMF) (talk) 16:32, 10 July 2017 (UTC)

Ah, that! It will be a bit more complicated, because we need a translatable item for MediaWiki:Sidebar. Trizek (WMF) (talk) 17:52, 10 July 2017 (UTC)

So what if someone else already reported the issue?

What if I have the same issue that someone else reported and the task is closed? Do I report it again? Do I add a comment on that closed task? Thinker78 (talk) 19:48, 13 December 2017 (UTC)

@Thinker78: Depends on the state and the age, I'd say. If the task has been closed as declined and you have any new arguments to share, add a comment to the existing task. If the task has been resolved (which normally means that a code change has been made, if we talk about tasks on software behavior) very recently, add a comment on that existing task. If the task has been resolved ages ago, create a new task (and mention the old existing task in your new task). Those would be my recommendations. --AKlapper (WMF) (talk) 20:16, 13 December 2017 (UTC)

If I may add a few details: a task being resolved doesn't mean the fix (if it's a bug) is live. So you may want to check the deployment date first before commenting "this is still broken for me" (this is an example). If it has been a while and you have reasons to believe there is a regression, I would rather file a new task than commenting an old one. Worst case scenario, the new one gets merged into an old one. But I can't promise that all PMs/devs really look at new comments in resolved tasks. Elitre (WMF) (talk) 09:49, 14 December 2017 (UTC)

Suggestion

I'm getting errors so I'll just leave it here. I was trying to add the following section:

===Have you tried fixing the issue yourself, or would you like to?=== In several occasions, nasty problems are just a consequence of using outdated user scripts and gadgets. There's [[Help:Locating broken scripts|a guide available]] with easy steps to attempt the identification of such faulty code, which could fix your issue so that you don't waste your time reporting it.

New task creation in Phab only links to this "write a good bug report" page, which doesn't give more visibility to the scripts one which, instead, is the one providing steps that could fix the issue at hand without even needing to file a task about it. (This post brought to you by yet another case of an apparently urgent situation which in the end wasn't actually it.) Elitre (WMF) (talk) 11:09, 14 January 2019 (UTC)

@Elitre (WMF): Thanks. Where exactly would you add this? I agree that "Reporting a JavaScript bug" isn't too helpful if you don't know that you are facing a JavaScript bug (or what JavaScript is and that gadgets use it). --AKlapper (WMF) (talk) 11:30, 14 January 2019 (UTC)

It was meant for How_to_report_a_bug#Before_you_do_anything. Elitre (WMF) (talk) 12:00, 14 January 2019 (UTC)

@Elitre (WMF): Thanks, added in https://www.mediawiki.org/w/index.php?title=How_to_report_a_bug&type=revision&diff=3053517&oldid=3014533 --AKlapper (WMF) (talk) 18:02, 14 January 2019 (UTC)

@Elitre (WMF): @AKlapper (WMF): I think "Have you tried fixing it yourself?" is a bit misleading. When I read the TOC and see that, I would probably think of something like "Fixing it in code as a dev" and completely skip it. Maybe it should say something "Make sure it's not an gadget/user-script issue from your settings" Christoph Jauera (WMDE) (talk) 16:14, 15 November 2019 (UTC)

@Christoph Jauera (WMDE): Thanks! Right, makes a lot of sense. I changed that in https://www.mediawiki.org/w/index.php?title=How_to_report_a_bug&type=revision&diff=3509017&oldid=3426207 --AKlapper (WMF) (talk) 18:41, 15 November 2019 (UTC)

Flickrs to Commons tools bug

This tool is not working for couples of week stack on loading. https://tools.wmflabs.org/flickr2commons/index.html Mohammed Galib Hasan (talk) 09:03, 17 July 2019 (UTC)

Javascript

The instruction for enabling or disabling javascript is not available. Please use archived version, or choose another one.Alfa80 (talk) 10:42, 26 July 2019 (UTC)

Wow, that link is ancient! I'm not sure what would be the best replacement... I looked at a dozen search results and this was the only page that seemed to have uptodate instructions and also covers mobile browsers: https://www.wikihow.com/Disable-JavaScript but it might be considered too overwhelming? Ping AKlapper (WMF) do you know of anything better? –Quiddity (talk) 01:25, 29 July 2019 (UTC)

@Quiddity: I boldly removed all that stuff in https://www.mediawiki.org/w/index.php?title=How_to_report_a_bug&diff=3333951 as I don't think that fiddling around in some hidden preferences to disable JavaScript is a better idea nowadays than simply opening the console of a web browser's Developer Tools. (No idea for mobile browsers though.) --AKlapper (WMF) (talk) 08:11, 29 July 2019 (UTC)

@AKlapper (WMF): Hmm, I think the "how to disable" section (T:59) was potentially useful, because some users are more comfortable with poking at browser settings (and Chrome/ium makes it fairly easy), than they are with being confronted with lines of code. I was just hoping we could find a better link for it. -- However, I'm also not a dev, so I'm not sure if it's actually valuable for a dev to know that simply "toggling JS off solved it" for a user?

(And yay for the other cleanup!) –Quiddity (talk) 08:35, 29 July 2019 (UTC)

When reporting a bug, most users won't have a clue if the problem is JavaScript or not, and it's not reasonable for us to expect users reporting new bugs to identify the root cause. Once reported, with the steps to reproduce, some developer with more knowledge can identify if it's a JavaScript issue or not, or ask specifically to disable JavaScript if that's relevant. I think it's fine to remove the JavaScript section. Another interesting thing to check would be to try to reproduce the bug using private browsing, a feature available in all major browsers, to discard personal JavaScript or user preferences problem. --Ciencia Al Poder (talk) 09:19, 29 July 2019 (UTC)

Bad example

• Title: A short one-sentence summary that explains the problem (not your suggested solution).
  • Good: "Selecting gender is not functional."
  • Bad: "Software crashes."

Get off the toilet seat and out of the restroom. People have user pages, talk pages, say what they want about themselves, but there is absolutely no reason whatsoever that the user's age, gender, or other condition should affect how the software operates, and there is no reason for others to be inquiring so solicitously about a person's gender, unless the purpose is to openly facilitate sex discrimination and/or sex traffic. Justinacolmena (talk) 19:44, 27 February 2020 (UTC)

Cut short with anti-sticky tools

When using some anti-sticky tools, such as AlwaysKillSticky on Firefox, many articles including this one get cut short partway through, and have other visual issues. I'm getting errors from Phabricator too. Since sticky elements can cause motion sickness and migraines, blocking tools can be useful, and constantly having to turn them back on and off can be a problem. 138.88.18.245 22:22, 29 April 2020 (UTC)

Account Creation is not Accessible

Since we're supposed to create Mediawiki accounts to report bugs, how are we supposed to report bugs which make it impossible to create accounts? As I type a username, parts of the page jump up and down, triggering a migraine. In addition, as I create a new section here, an animated pop-up animates, worsening the migraine. 138.88.18.245 15:05, 7 August 2021 (UTC)