Subject: [yaco-wgchair-tracker] Testdrive comments and concerns on the "Manage Workflow" tab

From: Ed Juskevicius <[email-masked]>
Date: Wed, 30 Mar 2011 08:38:32 -0400

Hello.  I have several comments and suggestions about the current Beta code
for the Datatracker Extensions for WG Chairs, after seeing the demonstration
of the tool during the WG Chairs lunch in Prague today.

Comments / Suggestions on the "Manage Workflow" tab:
(for example at: http://beta.wgchairs.yaco.es/wg/alto/management/workflows/
 )

   1. It is a good idea to list all of the possible states (as defined in
   RFC 6174) for documents related to IETF WGs.  I like this.
   2. The above being said, not everyone will memorize the definitions of
   each of the different states (as described in RFC6174)
      - I suggest this page be modified to provide definitions of each of
      the WG document states, or easy access to the state definitions BEFORE
      allowing the Chairs to say they don't want to use some of these states in
      their WGs.
      -
   3.  Next point:  Two of the states (viz. "WG Document" and "Submitted to
   IESG for Publication") appear on the list of possible states (which is
   good), however WG Chairs should not be allowed to decide these two states
   will not be used in their WGs.
      - Section 7 of RFC6175 specifies that the Datatracker will
      automatically move I-Ds into the "WG Document" state and then
later into the
      "Submitted to the IESG for Publication" state when certain things happen.
      - Therefore, the above two states are supposed to be used to describe
      the state of some I-Ds in ALL working groups, whether the Chairs put
      documents (manually) into those states or not.  They are to be automatic
      state transitions.
      -
      - I suggest you hard code a check mark in the "Check Box" that is
      current to the left of both of these two states, and then do not
let anyone
      remove those two check marks.  People who attempt to remove these check
      marks should be presented with a message to explain why these
two states are
      applicable to *all* WGs.
      -
   4. Next point:  The list of possible states is organized alphabetically.
   RFC6174 contains a state diagram showing typical or 'usual" state
   transitions for I-Ds through all of the states, for WGs that decied to use
   all of the states.
      - I suggest the states be re-ordered to more closely resemble how an
      I-D might traverse the state diagram, from top to bottom.
      - I suggest the list be re-ordered to read as follows:
         - Call For Adoption by WG Issued
         - Adopted by A WG
         - Adopted for WG Info Only
         - WG Document
         - Parked WG Document
         - Dead WG Document
         - In WG Last Call
         - Waiting for WG Chair Go-Ahead
         - WG Consensus: Waiting for Writeup
         - Sent to IESG for Publication
      -  If possible, it would be good to include a pointer to the state
      diagram in Section 4.1 of RFC6174
      -

Regards,

Ed  J.

---

From: "Emilio A. Sánchez" <[email-masked]>
Date: Wed, 30 Mar 2011 16:11:45 +0200

Hi,

El 30/03/11 14:38, Ed Juskevicius escribió:
> Hello.  I have several comments and suggestions about the current Beta
> code for the Datatracker Extensions for WG Chairs, after seeing the
> demonstration of the tool during the WG Chairs lunch in Prague today.
> (for example at:
> http://beta.wgchairs.yaco.es/wg/alto/management/workflows/ )
>
>    1. It is a good idea to list all of the possible states (as defined
>       in RFC 6174) for documents related to IETF WGs.  I like this.
>    2. The above being said, not everyone will memorize the definitions
>       of each of the different states (as described in RFC6174)
>           * I suggest this page be modified to provide definitions of
>             each of the WG document states, or easy access to the state
>             definitions BEFORE allowing the Chairs to say they don't
>             want to use some of these states in their WGs.

    Fine, I'll add the definitions from RFC6174

>    3.   Next point:  Two of the states (viz. "WG Document" and
>       "Submitted to IESG for Publication") appear on the list of
>       possible states (which is good), however WG Chairs should not be
>       allowed to decide these two states will not be used in their WGs.

    That makes sense.

>           * Section 7 of RFC6175 specifies that the Datatracker will
>             automatically move I-Ds into the "WG Document" state and
>             then later into the "Submitted to the IESG for Publication"
>             state when certain things happen.
>           * Therefore, the above two states are supposed to be used to
>             describe the state of some I-Ds in ALL working groups,
>             whether the Chairs put documents (manually) into those
>             states or not.  They are to be automatic state transitions.
>           *
>           * I suggest you hard code a check mark in the "Check Box" that
>             is current to the left of both of these two states, and then
>             do not let anyone remove those two check marks.  People who
>             attempt to remove these check marks should be presented
>             with a message to explain why these two states are
>             applicable to *all* WGs.

    I think that probably it's better if we gray out these states and 
disable their checkbox so they can not be unchecked. And probably add a 
message explaining why they can not be throw out at the top of the page.

>    4. Next point:  The list of possible states is organized
>       alphabetically.  RFC6174 contains a state diagram showing typical
>       or 'usual" state transitions for I-Ds through all of the states,
>       for WGs that decied to use all of the states.
>           * I suggest the states be re-ordered to more closely resemble
>             how an I-D might traverse the state diagram, from top to bottom.
>           * I suggest the list be re-ordered to read as follows:
>                 o Call For Adoption by WG Issued
>                 o Adopted by A WG
>                 o Adopted for WG Info Only
>                 o WG Document
>                 o Parked WG Document
>                 o Dead WG Document
>                 o In WG Last Call
>                 o Waiting for WG Chair Go-Ahead
>                 o WG Consensus: Waiting for Writeup
>                 o Sent to IESG for Publication

    Fine, I'll change the order of the states.

>           *   If possible, it would be good to include a pointer to the
>             state diagram in Section 4.1 of RFC6174

    Of course, without problem.

> Ed  J.

    Best,

---

From: Ed Juskevicius <[email-masked]>
Date: Wed, 30 Mar 2011 10:17:27 -0400

Good stuff here too.

Thank You!

Regards,

Ed  J.

-------------------

On Wed, Mar 30, 2011 at 10:11 AM, "Emilio A. Sánchez" <[email-masked]>wrote:

>   I think that probably it's better if we gray out these states and disable
> their checkbox so they can not be unchecked. And probably add a message
> explaining why they can not be throw out at the top of the page.
>
> _______________________________________________
> yaco-wgchair-tracker mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yaco-wgchair-tracker
>

---

From: "Emilio A. Sánchez" <[email-masked]>
Date: Wed, 30 Mar 2011 21:19:38 +0200

Hi,

    All the changes required have been commited [1] and applied in the 
beta server.

    In summary:

    * Added state definitions
    * Freeze states applicable to *all* WGs. In this point I included 
the 'Call For Adoption By WG Issued' cause you need it to enter a draft 
in your WG workflow.
    * Re-order state list
    * Added a link to the state diagram

    Regards,

[1] http://trac.tools.ietf.org/tools/ietfdb/ticket/644

El 30/03/11 16:17, Ed Juskevicius escribió:
> Good stuff here too.
> Thank You!
> Regards,
> Ed  J.
> -------------------
>
> On Wed, Mar 30, 2011 at 10:11 AM, "Emilio A. Sánchez" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>        Hi,
>
>     disable their checkbox so they can not be unchecked. And probably
>     add a message explaining why they can not be throw out at the top of
>     the page.
>
>     [email-masked] <mailto:[email-masked]>