bugzilla situation

Fri Feb 24 17:51:11 GMT 2012

On Friday 24 February 2012 19:32:10 Andras Mantia wrote:
> 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?
-> first level support

issues are not opened on the bug tracker but in a user support management 
system - e.g. forums.kde.org. Only if the supporters figure out that there is 
a real bug, they will open a bug report. This is high filtered, all the 
information present.

Just to give you a feeling about what we are talking in KWin: 
reported bugs in 2011: 824
bugs not marked as "spam" in 2011: 213
bugs fixed in 2011: 197

to filter out ten "spam" reports I need an hour. To fix a  simple issue I need 
with reviewboard etc. etc. maybe max half an hour. To search the bugtracker to 
find a fixable bug I need as long as filtering the spam, that is after reading 
about an hour of spam I find a fixable bug.

So consider I have an hour I want to spend for bug fixing - it is gone before 
I find a fixable bug. It annoys me and I mostly stopped using the bug tracker 
to manage bugs. So why do I need it then?
> 
> > 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.
which is fine if afterwards I have a bug report stating what it is about and I 
don't have to scroll through half an hour of user things to figure out again 
what it was about.
> 
> > > 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.
have a look how Mozilla uses bugzilla (IIRC it is developed by Mozilla). There 
it is a task organizer.
> 
> > > 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.
we have to get the noise out. I don't care how but we have to. It's a huge 
wast of our development resources if we developers do the first level support. 
I have never encountered any successful company where the developers do the 
first level support. If we want to be professional, we have to be 
professional. That means first level support out of the developer tools.

There are areas of KDE where it is still working, but applications like KWin 
and Plasma Desktop need a first level support in front of it. KMail is already 
for a more advanced user group, so it's not perfectly comparable. Kdelibs is 
completely only used by developers, so perfect audience.
> 
> > >  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.
no, we have to improve the situation! Accepting it means surrendering. It 
means accepting that Plasma has reached the state where nobody cares about the 
bugtracker, because it's not useful anymore. KWin is very close to that 
state...
> 
> > > 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?
yes, of course, we have to help the users. But they need to get a tool for 
user support, not a tool for developer communication. We need a first-level-
support to help the users. Developers are the third-level-support.

But I think I repeat myself here :-)

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120224/4df1a766/attachment.sig>