enter_bug page

Gervase Markham gerv at mozilla.org
Thu Oct 17 14:17:35 UTC 2002

Bradley Baetz wrote:
> On Thu, 17 Oct 2002, David Miller wrote:
>>On 10/17/02 2:25 PM +0100, Gervase Markham wrote:
>>>We should be aiming to have the most-used features accessible
>>>easily, and lesser-used features can require more clicks.
>>Which is exactly the reason I completely disagree with Gerv, both for
>>attachments and dependencies, because those are both VERY frequently used.
>>I get at least new bug notification every two or three days where someone
>>files a bug and immediately attaches a patch to it.  That's two bugmails
>>when I could have just gotten one.  We frequently have a need for metabugs
>>(though it's probably overused, it's a fact of life) and dependencies on
>>the enter_bug page makes that a lot easier, too.

I agree that there's more of an argument for attachment being on the 
enter_bug page, but I still don't think that's a good idea - both for UI 
and technical reasons (see below.)

I think there is a philosophical difference here - I see the enter_bug 
page as a starting point - where you put in the main bug details, and 
then flesh out things like aliases, dependencies, priority, status etc. 
in a subsequent change, reusing all the code we have to do that.

IMO, an enter_bug UI which looked like the show_bug UI (the logical 
destination of the "you should be able to add anything you can change" 
view) would be over-complex and confusing, because the people who enter 
bugs are more often easily-intimidated novice users of the system.

> Attachments have a lot of extra issues, though, and would be a massive
> ammount of work. 

If attachments were just a file upload control, then they could be on 
the enter_bug page. But they aren't (and Bugzilla is much the better for 
it - we have an excellent and very functional attachments system.)

Regarding bug 81642, I am a fan of that - in fact, there's a comment 
there from me detailing my vision of how exactly this would work. But I 
like that because it's a far more powerful and general mechanism for 
approximately the same level of UI complication.


More information about the developers mailing list