Re: [proto-team] PROTO - proceeding on adding PROTO shepherds to the tracker

[Henrik Levkowetz <[e-mail]>]

Hi Bill,

on 2006-05-11 21:21 Bill Fenner said the following:
> A couple of comments:
> 
>    *  Candidate WG Document
>       This document is under consideration for becoming a working group
>       document.
> 
>       Possible next states: "Active WG Document", "I-D Exists", "Dead"
> 
> "I-D Exists" is only a synthesized state.  There are two databases;
> the "I-D Database" and the "I-D Tracker database" (as you can see from
> the csv data dumps); a document is in "I-D Exists" iff it is
> in the I-D Database and not in the I-D Tracker database.
> 
> We've got a pending enhancement request to change this, but for now
> this particular transition probably couldn't happen.

Ok.  Would you suggest we take that out, then?  Or should we substitute
a different state which means the same, for now?

> I'm a little uncomfortable with the change in the way the substate
> field works.  The IESG tracker's substate set was chosen to apply
> in nearly any state, and to at least partially make it clear who
> was responsible for the next step.  I've got 2 main concerns:
> 1. Changing the way substates work may be a bigger implementation
>    load - both backend work associating what substates are associated
>    with what primary states, and frontend UI work to enable the
>    right selections (e.g., one of the design goals of the tracker is
>    to still function acceptably without javascript; I don't think
>    you can easily implement "change to the right set of substates"
>    without javascript.)

There's a number of things here.

 * Compared to not changing the way substates work, you're right of
   course - this would be more work.

 * I've heard comments from several ADs, griping about the way other
   ADs combine states and substates in a way which is incomprehensible
   to them.  If there was two truly orthogonal state enums; 'xstate' and
   'ystate', I wouldn't worry about them being independently settable,
   but it seems to me that the current design is a shortcut which is
   causing trouble already, and may be ripe for re-factoring.

 * Is it still a valid design goal to make the tracker function well
   without javascript?  I would question this - not the goal at the
   time of first creation, but that it should still be one today.
   Michael has used plenty of javascript in some of the new pages -
   both the materials upload page and the session request page - and
   I haven't heard complaints about the fact that they use javascript...

> 2. The set of substates seems fairly arbitrary, and doesn't necessarily
>    actually convey more information.  I'd like to suggest instead
>    that you consider if the "Note" field could suffice.

I think that in itself has its own drawbacks.  If you overload too
many functions on 'Note', it becomes much less useful for its original
use, and the additional functions cannot as easily be extracted and
represented as state, and used to trigger things in other tools.

If you were to suggest a new free-form sub-state field, I'd be
happier than pushing this into the existing 'Note', but we'd still not
be able to reliable build anything else on this, or use it to trigger
other tools / functions.

> I think there's a missing transition from "Active WG Document" to
> "In WG Last Call" - if the document is under active discussion
> in the WG, then there's not necessarily a need for a pause at
> "Awaiting Reviews".  Of course, since the states are all selectable
> directly, this is just a convenience.

Right.  I'll add that transition.  


Best,

	Henrik

_______________________________________________
proto-team mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/proto-team