Fwd: REST APIs, and Tags

[Gervase Markham]

On 15/02/10 22:21, Max Kanat-Alexander wrote:
> 	Yeah, I was thinking about that this morning, actually. I think that
> you could display a few extra items (maybe even using template hooks) on
> bmo for users who don't have editbugs.

We could try that - although of course, adding stuff is increasing
complexity. I'd like to try out a step-by-step wizard-style interface,
but I don't have time to write it :-(

> 	You know, having discussed this problem for years and years now with
> the Mozilla team, I think that ultimately the problem is a human problem
> that can't totally be solved with a tool. So I think that in the end,
> it's going to be having more humans do the right thing that solves the
> problem that Mozilla is experiencing, because for the most part, the
> tool is capable of doing *most* of what's necessary to solve the problem
> already, and it's just not being done because there is a lack of
> manpower (or organization, re: components?) to do it.

Mozilla does have a pretty large QA organization - including many paid
staff. It's not like they've hired no-one. And they are always trying to
find more people, and we are working on ways to do that. But it's never
enough.

>>> 	Hmm. I do agree that there are a lot of cases where certain data just
>>> isn't very important, particularly Platform/OS. Translating those into
>>> tags might be reasonable, but I worry that then we'd shift the burden of
>>> setting them properly *entirely* onto developers instead of how it is
>>> now, where it's just *mostly* on developers (or the fields are ignored).
>>
>> How would that be significantly worse? At least the responsibility is
>> clear in the new world.
> 
> 	When you have hundreds of thousands of bugs, having 10% of the work
> done for you is far better than having 0% of the work done for you.

Except that I suggest that you don't actually have 10% of the work done
for you. Because you have to check that 10% of the work anyway, and fix
it where it's wrong. And there's the increased uncertainty of not
knowing if the fields were set by someone competent or auto-set by the
reporter. IOW, putting it 100% in the hands of one group removes
coordination cost.

>> Quite :-) Here is the problem Mozilla has been struggling with for
>> years. We started with keywords, then moved to flags, and have now moved
>> to custom fields. None are ideal. What we really need is proper branch
>> support - although (and see my comments in that bug) there's a danger
>> that you are going to implement it and it won't be suitable either!
> 
> 	I suspect that it will be suitable. I've actually had the exact same
> feature proposed by two separate clients as necessary to solve their
> problem, and I've seen the UI mockups and it will work.

The two Mozilla people who commented on the bug agreed with each other
that it would be a "disaster"[0], and the design, while it has been
clarified, hasn't changed significantly since, nor (as far as I know)
has further requirements input been sought from them or other groups at
Mozilla.

This is what I meant when I wrote
https://bugzilla.mozilla.org/show_bug.cgi?id=55970#c40 . How am I to
interpret your confidence that "it will work", combined with their
statements that it will not, apart from as "you aren't listening"? I
don't think you're not listening with malicious intent, but how else am
I supposed to reconcile those two facts? That's a genuine question.

Gerv

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=55970#c32
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla