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

Bill Fenner <fenner@research.att.com> Thu, 18 May 2006 19:33 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoFk-00083m-0g; Thu, 18 May 2006 15:33:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoFj-00083W-2N; Thu, 18 May 2006 15:33:43 -0400
Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgoFg-0007yE-PJ; Thu, 18 May 2006 15:33:43 -0400
Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 912BE866C; Thu, 18 May 2006 15:33:40 -0400 (EDT)
Received: (from fenner@localhost) by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id k4IJXeiN013021; Thu, 18 May 2006 12:33:40 -0700
From: Bill Fenner <fenner@research.att.com>
Message-Id: <200605181933.k4IJXeiN013021@bright.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: Henrik Levkowetz <henrik@levkowetz.com>
Subject: Re: [proto-team] Re: PROTO - proceeding on adding PROTO shepherds to the tracker
References: <E1FdpF4-0007xU-Fk@megatron.ietf.org> <446715D7.7080701@zurich.ibm.com> <446726DE.8040904@levkowetz.com> <44673AB3.2050002@zurich.ibm.com> <4467436E.2060400@levkowetz.com> <A9A5C496-4C40-43F8-86C7-8EC882AF85D9@osafoundation.org> <4468F2AA.60707@levkowetz.com> <446980AD.7030200@zurich.ibm.com> <44699905.1090405@levkowetz.com> <93BF5579-D718-4C3E-A3E1-A44F04C87769@osafoundation.org> <446A0AD0.9020007@levkowetz.com> <200605161848.k4GImF4i005235@bright.research.att.com> <446ADEE0.3090301@levkowetz.com>
Date: Thu, 18 May 2006 12:33:40 -0700
Versions: dmail (linux) 2.7/makemail 2.14
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: iesg@ietf.org, proto-team@ietf.org
X-BeenThere: proto-team@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Process and Tools Team <proto-team.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/proto-team>, <mailto:proto-team-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:proto-team@ietf.org>
List-Help: <mailto:proto-team-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/proto-team>, <mailto:proto-team-request@ietf.org?subject=subscribe>
Errors-To: proto-team-bounces@ietf.org

>Mmm.  Either that (but then the two state machines are
>bound together by constraints, for the WG states are
>only meaningful in some IESG states) or we add WG states
>for the cases you mention, which are different from the
>pre-pub-request states.

>Preferences?  I think I'd prefer the latter, to avoid
>having to think about imposing constraints on two bound
>state sets.

Well, I have another idea, which may address both the
"multiple review" issue and the "wg vs IESG states" issue,
but may be too much of a change of model.

The idea is still rough, but basically boils down to
thinking of a document as a ticket in a ticket system,
and blocking tasks as sub-tickets which get opened and
closed as needed.  E.g., in the current state machine,
"New ID Needed" might be replaced with the creation of
a blocking sub-ticket "New ID Needed", which is automatically
closed when the new ID is submitted.  This may solve the
problem of multiple reviews in the WG: create multiple
blocking sub-tickets, for review and WGLC and etc., and
we know the document can proceed when all the sub-tickets
are closed; similarly, the IESG "New ID Needed" sub-ticket
could move around in the WG states all it wants.


That's probably too much of a paradigm change to be the kind
of change to the tracker that we'd like to make now.


When we were designing the tracker states, we originally
put in occasional "pause" states, e.g., there were

AD Evaluation <----> New Version Needed (WG/Author)

and a huge complicated mess of states

Ready for Telechat
Evaluation: DISCUSS
Discuss writing received
Token @WG or Author
New Version coming
AD Re-review
Discuss fix received
Discuss Cleared, wait for approval

which ended up all being resolved with the "generic pause"
mechanism implemented by substates.

I'm concerned that we'll end up with a set of in-WG
states for several different in-IESG states (in
particular, AD Evaluation and IESG Evaluation) so it's
not clear who gets to do what when and use which state
for what and ...

One of the state machines during the design phase
(I don't remember what the colors meant) is at
http://rtg.ietf.org/~fenner/iesg/datatracker-3.1-diagram.ppt

  Bill

_______________________________________________
proto-team mailing list
proto-team@ietf.org
https://www1.ietf.org/mailman/listinfo/proto-team