Subject: Requirements to Extend the Datatracker for WG Chairs and Document Authors

From: Ed Juskevicius <[email-masked]>
Date: Wed, 16 Jun 2010 23:35:00 -0400

Hello everyone.  This it to invite your attention to two IETF Last Calls
that are now underway on the following documents:

"*Definition of IETF Working Group Document States*":

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07548.html

"*Requirements to Extend the Datatracker for WG Chairs and Authors*":

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07575.html

The second document, in particular, has several pages of requirements and
specifications for new functionality to be added to the Datatracker
to enable you to track the status and progression of WG I-Ds with more
detail than is currently possible, and other things (e.g. to assign
delegates to input or update WG document status on your behalf, to designate
Document Shepherds)..

If you have a few hours to spare during the next few weeks, I will
appreciate your input to these Last Calls.

Best Regards, and Thanks in advance,

Ed Juskevicius
[email-masked]

---

From: <[email-masked]>
Date: Tue, 22 Jun 2010 17:06:54 -0400

Ed,

The requirements draft says this regarding WG chairs and document state
subsetting:

  - SHALL be given the option to select a subset of the WG document

    states defined in [WGDRAFTS] to be used in their WGs if they do not

    want to use of all of the predefined WG document states; (R-017)

Clearly there are limits here (e.g., WG Document is not an optional
state).  The minimum subset of required states appears to be:

      - Candidate WG Document

      - Adopted by a WG

      - WG Document

      - Dead WG Document

      - Submitted to IESG for Publication

plus at least one of the following two appears to be required for
Document Shepherd usage:

      - Waiting for WG Chair Go-Ahead

      - WG Consensus: Waiting for Write-Up

It would be useful for the states draft to indicate which states are
optional vs. required.

Also, this text on "Not Adopted by a WG" is subtly wrong when a document
is a candidate for multiple WGs:

  - the Datatracker will automatically change the state of the document
    to "Not Adopted by a WG" when time runs out, unless someone logs-on
    to the Datatracker and moves the document into some other state
    first.

I believe a correct statement can be obtained by adding the words "with
respect to this WG" to the end of the first line.

That surfaces an important functional requirement - a document may be a
candidate for multiple WGs, each of which manages that candidacy
separately so an unadopted document can have independent Candidate
and/or Not Adopted states wrt multiple WG.  OTOH, there is a "first
mover wins" behavior for the transition to "Adopted by a WG" because a
draft cannot be adopted by multiple WGs.  That suggests that the
transition from Candidate to Adopted in one WG has to change the
Candidate states for all other WGs to Not Adopted, but it might be
better to clear the Candidate and Not Adopted states for all other WGs
(their existence will have been recorded in the history log).

Thanks,
--David

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ed Juskevicius
Sent: Wednesday, June 16, 2010 11:35 PM
To: [email-masked]
Subject: Requirements to Extend the Datatracker for WG Chairs and
Document Authors

"Definition of IETF Working Group Document States":

"Requirements to Extend the Datatracker for WG Chairs and Authors":

The second document, in particular, has several pages of requirements
and specifications for new functionality to be added to the Datatracker
to enable you to track the status and progression of WG I-Ds with more
detail than is currently possible, and other things (e.g. to assign
delegates to input or update WG document status on your behalf, to
designate Document Shepherds)..

Ed Juskevicius

[email-masked]

---

From: Ed Juskevicius <[email-masked]>
Date: Wed, 23 Jun 2010 00:14:40 -0400

David, Thanks for your comments / questions ...

> The requirements draft says this regarding WG chairs and document state subsetting:
>
>  Clearly there are limits here (e.g., WG Document is not an optional state) ....

Yes and no.  Yes - the requirements document says the Datatracker
shall automatically place I-Ds into two states (in every WG)
regardless of whether the WG Chairs decide to use any of the other
states or not (viz. the "WG Document" state, and the "Sent to IESG for
Publication" state).

However, aside from the two states mentioned above, none of the other
states is absolutely required.  Any of them would (when used by a WG
Chair) would provide more transparency and visibility into the WG
status of each I-D, but none of the additional states can be mandated
(or required for use) by the Datatracker requirement document.  If we
tried to suggest that using the additional states is anything but
optional, then we would be defining IETF WG processes (versus just
defining requirements to extend the Datatracker tool).

>  The minimum subset of required states appears to be:
>
>     - Candidate WG Document
>     - Adopted by a WG
>     - WG Document
>     - Dead WG Document
> plus at least one of the following two appears to be required for Document Shepherd usage:
>
>      - Waiting for WG Chair Go-Ahe

Actually - No.   Only the "WG Document" state and the "Submitted to
IESG for Publication" states are not optional, because I've specified
requirements on the Datatracker to automatically move I-Ds into these
two states (as appropriate).  When a WG Chair approves the posting of
a newly submitted version-00 I-D that has a filename that includes
"draft-ietf-" followed by the WG acronym, the Datatracker shall
automatically identify that I-D as being a "WG Document".  Whenever a
WG document is moved (by an AD) into the "Publication Requested" state
in the IESG state machine, the Datatracker shall automatically
indicate the WG status of the same I-D to be "Sent to IESG for
Publication" (in the WG state machine) if the WG Chair has not already
done so.

All of the other states are optional.

For example, the "Dead WG Document" state may be used by a WG Chair to
flag the demise of a WG document as soon as it happens.  However, if
the Chair does not want to use this state, then the Datatracker will
automatically indicate that the availability of the I-D is "Expired"
within 6 months.  Anyone who looks at the history log of that I-D will
eventually see that I-D expired without being replaced (i.e. as good
as dead).

The "Candidate WG Document" and the "Adopted by a WG" states are not
essential because their use (or non-use) will have zero impact on the
Datatracker's ability to automatically identify an I-D as being in the
"WG Document" state (i.e. when a Chair approves the posting of a new
I-D submitted with a filename that conforms to
"draft-ietf-wgname-topicname-00").  If a WG Chair does not use either
of the "Candidate" or the "Adopted by a WG" states, then the history
log of an Individual submission I-D that is accepted as a WG document
will be incomplete for some weeks or months (while an author revises
it for submisison as a new version-00 I-D), but the history will be
able to catch-up after the WG Document appears.  The posting of a new
WG I-D will trigger the history log of an Individual I-D to be updated
with 'this I-D has been replaced by a WG Document' label.

With respect to WG Document Shepherd usage of the Datatracker,
Requirement R-032 says:

   "In WGs that do not use the “WG Consensus: Waiting for Write-Up” state,
    the Document Shepherds SHALL be allowed to input, upload and edit the
    protocol write-ups for documents assigned to them when the I-Ds have
    progressed into the “Waiting for WG Chair Go-Ahead” state (in WGs that use
    this state) or for I-Ds in the “WG Document” state (in all other WGs)."

>
> Also, this text on "Not Adopted by a WG" is subtly wrong when a document is a candidate for multiple WGs:>
>
> I believe a correct statement can be obtained by adding the words "with respect to this WG" to the end of the first line.
>

I think this will depend on whether the Datatracker is extended to
have one state machine per I-D, or one state machine per I-D per WG.

My thinking has been that the Datatracker would create a new record to
track the status (and to record all changes in status) for every I-D,
and thus it would always show the most relevant (and current) status
of every I-D.  If an I-D is a candidate in multiple WGs, then the
first one that adopts it will "win", and the Datatracker will record
that state change.  It shouldn't be necessary to explicitly enumerate
every other WG that did not adopt it.  The authors (and the community)
should only care about which WG did adopt the I-D.

>
> That surfaces an important functional requirement - a document may be a candidate
> for multiple WGs, each of which manages that candidacy separately so an unadopted
> document can have independent Candidate and/or Not Adopted states wrt multiple WG.
>
Yes, each WG needs to be able to manage the candidacy of an I-D
separately.  That is (I hope) specified correctly by requirements
R-051 to R-064 inclusive.

> OTOH, there is a "first mover wins" behavior for the transition to "Adopted by a WG" because
> a draft cannot be adopted by multiple WGs.

Ack.

> That suggests that the transition from Candidate to Adopted in one WG has to change
> the Candidate states for all other WGs to Not Adopted, but it might be better to clear
> the Candidate and Not Adopted states for all other WGs (their existence will have been
> recorded in the history log).
>

I respectfully disagree, for the same rationale as above.  As soon as
the history log for an I-D shows that is has been Adopted in one WG,
that entry becomes the most recent (and relevant) status of the I-D,
so it is not necessary to list all of the other WGs where it didn't
get adopted, for I-D authors or regular IETF participants.  This said,
if I was a WG Chair that had been copsidering the I-D, I might indeed
appreciate some closure on what happened to the I-D.  I wrote
Requirement R-061 to have the Datatracker send an e-mail to all of the
WG Chairs (who have listed an I-D as one of their candidates) to
inform them when an I-D is adopted by some other WG.

  If a “Candidate WG Document” is adopted by a WG ... , the
Datatracker SHALL ...
  send an e-mail to the author of the I-D and to every WG Chair and
delegate who had
  an interest in the document to inform them that the I-D has been
adopted by the
  (insert name of the WG here) WG.  (R-061)

Does this work for you?

Best Regards, and Thanks again ...

Ed  J.

---

From: <[email-masked]>
Date: Wed, 23 Jun 2010 11:01:47 -0400

Ed,

Thanks for the detailed response.

I think some more guidance would be useful to help a WG chair make good choices among the optional states - just presenting a state list with "use this state" checkboxes could lead to unexpected results due to lack of understanding of the implications of not using a state. For example:

>    "In WGs that do not use the "WG Consensus: Waiting for Write-Up" state,
>     progressed into the "Waiting for WG Chair Go-Ahead" state (in WGs that use
>     this state) or for I-Ds in the "WG Document" state (in all other WGs)."

I suggest that the tool express a preference for one of the former two states vs. overloading write-up wait on the WG Document state.  Among other things, I would expect this distinction to be useful to the responsible AD.

In addition, if "In WG Last Call" is used, the tool should recommend (but not require) use of at least one of these two states (Waiting for Write-Up, Waiting for WG Chair Go-Ahead).  On a good day, drafts go straight from WG Last Call to IESG submission, but not every day is a good day ...

Turning to Dead WG Document, I think some guidance is needed:

> Anyone who looks at the history log of that I-D will eventually see that I-D expired
> without being replaced (i.e. as good as dead).

I don't think it's that obvious, as we're all familiar with expired drafts that come back to life much later than one might expect.  The ability to distinguish temporarily expired (e.g., due to otherwise occupied authors) from a really and truly dead draft (WG decision) can be important, so my preference would be to have the tool at least recommend availability of the Dead WG Document state.

Beyond this, I think that Adopted for WG Info Only and Parked WG document are truly optional.

Turning to the candidate states, independently choosing to use the Candidate WG Document, Adopted by a WG and Not Adopted by a WG sates seems problematic to me.  For simplicity and consistency I would make use of these three states a single all-or-none choice.

> R-051 to R-064 inclusive.

My concern is that the separate management is incomplete.  There are about half-a-dozen requirements to send emails about the candidate draft when various events happen.  Suppose that a draft is a candidate for multiple WGs, one of which promptly and definitively rejects it, leaving the others to continue to consider it.  As the chair of the WG that has rejected the draft, I want to see *none* of those event emails.  What appears to be missing is the ability of a WG chair to terminate the candidacy of a document wrt his/her WG before the timer runs out on all the other candidacies for the draft.  R-064 appears to forbid that early termination:

   The Datatracker SHALL NOT allow a document that is a candidate in more
   than one WG to be moved into the "Not Adopted by a WG" state before
   the timer specified in R-051 and R-052 expires. (R-064).

I believe there should be a way to remove a WG from the list of WGs for which a draft is a candidate, but leave the draft in the Candidate state for the remaining WGs.  While tracking a candidate state per draft per WG would accomplish this, logging the removal of the WG from the candidate list in the history should suffice.

Thanks,
--David

> -----Original Message-----
> From: Ed Juskevicius [mailto:[email-masked]]
> Sent: Wednesday, June 23, 2010 12:15 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: Requirements to Extend the Datatracker for WG Chairs and Document Authors
> 
>    "In WGs that do not use the "WG Consensus: Waiting for Write-Up" state,
>     progressed into the "Waiting for WG Chair Go-Ahead" state (in WGs that use
>     this state) or for I-Ds in the "WG Document" state (in all other WGs)."
> 
> >
>   If a "Candidate WG Document" is adopted by a WG ... , the
> Datatracker SHALL ...

---

From: Ed Juskevicius <[email-masked]>
Date: Fri, 25 Jun 2010 14:14:54 -0400

David, Thanks for the on-going dialogue on this.

>> >  Clearly there are limits here (e.g., WG Document is not an optional
state) ....
> I think some more guidance would be useful to help a WG chair make good
choices
> among the optional states - just presenting a state list with "use this
state" checkboxes
> could lead to unexpected results due to lack of understanding of the
implications
> of not using a state. For example:

Sounds reasonable and useful ... but ... I wonder if
this kind of guidance should be hard coded into the Datatracker (e.g. to be
displayed to WG Chairs in real-time when they log-in to disable some of the
optional states from being used in their WGs).  I was thinking it should
appear in a user guide (e.g. on the WG Chairs' wiki), or in some EDU-team
training (at a future WG Chair's lunch)on how to use the evolved
Datatracker.

> I suggest that the tool express a preference for one of the former two
states vs. overloading
> write-up wait on the WG Document state.  Among other things, I would
expect this distinction
> to be useful to the responsible AD.

This sounds reasonable too,  Any suggestions for how the tool
should express a preference for a state in this case?

> In addition, if "In WG Last Call" is used, the tool should recommend (but
not require)
> use of at least one of these two states (Waiting for Write-Up, Waiting for
WG Chair Go-Ahead).
> On a good day, drafts go straight from WG Last Call to IESG submission,
but not every
> day is a good day ...

I could add a couple of requirements to specify that some guidance (or
"Help" text)  be added to the Datatracker, but that just makes be wonder
again if this is the right thing to do versus providing WG Chairs with some
training (and/or a user guide) on how to use the new features of the tool to
best effect.

> I don't think it's that obvious, as we're all familiar with expired drafts
that come back
> to life much later than one might expect.  The ability to distinguish
temporarily expired
> (e.g., due to otherwise occupied authors) from a really and truly dead
draft
> (WG decision) can be important, so my preference would be to have the tool
at least
> recommend availability of the Dead WG Document state.

I agree the "Dead WG Document" state should provide a better indication of
the state of an I-D versus "Expired" ... this is the intended purpose of
the state.  This said, if a WG Chair wants to disable the use of the "Dead
WG Document" state from his/her WG state machine, I don't know how the tool
could recommend anything to change a WG Chair's mind.

Please note that the "default" state of the Datatracker for every IETF WG
will be to have all of the WG I-D states enabled (for use) by each WG, for
every I-D.  The easiest way to maintain flexibility (and perhaps to avoid
complexity) could be for every WG Chair to *not* decide to turn any of the
predefined states "off", but rather to just use whatever "next state" they
want to, whenever they want to, to indicate the progression of an I-D.  The
tool will always suggest a "next state" (based on the WG state machine) to a
Chair, but it will not constrain any Chair to have to follow the state
machine.  A WG Chair will be able to move a document from any WG state to
any other WG state whenever he/she thinks it is appropriate to do so.

> Turning to the candidate states, independently choosing to use the
Candidate WG Document,
> Adopted by a WG and Not Adopted by a WG states seems problematic to me.
 For simplicity
> and consistency I would make use of these three states a single
all-or-none choice.

This is another case of "yes and no".  I agree that WG Chairs who identifty
I-Ds as being in the "Candidate WG Document" state in their WGs should not
try to disable the "Adopted by a WG" or the "Not Adopted by a WG" state.
However, the reverse does not have to be true.  A Chair shoul  be able
to adopt an I-D (and put the I-D into that state in the Datatracker) without
having to first put it into the "Candidate WG Docunent" state.

What would you think of *not* allowing a WG Chair to deactivate the use of
these three states from the state machine in their WG?   Perhaps the ability
to use these states should always be 'on' for every WG, as long as the
flexibility to use these states (or not) for every I-D still resides with
the Chairs.

> My concern is that the separate management is incomplete.  There are
> about half-a-dozen requirements to send emails about the candidate draft
> when various events happen.  Suppose that a draft is a candidate for
> multiple WGs, one of which promptly and definitively rejects it, leaving
the
> others to continue to consider it.  As the chair of the WG that has
rejected the
> draft, I want to see *none* of those event emails.  What appears to be
missing
> is the ability of a WG chair to terminate the candidacy of a document wrt
his/her
> WG before the timer runs out on all the other candidacies for the draft.
> R-064 appears to forbid that early termination:
>
> I believe there should be a way to remove a WG from the list of WGs for
which
> a draft is a candidate, but leave the draft in the Candidate state for the
remaining
> WGs.  While tracking a candidate state per draft per WG would accomplish
this,
> logging the removal of the WG from the candidate list in the history
should suffice.

Good catch !   Having a requirement to implement the above would be very
useful.

How about something like:

     The Datatracker SHALL allow a WG Chair (or delegate) to indicate when
an I-D
    that was in the "Candidate WG Document" state in their WG is no longer
of
    interest to them, before the timer runs out on all the other candidacies
for the
    draft.  The purpose of doing this is to enable the WG Chairs (and
delegates)
    to be removed from the e-mail list for future noticifications about the
status of
    candidacy of the I-D in all of the other WGs where the draft still is a
candidate.
    (R-nnn)

Best Regards,

Ed  J.

>> >  Clearly there are limits here (e.g., WG Document is not an optional
state) ....
Document Shepherd usage:
>> > Also, this text on "Not Adopted by a WG" is subtly wrong when a
document is a candidate for multiple
>> WGs:>
respect to this WG" to the
>> end of the first line.
candidate

---

From: <[email-masked]>
Date: Fri, 25 Jun 2010 16:12:29 -0400

Ed,

> Sounds reasonable and useful ... but ... I wonder if this kind of
guidance should be hard coded

> into the Datatracker (e.g. to be displayed to WG Chairs in real-time
when they log-in to disable

> some of the optional states from being used in their WGs).  I was
thinking it should appear in a

> user guide (e.g. on the WG Chairs' wiki), or in some EDU-team training
(at a future WG Chair's 

> lunch) on how to use the evolved Datatracker. 

IMHO, documentation and training are easy to ignore by comparison to a
brief explanation in a

pop-up dialog box punctuated by "Are you sure you want to do this?" and
Yes/No buttons.

> > I suggest that the tool express a preference for one of the former
two states vs. overloading

expect this distinction

> This sounds reasonable too,  Any suggestions for how the tool should
express a preference for a state in this case? 

Assuming that the IESG concurs with "useful to the responsible AD", a
warning might be:

            The selected states require drafts to remain in the WG
Document state until

            the writeup is completed for submission to the IESG.  Delays
are possible

            between completion of WG activity on a draft and completion
of the

            writeup (e.g., because the document shepherd is very busy).
Use of at least

            one of "WG Consensus: Waiting for Write-Up" and "Waiting for
WG Chair

            Go-Ahead" is recommended to accurately portray that draft
status.

> I agree the "Dead WG Document" state should provide a better
indication of the state of an I-D versus "Expired" ...

> this is the intended purpose of the state.  This said, if a WG Chair
wants to disable the use of the "Dead WG Document"

> state from his/her WG state machine, I don't know how the tool could
recommend anything to change a WG Chair's mind.

Invocation of higher authority? e.g.,

            The "Dead WG Document" state has not been selected.  The
Area Directors

            strongly recommend that the Dead WG Document state be
available to

            distinguish drafts that are truly dead from those that may
have temporarily

            expired.

If that turns out to be correct, "Dead WG Document" state availability
could be mandatory with use optional ... then on the candidate-related
states:

> What would you think of *not* allowing a WG Chair to deactivate the
use of these three states from the state machine in

> their WG?   Perhaps the ability to use these states should always be
'on' for every WG, as long as the flexibility to use these

> states (or not) for every I-D still resides with the Chairs.

What would you think of doing that across the board, removing R-017?:

That simplifies the user experience by making all the states available
to all WGs at all times (no "you didn't select that state" errors on
initial state selection or subsequent attempt to use a state that wasn't
selected), and obviates all of the discussion on state selection
guidance.

> > I believe there should be a way to remove a WG from the list of WGs
for which

> > a draft is a candidate, but leave the draft in the Candidate state
for the remaining

> > WGs.  While tracking a candidate state per draft per WG would
accomplish this,

should suffice.

> Good catch !   Having a requirement to implement the above would be
very useful.

>    The Datatracker SHALL allow a WG Chair (or delegate) to indicate
when an I-D

>    that was in the "Candidate WG Document" state in their WG is no
longer of

>    interest to them, before the timer runs out on all the other
candidacies for the

delegates)

>     to be removed from the e-mail list for future notifications about
the status of

>    candidacy of the I-D in all of the other WGs where the draft still
is a candidate.

>    (R-nnn)

Works for me.

Thanks,
--David

From: Ed Juskevicius [mailto:[email-masked]] 
Sent: Friday, June 25, 2010 2:15 PM
To: Black, David
Cc: [email-masked]
Subject: Re: Requirements to Extend the Datatracker for WG Chairs and
Document Authors

> I think some more guidance would be useful to help a WG chair make
good choices

> among the optional states - just presenting a state list with "use
this state" checkboxes

implications

> of not using a state. For example:

Sounds reasonable and useful ... but ... I wonder if this kind of
guidance should be hard coded into the Datatracker (e.g. to be displayed
to WG Chairs in real-time when they log-in to disable some of the
optional states from being used in their WGs).  I was thinking it should
appear in a user guide (e.g. on the WG Chairs' wiki), or in some
EDU-team training (at a future WG Chair's lunch)on how to use the
evolved Datatracker. 

states vs. overloading

expect this distinction

> to be useful to the responsible AD.

This sounds reasonable too,  Any suggestions for how the tool should
express a preference for a state in this case? 

> In addition, if "In WG Last Call" is used, the tool should recommend
(but not require)

> use of at least one of these two states (Waiting for Write-Up, Waiting
for WG Chair Go-Ahead).

> On a good day, drafts go straight from WG Last Call to IESG
submission, but not every

I could add a couple of requirements to specify that some guidance (or
"Help" text)  be added to the Datatracker, but that just makes be wonder
again if this is the right thing to do versus providing WG Chairs with
some training (and/or a user guide) on how to use the new features of
the tool to best effect.

> I don't think it's that obvious, as we're all familiar with expired
drafts that come back

temporarily expired

draft

> (WG decision) can be important, so my preference would be to have the
tool at least

> recommend availability of the Dead WG Document state.

I agree the "Dead WG Document" state should provide a better indication
of the state of an I-D versus "Expired" ... this is the intended purpose
of the state.  This said, if a WG Chair wants to disable the use of the
"Dead WG Document" state from his/her WG state machine, I don't know how
the tool could recommend anything to change a WG Chair's mind.

Please note that the "default" state of the Datatracker for every IETF
WG will be to have all of the WG I-D states enabled (for use) by each
WG, for every I-D.  The easiest way to maintain flexibility (and perhaps
to avoid complexity) could be for every WG Chair to *not* decide to turn
any of the predefined states "off", but rather to just use whatever
"next state" they want to, whenever they want to, to indicate the
progression of an I-D.  The tool will always suggest a "next state"
(based on the WG state machine) to a Chair, but it will not constrain
any Chair to have to follow the state machine.  A WG Chair will be able
to move a document from any WG state to any other WG state whenever
he/she thinks it is appropriate to do so. 

Candidate WG Document,

> Adopted by a WG and Not Adopted by a WG states seems problematic to
me.  For simplicity

all-or-none choice.

This is another case of "yes and no".  I agree that WG Chairs who
identifty I-Ds as being in the "Candidate WG Document" state in their
WGs should not try to disable the "Adopted by a WG" or the "Not Adopted
by a WG" state.  However, the reverse does not have to be true.  A Chair
shoul  be able to adopt an I-D (and put the I-D into that state in the
Datatracker) without having to first put it into the "Candidate WG
Docunent" state.

What would you think of *not* allowing a WG Chair to deactivate the use
of these three states from the state machine in their WG?   Perhaps the
ability to use these states should always be 'on' for every WG, as long
as the flexibility to use these states (or not) for every I-D still
resides with the Chairs.

> multiple WGs, one of which promptly and definitively rejects it,
leaving the

rejected the

missing

> is the ability of a WG chair to terminate the candidacy of a document
wrt his/her

> I believe there should be a way to remove a WG from the list of WGs
for which

> a draft is a candidate, but leave the draft in the Candidate state for
the remaining

> WGs.  While tracking a candidate state per draft per WG would
accomplish this,

should suffice.

    The Datatracker SHALL allow a WG Chair (or delegate) to indicate
when an I-D

    that was in the "Candidate WG Document" state in their WG is no
longer of

    interest to them, before the timer runs out on all the other
candidacies for the

    to be removed from the e-mail list for future noticifications about
the status of

    candidacy of the I-D in all of the other WGs where the draft still
is a candidate.

    (R-nnn)

Best Regards,

Ed  J.

Document Shepherd usage:

>> > I believe a correct statement can be obtained by adding the words
"with respect to this WG" to the

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jun 2010 17:44:34 -0400

--On Friday, June 25, 2010 02:14:54 PM -0400 Ed Juskevicius 
<[email-masked]> wrote:

> these three states from the state machine in their WG?   Perhaps the

I'm afraid I haven't had much time to review this document, but it's 
unclear to me why there needs to be a complicated discussion about whether 
we should be "allowed" to "deactivate" certain states.  If you don't want 
to use a state, just don't use it.  Problem solved.

More generally, from my point of view there is a hard requirement:

The tool MUST NOT impose constraints on WG process.  Any questions about 
whether I should be "allowed" to use a state, or transition from a state to 
a particular other state, or _not_ use a state, all have the same answer: 
_Of course_ I should be allowed to do that!  The tool's job is to _track_ 
document state, not _control_ it.  The only possible result of imposing 
constraints on what states a chair is or is not allowed to use is to force 
chairs to record inaccurate state to satisfy the tool, at which point the 
tool is no longer doing its job.

-- Jeff

---

From: Adam Roach <[email-masked]>
Date: Tue, 29 Jun 2010 17:03:59 -0500

On 6/29/10 4:44 PM, Jeffrey Hutzelman wrote:
>> use of
> unclear to me why there needs to be a complicated discussion about 
> whether we should be "allowed" to "deactivate" certain states.  If you 
> don't want to use a state, just don't use it.  Problem solved.
>
> The tool MUST NOT impose constraints on WG process.  Any questions 
> about whether I should be "allowed" to use a state, or transition from 
> a state to a particular other state, or _not_ use a state, all have 
> the same answer: _Of course_ I should be allowed to do that!  The 
> tool's job is to _track_ document state, not _control_ it.  The only 
> possible result of imposing constraints on what states a chair is or 
> is not allowed to use is to force chairs to record inaccurate state to 
> satisfy the tool, at which point the tool is no longer doing its job.

I've been struggling to compose a constructive response to this ongoing 
conversation. I'd like to thank Jeff for putting into appropriate 
language exactly what I've been wanting to convey. I agree 100% with his 
assertions.

/a

---

From: Ed Juskevicius <[email-masked]>
Date: Wed, 30 Jun 2010 11:30:58 -0400

Thanks for your inputs on this!

One point that is perhaps not clear enough in the Requirements document is
that the *default* condition of the Datatracker will be to have all of the
different possible WG states to be enabled for use by every WG Chair.

In addition to the above, and in alignment with Jeff's sentiments yesterday,
the default configuration of the Datatracker for each WG will be that every
WG Chair will be able to use all of the states that he/she wants at any time
to indicate the status of an I-D.  Note, this requirement does *not*
constrain any WG Chair to have to use all of the states.  It just means that
all of the states shall be available for use, and ultimately it will be the
WG Chair or his/her delegate who decides which of the states they want to
use to desribe the WG status of an I-D at any moment in time.

The discussion started by David last week pertains to a few "what if"
situations that arise if a WG Chair wants to consciously disable the use of
some of the possible states.  A few people asked for this ability to be
included in the Datatracker requirements specification, and Henrik has
confirmed the Datatracker could be programmed to allow this.  Speaking only
for myself, if I was a WG Chair, I would not use this feature.  I think I
would leave all of the states "enabled for use" in my WG, and I would then
have maximum flexibility to use whatever state is most applicable and
appropriate to describe the WG status of an I-D whenever I wanted to do
that.

The other aspect of my discussion with David last week pertained to "what
should happen if a WG Chair does not manually enter or input the status of
any WG I-D."  Recall that one of the goals of extending the Datatracker is
to provide more visibility to the community about the WG status of every
I-D.  In this context, "more" means more than is available today.

The current proposal is to have the Datatracker automatically generate two
state transitions for every document as described below.  By doing this,
"more" information will get recorded in the Datatracker than is currently
tracker.  The automatic state transitions are as follows:

   1. The Datatracker shall iIdentify the WG status of an I-D as being in
   the "WG Document" state when the WG Chair approves the posting of a newly
   submitted I-D having a filename that contains "draft-ietf-wgname-"; and
   2. The Datatracker will check the WG status of every WG I-D when
   the I-D is put into the "Publication Requested" state in the IESG state
   machine (by an AD).  If the WG status of the I-D is not already "Sent to
   IESG for Publication" by the time it gets to "Publication Requested" in the
   IESG state machine, the Datatracker shall automatically update the WG status
   of the I-D to read "Sent to IESG for Publication".

The above two actions will be done automatically by the Datatracker.
Anything and everything above and beyond the above will be at the discretion
of each WG Chair.  If you want the Datatracker provide more visibility into
the WG status of any I-D, then you (or one of your delegates) will need to
log into the tool to manually enter the WG status of an I-D.

Circling back to the discussion that started this thread ... I would be OK
with deleting the proposed requirement (R-018).  R-018 says that each WG
Chair should be allowed to configure the Datatracker for their WG to disable
the use of some of the WG states from their WGs.

However, the above being said, I did not dream up R-018 on my own.  I would
like to hear if we have people who strongly want to retain this ability.

Best Regards,

Ed  J.

On Tue, Jun 29, 2010 at 6:03 PM, Adam Roach <[email-masked]> wrote:

>> --On Friday, June 25, 2010 02:14:54 PM -0400 Ed Juskevicius <
>> [email-masked]> wrote:
>>
>> we should be "allowed" to "deactivate" certain states.  If you don't want to
>> use a state, just don't use it.  Problem solved.
>>
> conversation. I'd like to thank Jeff for putting into appropriate language
> exactly what I've been wanting to convey. I agree 100% with his assertions.
>
> /a
>

---

From: Ed Juskevicius <[email-masked]>
Date: Wed, 30 Jun 2010 11:39:40 -0400

Ooops.  In my message below, please:

s / R-018 / R-017

Thanks!

Ed

On Wed, Jun 30, 2010 at 11:30 AM, Ed Juskevicius <[email-masked]> wrote:

> In addition to the above, and in alignment with Jeff's
> sentiments yesterday, the default configuration of the Datatracker for each
> WG will be that every WG Chair will be able to use all of the states that
> he/she wants at any time to indicate the status of an I-D.  Note, this
> requirement does *not* constrain any WG Chair to have to use all of the
> states.  It just means that all of the states shall be available for use,
> and ultimately it will be the WG Chair or his/her delegate who decides which
> of the states they want to use to desribe the WG status of an I-D at any
> moment in time.
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Jun 2010 11:07:51 -0500

On Jun 29, 2010, at 5:03 PM, Adam Roach wrote:

>> The tool MUST NOT impose constraints on WG process.  Any questions about whether I should be "allowed" to use a state, or transition from a state to a particular other state, or _not_ use a state, all have the same answer: _Of course_ I should be allowed to do that!  The tool's job is to _track_ document state, not _control_ it.  The only possible result of imposing constraints on what states a chair is or is not allowed to use is to force chairs to record inaccurate state to satisfy the tool, at which point the tool is no longer doing its job.
> 
> I've been struggling to compose a constructive response to this ongoing conversation. I'd like to thank Jeff for putting into appropriate language exactly what I've been wanting to convey. I agree 100% with his assertions.

+1

Ben.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Jun 2010 10:16:50 -0700

I don't see the need to be able to disable tool features, as long as
chairs are not required to use them.
 
What happens if a chair changes his mind about disabling the feature?
how would that effect drafst already in process?
or a change of chairs?
Disabling features sounds to me like a lot of added complexity for
very little benefit.
I would much rather have additioinal useful tools than to spend
money/effort on a disable-feature feature.
Let's have standardized tools
 
dbh

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ed Juskevicius
Sent: Wednesday, June 30, 2010 8:31 AM
To: Adam Roach; [email-masked]
Cc: [email-masked]
Subject: Re: Requirements to Extend the Datatracker for WG Chairs and
DocumentAuthors

One point that is perhaps not clear enough in the Requirements
document is that the *default* condition of the Datatracker will be to
have all of the different possible WG states to be enabled for use by
every WG Chair. 
 
In addition to the above, and in alignment with Jeff's sentiments
yesterday, the default configuration of the Datatracker for each WG
will be that every WG Chair will be able to use all of the states that
he/she wants at any time to indicate the status of an I-D.  Note, this
requirement does *not* constrain any WG Chair to have to use all of
the states.  It just means that all of the states shall be available
for use, and ultimately it will be the WG Chair or his/her delegate
who decides which of the states they want to use to desribe the WG
status of an I-D at any moment in time.
 
The discussion started by David last week pertains to a few "what if"
situations that arise if a WG Chair wants to consciously disable the
use of some of the possible states.  A few people asked for this
ability to be included in the Datatracker requirements specification,
and Henrik has confirmed the Datatracker could be programmed to allow
this.  Speaking only for myself, if I was a WG Chair, I would not use
this feature.  I think I would leave all of the states "enabled for
use" in my WG, and I would then have maximum flexibility to use
whatever state is most applicable and appropriate to describe the WG
status of an I-D whenever I wanted to do that.  
 
The other aspect of my discussion with David last week pertained to
"what should happen if a WG Chair does not manually enter or input the
status of any WG I-D."  Recall that one of the goals of extending the
Datatracker is to provide more visibility to the community about the
WG status of every I-D.  In this context, "more" means more than is
available today. 
 
The current proposal is to have the Datatracker automatically generate
two state transitions for every document as described below.  By doing
this, "more" information will get recorded in the Datatracker than is
currently tracker.  The automatic state transitions are as follows:

1.	The Datatracker shall iIdentify the WG status of an I-D as
being in the "WG Document" state when the WG Chair approves the
posting of a newly submitted I-D having a filename that contains
"draft-ietf-wgname-"; and 

2.	The Datatracker will check the WG status of every WG I-D when
the I-D is put into the "Publication Requested" state in the IESG
state machine (by an AD).  If the WG status of the I-D is not already
"Sent to IESG for Publication" by the time it gets to "Publication
Requested" in the IESG state machine, the Datatracker shall
automatically update the WG status of the I-D to read "Sent to IESG
for Publication". 

The above two actions will be done automatically by the Datatracker.
Anything and everything above and beyond the above will be at the
discretion of each WG Chair.  If you want the Datatracker provide more
visibility into the WG status of any I-D, then you (or one of your
delegates) will need to log into the tool to manually enter the WG
status of an I-D.
 
Circling back to the discussion that started this thread ... I would
be OK with deleting the proposed requirement (R-018).  R-018 says that
each WG Chair should be allowed to configure the Datatracker for their
WG to disable the use of some of the WG states from their WGs.
 
However, the above being said, I did not dream up R-018 on my own.  I
would like to hear if we have people who strongly want to retain this
ability.
 
Best Regards,
 
Ed  J.

What would you think of *not* allowing a WG Chair to deactivate the
use of
these three states from the state machine in their WG?   Perhaps the
ability to use these states should always be 'on' for every WG, as
long
as the flexibility to use these states (or not) for every I-D still
resides with the Chairs.

I've been struggling to compose a constructive response to this
ongoing conversation. I'd like to thank Jeff for putting into
appropriate language exactly what I've been wanting to convey. I agree
100% with his assertions.

/a