Re: Triage Plan for Firefox Components

Gervase Markham wrote:
> On 01/04/16 15:51, Mike Hommey wrote:
>> Bug status is currently, IMHO, completely misused and thus useless:
>> - people with editbug capability file as NEW by default. Why should a bug
>>    I file in a component I'm not working on (because I noticed a bug
>>    in Firefox) be NEW?
>> - there is a long tail of bugs assigned to people that are not being worked
>>    on (I should know, I have a lot of those, shame on me)
>>
>> So it feels to me triage should replace/subsume it in some way.
> I suspect they want to add a new field because changing bug statuses
> seems like a massive change. Which it would be. However, not doing it
> will leave us with two workflow widgets in Bugzilla instead of one, with
> all the ambiguity that brings. In the long term, I see pain here.
right - adjusting the workflow is a silently breaking one so we're not 
taking that step just (yet!).
eg. dashboards that use a hardcoded list of "open" states will silently 
stop reporting on all bugs if we add a new state.
> If Bugzilla supported per-product workflow that might help. Is it worth
> investing the BMO-hacking resources for this plan into that?
the plan is to have per-product customisations in the UI with 
per-product workflow enforcement via extensions.
"per-product workflows" isn't an option as we're not altering the BMO 
workflow fields (status/resolution) in a way that would make this viable.

imho long term the list of status/resolutions needs to be updated; but 
first we need to determine, document, and mandate the desired workflow.  
emma's work is the first step of this process, and i expect somewhere 
near the end lives a "break all the things" change for the greater good.


-glob

-- 
byron jones - :glob - bugzilla.mozilla.org team lead -

_______________________________________________
firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/firefox-dev