> A start would be if Zarro bugs is the result of a query to ask directly if
> a new bug is wanted and then populate with whatever they've already entered
> in the query.
Most people to whom this would be useful query on two or three words. It's
hardly an effort to get them to type them again in the "New bug" form. And
where would you put them?
Well if they've chosen the platform and component it seems reasonable to re-use them.
Also, if someone comes up "Zarro Boogs" we want them to try a few more
searches - that's what Zarro Boogs means - your bug exists, you just
haven't found it yet ;-)
Well then you don't understand the psychology of someone that has a problem, unless you aren't serious. Believing that a bug already exists, that it must have been reported is about the only motivation to change the query and try again and for the most part those you aim the Helper at will fall at that fence.
Asking people who do a failed search explicitly if they want to file a new
bug will lead to more dupes being filed.
And this is bad because someone has to recognise its a duplicate? Hmmm, that tends to suggest that the original wasn't easy to find in the first place or if its difficult to spot a duplicate that perhaps it isn't really a duplicate at all. Personally I'd rather have more duplicates the alternative of no entry, the more there are on the 'same' behaviour the more likely all nuances will be convered. And that's not particularly to perpetuate the idea that more dupes = higher visibility = more likely to be fixed. I think its another example of the evolution of a bug.
In a closed system duplicates are very important because they give an indication of incidence, if we have a 1000 disparate users and 250 of them report something very similar we're in the slime. In an open system we have fewer duplicates and about the only indicator of incidence is volume of protest. This is potentially quite bad because it becomes easier for those that can fix to ignore the mob because its a much smaller proportion (and there's no real way of knowing what proportion it is) of the population.
> To be honest I think there's too much text in the Bugzilla
> Helper to make it useful but that's an opinion of someone that it isn't
> aimed at.
I can't see how we can reduce the text while still making it
well-explained, but I'm open to suggestions :-)
Well, I'm not exactly innocent of the deed of spilling of words but I'll look. You should be revising and inwardly digesting other stuff anyway :-)
The thing which first came to mind was the detailed description of DOCTYPE, quirks and strict. While this is useful stuff the important question is right at the end of that whole set of text...
'So, if your bug is with the layout of a particular web page, and you're certain that it's not caused by either:
- The page using proprietary HTML, such as the LAYER tag
- The page using proprietary DOM extensions, such as document.all
- The page being rendered in quirks mode (as described above)'
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Where <here> of course is a link to the detailed description of quirks mode et al. The reason I think this, is that it prunes the tree right at the start as intended but it doesn't confuse the user with things they know nothing of and care less about or if they really don't understand it diverts them rather than clogging up the process of getting the bug described.
> For the accurate collection of data I prefer a true interview method, which
> rather than filling in a form would present each question as part of a
> series of dialogs, possibly with a set of forward and backward buttons, but
> modal so that the underlying form variables could be built properly. The
This is bad for several reasons:
a) Requires a complete rewrite
Umm I'm not sure that in itself is either true or a reason for or against. It needs writing that's for sure but that in itself isn't a reason for not writing it.
b) Slower for intermediate users
Dubious, if it becomes too slow for them the nuts and bolts way of adding a bug will be faster, but I can't see why it would be slower for anyone really. Enter data, click next compared to Enter data, tab or fiddle with mouse (scrollbar etc, etc)
c) Much greater possibility of data loss if the process breaks
Umm how? If the state is maintained in the underlying document its no different at all.
> reasonable order and concentrates the user's attention whereas a form
> filling exercise lets the user be lazier or simply miss sections. That
If the user misses important sections Bugzilla Helper already nags them
about it.
Is this at the time of missing out that section? Nagging at the end of a form after they've struggled with the form in the first place is a large drain of gumption, they weigh up how much its worth to them to go back and fix it reckon its trivial and obvious and don't bother.
> It would be nice that, before the bug was actually added, a search was made
> using their Summary or Description or both to come up with possible
> duplicates as well.
Would this not irritate people who have already done all the searching?
I'm not sure why. There's been a number of occasions where people have added bugs simultaneously about the same thing. Its a rational thing to do on a distributed system to check before you add new data that someone hasn't already added it.
Simon
Gerv
If I'd known I would spend so much time sorting and rearranging boxes
I'd have paid more attention at kindergarten
S.P. Lucy
