Re: [GMG-Devel] New ticket workflows, and relevant meeting

[Christopher Allan Webber]

So I've made some updates to the workflows of tickets :)

Here, more or less, is the new workflow.
 - There are several states to tickets now:
   - new (ticket created, no activity, not marked as a confirmed
     feature/bug)
   - accepted (someone has confirmed this as a feature/bug, but no
     significant work is not currently in progress... may be renamed to
     "confirmed" at some point)
   - in_progress (set when someone assigns the bug to themselves... see
     more below, we are now only encouraging setting the bug to someone
     when we know they are working on it!)
   - review (Mark for code review.  The ownership will be preserved of
     the person who has been working on the ticket, but will move into
     the "review queue"... any experienced mediagoblin developer can
     help with code reviews)
 - The actions section at the bottom of the ticket has some wording that
   tries to help guide a good workflow.
 - You can mark a ticket to be closed at any present state of the ticket
   being open.
 - Generally, tickets only should have owners *when someone is presently
   working on them*!  This is to try to help discourage "stuck tickets"
   that have an owner but no activity for a long time.

What this means possibly for bug triage:
 - Bugs in the "new" state can be triaged to confirm they're a real bug
   first or actually a ticket we intend to work on
 - Ownership of a ticket is easier to diagnose, as tickets should be
   claimed when people are in progress but not otherwise.

Of course, sometimes when people have tickets claimed and marked as in
progress but haven't had activity for some time, the best thing to do
might be to ask them if they intend to get to it soon!

There are some old tickets in the "assigned" and "reopened"
statuses... these need to be converted, and I could use some help
updating them:

  
http://issues.mediagoblin.org/query?status=assigned&status=reopened&col=id&col=summary&col=owner&col=type&col=status&col=priority&col=milestone&col=component&order=priority

Meanwhile, I am off for a doctor's appointment :)

Happy to talk about this further!
 - cwebb

Christopher Allan Webber writes:

> We had our meeting... Here's what came out of it:
>
> Participants: paroneayea, shawnrisk, freedeb, tsyesika
>
>  - First we discussed the states I suggested in the email below
>    Generally people agreed that the states are all good but we shouldn't
>    have needs-work since that's making things too complex, just pass
>    back to in-progress when things are done.
>
>    So moving these states into place should happen soonish.
>
>  - There was a lot of discussion about the problem of stuck, claimed
>    tickets that haven't had any activity for a while.  Generally it's
>    agreed that we should have a filter in Trac that lists claimed
>    tickets that are in-progress that haven't haven't had updates for
>    some time.
>
>    How to update users?  Should we create notify scripts?  (Risk: those
>    tend to annoy people)  Should it all be done by hand?  Maybe some
>    tooling in-between that can help triagers.
>
>  - We discussed the current "triage workflow" we have and what kind of
>    future workflows we might want.
>
>    - Currently Shawnrisk pulls up 5 tickets or so and has a contributor
>      go through them with him.  This has been great in many ways but
>      Shawnrisk raised two primary frustrations for him:
>      1) If he is the only one looking for tickets, and 2 or 3 people   
>         say want to help with tickets, how does that work?
>      2) The ticket days are only done when Shawnrisk is around and
>         others are available so this is a very limited time.  Shawnrisk
>         says if we were able to extend this to all day would be better.
>
>    - We talked about these bits, and I mentioned I've been talking to
>      other projects (especially thanks to Greg Grossmeier for taking
>      time) to figure out how they handle triage workflows; could we
>      learn from them to make things easier for ourselves?
>
>    - Currently also I read every bug update that happens (they all go to
>      my bugmail folder) to try to make sure I don't miss patches that
>      need to be reviewed; Greg encouraged on call that a state we should
>      shoot for is where bug triage can happen in background and I can
>      trust it's going on and contributions are being made (even things
>      being merged sometimes!) without me overviewing everything.
>
>    - This doesn't mean lack of bug review days; ideally finding a much
>      more specific set of bugs to work on would be good
>
>    - Deb Nicholson has mentioned interest in joining in helping with
>      workflow stuff also, she and ShawnRisk agreed that maybe a good
>      route for now is for her to "shadow" him on triage days for a few
>      weeks and then maybe they can discuss further?
>
> That's the summary anyway!  Good meeting!
>  - Chris
>
> Christopher Allan Webber writes:
>
>> Somehow this never got sent out when I wrote it originally!
>>
>> Christopher Allan Webber writes:
>>
>>> Heya all,
>>>
>>> I've been talking to a number of people trying to get a sense if we
>>> can't improve our ticket workflows.  So, a couple of things.
>>>
>>> 1) We're having a meeting about it on IRC!  Thursday May 2nd at 3PM UTC
>>>    / 11AM EDT.  ShawnRisk, freedeb, and I will be there.  You're welcome
>>>    to come as well if interested.
>>>
>>>    
>>> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130406T09&p1=224&ah=1
>>>
>>> 2) I've been thinking of adding some new states.  Here roughly is the
>>>    list of states I've been thinking about:
>>>
>>> open states:
>>>  - new  <- bug first opened
>>>  - confirmed/accepted  <- someone has triaged this to a state where
>>>                           we generally know it exists or expect it to be
>>>                           worked on
>>>  - in-progress  <- someone has actually started doing specific work on it
>>>  - needs-review  <- Needs code review or needs someone with commit
>>>                     access to pull it in.
>>> # - needs-work   <- possibly a state it can be set back to if it's been
>>> #                   reviewed but determined there still needs to be work
>>> #                   done... maybe we could just use in-progress though.
>>>
>>> close states would be as they presently are:
>>>  - fixed
>>>  - invalid
>>>  - duplicate
>>>  - worksforme
>>>
>>> ... I think this would allow for better triaging that we have now.  But
>>> anyway, the meeting will be a good place to discuss all this. ;)
>>>
>>> Cya then, quite possibly!
>>>  - Chris
>>
>> _______________________________________________
>> devel mailing list
>> address@hidden
>> http://lists.mediagoblin.org/listinfo/devel
>
> _______________________________________________
> devel mailing list
> address@hidden
> http://lists.mediagoblin.org/listinfo/devel