|Summary:||Make it easier to find components for common products|
|Product:||[Websites] bugs.kde.org||Reporter:||Brylie Christopher Oxley <brylie>|
|Component:||general||Assignee:||KDE sysadmins <sysadmin>|
|Severity:||wishlist||CC:||chealer, christophe, doncbugs, d_debnath, hvm2hvm, johannes.claesson, kermit, majewsky, nate, rulatir, serkonda7, sheedy|
|Latest Commit:||Version Fixed In:|
Description Brylie Christopher Oxley 2014-10-28 08:25:33 UTC
As a bug reporter, I would like to file a report without having to sort through a list of dozens of projects, So that I can file the bug quickly As a new user I would like to file a report without having to browse through a list of dozens of projects, So that I can simply file a bug report Problem ======= The current bug reporting workflow forces an end-user to choose among dozens of ambiguously named, loosly described projects. This is a blocker from the standpoint of a casual user, and a deterrent even for people with familiarity of the KDE ecosystem. Suggestion ========= Defer trove classification to the verification stage, e.g. need feedback, etc. At least the user will be able to capture the initial bug report, and the categorization, prioritization, etc. can commence as normal.
Comment 1 Christoph Feck 2014-10-28 12:19:35 UTC
Regarding new users, I do not see this as a problem. If someone picks the wrong product, we can reassign it. Additionally, many users simply use "kde" as the product, because they do not exactly know where the issue is. This has served us well in the last years. Not requiring the user to pick any product would increase our workload. Btw, I use "https://bugs.kde.org/enter_bug.cgi?product=productname" to report bugs. This way, I do not have to pick it from a large list.
Comment 2 Frédéric Sheedy 2014-10-28 12:31:57 UTC
I agree with Christoph
Comment 3 Christophe Marin 2014-10-29 10:55:52 UTC
Also note that for most graphical apps, Help / Report bug will open bugzilla and pick the current app by default.
Comment 4 Brylie Christopher Oxley 2014-10-29 11:04:32 UTC
Christopher, great idea :) We can set the issue project to KDE by default, and let more informed users choose a specific location. This way we can dispense with the lengthy, and ambiguous, project listing page, while still allowing for the specificity and categorization necessary for developers. Also, interesting method with product=product_name. You seem to be very knowledgeable about the KDE ecosystem and tooling.
Comment 5 Brylie Christopher Oxley 2014-10-29 11:06:46 UTC
Christophe, I agree that the graphical apps handle bug reporting effectively. Please note that this idea is specifically talking about the online bug reporting process: https://bugs.kde.org/enter_bug.cgi?format=guided
Comment 6 Brylie Christopher Oxley 2014-10-29 11:08:21 UTC
Christophe, also, I'm sorry for the initial misspelling of your name :)
Comment 7 Brylie Christopher Oxley 2014-10-29 11:09:33 UTC
Ah! Christoph ... and Christophe! Apologies. :)
Comment 8 Frédéric Sheedy 2014-11-14 18:47:31 UTC
If 'KDE' is put by default, I think that most users will not change it! This will result in more re-classification by developers?
Comment 9 Arek Guzinski 2016-02-12 15:29:35 UTC
While i agree that finding the product works well for a specific application, it does not for bugs that appear in multiple applications (aka bugs in the frameworks). This is made even worse by having kde 4&5 stuff mixed together. I propose the following changes: add a checkbox "show deprecated products" and/or add columns to the table, which show in which version of kde it is used add the Line "If you are unsure, choose kde" at the bottom of the table. This way it will be visible, after trying to find the right product, but not encourage people to use it every time. I remember that i did not file at least one bug in the past, because i could not find the right product and did not see the "kde" category. If you click the "search" link from https://bugs.kde.org/enter_bug.cgi?product=productname , the product should be preselected. sometimes i knew which api call causes a problem (through debug output, stack trace, alook into the applications source code, etc..). However, finding to which part of frameworks it belongs, is not that easy. it would be great if you could search for an api call. Or simply find the product name in the api reference.
Comment 10 Christophe Marin 2019-07-17 21:36:43 UTC
*** Bug 360400 has been marked as a duplicate of this bug. ***
Comment 11 Philippe Cloutier 2019-07-17 21:54:43 UTC
(In reply to Brylie Christopher Oxley from comment #7) > Ah! Christoph ... and Christophe! Apologies. :) Christoph, Christophe, Brylie Christopher... for Christ's sake, this is getting as confusing as KDE's product list! Thanks for reporting Brylie. Unfortunately as currently titled this ticket's scope is very wide. Would you mind if this ticket was re-titled to "Simplify filing the product/component part of tickets"? Anyone is free to open new tickets about other parts of the reporting process, of course.
Comment 12 Philippe Cloutier 2019-07-18 00:31:12 UTC
(In reply to Christoph Feck from comment #1) > Regarding new users, I do not see this as a problem. If someone picks the > wrong product, we can reassign it. You wouldn't be wrong to call me a perfectionist, but if I start filing a report and find myself unable to answer a question which mandates an answer, I will give up, not give an answer in which I'm not confident. I see 3 possible consequences of the current status: 1. Reporters waste excessive time determining the product, and may decide not to report further issues for that reason. 2. Reporters give up reporting the problem. 3. Reporters select the wrong product. If it takes time for developers to correct this, that means a duplicate ticket may be opened, again wasting reporter time. Or worst, it will take more time for product maintainers to be notified of the issue, which may be fixed late. > Additionally, many users simply use "kde" > as the product, because they do not exactly know where the issue is. This > has served us well in the last years. Thanks for bringing up this point. But I reported my first issue on this site in 2006, and I never knew that it was fine to select the kde product when the precise product is unknown. If you are saying that is the case: 1. It is not clear that the kde product is intended to be used this way. The product description is simply "General KDE Software problems". Does that mean problems which affect several applications, such as Qt issues? Is this intended for requests for new products? This is entirely unclear. 2. If it is fine to use the kde product this way, either: 1. Such usage should be split to a dedicated product, so triagers only have to monitor tickets in that product. 2. Or, if that's its only usage, it should be renamed to something clearer, like "unknown". 3. The duplicate finder should be taught that when filing an issue in that "unknown" pseudo-product, all products should be searched. Conversely, when filing an issue in a specific product, the "unknown" pseudo-product should be searched. 4. The pseudo-product to select when a reporter has too much difficulty identifying the precise product should be a lot more clear. It should be mentioned at the top, or even better - there should be an "I am not sure" button which allows to skip. > Not requiring the user to pick any product would increase our workload. That depends on who "we" are, and which work is being discussed. If "we" are KDE users: 1. Requiring to indicate the product largely increases the reporting workload for reporters. I have used KDE for over 15 years. I hit an issue after switching to Kubuntu 19.04 and to report it to KDE, even though I am a veteran user who spent several person-months developing KDE and helping KDE users, and even though I am a senior software developer who somewhat knows C++, I just had to spend over 1 person-day of work, just to figure out that the symptom actually resulted from 3 root issues, and locating each of these issues. Even with my level of knowledge way above the average reporter's, I am not convinced it was optimal for me to be the one doing all this work. 2. If reporters decide not to report, users will spend more time finding workarounds for the issues they hit. 3. If reporters decide not to report, resolution is delayed and users will waste more time dealing with the issues they hit. 4. If reporters refrain from reporting to KDE: 1. they will report to redistributors, which means reporters waste time filing duplicate issues. 2. potential users spend more time and/or have more difficulty evaluating the quality of KDE or specific KDE products before they pick KDE or choose between KDE products, as they do not have a complete database of issues to query. 5. If reporters decide to report on alternative channels, such as mailing lists, these channels are needlessly "polluted", which increases the time wasted by developers. 6. If reporters select the wrong product, as indicated above, other reporters may waste time filing a duplicate, and users may waste time with issues fixed later. > Btw, I use "https://bugs.kde.org/enter_bug.cgi?product=productname" to > report bugs. This way, I do not have to pick it from a large list. I am not sure what your point is. To use that, you need to know the "productname" (in fact, its codename in this ITS).
Comment 13 Nate Graham 2022-07-29 17:59:11 UTC
*** Bug 457259 has been marked as a duplicate of this bug. ***
Comment 14 Nate Graham 2022-09-02 17:37:36 UTC
*** Bug 448591 has been marked as a duplicate of this bug. ***
Comment 15 Nate Graham 2022-09-14 17:27:48 UTC
*** Bug 459076 has been marked as a duplicate of this bug. ***
Comment 16 Nate Graham 2022-09-20 04:48:55 UTC
This has now been done! See https://bugs.kde.org/enter_bug.cgi.
Comment 17 Nate Graham 2022-09-24 18:20:36 UTC
*** Bug 238608 has been marked as a duplicate of this bug. ***