After filing a ticket, an Importance field displays. For most tickets, its value is displayed as "NOR normal". It is unclear what that means. Clicking the link on the Importance label brings to https://bugs.kde.org/page.cgi?id=fields.html#importance which explains: > The importance of a bug is described as the combination of its Priority and Severity. Unfortunately, there is nothing more explaining how that combination is done. One possible interpretation is that the field simply displays together 2 ticket properties. Unless the definition is very misleading, that would mean that "NOR" would be the ticket's Priority, and "normal" would be its Severity. The Priority property is described below: > Engineers prioritize their bugs using this field. And Severity is described even lower: > How severe the bug is, or whether it's an enhancement. If my understanding is correct, please: 1. Call Importance a computed field, or otherwise make it clear that it does not display a fundamental ticket property. 2. Specify the Priority field (don't just say what specific people do with it, but explain what values it contains (what does "NOR", for instance, mean). If my understanding is correct, I would also recommend just clarifying the interface (possibly just display these 2 properties in different fields).
I forgot to say... if the understanding I described is correct, another reason why Importance is so unclear is that... it really makes no sense. Normally, "severity and "importance" are synonymous in issue trackers (except that "Importance" is more general, as "severity" only applies to bugs). Worse, normally, it is "priority" which is a combining field (combining difficulty/cost and importance). So, if this is solved by fixing the interface and both properties are kept together, "Priority" would be a better name than "Importance".
What is unclear about "Engineers prioritize their bugs using this field"? The importance field is for the developers so that they can order the bugs in the way they see the need to be fixed. There is no need for users to mess with Alias, Importance, Target, Assignee, Keywords, Depends on, Blocks, Latest Commit, Version Fixed In, and Flags fields. Are you going to report a ticket for each field where you don't understand why they are there? Are you asking why users are able to change them? (Answer: we really only wanted to simplify the life of those that want to help triaging bugs.) Are you reporting all these issues because you want us to swap out Bugzilla for the "modern" options? Bugzilla has served us well the last 20 years, and we get plenty of bug reports. There is no need to invite all but the last user. If your intention is rather to improve Bugzilla, I suggest to report issues directly to Bugzilla developers. KDE sysadmins don't have the resources to maintain their own fork of Bugzilla, so issues really need to be tackled upstream.
Christoph's answer is correct. You don't need to understand 100% of everything you see to be able to use the bug tracker. :)
(In reply to Christoph Feck from comment #2) > What is unclear about "Engineers prioritize their bugs using this field"? No one claimed that was unclear. The problem is this doesn't define what the field contains (and has no clear relevance). Imagine I tell you about the Oumuamua field which my sister's school added. When you ask me what it contains, I tell you my sister and her colleagues use it to optimize their work. I then ask you what is the difference between records whose Oumuamua is A10 and those whose Oumuamua value is C1. How would you answer? > The importance field is for the developers so that they can order the bugs > in the way they see the need to be fixed. I guess you're talking about Priority here... but I'm not just asking for myself. > There is no need for users to mess with Alias, Importance, Target, Assignee, > Keywords, Depends on, Blocks, Latest Commit, Version Fixed In, and Flags > fields. I am not sure what is your point. > Are you going to report a ticket for each field where you don't understand > why they are there? I have no divination power, but I'm more likely to report unclear fields when they have a name which sounds relevant. > Are you asking why users are able to change them? No, obviously all fields need to be changed. What I am asking is to document what values mean. > [...] Are you reporting all these issues because you want us > to swap out Bugzilla for the "modern" options? Bugzilla has served us well > the last 20 years, and we get plenty of bug reports. There is no need to > invite all but the last user. I do not understand the last sentence. My goal is to improve bugs.kde.org. This specific issue can certainly be solved in Bugzilla, if it is a Bugzilla issue, or by forking Bugzilla. In general, there are several benefits in documenting issues as much as possible: 1. The cost of keeping Bugzilla is clearer. This means: A) The option of keeping Bugzilla can be compared more easily against alternatives (either moving to a different engine or creating one). B) In this case, if Bugzilla is kept, KDE could better decide whether it should finance a worker on the ITS, or offer a Google Summer of Code project on the ITS, for instance. 2. If Bugzilla is kept, part of the job has been done when issues are documented. 3. Until the issues are solved: 1. To select (or review) a product family of KDE's size, it can be necessary to evaluate not just issues, but issue metrics. These cannot be evaluated properly without a proper understanding of the issue tracker's quality. 2. Documenting issues and their workarounds reduces their impact on users. There are few free software ITS engines which target large umbrella organizations like KDE. Perhaps Redmine is an option, but I can only recommend evaluating it. There may be other options in the proprietary world, like Jira, but I haven't used it enough to recommend it neither. > If your intention is rather to improve Bugzilla, I suggest to report issues > directly to Bugzilla developers. KDE sysadmins don't have the resources to > maintain their own fork of Bugzilla, so issues really need to be tackled > upstream. My intention is merely to improve bugs.kde.org and document its status, but thank you. Hopefully this issue is not in Bugzilla, but if you think it is, you can file a ticket upstream and point this ticket to the one you create there. If this is a frequent issue, you could file tickets against bugs.kde.org asking: 1. That bugs.kde.org indicate its engine is Bugzilla. 2. That users reporting against bugs.kde.org be notified about the possibility of the issue coming from Bugzilla.
Nate, why was this issue marked as resolved?
(In reply to Filipus Klutiero from comment #4) > (In reply to Christoph Feck from comment #2) > > What is unclear about "Engineers prioritize their bugs using this field"? > > No one claimed that was unclear. The problem is this doesn't define what the > field contains (and has no clear relevance). Imagine I tell you about the > Oumuamua field which my sister's school added. When you ask me what it > contains, I tell you my sister and her colleagues use it to optimize their > work. I then ask you what is the difference between records whose Oumuamua > is A10 and those whose Oumuamua value is C1. How would you answer? Your excellent command of English leads me to believe you know what the word "Importance" means. I want a better bug reporting UI as much as anyone, but KDE's sysadmins are in the middle of the GitLab transition and there is no bandwidth available for improving Bugzilla at this point in time. After that, there are essentially two options: - Move from Bugzilla to GitLab issues - Upgrade out Bugzilla instance to a new version, which has a better UI Given those options it doesn't seem to make any sense to put resources into the current rather old Bugzilla instance.
FWIW, severity is documented at: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging#Set_Bugzilla_fields At one point we did also have this in our bugzilla instance in the page you're referring to, but maintaining the templates separately of upstream is a hassle.
(In reply to Nate Graham from comment #6) > (In reply to Filipus Klutiero from comment #4) > > (In reply to Christoph Feck from comment #2) > > > What is unclear about "Engineers prioritize their bugs using this field"? > > > > No one claimed that was unclear. The problem is this doesn't define what the > > field contains (and has no clear relevance). Imagine I tell you about the > > Oumuamua field which my sister's school added. When you ask me what it > > contains, I tell you my sister and her colleagues use it to optimize their > > work. I then ask you what is the difference between records whose Oumuamua > > is A10 and those whose Oumuamua value is C1. How would you answer? > Your excellent command of English leads me to believe you know what the word > "Importance" means. Alright. In that case, imagine the school's student list has a field called "Letter". Since you surely know what the word "letter" means, what is the difference between students with a Letter value of A10 and those whose Letter value is C1? (Here's a hint: the school's teachers evaluate students using this field.) > I want a better bug reporting UI as much as anyone, but KDE's sysadmins are > in the middle of the GitLab transition and there is no bandwidth available > for improving Bugzilla at this point in time. After that, there are > essentially two options: > - Move from Bugzilla to GitLab issues > - Upgrade out Bugzilla instance to a new version, which has a better UI > > Given those options it doesn't seem to make any sense to put resources into > the current rather old Bugzilla instance. There is unfortunately no new version of Bugzilla. Any of the options you mentioned will take a lot of time to implement if it is chosen. In the meantime, rather than discouraging any request for improvement in the Bugzilla path, I recommend you add a warning to reporters against bugs.kde.org, with a link to more information on your prediction. In any case, if you are implying that a future Bugzilla version already has this issue solved, please indicate so explicitly.
(In reply to David Edmundson from comment #7) > FWIW, severity is documented at: > > https://community.kde.org/Guidelines_and_HOWTOs/ > Bug_triaging#Set_Bugzilla_fields In case that wasn't clear, this report is not specifically about severity, but thank you David. > At one point we did also have this in our bugzilla instance in the page > you're referring to, but maintaining the templates separately of upstream is > a hassle. I do not know Bugzilla internals, so apologies if I'm missing something obvious, but I fail to see why maintaining templates separately would be more of a hassle than maintaining wiki pages separately. Unless you just mean write access to that wiki are wider than to the templates (which would be unfortunate).
>I recommend you add a warning to reporters against bugs.kde.org, with a link to more information on your prediction Being overly dramatic has opposite effect. In any case this field is for triagers rather than end users. At worst it's some pointless noise on the screen that they can leave alone. >so apologies if I'm missing something obvious, Bugzilla supports locales, this wiki doesn't. So it's one changes as opposed to many. Bugzilla templates update every bugzilla release. Sometimes they're compatible, sometimes not.
(In reply to David Edmundson from comment #10) > >I recommend you add a warning to reporters against bugs.kde.org, with a link to more information on your prediction > > Being overly dramatic has opposite effect. Well, are you saying you find Nate's intervention dramatic? If not, I fail to see why a warning conveying the same information would have to be. > In any case this field is for triagers rather than end users. > At worst it's some pointless noise on the screen that they can leave alone. I wish it was, but this field is currently the only one which shows (somewhat) each ticket's importance, which is one of the most important issue properties. > >so apologies if I'm missing something obvious, > > Bugzilla supports locales, this wiki doesn't. So it's one changes as opposed > to many. Thanks for mentioning that consideration. But if that's the only problem, and if (as is visibly the case) we preferred to have definitions only in English, nothing prevents disabling translation for that template (or getting rid of outdated translations each update). And in any case, if this issue is upstream, I fail to see why it couldn't be solved there. > [...]