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

"Emilio A. Sánchez" <> Wed, 30 March 2011 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E2EE28C18E for <>; Wed, 30 Mar 2011 07:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.503
X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=1.314, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hv-VL3FxzszM for <>; Wed, 30 Mar 2011 07:10:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 42A563A69A4 for <>; Wed, 30 Mar 2011 07:10:11 -0700 (PDT)
Received: by fxm15 with SMTP id 15so1199108fxm.31 for <>; Wed, 30 Mar 2011 07:11:49 -0700 (PDT)
Received: by with SMTP id 9mr1378021fae.44.1301494308761; Wed, 30 Mar 2011 07:11:48 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id l2sm62830fam.5.2011. (version=SSLv3 cipher=OTHER); Wed, 30 Mar 2011 07:11:45 -0700 (PDT)
Message-ID: <>
Date: Wed, 30 Mar 2011 16:11:45 +0200
From: =?ISO-8859-1?Q?=22Emilio_A=2E_S=E1nchez=22?= <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [yaco-wgchair-tracker] Testdrive comments and concerns on the "Manage Workflow" tab
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of the Yaco / WG Chairs' and Authors' Tracker Project <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2011 14:10:12 -0000


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.
> Comments / Suggestions on the "Manage Workflow" tab:
> (for example at:
> )
>    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.

> Regards,
> Ed  J.