Bugzilla – Full Text Bug Listing
| Summary: | Streamline bug entry for experienced users | ||
|---|---|---|---|
| Product: | Community | Reporter: | Carolyn MacLeod <carolynmacleod4> |
| Component: | Bugzilla | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | denis.roy |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Carolyn MacLeod
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 |