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 <dvanli...@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
