On Tuesday, 27 February 2018 14:45:51 CET Paul Brown wrote:
> On Tuesday, 27 February 2018 13:43:17 CET Boudewijn Rempt wrote:
> > On Tuesday, 27 February 2018 13:30:12 CET Paul Brown wrote:
> > > Is it true that users get confused by the bugtracking system? If so,
> > > this
> > > is an issue, right?
> > 
> > Well, users can get confused by _everything_.
> 
> If a service is confusing for the target it is designed for, then should it
> not be the job of the implementers to change it so it isn't?

That is my argument: bugzilla is not designed for the reporters. It's a tool 
for developers. 

> > Though I probably have more
> > absolutely non-technical users reporting bugs than most other KDE
> > projects.
> > I haven't seen many signs of users being confused by UNCONFIRMED vs
> > CONFIRMED, though.
> > 
> > I'm all for making the initial reporting of bugs as smooth as possible for
> > users... Though really, I don't need any more bug reports.
> 
> Are you the only one dealing with bugs?

No, but I am the fourth most prolific bug closer in the KDE community and the 
maintainer of the bugzilla product that gets the second most bug reports per 
year. So I guess my experience is relevant. If not, please tell me, and I'll 
drop out of the discussion.

Going back to the original discussion:

"Let's replace UNCONFIRMED with NEW because confused users set bugs to 
CONFIRMED themselves, and besides, UNCONFIRMED makes them feel bad."

I haven't seen much if any of that, and I doubt that messing with the part of 
the workflow that's important for the people bugzilla is meant for, namely the 
developers, will make a lot of difference for reporters. Based on my 
experience, s/UNCONFIRMED/NEW won't make one iota of real difference.

There is a lot of things we can do to make life smoother for bug reports; but 
on the other hand, it shouldn't be too easy to report bugs because then we get 
even more crap to drown in.

The one thing that I wish we _would_ when changing the available statuses in 
bugzilla, is make life easier for developers by making it possible to 
distinguish between

* A bug nobody has looked at yet
* A bug someone other than the reporter has looked at, but which was not 
reproducible
* A bug someone other than the reporter has been able to reproduce.

That's all -- I don't care what those statuses are called, but having that 
would make it easier for me to handle my 1000+ bug reports a year.

-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org


Reply via email to