264721 - create READY state for bugs which have enough info/testcases to start work

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[fantasai]

from one of hixie's comments on how to make bugzilla.m.o more manageable:

 |  instead of simply UNCO and NEW, have UNCO, NEW, and READY, with the
 |  meanings:
 |
 | UNCO  -- bug filed by someone with no privs, could be garbage
 | NEW   -- bug is not garbage, but may need more QA work
 | READY -- bug has a testcase, has steps to reproduce, etc.

Essentially, READY is a bug that has enough information that one can start
diving into actually writing the fix rather than discussing what the problem is.
Depending on the bug, it may require testcases, crash data, detailed specs, etc.

I took a look, but haven't seen this rfe filed yet.

Comment 1

[fantasai]

Attachment: Mike Connor's email to Aviary about this

Comment 2

[Dave Miller [:justdave]]

Nothing against this idea, but just informing you of similar ideas which might
serve the same purpose...

Several sites have locally added a NEEDINFO status which they set the bug to
during triage if it doesn't have enough information to tackle it yet.  I have
working patches against pretty darn close to CVS tip right now to add this status.

The patch I have right now lets anyone with editbugs set the status to NEEDINFO,
and while the bug is in NEEDINFO state, a checkbox shows up above the additional
comments for which says something to the effect of "This bug is currently
waiting additional information.  If you're supplying the requested information,
please check this box."

The problem with this status according to what you've suggested, though, is that
it puts everything into the "hey developer!" queue until someone says "hey,
there's not enough info here" and sends it back.  What READY would do is make it
a proactive thing on the part of QA to say "ok, now there is enough data here,
lets send it to the developers".

So there's still drawbacks either way.  Short term, since we're still lacking
custom statuses in Bugzilla, I think this would be better done as a local hack
to b.m.o.  Since we're likely to need this long before custom statuses lands,
moving this bug to the mozilla.org product.

Comment 3

[Gervase Markham [:gerv]]

Indeed, this would be a local hack, and the "QA must put it in the 'hey,
developer' queue" part is extremely intentional :-)

Gerv

Comment 4

[Rod Whiteley]

Isn't this what the keyword clean-report is for?

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: proposed triage workflow with a READY state

Created by mconnor and posted to his "Modest Proposal"
http://steelgryphon.com/blog/?page_id=61

Comment 6

[timeless]

Comment on attachment 197792 [details]
proposed triage workflow with a READY state

this chart is broken. beltzner new it was before he posted it but forgot to
check it.

Comment 7

[Gervase Markham [:gerv]]

Discussion is going on over at:
http://wiki.mozilla.org/BugzillaWorkflowImprovements

Gerv

Comment 8

[Dave Miller [:justdave]]

Taking all of myk's bugs in the Other b.m.o issues component that he isn't actively working on, since he's no longer the default assignee for this component, and these were all filed while he was.

Comment 9

[Gervase Markham [:gerv]]

Bugzilla 3.2 will have customisable statuses, allowing us to implement this feature on b.m.o. At last :-)

Gerv

Comment 10

[Dave Miller [:justdave]]

Rearranging this component to not have me as the default assignee, so that it doesn't appear like I'm intending to work on bugs that other people could be taking care of if they didn't think I was already doing them.  If this bug is a software issue on b.m.o and you'd like to fix it, the modified source is now available for the patching (see bug 373688).  Reassigning to the new default owner.

Comment 12

[Wayne Mery (:wsmwk)]

from bug 769433 ...
(In reply to David Lawrence [:dkl] from comment #3)
> IMO opinion there is enough consensus for us to go ahead and add the READY
> status to BMO now and then work out the other improvements in future pieces.
> The READY state would give a small win for now while we work out the other
> details.
(In reply to Gervase Markham [:gerv] from comment #5)
> I have no objections to adding the READY state, because it looks like I
> won't have time in the near future to push through a general reconsideration
> of how we do this. But what is very important is that it's clear to everyone
> from the outset what this state is meant to signify. That involves
> documentation in Bugzilla but also a public awareness campaign with blogs
> and discussion forum posts. If the semantics are not clear, it will rapidly
> end up as not useful.
> 
> Gerv

dkl, have you considered a target time?  TBird QA is considering some process changes where having this would be very useful

Comment 13

[David Lawrence [:dkl]]

Attachment: Patch to add READY state to field documentation (v1)

I ported part of Gervs patch in bug 616453 to add the hook needed in fields.html.tmpl. Aside from this patch, the rest of the changes needed are just adding the READY value to the list of bug statuses and updating the workflow to display the new status. 

dkl

Comment 14

[:glob ✱]

Comment on attachment 665584 [details] [diff] [review]
Patch to add READY state to field documentation (v1)

r=glob

Comment 15

[Gervase Markham [:gerv]]

OK. In the duped bug I said:

"I have no objections to adding the READY state, because it looks like I won't have time in the near future to push through a general reconsideration of how we do this. But what is very important is that it's clear to everyone from the outset what this state is meant to signify. That involves documentation in Bugzilla but also a public awareness campaign with blogs and discussion forum posts. If the semantics are not clear, it will rapidly end up as not useful."

So glob's patch which defines some semantics is good. And I agree that we should just go ahead and do this, based on previous discussions, rather than having yet another round of discussion. However, I think we also need to propagate this information widely before we enable it. Can someone draft up a short blog post, based around that text, which says:

- We are introducing a new Status in Bugzilla
- The semantics are <definition>
- We've been thinking of doing this for years
- People keep asking for it
- The last set of discussions on this topic agreed it was a good idea
- We aren't opening the wider question of other possible statuses/resolutions for now

Thanks,

Gerv

Comment 16

[David Lawrence [:dkl]]

Documentation will show up in the next code push next week. I don't see any harm though in enabling the state in BMO now so that people can start using it.

Committing to: bzr+ssh://[e-mail]/bmo/4.0
added extensions/BMO/template/en/default/hook/pages/fields-open-status.html.tmpl
modified template/en/default/pages/fields.html.tmpl
Committed revision 8340.

Committing to: bzr+ssh://[e-mail]/bmo/4.2
added extensions/BMO/template/en/default/hook/pages/fields-open-status.html.tmpl
deleted extensions/BMO/template/en/default/hook/pages/fields-resolutions.html.tmpl
Committed revision 8362.

dkl

Comment 17

[Reed Loden [:reed]]

(In reply to David Lawrence [:dkl] from comment #16)
> Documentation will show up in the next code push next week. I don't see any
> harm though in enabling the state in BMO now so that people can start using
> it.

I've turned READY back off until proper notification is ready and has been sent out to various places, as per gerv's comment #15. New statuses are not to be taken lightly, and we should ensure people understand exactly what READY means before it gets turned on.

Comment 18

[David Lawrence [:dkl]]

Sorry Gerv for not reading your comment before proceeding with this update. I have disabled the state for now and the documentation changes will not show up til next Thursday anyway. This should give us ample time to announce the new state. Byron can post something on his blog and/or I can post something to dev.planning if that would help as well. Sound good?

dkl

Comment 19

[Wayne Mery (:wsmwk)]

I hadn't thought about this, and no doubt it deserves a new bug, is there eventually should be a new email preferences line in https://bugzilla.mozilla.org/userprefs.cgi?tab=email for READY

   I want to receive mail when: 
.. but not when (overrides above): 
to supplement
  The bug is in the UNCONFIRMED state for

Comment 20

[Gervase Markham [:gerv]]

wsmwk: No; that checkbox is a special one which exists only for UNCONFIRMED.

Here's a proposed announcement:


New READY Status Coming To bugzilla.mozilla.org

Next Thursday, a new open Status will be introduced on bugzilla.mozilla.org, alongside UNCONFIRMED, NEW and ASSIGNED.

READY is designed as a Status which passes responsibility for the bug from QA/triage to those responsible for implementing a fix. A bug should be switched to this state when all the necessary preparatory work has been done. The bug has been confirmed to exist, a testcase has been produced, a regression range has been found, any necessary UI design has been done and so on, but the person who is going to fix it has not been identified. Engineers can search for READY bugs to find things which are suitable to be worked on.

Clearly, for the Status to be useful in the long term, it must actually mean the same thing to everyone. So we ask people to respect the semantics above. Obviously, different groups have different processes. Either the meaning will make sense for your group, or it won't - in which case, feel free not to use the status, and jump straight to ASSIGNED.

Initially, no bugs will be in this Status. Please switch bugs to this Status only when you are sure that they are ready to be immediately worked on. Please remove bugs from this Status (and revert to NEW) if more information is being gathered.

If you see any problems relating to the introduction of this new Status, please <a href="">file a bug in the bugzilla.mozilla.org product</a>.


Gerv

Comment 21

[Wayne Mery (:wsmwk)]

(In reply to Gervase Markham [:gerv] from comment #20)
> wsmwk: No; that checkbox is a special one which exists only for UNCONFIRMED.

of course. I'm just citing that as the current implementation.

What I am suggesting is when READY becomes available then some people (developers?) might also not be interested in bugmail for bugs in status=NEW. But I suppose that's a hypothetical until we hear anyone express the need.

Comment 22

[David Lawrence [:dkl]]

Gerv, can you please post this to your blog for us? I will send this text to dev.planning myself.

Thanks
dkl


(In reply to Gervase Markham [:gerv] from comment #20)
> New READY Status Coming To bugzilla.mozilla.org
> 
> Next Thursday, a new open Status will be introduced on bugzilla.mozilla.org,
> alongside UNCONFIRMED, NEW and ASSIGNED.
> 
> READY is designed as a Status which passes responsibility for the bug from
> QA/triage to those responsible for implementing a fix. A bug should be
> switched to this state when all the necessary preparatory work has been
> done. The bug has been confirmed to exist, a testcase has been produced, a
> regression range has been found, any necessary UI design has been done and
> so on, but the person who is going to fix it has not been identified.
> Engineers can search for READY bugs to find things which are suitable to be
> worked on.
> 
> Clearly, for the Status to be useful in the long term, it must actually mean
> the same thing to everyone. So we ask people to respect the semantics above.
> Obviously, different groups have different processes. Either the meaning
> will make sense for your group, or it won't - in which case, feel free not
> to use the status, and jump straight to ASSIGNED.
> 
> Initially, no bugs will be in this Status. Please switch bugs to this Status
> only when you are sure that they are ready to be immediately worked on.
> Please remove bugs from this Status (and revert to NEW) if more information
> is being gathered.
> 
> If you see any problems relating to the introduction of this new Status,
> please <a href="">file a bug in the bugzilla.mozilla.org product</a>.
> 
> 
> Gerv

Comment 23

[Gervase Markham [:gerv]]

Done: http://blog.gerv.net/2012/10/new-ready-status/ .

We need to remember to update the mybugstemplate parameter. Will there also be issues with charts we need to address? That could be a can of worms...

Gerv

Comment 24

[Gervase Markham [:gerv]]

Actually, I just pulled that blog post. We need to think the ramifications of this through a bit more. Are we going to automatically update everyone's saved queries? We did that for the last Bugzilla reorg, which was a major change which impacted a lot of queries. If we don't, either lots of people have to do manual work (not necessarily even possible with charting, I think) or bugs start falling off the radar. Both are bad outcomes.

Gerv

Comment 25

[David Lawrence [:dkl]]

Attachment: Patch to add a new open state to stored queries when user is looking for all open states (v1)

First crack at migration script to update user queries and series queries to include a new open state when user is looking for all open states.

I am simply comparing the list of open states and the list of states in the query string. If the only difference is the new status being added then I update the query string and update the database. Otherwise I leave it alone.

This script assumes we are only dealing with adding "open" states and would need to be adjusted if we wanted to add a "closed" state in the same fashion in the future.

Please review
dkl

Comment 26

[:glob ✱]

looking at the logs for queries made via bzapi, i'm seeing a lot of queries which have an explicit list of open states.

i'd like to see followup posts which highlight this change to developers of tools which integrate with bmo.

Comment 27

[Gervase Markham [:gerv]]

I've started this document:
https://wiki.mozilla.org/BMO/Integration_Best_Practice
which contains this advice. Please feel free to add other things to it as well.

We can reference that document in a blog post highlighting this upcoming change.

We could also consider a hack to add READY to searches which contained all other open statuses for a while, but perhaps that would just defer the breakage... It would also make it impossible to query for "all open non-READY bugs", but perhaps that's an unlikely request.

Gerv

Comment 28

[:glob ✱]

(In reply to Gervase Markham [:gerv] from comment #27)
> We could also consider a hack to add READY to searches which contained all
> other open statuses for a while, but perhaps that would just defer the
> breakage... It would also make it impossible to query for "all open
> non-READY bugs", but perhaps that's an unlikely request.

i don't think this is a good idea .. as you pointed out it would just defer the breakage.  i think it would be clearer (not to say simpler!) to take this hit at the same time the state goes live.

Comment 29

[:glob ✱]

Comment on attachment 668085 [details] [diff] [review]
Patch to add a new open state to stored queries when user is looking for all open states (v1)

Review of attachment 668085 [details] [diff] [review]:
-----------------------------------------------------------------

the actual conversion routine looks good and works well in my testing, however i'd like to see a transaction block around the updates.

::: contrib/reorg-tools/fix_all_open_status_queries.pl
@@ +17,5 @@
> +# Corporation. Portions created by Netscape are
> +# Copyright (C) 1998 Netscape Communications Corporation. All
> +# Rights Reserved.
> +#
> +# Contributor(s): Gervase Markham <[e-mail]>

wrong boilerplate.

@@ +54,5 @@
> +        foreach my $row (@$query) {
> +            my ($id, $old_query) = @$row;
> +            print "$old_query\n";
> +            my $new_query = all_open_states($new_status, $old_query);
> +            print "$new_query\n";

remove debugging code :)

@@ +120,5 @@
> +    usage();
> +    exit();
> +}
> +
> +my ($new_status) = @ARGV;

please validate and uc() $new_status

@@ +125,5 @@
> +
> +print "Adding new status '$new_status'.\n\n";
> +
> +do_namedqueries($new_status);
> +do_series($new_status);

the updates need to happen within a transaction block, to guard against people updating their query while this script is running.

Comment 30

[David Lawrence [:dkl]]

Attachment: Patch to add a new open state to stored queries when user is looking for all open states (v2)

Thanks for the review. New script with suggested changes.

dkl

Comment 31

[:glob ✱]

Comment on attachment 669698 [details] [diff] [review]
Patch to add a new open state to stored queries when user is looking for all open states (v2)

r=glob

Comment 32

[Ludovic Hirlimann [:Usul]]

I've just experienced a glitch and think it might be related to this bug. I had a UNCO bug 801314 where I could resolve as WFM, but I had to change the bug to new in order to see a list of possible resolve . I couldn't resolve immediatly. This will really kill my productivity.

Comment 33

[:glob ✱]

(In reply to Ludovic Hirlimann [:Usul] from comment #32)
> I've just experienced a glitch and think it might be related to this bug.

that isn't anything to do with this bug.  if you can reproduce this issue after a forced refresh, please file a new bug to track this.

Comment 34

[David Lawrence [:dkl]]

glob and I discussed this and we have decided to enable the new state and run the migration script one we are back from work week, next week. So let's plan doing this the last week of October. This gives us more time to announce the change a little farther and wider. 

One thing we thought of is that this will not help those using BzAPI directly and we need to consider either just really making sure people are aware of the change and to update their dashboards, and/or making some changes software wise to fix the queries as they come into BzAPI.
Gerv, do you have any suggestions to the latter?

dkl

Comment 35

[Gervase Markham [:gerv]]

I could make a fix to BzAPI to alter queries, but I think we decided not to make a similar fix to Bugzilla (see comment 28), so I assume the same logic applies.

Gerv

Comment 36

[David Lawrence [:dkl]]

Committing to: bzr+ssh://[e-mail]/bmo/4.0
added contrib/reorg-tools/fix_all_open_status_queries.pl
Committed revision 8360.

Committing to: bzr+ssh://[e-mail]/bmo/4.2
added contrib/reorg-tools/fix_all_open_status_queries.pl
Committed revision 8384.

Comment 37

[:glob ✱]

the list of statuses is now considered a 'static api' as any changes to them would cause significant breakage of systems which interact with bugzilla.

To ssh://[e-mail]/webtools/bmo/bugzilla.git
   39a5ff6..779e5ad  master -> master