On the fedora devel list in this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YMAFCCERFIB43FKZ2WTDI5DNR2O5UWPQ/ it's mentioned that users often just pick 0ad (the first entry in the component list) when they don't know what they should file against. Would it be possible to somehow promote the 'distribution' component to the top of the list ? Or would we have to rename it '00-distribution' or something? Also, might it be possible to just have 'distribution' in the component field by default in case they dont look at the entire list? Any other solutions welcome. Thanks
Hi, currently there isn't anyway to set a default component. Changing the name of the distribution component, or making a new aptly named component specifically for triaging, would be something the Fedora Infrastructure Team could do. Setting the default is something that could be done on the guided entry page for Fedora bugs [1] but doing it on the standard bug creation page would more difficult. We would have to create a new template specifically for Fedora bugs and hard code the component. There are already some templates for some Fedora products [2]. For that to be effective you'd basically have to force users creating fedora bugs to use the guided entry page, this isn't currently possible but is a minor change. FWIW I think that step one on that page isn't useful and should go, but that would have to be agreed by the Fedora project. At the least it should be like the standard bug entry page and wait until you start typing a summary. 1: https://bugzilla.redhat.com/enter_bug.cgi?format=guided&product=Fedora 2: https://pagure.io/Red-Hat-Bugzilla/rh-bugzilla/blob/master/f/extensions/RedHat/template/en/default/bug/create/
Maybe an option saying "Not sure", "I don't know" or "Unclear" could help.
What does "forcing" the guided entry mean, in practice? Does it mean that all calls to /enter_bug.cgi would go to the guided page for the Fedora product, even if a specific component is specified in the URL? For example, some documentation has a create bug link that has product=Fedora&component=thespecificcomponentwewantyoutofileabugagainst. If my search[1] is correct, only 47 Fedora bugs have been filed against 0ad and then re-assigned to other components in the last eight years. I'm not sure the scale of the problem is worth putting much effort into. [1] https://bugzilla.redhat.com/buglist.cgi?f1=component&list_id=11712829&o1=changedfrom&product=Fedora&query_format=advanced&v1=0ad
(In reply to Ben Cotton from comment #3) > What does "forcing" the guided entry mean, in practice? It's not defined yet :) > Does it mean that > all calls to /enter_bug.cgi would go to the guided page for the Fedora > product, even if a specific component is specified in the URL? For example, > some documentation has a create bug link that has > product=Fedora&component=thespecificcomponentwewantyoutofileabugagainst. It could do either, IMO the guided entry isn't any less appropriate if someone is just clicking a link someone else made. > If my search[1] is correct, only 47 Fedora bugs have been filed against 0ad > and then re-assigned to other components in the last eight years. I'm not > sure the scale of the problem is worth putting much effort into. Interesting, I wonder if it's an issue in other projects.
(In reply to Jeff Fearn π from comment #4) > (In reply to Ben Cotton from comment #3) > > If my search[1] is correct, only 47 Fedora bugs have been filed against 0ad > > and then re-assigned to other components in the last eight years. I'm not > > sure the scale of the problem is worth putting much effort into. > > Interesting, I wonder if it's an issue in other projects. Those 47 are just the bugs which were actually filed. I would presume that more bugs were not filed at all just due to the component not being known to the user. I know for a fact that when I begin to realize that I have no idea what to file the bug against, I often do not file the bug at all. Mainly when I am willing to invest 30 minutes, and it starts appearing that describing the bug takes me 5-10 minutes, and finding out the component to file against begins looking like a task of hours or days. (The bug might involve connected hardware devices, udev, hardware property databases, system wide services, user services, and a large set of Gnome components.) Obviously, I do not have recordings about the bugs I have not filed over the last 15 years, but it feels like I have opted to just not file a bug at all much more frequently than actually investing the time to find out.
I'm not sure there is anything we can practicably do here. If there is a default component many people will use it and this could create a significant triaging issue. One thing that would be possible to do is change the format of the drop down. Currently it shows the name, but if you hover over a component it shows the short description. If you select it it shows the long description. It would be possible to show the short description in the drop down, on a second row, lighter weight, etc. This would obviously make the drop down mush longer, but it might also add some context to help the user choose a component. You can see an example of a more complex drop down at https://selectize.dev/demos/2019/01/01/remote-source-github/
@agk should we go with the reformatted drop down? If not, any other ideas?
I wonder if adding a note to that screen saying something like: "If you are unsure what component to file your bug against, consider posting to ask.fedoraproject.org for advice" (that way we could move the triage off to ask instead of people misfiling?
This has sat here unloved for too long, here is what I am going to do. 1: Add a new guided template for Fedora* 2: Add a product level parameter to default to guided work flow 3: Enable the new setting on the Fedora product 4: Use the suggested component drop down change on the new template 5: Add a user setting to allow a user to override the new product setting (default: off) * The new template will be based on the existing guided template, with some Fedora specific text in it. e.g. https://bugzilla.redhat.com/enter_bug.cgi?format=guided&product=Fedora Besides the exact text to use, the issue for me is the duplicate bugs table ... it's ugly and slow. Should we try to improve that or just remove it? FYI guided bug entry is a UI thing, this won't affect the API at all.
(In reply to Jeff Fearn π from comment #10) > This has sat here unloved for too long, here is what I am going to do. I approve this message! > Besides the exact text to use, the issue for me is the duplicate bugs table > ... it's ugly and slow. Should we try to improve that or just remove it? I'm not sure it's particularly useful to most people. I'd be in favor of dropping it. I keep stats on the amount of duplicate bugs we get per release, so with the F38 release approaching, that serves as a good opportunity to see if dropping the table has a meaningful impact on duplicates. Science!
I'm holding off on implementing the user preference to skip the new form until it's basically complete. Then we can review the new form and determine if and when it'd be better to skip it. I need input on the text and layout changes desired. As I don't have a public test platform I'll attach some images of what I have so far ... apparently the Fedora logo I have is out of date, so just ignore that for now ^_^
Created attachment 1953837 [details] Top of form
Created attachment 1953838 [details] Bottom of form
Created attachment 1953840 [details] Modified component drop down layout
Thanks so much for working on this! :) A few random comments: * Does the search in the component field only match on component names? Could it also match on descriptions? Or would that cause too much trouble? * Can the fedora_pm group edit the contents of this if we want to change links/wording? Or is it something only you can change? * I'd suggest dropping severity entirely. It should be probably set by the maintainer(s), although we really don't use it much at all since anyone can set it. Thanks again.
(In reply to Kevin Fenzi from comment #16) > Thanks so much for working on this! :) > > A few random comments: > > * Does the search in the component field only match on component names? > Could it also match on descriptions? Or would that cause too much trouble? It matches on both. > * Can the fedora_pm group edit the contents of this if we want to change > links/wording? Or is it something only you can change? It's in the git repo so it needs to be merged by me, but anyone can see it and open an MR in pagure. e.g. like the non-responsive maintainer template. https://pagure.io/Red-Hat-Bugzilla/rh-bugzilla/blob/master/f/extensions/RedHat/template/en/default/bug/create/create-fedora-nonresponsive-maintainer.html.tmpl > * I'd suggest dropping severity entirely. It should be probably set by the > maintainer(s), although we really don't use it much at all since anyone can > set it. Severity is the external weighting of an issue, priority is the internal weighting. It's absolutely working as expected that external parties set severity, internal parties should set priority to reflect how they weigh the issue. e.g. it's perfectly acceptable for a user to think a bug is urgent but for the team responsible for addressing the issue to rate it as medium. Having them in separate fields is to allow differences of opinion to not overwrite each other. Who can set priority is governed by the editbugs right in the Product, currently this is granted to the community group on the Fedora product, so anyone in any other group in RHBZ can set it. We can remove it if that's desired.
I have changed the text for the severity field to make it's use clearer,it can still be removed if preferred. "Say how serious you think this bug is. When the bug has been triaged the priority field will be set to let you know how the team rates this bug."
I'm in favor of keeping severity and priority as they are. Severity gets set roughly a third of the time, but it's useful in doing analysis. See https://communityblog.fedoraproject.org/exploring-our-bugs-part-1-the-basics/ for example. I should add a comparison of severity and priority and see how often there's a mismatch. (In reply to Jeff Fearn π from comment #18) > "Say how serious you think this bug is. When the bug has been triaged the > priority field will be set to let you know how the team rates this bug." +1 to this text.
Great. All that looks good to me. I don't think many fedora maintainers use or set priority, but thats fine...
Hey Ben, time to discuss when you would wouldn't want to use the guided entry. IMO just setting the component isn't a good reason not to use the form. It will simply load with that field set. Also you mentioned the cf_type field. IMO this is a bad field, it's a subset of keywords. I think making keywords available on the form would be better. If there are some keywords you'd like to highlight to people then maybe we can do some check boxes or radios to present to them? hmm maybe have the keywords drop down and below it some check boxes for the "important" keywords and have checking them select and deselect them in the drop down. Shiny!
(In reply to Jeff Fearn π from comment #21) > Hey Ben, time to discuss when you would wouldn't want to use the guided > entry. > > IMO just setting the component isn't a good reason not to use the form. It > will simply load with that field set. I'm convinced about just setting the component not being a good reason to use it. I can't think of a specific case off the top of my head that we wouldn't. Anything that would potentially break is created through the API anyway, so it wouldn't be affected. > Also you mentioned the cf_type field. IMO this is a bad field, it's a subset > of keywords. I think making keywords available on the form would be better. My main argument for continuing to use that field is the historical value, but I just ran the stats through my Jupyter notebook and literally dozens of bugs have used that field at all. So losing history is no big deal here. > If there are some keywords you'd like to highlight to people then maybe we > can do some check boxes or radios to present to them? Looking at the Keywords that have been used, I don't see any that are both 1. common and 2. something we'd want the report to set in the general case (excluding security, but there's already a check box for that). Listing below for the curious (or if anyone in cc has a keyword they think should be called out) # For 163944 F19β34 bugs because I haven't gotten around to adding F35 yet used_keywords = [] for keyword in deduped_bugs["Keywords"]: for keywords in str(keyword).split(' '): used_keywords.append(keywords) sorted([[used_keywords.count(x),x] for x in set(used_keywords)], reverse=True) [[136337, 'nan'], [14491, 'Security'], [14378, 'SecurityTracking'], [8677, 'Reopened'], [3012, 'Triaged'], [685, 'Patch'], [558, 'Regression'], [395, 'FutureFeature'], [372, 'CommonBugs'], [294, 'i18n'], [292, 'EasyFix'], [164, 'Tracking'], [119, 'Upstream'], [70, 'Bugfix'], [58, 'UserExperience'], [48, 'Desktop'], [47, 'Translation'], [38, 'Documentation'], [32, 'SELinux'], [30, 'TestBlocker'], [30, 'Reproducer'], [26, 'MoveUpstream'], [22, 'Rebase'], [15, 'Upgrades'], [15, 'Extras'], [12, 'VerifiedUpstream'], [12, 'RFE'], [12, 'HardwareEnablement'], [8, 'OtherQA'], [8, 'Improvement'], [7, 'ManPageChange'], [7, 'BuildBlocker'], [6, 'screened'], [5, 'ZStream'], [5, 'TestCaseNotNeeded'], [5, 'Performance'], [5, 'ABIAssurance'], [4, 'WorkAround'], [4, 'TestCaseProvided'], [4, 'FastFix'], [3, 'Question'], [3, 'NeedsTestCase'], [3, 'DevelBlocker'], [3, 'BetaBlocker'], [3, 'AutomationBlocker'], [3, 'Automation'], [2, 'UserStory'], [2, 'UseCase'], [2, 'Unconfirmed'], [2, 'TestOnly'], [2, 'SupportQuestion'], [2, 'SubBug'], [2, 'Branch'], [2, 'AutomationBackLog'], [1, 'UpgradeBlocker'], [1, 'UpcomingRelease'], [1, 'TestCaseNeeded'], [1, 'Task'], [1, 'SubscriptionExperience'], [1, 'StudentProject'], [1, 'ManyUsersImpacted'], [1, 'InstallerIntegration'], [1, 'AutoVerified']]
Maintaining history is useful, but that should not exclude thinking about what you'd like to try adding to the process. e.g. Adding keywords isn't an obvious part of creating a bug using the default workflow. Are there a subset of keywords you'd like users to consider adding when opening a bug? If so how can we make it more intuitive than selecting them from the dirty big list of keywords? If there aren't any then I'll just commit what I have :)
Point taken. :-) Here are the ones that I can see being useful at creation-time by general users: Desktop Documentation --- so we can quickly identify issues that should probably be reported outside of BZ Security Regression RFE Translation Upgrades
On QA server. 1: Test following a link to $server/enter_bug.cgi?product=Fedora Guided entry form. 2: Test creating a via the New menu Guided entry form. 3: Test following a link to $server/enter_bug.cgi?product=Fedora&component=publican Guided entry form with component set. 4: test submitting form All options except keywords work as expected. When specifying multiple keywords only 1 keyword is set on the created bug.
On QA server. 1: Test following a link to $server/enter_bug.cgi?product=Fedora Guided entry form. 2: Test creating a via the New menu Guided entry form. 3: Test following a link to $server/enter_bug.cgi?product=Fedora&component=publican Guided entry form with component set. 4: test submitting form All options work as expected.
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.
Opened bz2187261 and bz2187263. Folks, please cooridnate changes like this on the Fedora devel mailing list or via the Fedora Change process. This was an unexpected surprise :(
Is there some special URL that can display the old full-featured form, or is it the guided form only now? Thanks for info.
(In reply to Kamil PΓ‘ral from comment #29) > Is there some special URL that can display the old full-featured form, or is > it the guided form only now? Thanks for info. Yes, please. I think the new form is a big improvement for people who've never interacted with Bugzilla before, but it's quite cumbersome for experienced users. I strongly prefer the old bug entry form. IMO, there should be a link on the bug entry to toggle back to the old view. It also should be possible to disable it on an account wide basis in my user preferences. In reply to Miro HronΔok from comment #28) > Opened bz2187261 and bz2187263. > > Folks, please cooridnate changes like this on the Fedora devel mailing list > or via the Fedora Change process. This was an unexpected surprise :( 100%. It seems there's an ongoing communication problem here; breaking changes in RHBZ are often not properly announced to Fedora developers. Thanks
(In reply to Maxwell G from comment #30) > I strongly prefer the old bug entry form. IMO, there > should be a link on the bug entry to toggle back to the old view. It also > should be possible to disable it on an account wide basis in my user > preferences. Both of these seem reasonable, please open a new bug asking for them.
I requested it in bug 2189110 .