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

[=JeffH <[e-mail]>]

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