Fwd: REST APIs, and Tags

Max Kanat-Alexander mkanat at bugzilla.org
Mon Feb 15 22:21:09 UTC 2010

On 02/15/2010 06:32 AM, Gervase Markham wrote:
> I agree we need to change something here... but does the simple form
> encourage or help people to search for existing bugs first? If not, how
> could that be incorporated?

	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.

>> 	Yeah, I agree. I believe my most last suggestion in this area was that
>> Mozilla should hire several full-time bug triagers.
> That may or may not happen; but it shouldn't stop us looking at ways
> that we can change the software to make them less necessary :-)

	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.

>> 	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.

> 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.

Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

More information about the developers mailing list