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