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