Community
Participate
Working Groups
"As an Eclipse committer, you get to use the raw bug entry form. Users are guided through the bug entry process for more accurate bug reports and fewer duplicates." I believe we should recognize a third category of Bugzilla user: 1) Committer 2) User 3) Experienced User Experienced users do not need/want to be "guided though the bug entry process". They want to go directly to the raw bug entry form. It is ok with them if there are fields that are not enabled, but they want to see them. For example, I asked my coop student to do accessibility testing on Orion and open all bugs he finds. I know that this testing has not been done before, so he can basically skip the step of searching for dups. I want him to add my name as the QA contact, and I want him to enter the "accessibility" keyword on all bugs he enters. I want him to enter version 0.3 because that is the version of Orion that he is testing. I sat down with him and we logged on to his Bugzilla account and attempted to file a bug. We were presented with a large unwieldy page full of "too much information". Useful fields like Keywords, QA Contact, and Version were missing. (The "Build ID" field is not useful for Orion. Browser/version would be useful).
My student tells me that he can enter keywords and version after the bug is open. This is sub-optimal, because then bug entry becomes a 2-step process (which is more error-prone), and it also tends to spam the inbox list with unnecessary emails. All enabled fields should be available on the bug entry page, particularly for the category of experienced users that are not committers.
I like your idea of a third category, but I'm not sure how we'd go about implementing that without touching the Bugzilla source code.
Ah, I see. Have we ever done that before?
I notice that in this doc: http://www.bugzilla.org/docs/3.4/en/html/cust-change-permissions.html it says that administrators can give certain groups different privileges. Apparently, you have to edit Bugzilla's Perl code, but hopefully this doc tells how. Of course, the warning at the top of the page says that any mods are not guaranteed to work if you upgrade Bugzilla. <sigh>
Therein lies the problem ... We'd need some automated way for users to be able to place themselves in this magical "third group". I already know who committers are and tweaked the customized templates to differentiate committers from the general public, but a third group would add much complexity. Although we've customized several of the Bugzilla UI templates (which we must diff and hack for each BZ upgrade) we don't want to touch the actual code. With that being said, we certainly can add some fields, such as the Keywords, to the guided entry form. But we must keep in mind that that form is also used by Bugzilla novices, and we don't want to overload it with a ton of fields that may intimidate them.
The guided entry form is a little bit intimidating already <grin>. That huge list of bugs to look through... what is that? The top 100 reported bugs? Anyhow, it's the first time I have seen the new user form, and although I understand the need for getting folks to think about dups and build id and steps to replicate, I do feel that the current form does have too much information. Maybe just a title-and-comment search field (can you do both searches with a single field?) without the imposing bug list. Also, the "build id" is useful for most eclipse-based products, but useless for Orion and anything web based (like for example, most Eclipse Community bugs <grin>). For those, it is more useful to know what browser/version. So the user should be prompted to enter that info. It would be nice if the build id field conformed to the product/component that the user selected. I also think that the steps-to-replicate should be in the same text field as the description, so the user can optionally select all and delete if it doesn't make sense to have both. If the guided entry form was simpler in general, then it would not be a burden to add the keyword and version fields. (The version field should populate when the user enters the build id in the case of eclipse products <g>).
One possible way to add users to the "third group" could be to automatically add them after they have opened, say, 10 bugs? By then, they know the drill, and they can probably be trusted to do their due diligence before opening new bugs.
In the case of Orion, and Eclipse Community bugs, where it might be important to know what browser the user is using, maybe we could populate the "browser/version" field (which would be part of the description or initial comment). I'm not sure how to do this, but it is possible. This web site does a good job of it: http://www.whatbrowser.org/en/
We won't be investing any resources into improving Bugzilla, as we encourage projects to use GitHub and Eclipse GitLab (https://gitlab.eclipse.org). Please see: Shutdown this bugzilla instance. https://bugs.eclipse.org/bugs/show_bug.cgi?id=577151
