Re: bugzilla situation
On Friday, 2012-02-24, Martin Gräßlin wrote: 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 aman...@kde.org: 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 We do have plenty of such channels and they do tend to work pretty well for a wide range of questions (not necessarily problems). Some questions (again not necessarily problems) require either understand code (and of course find the relavant portions first) or in some cases even bigger view of things. I guess it all boils down on how you define first level. For me that's all kinds of things that can be solved by users themselves, e.g. finding the answer through experiementation or through easily findable public documentation. Anything beyond that, e.g. requiring understanding of developer level documentation or reading files in the respository (code, READMEs, etc) is IMHO already second level. This or rather the transition between the two is what we currently lack most. 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. Separate tools make it harder to move/share context. In some cases it even requires manual opcying, e.g. of information between two contexts which should be the same. This approach is similar to doing a backup by manually copying new/modified files to the backup location instead of using some synchronisation tool. I think introducing another separate tool is the least preferable solution. It will just increase the work on those who currently weed out the important entries. 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. I disagree. For one because I think the level we are missing or have understaffed is level two and second because the real issue is losing all information when crossing a level threshold, especially when crossing into third level. Lets assume the issue tracking system is closed and only allows write access to developers and accredited second level support people (e.g. like the triagers). Now a user with a problem shows up in some first level support channel, e.g. forum.kde.org or a mailinglist. After a while it is clear that the problem cannot be solved by user community support. Problem at this stage is that there is not mechanism or rules on how to esacalte to second level, so this transition already requires second level to constantly monitor first level discussions to determine when that particular stage is reached. Lets assume that we are lucky and someone with access to and understanding of code happens to come across this halted thread. They might not be able to solve it either but maybe exhaust more options that the original user could try. Under our initial assumption of a closed issue tracking system we do have mechanism and rules for transition (yay!) but we now lose all context (doh!). You end up with two contexts, have to manually copy information back and forth. And there is a significant effort involved in creating the second context, because someone has to wade through all information in the first context and selectively copy/rewrite bits and pieces. I agree that this second context is ideal for consumption for developers, i.e. being reduced to only the required information, but if we already have a scalability problem with the current approach, I don't see how that can scale either. IMHO the only viable way is to keep the same context and
Re: bugzilla situation
On 02/22/12 20:41, David Faure wrote: On Wednesday 22 February 2012 16:15:45 Giorgos Tsiapaliwkas wrote: Hello, Toma's blog posthttp://www.omat.nl/2012/02/18/sysadmin-needs-help-with-bugzilla-instal lation/ inspired me to send you this mail. Right now our bugzilla is a mess. We have so many bug entries which we can't handle. Everyone is able to open a new bug, but only a few people are able to triage them. Most of the bugs are useless(duplicates and wishes). The true bugs are very few and most of them are being lost by the massive amount of open bugs. With such a mess on the bugzilla we are not able to coordinate our work using it. Our projects have different needs, that's why they differ from each other(ML etc). Every project should be able to choose if everyone will be able to open a new bug or not. In case that a user finds a true bug, he can go to the project's irc and to ask from someone to open the new bug. Doesn't sound very open The alternative is the opposite: allowing everyone to edit/move/close bugs. I'm told this is how some other projects do it, and they say it's working well in practice. He asked me why we don't do this, and the only reply I could come up with was the few cases where bugs turned into actual political flamewars; his answer was obviously give rights to everyone, and remove rights when someone abuses them. This is also what we do for SVN/GIT, so why don't we do this for bugzilla? Presuming people are innocent upfront, rather than guilty ;) I tend to think closing duplicate bugs and checking wish list issues can be done by a non-developer contributers. In which case there should be an option by which a particular user can be CCd to for a specific program(s). There should be an entry about this in the wiki pages also (contributing). As of the current time, it appears that the real bugs ( there are a lot of them) gets eclipsed with too many duplicates, unnecessary feature requests and wrong info.
Re: bugzilla situation
On Sat, Feb 25, 2012 at 03:06, dE . wrote: I tend to think closing duplicate bugs and checking wish list issues can be done by a non-developer contributers. In which case there should be an option by which a particular user can be CCd to for a specific program(s). There should be an entry about this in the wiki pages also (contributing). Mailing lists can already be set up for that. For example, all bugs affecting games are automatically CCed to kde-games-b...@kde.org. Parker
Re: Re: bugzilla situation
On Fri, Feb 24, 2012 at 8:06 PM, Martin Gräßlin mgraess...@kde.org wrote: On Friday 24 February 2012 02:15:54 Sven Burmeister wrote: Am Mittwoch, 22. Februar 2012, 19:00:26 schrieb Martin Gräßlin: Personally I'm not sure whether the MeeGo bugzilla can be compared to the KDE one (technical oriented vs. user oriented). From my personal experience (KWin bugtracker is felt 90 % a user support forum) My claim is that most of that user support only ends-up in bugzilla because people did not get help somewhere else, e.g. because only developers are familiar enough with the code to understand the issue. No, that is clearly not the case and it's not the case that the users are searching for user support. It is they have a problem and consider it a bug. They don't know, that: * they just didn't find that damn config option * they have installed the wrong driver/distro/whatever * how to circumvent that stupid driver crash * many many more things which turn out to be user support (interesting side node: the second most often reported bug against KWin is Compiz crashing. That says all about the usefulnes of reports) Is there a page somewhere (such as on Userbase) which documents these broken driver/distribution combinations - and the hardware generally associated with it? In regards to the Compiz component, is that something KDE ships - or is that something Compiz ships? If it is something Compiz ships, it should probably be blocked and that's what first level support is actually for: filtering the noise so that only the real bugs get through. Just consider the bug named kwin-intel - each of the duplicates is about 2 min work. Each of the duplicates is set by a developer. Each of the duplicates is simple user support. Nothing the developers can do about, but users support was possible (use a workaround or switch to a distribution not shipping broken drivers and failing to fix it in the complete cycle given that the patches exist). Most users do not like reporting bugs and thus ask somewhere else first – and only after that, if at all, they report an issue. this is clearly not the case with DrKonqui. They just report Only if it is a crash. Last I heard DrKonqi included functionality to only add the backtrace to the existing report - does this not work with KWin? The majority of users only complains about the buggy piece of software without reporting any issues. So only if they get no answer on IRC, a forum a mailinglist etc. they leave their issue with the developer at bugzilla to document it and wait for an answer. no, I would even deny that they wait for an answer. Please do a search for WAITINGFORANSWER on the KWin product (I need to add that to my statistics). Some users do await replies. Unfortunately there is a not so small segment which never read replies. Leaving the user without answer will not increase KDE's reputation. Thus the discussion should not be about how to restrict user access to bugzilla but rather how to help them before they feel the need to report at bugzilla. Filling out those forms is nothing users like to do. agreed. The proper way has to be to not let users enter support questions into the bugzilla. My perfect scenario is: a) first level support to help users b) if first level support cannot help it goes to second level support c) second level support identifies the important information from first level support, verifies that there is no bug reported yet and reports bug d) developers can concentrate on fixing that bug Note that in many cases, first level support as it were already exists - however we ask the user themselves to report the bug if we believe it to be a valid bug. Unfortunately, without a page as mentioned above with known issues / broken combinations which we can point the users to we have no other choice other than to believe it is an actual bug - which should be reported. in case of KWin that would mean that we get all relevant informations without asking for it: * distribution * version (in case not default of distribution, how installed) These should be reported anyway by DrKonqi if it is not - as many other applications need them as well to determine if a report is useful / a duplicate / known issue. * which compositing backend is use * which effects are used * which effects are active when the problem occurs * hardware * driver/version for that hardware * glxinfo -l output Consider that we have to ask again and again for all those things to find out in the end that it is a known issue with $foo driver in combination with $bar feature. All these things could so easily be handled by a first level support. I'm not aware of any documented list of these broken combinations, at least at the moment. But to get there the bugtracker has to be closed and *cleaned*. Drop all bugs - nothing useful in it anyway. I would not allow users to edit/close all bugs. We have too many users who
Re: Re: Re: bugzilla situation
On Friday 24 February 2012 21:03:42 Ben Cooksley wrote: On Fri, Feb 24, 2012 at 8:06 PM, Martin Gräßlin mgraess...@kde.org wrote: On Friday 24 February 2012 02:15:54 Sven Burmeister wrote: Am Mittwoch, 22. Februar 2012, 19:00:26 schrieb Martin Gräßlin: Personally I'm not sure whether the MeeGo bugzilla can be compared to the KDE one (technical oriented vs. user oriented). From my personal experience (KWin bugtracker is felt 90 % a user support forum) My claim is that most of that user support only ends-up in bugzilla because people did not get help somewhere else, e.g. because only developers are familiar enough with the code to understand the issue. No, that is clearly not the case and it's not the case that the users are searching for user support. It is they have a problem and consider it a bug. They don't know, that: * they just didn't find that damn config option * they have installed the wrong driver/distro/whatever * how to circumvent that stupid driver crash * many many more things which turn out to be user support (interesting side node: the second most often reported bug against KWin is Compiz crashing. That says all about the usefulnes of reports) Is there a page somewhere (such as on Userbase) which documents these broken driver/distribution combinations - and the hardware generally associated with it? no, there is to my knowledge no such page. This is knowledge we actually learnt. And I think a page would not fit, more something like a process diagram/decision tree which results in a fairly clear solution. In regards to the Compiz component, is that something KDE ships - or is that something Compiz ships? If it is something Compiz ships, it should probably be blocked it is an application called kde-window-decorator which is part of Compiz. Luckily nowadays nobody seems to use Compiz any more, so it's not a real issue anymore. and that's what first level support is actually for: filtering the noise so that only the real bugs get through. Just consider the bug named kwin-intel - each of the duplicates is about 2 min work. Each of the duplicates is set by a developer. Each of the duplicates is simple user support. Nothing the developers can do about, but users support was possible (use a workaround or switch to a distribution not shipping broken drivers and failing to fix it in the complete cycle given that the patches exist). Most users do not like reporting bugs and thus ask somewhere else first – and only after that, if at all, they report an issue. this is clearly not the case with DrKonqui. They just report Only if it is a crash. Last I heard DrKonqi included functionality to only add the backtrace to the existing report - does this not work with KWin? for which version? 4.6? 4.7? It is no real help that this is now working in the latest release :-( The majority of users only complains about the buggy piece of software without reporting any issues. So only if they get no answer on IRC, a forum a mailinglist etc. they leave their issue with the developer at bugzilla to document it and wait for an answer. no, I would even deny that they wait for an answer. Please do a search for WAITINGFORANSWER on the KWin product (I need to add that to my statistics). Some users do await replies. Unfortunately there is a not so small segment which never read replies. Leaving the user without answer will not increase KDE's reputation. Thus the discussion should not be about how to restrict user access to bugzilla but rather how to help them before they feel the need to report at bugzilla. Filling out those forms is nothing users like to do. agreed. The proper way has to be to not let users enter support questions into the bugzilla. My perfect scenario is: a) first level support to help users b) if first level support cannot help it goes to second level support c) second level support identifies the important information from first level support, verifies that there is no bug reported yet and reports bug d) developers can concentrate on fixing that bug Note that in many cases, first level support as it were already exists - however we ask the user themselves to report the bug if we believe it to be a valid bug. I would like to see this process change, quite simple as it gives us the information that the user support has already been done. If we get the information to where the user information has been done we can read it through and don't have to ask again for the same things. Unfortunately, without a page as mentioned above with known issues / broken combinations which we can point the users to we have no other choice other than to believe it is an actual bug - which should be reported. if there is interest in it, we should discuss how such a page should look like. E.g. that whenever there is a problem the summary of it goes into a wiki page and we verify that
Re: bugzilla situation
On Friday, February 24, 2012 08:06:41 Martin Gräßlin wrote: Consider that we have to ask again and again for all those things to find out in the end that it is a known issue with $foo driver in combination with $bar feature. All these things could so easily be handled by a first level support. But to get there the bugtracker has to be closed and *cleaned*. Drop all bugs - nothing useful in it anyway. Why not have a state for bugs that you know are worth fixing? Then the developers can concentrate on those and Other people can do the initial cleaning to get the bugs to a state they can be closed or the proper state set. Thorsten
Re: bugzilla situation
On Thursday, February 23, 2012 04:57:16 PM David Edmundson wrote: First of all, the bugzilla is supposed to be a communication tool between the user and the developer. Or is it? If I understand Martin correctly, he wants bugzilla to be a list of things broken in my app, not a communication tool for every user who wants to say something. Bugzilla is not a to-do list, it is for what else... a bug (and wishlist) reporting tool for users. If you wish to organize your tasks, I'm afraid you should do in another tool. (The rest is not for you, just well, more or less generic comments.) If you don't like users reporting bugs, close the product for bugzilla, ignore the users, and do what you want. Nobody stops you to do that. The projects reputation will be hurt, but that is how it works. If you have an open bug reporting tool, you should be prepared that users will use it. And users are not developers, there are (luckily) millions of KDE users out there with various technical knowledge. If you can't accept it, you should probably not do front-end application development where you interact with people. Or you should do what is written above, or just ignore every report. I already wrote in a similar thread in the past: open source and especially KDE development (where you write applications used directly by a lot of people) requires some communication skills towards inexperienced and upset users. If you can't deal with such cases, you better ignore them, it is better for your health. :) And if there pitfalls, common problems with your application in certain setups, document them and distribute to as many channels as possible (forums, wiki, mailing lists). People will learn to look at it. When somebody else has the same problem and asks on IRC, others can point to it, and it doesn't have to be you, the developer. This saves your time, the users time. If you think I don't know what I'm talking about, as I don't have experience, then: - look at the bugzilla statistics and search for kmail - look at the nice mails on kdepim mailing lists :) - while I was working on another KDE app, years ago with a large use base (not that large as kmail though), I only remember one case when the user left upset. Yes, I spent time also on mail writing, not only coding, but this is normal. And the app was not bug-free, still the users were nice and the communication happened in a nice atmosphere. This all depends on both sides. Andras
Re: bugzilla situation
On Fri, 24 Feb 2012, Alex Merry wrote: On 24/02/12 09:22, Thorsten Zachmann wrote: Why not have a state for bugs that you know are worth fixing? Then the developers can concentrate on those and Other people can do the initial cleaning to get the bugs to a state they can be closed or the proper state set. That would be assigned, I'd have thought. Or perhaps new, although bugzilla makes the assumption that all developers will file real bugs straight away. For Krita, I assume that developers know what they are doing, so I'm fine with bugs being set to New immediately, although I would prefer if every bug started out as unconfirmed. I only mark bugs as assigned if it's clear who should work on it; until then, as soon as I can confirm a krita bug, it becomes new. I try to give every report a respons within a week, as well, and I've noticed that if I say thank you for your report, reporters don't mind waiting for a fix, me asking them for more information, closing the bug as duplicate, or telling them to get a newer version and closing the bug as already fixed. It might be a little bit of social engineering, but I try to never close a bug as wontfix or worksforme; in those cases I close the bug as needsinfo. If the user gets back to me with more information, I'll thank them again and look at the bug again. But I'm lucky, I'm not getting dozens of reports a day yet, and bugzilla is an extremely useful tool for me. Boudewijn
Re: bugzilla situation
On Friday 24 February 2012, Martin Gräßlin wrote: On Friday 24 February 2012 21:03:42 Ben Cooksley wrote: On Fri, Feb 24, 2012 at 8:06 PM, Martin Gräßlin mgraess...@kde.org ... Consider that we have to ask again and again for all those things to find out in the end that it is a known issue with $foo driver in combination with $bar feature. All these things could so easily be handled by a first level support. I'm not aware of any documented list of these broken combinations, at least at the moment. yes it does only exist in our heads and I think that is the case for more products. If we want to go for a proper first level support approach, we of course have to educate our first level supporters. But before we can do that we have to know that e.g. forum.kde.org is seen as our first level support where everything should go to instead of bugs.kde.org. For bko I don't need wiki pages as it is in my head. I think having such a (wiki) page documenting known problematic setups would be a good thing. It might reduce the number of bugs entered into bugzilla (or maybe not, but at least the users could simply be pointed to that page, if this does not happen automatically via google, instead of waiting for input from inside your head ;-) ) Alex
Re: bugzilla situation
On Friday 24 February 2012, Ben Cooksley wrote: On Fri, Feb 24, 2012 at 11:41 AM, Kevin Ottens er...@kde.org wrote: On Thursday 23 February 2012 17:39:12 Trever Fischer wrote: Random, possibly entirely unhelpful suggestion: Perhaps using our redmine install of projects.kde.org for this kind of task tracking? I'd love to see p.k.o be used as something more of a central place for devs to get together and collaborate. I keep track of all my phonon tasks in my head or community.kde.org, which is terribly inefficient. Yet, I feel it is better suited than bugzilla. Yes, I'd love to have bugzilla for user support and p.k.o for managing my projects roadmap and tasks (and so developers centric). As far as I know there's even a way to link a bugzilla entry to a redm^Wchiliproject ticket which would come in handy for those high quality long term bugs you've to take care of while roadmapping. With an akonadi resource talking to it on top talking to ChiliProject it'd be heaven on earth. :-) Sysadmin is not permitting the task tracking abilities of KDE Projects to be used at the moment, as it is not possible to effectively use a bug tracker when different projects are using different trackers. When you say different trackers, do you mean some use use p.k.o and some use b.k.o, or do you mean using different trackers in redmine/chili ? Beside that, I'd love to be able to use the wiki on p.k.o for the projects. Alex
Re: bugzilla situation
Am 24.02.2012, 09:44 Uhr, schrieb Andras Mantia aman...@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) As long as the relevant informations are scattered between tons of duplicate notes and -OT drifting- discussions, the bugtracker doesn't help users and thus becomes an annoyance for developers. 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) c) make the description (that is the original report message) editable by component owners ANYTIME - this here: == don't worry, just keep scrolling === Application: kwin (4.5.1 (KDE 4.5.1) release 3) KDE Platform Version: 4.5.1 (KDE 4.5.1) release 3 Qt Version: 4.6.3 Operating System: Linux 2.6.34.7-0.3-desktop x86_64 Distribution: openSUSE 11.3 (x86_64) -- Information about the crash: - What I was doing when the application crashed: I'm not exactly sure how KWin crashed, but I was watching a flash video in Chromium. It ended and I alt-tabbed and things locked up. Suddenly a Chromium tab was in it's own window like I had dragged it off the tab bar, but I hadn't. Not sure if this really helps or not. This is on an R400 Thinkpad laptop with intel i945 graphics. KWin works fairly good with effects but these intel drivers are really buggy it seems. -- Backtrace: Application: KWin (kwin), signal: Segmentation fault [KCrash Handler] #6 intel_region_buffer (intel=0x780530, region=0x0, flag=2) at intel_regions.c:498 #7 0x7f123d601dc4 in intelClearWithBlit (ctx=0x780530, mask=2) at intel_blit.c:266 #8 0x7f123d603dca in intelClear (ctx=0x780530, mask=value optimized out) at intel_clear.c:173 #9 0x7f12540ddf85 in KWin::SceneOpenGL::paintBackground (this=value optimized out, region=value optimized out) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/scene_opengl.cpp:892 #10 0x7f12541372b6 in KWin::Scene::paintGenericScreen (this=0x10a60a0, orig_mask=32) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/scene.cpp:187 #11 0x7f12541090aa in KWin::Scene::finalPaintScreen (this=0x10a60a0, mask=32, region=value optimized out, data=value optimized out) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/scene.cpp:177 #12 0x7f125413a4dc in KWin::EffectsHandlerImpl::paintScreen (this=value optimized out, mask=32, region=value optimized out, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects.cpp:172 #13 0x7f123ccf8e6f in KWin::LogoutEffect::paintScreen (this=0x10790b0, mask=32, region=..., data=value optimized out) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects/logout/logout.cpp:207 #14 0x7f125413a56c in KWin::EffectsHandlerImpl::paintScreen (this=0x1341ca0, mask=32, region=value optimized out, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects.cpp:168 #15 0x7f123ccfd842 in KWin::PresentWindowsEffect::paintScreen (this=0x11311c0, mask=32, region=..., data=value optimized out) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects/presentwindows/presentwindows.cpp:196 #16 0x7f125413a56c in KWin::EffectsHandlerImpl::paintScreen (this=0x1341ca0, mask=32, region=value optimized out, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects.cpp:168 #17 0x7f125279241f in KWin::Effect::paintScreen (this=value optimized out, mask=32, region=value optimized out, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/lib/kwineffects.cpp:227 #18 0x7f125413a56c in KWin::EffectsHandlerImpl::paintScreen (this=0x1341ca0, mask=32, region=value optimized out, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects.cpp:168 #19 0x7f125279241f in KWin::Effect::paintScreen (this=value optimized out, mask=32, region=value optimized out, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/lib/kwineffects.cpp:227 #20 0x7f125413a56c in KWin::EffectsHandlerImpl::paintScreen (this=0x1341ca0, mask=32, region=value optimized out, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects.cpp:168 #21 0x7f125279241f in KWin::Effect::paintScreen (this=value optimized out, mask=32, region=value optimized out, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/lib/kwineffects.cpp:227 #22 0x7f125413a56c in KWin::EffectsHandlerImpl::paintScreen (this=0x1341ca0, mask=32, region=value optimized out, data=...) at
Re: bugzilla situation
On Friday, February 24, 2012 06:10:23 PM Thomas Lübking wrote: Am 24.02.2012, 09:44 Uhr, schrieb Andras Mantia aman...@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
Re: Re: bugzilla situation
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 aman...@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
Re: bugzilla situation
On 2012-02-22, David Faure fa...@kde.org wrote: up with was the few cases where bugs turned into actual political flamewars; his answer was obviously give rights to everyone, and remove rights when someone abuses them. This is also what we do for SVN/GIT, so why don't we do this for bugzilla? Presuming people are innocent upfront, rather than guilty Everyone can manipulate with bugs in the debian bugtracking system. There is very littel abuse. From time to time, assholes drop by but usually tehy can actually be educated to at least find another place for their trolling. beside that, the debian bts blacklist, iirc called politely @gFuckheads, has over time had around 10 people on it or so. /Sune
Re: bugzilla situation
Am Freitag, 24. Februar 2012, 08:06:41 schrieb Martin Gräßlin: My claim is that most of that user support only ends-up in bugzilla because people did not get help somewhere else, e.g. because only developers are familiar enough with the code to understand the issue. No, that is clearly not the case and it's not the case that the users are searching for user support. It is they have a problem and consider it a bug. Maybe it's different for kwin but what I see is: User asking on distro/KDE mailinglist/forum/IRC because xyz does not work. 1. he gets an answer 1.1 known bug 1.2 me too - the user might open a bug report 1.3 it works like this… 2. he does not get an answer 2.1) frustrated and no bug report 2.2) frustrated and bug report They don't know, that: * they just didn't find that damn config option * they have installed the wrong driver/distro/whatever * how to circumvent that stupid driver crash * many many more things which turn out to be user support (interesting side node: the second most often reported bug against KWin is Compiz crashing. That says all about the usefulnes of reports) Well, most other apps do not depend on a special hardware driver, so while this might be true for kwin it's not for many other apps. Just consider the bug named kwin-intel - each of the duplicates is about 2 min work. Each of the duplicates is set by a developer. Each of the duplicates is simple user support. Nothing the developers can do about, but users support was possible (use a workaround or switch to a distribution not shipping broken drivers and failing to fix it in the complete cycle given that the patches exist). Most users do not like reporting bugs and thus ask somewhere else first – and only after that, if at all, they report an issue. this is clearly not the case with DrKonqui. They just report Dr.Konqui is mainly about crashes, I'd guess that most bugs in bko are not crashes. And they do ask does sombody else get a crash when…. The majority of users only complains about the buggy piece of software without reporting any issues. So only if they get no answer on IRC, a forum a mailinglist etc. they leave their issue with the developer at bugzilla to document it and wait for an answer. no, I would even deny that they wait for an answer. Please do a search for WAITINGFORANSWER on the KWin product (I need to add that to my statistics). What you miss is that most of your users do not even have a bko account. Hence most of your users never report a bug but give-up before that. Yet it's true that the longer it takes until they get the first answer the lower the chance to get some feedback because they have already worked around the issue or given-up. Leaving the user without answer will not increase KDE's reputation. Thus the discussion should not be about how to restrict user access to bugzilla but rather how to help them before they feel the need to report at bugzilla. Filling out those forms is nothing users like to do. agreed. The proper way has to be to not let users enter support questions into the bugzilla. My perfect scenario is: a) first level support to help users b) if first level support cannot help it goes to second level support c) second level support identifies the important information from first level support, verifies that there is no bug reported yet and reports bug d) developers can concentrate on fixing that bug in case of KWin that would mean that we get all relevant informations without asking for it: * distribution * version (in case not default of distribution, how installed) * which compositing backend is use * which effects are used * which effects are active when the problem occurs * hardware * driver/version for that hardware * glxinfo -l output Consider that we have to ask again and again for all those things to find out in the end that it is a known issue with $foo driver in combination with $bar feature. All these things could so easily be handled by a first level support. Most of that could easily be handled by a script the user runs and whose output he attaches to the bug report. I would guess you could have saved a lot of time and you would have enabled people on the forums to point users to that script before reporting bugs. But to get there the bugtracker has to be closed and *cleaned*. Drop all bugs - nothing useful in it anyway. That claim is rubbish because it would mean that nobody can report any useful bug report for any app in bko. Which is obviously wrong. It would also mean that either KDE devs do not report bugs or are themselves not capable of creating useful bug reports. Sven
Re: bugzilla situation
Am Freitag, 24. Februar 2012, 18:51:11 schrieb Martin Gräßlin: 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 aman...@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
Re: Re: bugzilla situation
On Friday 24 February 2012 19:11:12 Sven Burmeister wrote: Am Freitag, 24. Februar 2012, 08:06:41 schrieb Martin Gräßlin: My claim is that most of that user support only ends-up in bugzilla because people did not get help somewhere else, e.g. because only developers are familiar enough with the code to understand the issue. No, that is clearly not the case and it's not the case that the users are searching for user support. It is they have a problem and consider it a bug. Maybe it's different for kwin but what I see is: User asking on distro/KDE mailinglist/forum/IRC because xyz does not work. 1. he gets an answer 1.1 known bug 1.2 me too - the user might open a bug report 1.3 it works like this… 2. he does not get an answer 2.1) frustrated and no bug report 2.2) frustrated and bug report which sounds exactly like first level support which needs to become better so that point 2 never happens and point 1.2 is not handled by the user. Think about how awesome it is to get the feedback that the task has been delegated to the developers for further investigation :-) They don't know, that: * they just didn't find that damn config option * they have installed the wrong driver/distro/whatever * how to circumvent that stupid driver crash * many many more things which turn out to be user support (interesting side node: the second most often reported bug against KWin is Compiz crashing. That says all about the usefulnes of reports) Well, most other apps do not depend on a special hardware driver, so while this might be true for kwin it's not for many other apps. remove the hardware specific thing and I'm quite sure that it holds for almost all applications. Just consider the bug named kwin-intel - each of the duplicates is about 2 min work. Each of the duplicates is set by a developer. Each of the duplicates is simple user support. Nothing the developers can do about, but users support was possible (use a workaround or switch to a distribution not shipping broken drivers and failing to fix it in the complete cycle given that the patches exist). Most users do not like reporting bugs and thus ask somewhere else first – and only after that, if at all, they report an issue. this is clearly not the case with DrKonqui. They just report Dr.Konqui is mainly about crashes, I'd guess that most bugs in bko are not crashes. And they do ask does sombody else get a crash when…. For 2011 in KWin: 452 reported crashes, compared to 824 reported bugs from which only 213 were no spam. 42 crashers were not marked as duplicates. So for kwin more than the half of all reports are crashers. Well in 2011 there was the mentioned kwin-intel problem on Ubuntu. The majority of users only complains about the buggy piece of software without reporting any issues. So only if they get no answer on IRC, a forum a mailinglist etc. they leave their issue with the developer at bugzilla to document it and wait for an answer. no, I would even deny that they wait for an answer. Please do a search for WAITINGFORANSWER on the KWin product (I need to add that to my statistics). What you miss is that most of your users do not even have a bko account. Hence most of your users never report a bug but give-up before that. yes it's true. I consider that at least 100 users have the same problem per reported bug. Yet it's true that the longer it takes until they get the first answer the lower the chance to get some feedback because they have already worked around the issue or given-up. in kwin we are normaly able to answer in hours :-) Leaving the user without answer will not increase KDE's reputation. Thus the discussion should not be about how to restrict user access to bugzilla but rather how to help them before they feel the need to report at bugzilla. Filling out those forms is nothing users like to do. agreed. The proper way has to be to not let users enter support questions into the bugzilla. My perfect scenario is: a) first level support to help users b) if first level support cannot help it goes to second level support c) second level support identifies the important information from first level support, verifies that there is no bug reported yet and reports bug d) developers can concentrate on fixing that bug in case of KWin that would mean that we get all relevant informations without asking for it: * distribution * version (in case not default of distribution, how installed) * which compositing backend is use * which effects are used * which effects are active when the problem occurs * hardware * driver/version for that hardware * glxinfo -l output Consider that we have to ask again and again for all those things to find out in the end that it is a known issue with $foo driver in combination with $bar feature. All these things could so easily be handled by a first level support.
Re: bugzilla situation
On Friday, February 24, 2012 06:51:11 PM Martin Gräßlin wrote: - 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. Fair enough, good solution, but with an if. If you have a team who does the filtering. If you don't have, you did nothing. Also this can be done just as fine in bugzilla, no need for a forum or else, by using a state for the bug (checked, confirmed, new whatever) and the developer can look only to the filtered list. But you must have people to do it. If your project doesn't have them, restricting reporting will not help at all. And then the developers are in first line. And this is true for many parts of KDE, as big teams - especially mixed developer and support persons - are not that common at all. What we need is people, but unfortunately this kind of task doesn't really attract contributors. Andras
Re: Re: bugzilla situation
On Friday 24 February 2012 19:27:09 Sven Burmeister wrote: 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. I doubt that there are enough people for doing first-level support. Hence it falls back on the devs, at least on those areas where nobody else has the knowledge/time to do so. I'd love to do first level support. But only in tools which are suited for first level support. I don't want to do first level support on bugzilla - it is just not suited for it. If we get the user support out of bko, I'm happy to help and moderate the KWin subforum on forum.kde.org. If people who know how to get the info and what info is needed cannot be bothered to document and spread it, how are users or first-level supporters supposed to know and act? And how can those devs be surprised that their ratio of useless bug reports is high? It's clearly a circle. Due to the fact that the ratio on bko is so bad, I don't have the time to help improving the first-level-support. Because first- level-support is bad the ratio on bko is bad. We have to break that circle. Getting the first-level-support out of bko will give the developers the time to work on preparing documents. It gives first- level-supporters the possibility to demand those documents. I'm quite into my stuff and probably I'm not the best one to design first-level-support documents, but others could tell me which info they need. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: bugzilla situation
On Fri, Feb 24, 2012 at 8:44 AM, Andras Mantia aman...@kde.org wrote: On Thursday, February 23, 2012 04:57:16 PM David Edmundson wrote: First of all, the bugzilla is supposed to be a communication tool between the user and the developer. Or is it? If I understand Martin correctly, he wants bugzilla to be a list of things broken in my app, not a communication tool for every user who wants to say something. Bugzilla is not a to-do list, it is for what else... a bug (and wishlist) reporting tool for users. If you wish to organize your tasks, I'm afraid you should do in another tool. No, that's one possible what bugzilla is for. My point is that everyone has slightly different expectations of what B.K.O should be for, and no one opinion can be deemed as correct. There are clearly two different of opinions on this thread it's a user tool, it's a developer tool, these conflict and is the root of all the discussion here. Dave
Re: bugzilla situation
On Friday, February 24, 2012 07:28:33 PM Martin Gräßlin wrote: User asking on distro/KDE mailinglist/forum/IRC because xyz does not work. 1. he gets an answer 1.1 known bug 1.2 me too - the user might open a bug report 1.3 it works like this… 2. he does not get an answer 2.1) frustrated and no bug report 2.2) frustrated and bug report which sounds exactly like first level support which needs to become better so that point 2 never happens and point 1.2 is not handled by the user. Think about how awesome it is to get the feedback that the task has been delegated to the developers for further investigation :-) So, do you have a community around KWin who could do that? Do you have a user mailing list (lists.kde.org doesn't show any), a user forum, where someone with knowledge can help the users? If not, no surprise that the only entry for users is bugzilla. Andras
Re: Re: bugzilla situation
On Friday 24 February 2012 20:31:46 Andras Mantia wrote: On Friday, February 24, 2012 06:51:11 PM Martin Gräßlin wrote: - 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. Fair enough, good solution, but with an if. If you have a team who does the filtering. If you don't have, you did nothing. Also this can be done just as fine in bugzilla, no need for a forum or else, by using a state for the bug (checked, confirmed, new whatever) and the developer can look only to the filtered list. bugzilla s***s at filtering. I just refer to Thomas's mail about all the issues we have in bugzilla (for KWin) because it's not filtered and cannot be moderated. It's just the wrong tool for user support and I understand everybody who does not want to do usersupport through bugzilla. (one of my favorite moderation feature is bug confirmed by popular vote - great thing to destroy the NEW state) Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: bugzilla situation
On Thursday, February 23, 2012 11:57:16 AM David Edmundson wrote: First of all, the bugzilla is supposed to be a communication tool between the user and the developer. Or is it? If I understand Martin correctly, he wants bugzilla to be a list of things broken in my app, not a communication tool for every user who wants to say something. In KDE Telepathy we use bugzilla as a glorified TODO list which I consult every time I need to check what I should spend my evening doing. I personally am perfectly happy with users posting bugs we need to fix, but get really annoyed at users posting completely mental wishlist ideas without any sort of prior communication first or filtering process. So our bugzilla is full of entries that we, as a team, haven't agreed on implementing, rendering it extremely annoying for our purposes. I don't think this discussion of how bugzilla should operate can really get anywhere until there's a consensus of what is bugzilla actually for? as there are a range of different views. I think each of the use cases of bugzilla needs to be addressed in turn, identifying whether bugzilla is in fact the right place for that task. Random, possibly entirely unhelpful suggestion: Perhaps using our redmine install of projects.kde.org for this kind of task tracking? I'd love to see p.k.o be used as something more of a central place for devs to get together and collaborate. I keep track of all my phonon tasks in my head or community.kde.org, which is terribly inefficient. Yet, I feel it is better suited than bugzilla. Dave -- Trever Fischer (tdfischer) Fedora Ambassador, KDE Hacker http://wm161.net GPG: C40F2998 hkp://wwwkeys.pgp.net signature.asc Description: This is a digitally signed message part.
Re: bugzilla situation
On Fri, Feb 24, 2012 at 11:41 AM, Kevin Ottens er...@kde.org wrote: On Thursday 23 February 2012 17:39:12 Trever Fischer wrote: Random, possibly entirely unhelpful suggestion: Perhaps using our redmine install of projects.kde.org for this kind of task tracking? I'd love to see p.k.o be used as something more of a central place for devs to get together and collaborate. I keep track of all my phonon tasks in my head or community.kde.org, which is terribly inefficient. Yet, I feel it is better suited than bugzilla. Yes, I'd love to have bugzilla for user support and p.k.o for managing my projects roadmap and tasks (and so developers centric). As far as I know there's even a way to link a bugzilla entry to a redm^Wchiliproject ticket which would come in handy for those high quality long term bugs you've to take care of while roadmapping. With an akonadi resource talking to it on top talking to ChiliProject it'd be heaven on earth. :-) Sysadmin is not permitting the task tracking abilities of KDE Projects to be used at the moment, as it is not possible to effectively use a bug tracker when different projects are using different trackers. As for using it for Task tracking for internal development use, that is a little hard - as we couldn't limit it to only developers due to limitations in the Chiliproject groups system (it can't handle groups of 2000+ members very well at all) - not to mention that this could possibly be seen as a split bug tracker Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com Regards, Ben
Re: bugzilla situation
Am Mittwoch, 22. Februar 2012, 12:38:38 schrieb Antonis Tsiapaliokas: For e.x., someone is a core developer, someone is on release team or someone else is a sysadmin and some others are taking critical decisions about the feature of KDE. I don't think that neither of them was there where he is now from it's first day of KDE. So in my opinion some privileges must be earned, in order to be able to communicate better and faster. Earning the privilege to report bugs? Forcing users to subscribe to a mailinglist or wait for hours on some IRC channel? Seriously? I have come across lots of occasions where people did not get a reply on IRC or were told on a mailinglist that bugs should be reported at bugzilla. A lot of KDE is released as rather untested software, compared to software you pay for. Part of the deal with users is that they do not expect the same kind of QA before code gets released as one would for paid software and that they act as the testers software companies usually have to pay for. You get testers for free and do not have to do QA at the level of paid software but you still want them to earn the privilege to report bugs without offering a smarter alternative than to keep them away from bugzilla? Of course a lot of people are not on the technical level to report perfect bug reports, but that's the price you have to pay if you do not want to pay professional testers. If you want to get rid of dead bug reports be smarter than complaining about your users. Sven
Re: bugzilla situation
Am Mittwoch, 22. Februar 2012, 19:00:26 schrieb Martin Gräßlin: Personally I'm not sure whether the MeeGo bugzilla can be compared to the KDE one (technical oriented vs. user oriented). From my personal experience (KWin bugtracker is felt 90 % a user support forum) My claim is that most of that user support only ends-up in bugzilla because people did not get help somewhere else, e.g. because only developers are familiar enough with the code to understand the issue. Most users do not like reporting bugs and thus ask somewhere else first – and only after that, if at all, they report an issue. The majority of users only complains about the buggy piece of software without reporting any issues. So only if they get no answer on IRC, a forum a mailinglist etc. they leave their issue with the developer at bugzilla to document it and wait for an answer. Leaving the user without answer will not increase KDE's reputation. Thus the discussion should not be about how to restrict user access to bugzilla but rather how to help them before they feel the need to report at bugzilla. Filling out those forms is nothing users like to do. I would not allow users to edit/close all bugs. We have too many users who report bugs, get it set to WONTFIX/INVALID and just reopen it. If I now imagine that everyone would be allowed to do so... If one wants users to keep reports up-to-date one should e.g. allow them to edit any bug report's version fields. Sven
Re: Re: bugzilla situation
On Friday 24 February 2012 02:15:54 Sven Burmeister wrote: Am Mittwoch, 22. Februar 2012, 19:00:26 schrieb Martin Gräßlin: Personally I'm not sure whether the MeeGo bugzilla can be compared to the KDE one (technical oriented vs. user oriented). From my personal experience (KWin bugtracker is felt 90 % a user support forum) My claim is that most of that user support only ends-up in bugzilla because people did not get help somewhere else, e.g. because only developers are familiar enough with the code to understand the issue. No, that is clearly not the case and it's not the case that the users are searching for user support. It is they have a problem and consider it a bug. They don't know, that: * they just didn't find that damn config option * they have installed the wrong driver/distro/whatever * how to circumvent that stupid driver crash * many many more things which turn out to be user support (interesting side node: the second most often reported bug against KWin is Compiz crashing. That says all about the usefulnes of reports) and that's what first level support is actually for: filtering the noise so that only the real bugs get through. Just consider the bug named kwin-intel - each of the duplicates is about 2 min work. Each of the duplicates is set by a developer. Each of the duplicates is simple user support. Nothing the developers can do about, but users support was possible (use a workaround or switch to a distribution not shipping broken drivers and failing to fix it in the complete cycle given that the patches exist). Most users do not like reporting bugs and thus ask somewhere else first – and only after that, if at all, they report an issue. this is clearly not the case with DrKonqui. They just report The majority of users only complains about the buggy piece of software without reporting any issues. So only if they get no answer on IRC, a forum a mailinglist etc. they leave their issue with the developer at bugzilla to document it and wait for an answer. no, I would even deny that they wait for an answer. Please do a search for WAITINGFORANSWER on the KWin product (I need to add that to my statistics). Leaving the user without answer will not increase KDE's reputation. Thus the discussion should not be about how to restrict user access to bugzilla but rather how to help them before they feel the need to report at bugzilla. Filling out those forms is nothing users like to do. agreed. The proper way has to be to not let users enter support questions into the bugzilla. My perfect scenario is: a) first level support to help users b) if first level support cannot help it goes to second level support c) second level support identifies the important information from first level support, verifies that there is no bug reported yet and reports bug d) developers can concentrate on fixing that bug in case of KWin that would mean that we get all relevant informations without asking for it: * distribution * version (in case not default of distribution, how installed) * which compositing backend is use * which effects are used * which effects are active when the problem occurs * hardware * driver/version for that hardware * glxinfo -l output Consider that we have to ask again and again for all those things to find out in the end that it is a known issue with $foo driver in combination with $bar feature. All these things could so easily be handled by a first level support. But to get there the bugtracker has to be closed and *cleaned*. Drop all bugs - nothing useful in it anyway. I would not allow users to edit/close all bugs. We have too many users who report bugs, get it set to WONTFIX/INVALID and just reopen it. If I now imagine that everyone would be allowed to do so... If one wants users to keep reports up-to-date one should e.g. allow them to edit any bug report's version fields. yes that might make sense to allow them to change the version field. But in the scenario outlined above it would not be needed as the second level support already entered it correctly. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: bugzilla situation
On Wednesday 22 February 2012 16:15:45 Giorgos Tsiapaliwkas wrote: Hello, Toma's blog posthttp://www.omat.nl/2012/02/18/sysadmin-needs-help-with-bugzilla-instal lation/ inspired me to send you this mail. Right now our bugzilla is a mess. We have so many bug entries which we can't handle. Everyone is able to open a new bug, but only a few people are able to triage them. Most of the bugs are useless(duplicates and wishes). The true bugs are very few and most of them are being lost by the massive amount of open bugs. With such a mess on the bugzilla we are not able to coordinate our work using it. Our projects have different needs, that's why they differ from each other(ML etc). Every project should be able to choose if everyone will be able to open a new bug or not. In case that a user finds a true bug, he can go to the project's irc and to ask from someone to open the new bug. Doesn't sound very open The alternative is the opposite: allowing everyone to edit/move/close bugs. I'm told this is how some other projects do it, and they say it's working well in practice. He asked me why we don't do this, and the only reply I could come up with was the few cases where bugs turned into actual political flamewars; his answer was obviously give rights to everyone, and remove rights when someone abuses them. This is also what we do for SVN/GIT, so why don't we do this for bugzilla? Presuming people are innocent upfront, rather than guilty ;) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
Re: bugzilla situation
On Wed, Feb 22, 2012 at 4:11 PM, David Faure fa...@kde.org wrote: give rights to everyone, and remove rights when someone abuses them. This is also what we do for SVN/GIT, so why don't we do this for bugzilla? Presuming people are innocent upfront, rather than guilty What we do for SVN/Git is to give rights not to everyone, but to everyone who cares to ask. A certain very low barrier may help to keep out people who intend to act in the heat of the moment. Plus new SCM accounts need a supporter. Greetings Stefan
Re: bugzilla situation
On Wednesday 22 February 2012 11:57:25 Parker Coates wrote: On Wed, Feb 22, 2012 at 10:23, Stefan Majewsky wrote: On Wed, Feb 22, 2012 at 4:11 PM, David Faure wrote: give rights to everyone, and remove rights when someone abuses them. This is also what we do for SVN/GIT, so why don't we do this for bugzilla? Presuming people are innocent upfront, rather than guilty What we do for SVN/Git is to give rights not to everyone, but to everyone who cares to ask. A certain very low barrier may help to keep out people who intend to act in the heat of the moment. Plus new SCM accounts need a supporter. Applicants for a developer account are also required give their real name. While this can easily be faked, I think that step has the psychological effect of implied responsibility. Someone is less likely to do deliberately stupid things if they do so under their own name than they are when calling themselves turdNINJA1988. OK, so forget the parallelism with SVN/GIT accounts. The suggestion remains: to allow everyone to edit and close bugs, as is apparently the case in some other bug trackers. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
Re: bugzilla situation
The suggestion remains: to allow everyone to edit and close bugs, as is apparently the case in some other bug trackers. +1. Worked fine on the MeeGo bugzilla for instance, I previously used. Best Regards, Laszlo Papp
Re: bugzilla situation
Am 22.02.2012 18:13, schrieb Laszlo Papp: The suggestion remains: to allow everyone to edit and close bugs, as is apparently the case in some other bug trackers. +1. Worked fine on the MeeGo bugzilla for instance, I previously used. Personally I'm not sure whether the MeeGo bugzilla can be compared to the KDE one (technical oriented vs. user oriented). From my personal experience (KWin bugtracker is felt 90 % a user support forum) I would not allow users to edit/close all bugs. We have too many users who report bugs, get it set to WONTFIX/INVALID and just reopen it. If I now imagine that everyone would be allowed to do so... Also I clearly don't want that people can change product or confirm bugs - that is something I like to see people doing where I know that I can trust them. Funny site note: I find it annoying that bugs reported by other developers are opened as NEW instead of UNCONFIRMED. I really like the idea of giving further rights to users who care. That is there are enough users in the bugtracker where you very fast notice that they are capable of doing bug tracking work. Helping them to become a triager - maybe just by sending a mail do you want more rights - might bring us quite some help in that area. Cheers Martin
Re: bugzilla situation
On Wednesday, February 22, 2012 07:00:26 PM Martin Gräßlin wrote: Am 22.02.2012 18:13, schrieb Laszlo Papp: The suggestion remains: to allow everyone to edit and close bugs, as is apparently the case in some other bug trackers. +1. Worked fine on the MeeGo bugzilla for instance, I previously used. Personally I'm not sure whether the MeeGo bugzilla can be compared to the KDE one (technical oriented vs. user oriented). From my personal experience (KWin bugtracker is felt 90 % a user support forum) I would not allow users to edit/close all bugs. We have too many users who report bugs, get it set to WONTFIX/INVALID and just reopen it. If I now imagine that everyone would be allowed to do so... Also I clearly don't want that people can change product or confirm bugs - that is something I like to see people doing where I know that I can trust them. Funny site note: I find it annoying that bugs reported by other developers are opened as NEW instead of UNCONFIRMED. I really like the idea of giving further rights to users who care. That is there are enough users in the bugtracker where you very fast notice that they are capable of doing bug tracking work. Helping them to become a triager - maybe just by sending a mail do you want more rights - might bring us quite some help in that area. I'm willing to invest some time in doing this kind of thing, but it wasn't obvoius to me how to go about getting rights to do it. Scott K
Re: bugzilla situation
Am 22.02.2012, 16:11 Uhr, schrieb David Faure fa...@kde.org: In case that a user finds a true bug, he can go to the project's irc and to ask from someone to open the new bug. Doesn't sound very open [Disclaimer: Describing a custom, proprietary and vastly expensive system ;-) No promotion, just laying out how it works] 3 stage system: -- 1. stage and ONLY entrance point for every user is some sort of info center. Whether approached by mail, irc or web frontend, the user always ends up in the same system. On the other side are the dispatchers - the only requirement and task is to direct the issue to the -assumed- correct component. 2. stage is a helpdesk (by component). Requirement is some more experience in using the component, task is to -guess what- help the user or direct them to the component (core) developers. DISCUSSIONS HAPPEN HERE 3. stage is the bugtracker itself. In a way it's a tasklist for development. Only (core) component developers can file a ticket here and unlike all previous communication, this one is really permanent (the other two stages have a lifetime of a month. What wasn't staged in this timeframe has to be retriggered) To prevent flamewars on this stage, only component developers, the original reporter and the components helpdesk team can comment (in doubt on behalf of later reporters) === === That however doesn't cover crashes at all === === From my experience, the greatest gift - and pain - is Dr.Konqi. Users encounter crashes (bad enough), press the report button (very good user behavior) and Dr. Konqi either files a bug, a dupe or a bug with dupe suggests. The problem here is that this has the potential to vastly reduce entropy: Have a look at bug #252817 Try to figure the relevant information (yes, it's about the worst example i know ;-) As a user, being attached to this bug helps and tells you nothing. You wanted to know: - a) is this my bug? b) why does it happen? c) does it happen to only me? d) what can i do to prevent it / help fixing it. You got: -- - weird lines with weird numbers - *** Bug 123456 has been marked as a duplicate of this bug. *** - Created an attachment (id=12345) [details] New crash information added by DrKonqi [ more weird lines and numbers ] There's actually some very relevant information in this bugreport, you'll just have a hard time to find it - even if you know what you're looking for. There's of course good reason to keep duplicate references as well as additional backtraces (could be helpful) but there's absolutely no point in visualizing that stuff (at least not by default) - it's not even possible to shadow that stuff by some userstyle css. As a result nearly every *** Bug 123456 has been marked as a duplicate of this bug. *** line has a comment and explanation to it on the other side of the dupe (Intel driver bug, uncheck Suspend compositing for fullscreen windows in kcmshell4 kwincompositing, 3rd tab) - good for the user who reported the dupe and was not duped by Dr.Konqui or just found this bug otherwise. === Suggestions - a) the component maintainer can block (and unblock) bugs against Dr.Konqi resulting in kfmclient openURL 'http://bugs.kde.org/show_bug.cgi?id=123456' b) duplicates are stored and can be queried but are no way part of the plain view on the bug c) leading to has been marked as is mailed to the bug assignees but NOT posted to the bug d) as long as a bug is marked a dupe, it is not possible to post to it, neither by mail, web or Dr.Konqi e) Every bug (esp. those resulting from crashreports) comes with a sticky which can be edited any time by the maintainer to provide a summary, so the first thing the user sees is no weird lines with weird numbers I however don't know whether bugzilla can do this. Cheers, Thomas
Re: bugzilla situation
On Wed, Feb 22, 2012 at 7:11 AM, David Faure fa...@kde.org wrote: Doesn't sound very open -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 First of all, the bugzilla is supposed to be a communication tool between the user and the developer. And the fact that there are a lot of bug reports which are not real, this actually worse.And because of that of that, the bugzilla has lost his usability. On the best case scenario, 5/10 bug reports are real. Also in a lot of bugs, users or even contributors, cannot find the real cause of a bug. Imagine what will happen if everyone has write access to the bugzilla. Furthermore, in most of the bug reports, users are reporting them and then they never look back to see what happened with that bug. E.x. Is it reproducible in the newest version of KDE?. And based on that fact i guess that if there was a bug that was very important, then they (the users) was going to contact with that team through irc or using the ML. So i guess that they can live with that... Also each team of KDE has a different target group. And that is very important, because: For e.x. everyone is using the PLASMA and KWIN, and as a result of that the target group is very big. The reporter could be a developer,a contributor,an end user or a power user. So in scale from 1 to 10, a bug report take 3 or 5 or 7 etc. But on a team like the kdelibs, only contributors or developers are reporting bugs. So there you know that 8/10 bug reports will be useful. Nobody said that the bugzilla must be more close. That which has been said, is that every user who is opening a bug report, needs about 5-10 (max 15), to report a bug which is going to be 100% true. but instead of that they skip almost everything and they only write a very small description of the bug. So if they cannot spend 15 minutes of their life, then how do they expect from the developer to spend half an hour or even more to fix the bug... the 99% of KDE developers, are volunteers, and each one of them has a different role on KDE. For e.x., someone is a core developer, someone is on release team or someone else is a sysadmin and some others are taking critical decisions about the feature of KDE. I don't think that neither of them was there where he is now from it's first day of KDE. So in my opinion some privileges must be earned, in order to be able to communicate better and faster. Cheers
Re: bugzilla situation
On Wednesday, February 22, 2012 04:11:57 PM David Faure wrote: He asked me why we don't do this, and the only reply I could come up with was the few cases where bugs turned into actual political flamewars; his answer was obviously give rights to everyone, and remove rights when someone abuses them. I like the idea. Andras
