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.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
