[yaco-wgchair-tracker] Testdrive comments and suggestions on the "Manage Delegations" tab

[Ed Juskevicius <[e-mail]>]

Hi.  This message contains a few comments and suggestions about the
Beta-test code running the "Manage Delegations" tab:

When someone goes to this tab in the WG-Chair Datatracker, and then tries
to assign someone to be a delegate for them, an e-mail address for the
person needs to be entered.  If the e-mail address is not recognized by the
Datatracker, a warning message is displayed.  There are a few spelling and
grammar issues with some of the text used in the warning.

Part of the Warning text currently is:

>  An email will be sent to the following address to inform that the person
designated
> sould contact with the Secretariat to obtain their own user-id and
password to the
> Datatracker.

I suggest the text above be replaced with the following words:

   - An email will be sent to the following addresses to inform that the
   person you have designated to be one of your delegates currently does not
   have login credentials for the Datatracker and should contact the
   Secretariat to obtain their own user-id and password for the Datatracker.

Related to the above, I can't tell (from my test drive of the Beta code)
whether the Datatracker will actually add the e-mail address of the person
who was delegated (per the above) to the list of Delegates if a Chair
decided to proceed with the Delegation anyway .... or not.  If "yes", then
good.  If not, how and when will the tool know to add it later?   I tried to
test this just now, but nothing happened.

Thanks,

Ed  J.


On Wed, Mar 30, 2011 at 8:38 AM, Ed Juskevicius <[e-mail]> wrote:

> 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.
>