On 12/05/12 18:17, David Gerard wrote: > Discussion on Oliver Keyes' blog: > > http://quominus.org/archives/714 > > He's coming from the perspective of liaison with newbies. Read the comments.
I have to say it's the first time I met him. I'll try to summarise his points below with my comments: 1a) The steps are not clear. Solution: Make the "Enter a new bug report" link of https://bugzilla.wikimedia.org/ much bigger. The intermediate page asking you to login is not "cool", but I think that's a clear enough path. 1b) There's no indication that your login is your email. Granted. This can be confusing. Specially for the perspective of a mediawiki user. The only positive point might be that, if you have recently registered, you probably remember that your email is your login. The email sent by bugzilla does help, although it isn't explicit, either: > To use the wonders of Bugzilla, you can use the following: > > E-mail address: [email protected] > Password: HPqd4NwIu Proposal: Add a message at the front page noting that you need a different login for bugzilla, that it is our email, and it'll be publicly visible. 2) You need to know the components where to file the bug. Yes, it can be confusing. Add a Generic group from where they should be refiled into the appropiate component? 3a) Bugzilla status keywords are confusing. Indeed they are. Those closing the bug should provide a justification message suitable for everyone, though. 3b) There's no threading in the bugs Valid, although not too important for the common bug. 3c) It is in ascending order by date NOTABUG :) Top-posting is bad. It would be crazy to read the bug reports backwards. I don't oppose to an option to show them in reverse order, though. I also like how we have our bugzilla configured with the comment box in the bottom, ie. where the new comment will be added, and just below the last comment. [4] He provided no step 4, so I'm adding another problem for naive reporting not listed there: all bugzilla communication is in English. 5a) Bugzilla is not used to discuss fixing the bug but for discussing where it appears. The first step is always determining what needs to be fixed and how to reproduce it. The how to do it is usually straightforward and doesn't require discussion, although it is sometimes there (moreover, that newbie reporter wouldn't understand them anyway, I expect him to think "you're the developers, just fix it"). 5b) watching these threads usually provides me with very little information about what is happening with the bug, who is dealing with it, what the proposed ETA is, whether it will be deployed now or rolled into the next MediaWiki release, so on and so forth Who says that anyone would do it? :) Consider it won't be done until, someone says "fixed here". Alternatively, if a developer is asking many quesitons about it, he may be considering to fix it. Time of deployment is usually on next deployment, which should be very easy with the planned new two-week deployments. https://blog.wikimedia.org/2012/04/12/mediawiki-1-20wmf1-deployment/ It used to be harder, like needing you to know the revision number and the branch point of next release. 5c) real conversation happens elsewhere... What makes you think there's any conversation at all? I don't think there's much discussion needed on most bugs. You should just wait until there's a message like "it's done here" in bugzilla. Then there might be later objections at gerrit, though, which may drift the conversation to a different site. What may be harder and needing extra skills would be to actually bug the right person convincing them to implement a fix for that little bug that really annoys you. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
