bugzilla situation
Andras Mantia
amantia at kde.org
Fri Feb 24 17:32:10 GMT 2012
On Friday, February 24, 2012 06:10:23 PM Thomas Lübking wrote:
> Am 24.02.2012, 09:44 Uhr, schrieb Andras Mantia <amantia at kde.org>:
> > Bugzilla is not a to-do list, it is for what else... a bug (and wishlist)
> > reporting tool for users.
>
> The problem here that this is noise prone and the low entropy isn't
> helping anyone (and i'm not talking about users should not state their
> opinion or whatever)
The point is you can't avoid noise. How would you do that?
Remove Dr. Konqui? Close bugzilla to the public and allow only for some to
report? Moderate it?
If you can moderate it, it means you have time and resource to do it, so you
could have done until now as well. The rest is not a real solution (maybe Dr.
Konqui is, but then you will also lose valid reports).
Any other suggestion?
> Luckily this isn't a must.
> a) NO system message should be posted to bugs (adding CC etc. isn't but is
> available in bug activities, so why is duping or Dr. Konqi attaching a
> trace?)
> b) change the DEFAULT message order to "description" -> newest -> oldest,
> users (passing by) will not edit bugzilla presets (if ever they know about)
With this I agree, we could tweak the defaults.
> c) make the "description" (that is the original report message) editable
> by component owners ANYTIME - this here:
Bug editing/cleaning up makes sense (still doesn't solve the ORIGINAL noise,
but indeed, you can clean it up), and indeed Bugzilla doesn't help with it (at
least the current version), contrary to JIRA for example. But you still have
the problem that you need to spend time to do that.
> > If you wish to organize your tasks, I'm afraid you should do in another
> > tool.
>
> That doesn't cut it. *I* can organize my stuff in *my* *private* - but
> that information is entirely exclusive.
> It doesn't change anything for anybody else and esp. not for the user with
> a problem.
This was a suggestion for the project, not the individual. Bugzilla is not a
task organizer. For that we have other tools, use them. Those entries might
refer to bugzilla bugs.
>
> > If you don't like users reporting bugs, close the product for bugzilla,
> > ignore the users, and do what you want.
>
> Nonsense. This is not about "I don't like hearing about bugs" but about "i
> don't like my bugs being spammed"
See above and my mail. IMO you can't avoid that with the userbase we have.
You have to live with it. Of course, I was ironic, and I hope nobody will do
that, but I know there are developers from teams who don't really care about
bugzilla reports. That's fine, I can accept it.
> > And if there pitfalls, common problems with your application in certain
> >
> > setups, document them
>
> Yes, best in a blog. /sarcasm
Sure. :) BTW, if you refer to my Akonadi blogs, that content is more or less
also in the userbase wiki and in KMail's manual nowadays. And seen it being
used as a reference on IRC and user mailing list by others. So the information
spreads out. And google also finds it.
> > and distribute to as many channels as possible
>
> So users can search there for the solution? In a way hoping that their
> circles somehow match the developer ones?
Yes.
> And you think, that's what they'll do instead pressing "report bug" in
> Dr.Konqi? (what *is* the expected behavior and will usually take the to
> the right bug in short time.
Maybe not for crashes, but there are more than crashes in applications.
I know, that I google many times if I have a problem. But I'm also a
developer, so users might not do that. But still, keeping things "secret"
won't help, you need to tell the solution everytime when somebody has a
problem.
> Developers and experienced users will google the issue up anyway.
> Ubuntu users won't. They think "OMG, >>>I<<< have a problem. Best report
> it and ask to get help"
I'd skip this, as I don't want to categorize users. Certainly there are some
hard to deal with, but this just proves what I said: you have to accept the
situation.
> > that large as kmail though), I only remember one case when the user left
> > upset.
>
> This is not about the user being upset. That's the users problem ;-)
Questionable. It is about an atmosphere problem in the community.
I'm all for a better tool, that's not a problem, but blaming the users for
reporting everything they have in mind is not a solution. They have a problem,
that's why they turn to bugs.kde.org, and every problem you have is the
biggest and most important on earth, no?
Andras
More information about the kde-core-devel
mailing list