Martijn is on to something here. I write as a non-developer who has identified bugs and has been pressed to report them via Bugzilla, despite the fact that I feel very much out of my depth there. For those of us who can report problems but not solve them (other than to test solutions), a simpler process would probably help to ensure that the bugs are reported in a more standard way that is most likely to be useful to the developer team.
On a side note, Bugzilla is also used not just to report bugs but to request enhancements and/or activation of extensions. This can be the developer equivalent of walking through a field of landmines, as many are not familiar enough with the disparate communities to determine whether this is actually a community request or just a bunch of guys on a little-watched page asking for something. The communities can get pretty nasty with the developer team if an unexpected change is made, so finding a better way to resolve these issues would be mutually beneficial.
Risker/Anne
On 14 May 2012 12:07, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
Thats actually quite an interesting thought, and it could well be true, even if it is the opposite of the Wiki philosophy.
On the other hand, it might also be true that non-developers do find bugs, but fail to report them exactly because of the BZ user experience. It's quite important that reporters don't 'get in the way' of development. Keeping them out of the devolopers shouldn't be done by erecting walls of artificial difficulties - which is what BZ'ed user experience is, it hides the difficulty of finding and properly reporting a bug in itself behind the difficulty of going through the technical process of reporting a bug.
How it should be done is a more difficult question though. Hardly anyone equipped to do proper triage from the firehose of a low-boundries bugtracker is interested in actually doing that triage (see also: code review)
On Mon, May 14, 2012 at 5:46 PM, Diederik van Liere dvanliere@gmail.com wrote:
I don't think we should aim to cater to non-developers at all. The
changes that a non-developer finds a real bug are very very small (in my previous life as an academic I have done a lot of research on Bugzilla and developer productivity and it's based on that experience that I am making this statement). I think that if a newbie / non-developer finds bugzilla then he /she should be redirected to either IRC / Teahouse / Talk pages / FAQ or any other support channel that we have. They can always be send back to file a bug report.
If we are going to spend effort on improving bugzilla then it should be
focused (IMHO) on matching a bug with the right developer (right meaning a person who can actually fix the problem). It is this area that Bugzilla (or any other bug tracker AFAIK) provides very limited support.
-- Diederik On 2012-05-14, at 1:10 AM, Ryan Lane wrote:
I don't think you'll ever find a finished bug-/issue-tracking solution
that
caters just as well for newbies and developers. The main reason is (of course?) that most issue tracking software is written for developers,
by
developers with little or no experience or thought as to what makes a
good
end-user experience. Also, most issue tracking tools are *made deliberately* to work best for developers - with human (end-user) interaction kept to a minimum. That's also why most issue tracking solutions end up looking like glorified (not the good kind)
spreadsheets
(Mantis, Flyspray, others?), something the IRS would want you to fill
out
(BZ, OTRS, RT, others?), or some kind of bastard child in-between (The
Bug
Genie, Redmine, Jira, Fogbugz, others?).
I'd like to go one step further. There is not a single good bug/issue tracking system in existence. Yes, I'm completely serious too. I've come to believe that it's impossible to make one that anyone will be happy with. That includes most developers of tracking systems too (I've written one, and I hated it, though I liked it better than what I was using before).
We can complain about this till the end of time. This discussion is even worse than bikeshedding discussions. At least with bikeshedding discussions you end up with a color for the bikeshed. When discussing bug/issue trackers you just end up with the same tracker, or another crappy tracker.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l