Subject: [websec] proposed workflow for trac issue tickets (HSTS)

From: =JeffH <[email-masked]>
Date: Fri, 27 Jan 2012 17:38:08 -0800

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

=JeffH

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 31 Jan 2012 17:29:57 +0000

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.
>
> 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..
>
>   b. if wg consensus (as assessed by co-chairs) is that the ticket's 
> fix needs revision, ticket is "reopened", goto 2.
>
> 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.