Re: proposed workflow for trac issue tickets (HSTS)

On 28/01/2012 01:38, =JeffH wrote:
> I did some modest checking around, and there is not a ietf-wide 
> process for using the issue tracker aka trac. Each working group is up 
> to their own devices whether they wish to use it, and if they do, for 
> establishing their workflow for such use.
>
> trac is installed with a nominal default workflow, and we apparently 
> can't customize things like new additional values for "Status" or 
> state transitions on our own.
>
> The default as-installed workflow is illustrated here..
>
>   http://trac.tools.ietf.org/wg/websec/trac/wiki/TracWorkflow
>
> I /think/ we're using trac >= version 0.11, so the second diagram 
> should apply.
>
>
> I've submitted all the issue tickets for strict-transport-sec with 
> default attribute values (e.g., for status), and it appears no one 
> else has edited the attrs, so the status of all the tickets is "new".
>
> for a nominal websec wg workflow for specification bugs, without 
> "reassignment" of tickets, I suggest..
>
> 1. ticket initially submitted, status: "new"
>
> 2. ticket addressed in a spec revision, status <- "closed", resolution 
> <- "fixed"
>
> 3. folks review the spec
>
>   a. no objections to ticket's fix, then goto 4.
>
>   b. if wg consensus (as assessed by co-chairs) is that the ticket's 
> fix needs revision, ticket is "reopened", goto 2.
>
> 4. ticket closed, really.
>
>
>
> So, if there aren't any objections to this workflow, I'll close all 
> the strict-transport-sec as resolution <- "fixed".  If issues arise 
> with any of the ticket's fixes in reviewing the spec, we can 
> selectively reopen. If new issues arise, then we submit new ticket(s).
Works for me.