Subject: [proto-team] WG chair use of the ID-tracker: Proposed tool addition

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 09 Jan 2007 16:05:38 +0100

Hi,

   The proto-team document that describes proposed changes to the
ID-tracker (https://datatracker.ietf.org/) which makes it possible
for WG chairs to use the I-D tracker for managing WG documents
has been revised after the feedback from this list (May 2006).

I've taken out all explicit state transitions; the tracker won't
enforce or check the state transitions.  I've also removed sub-states,
and instead introduced annotations to capture such things as documents
awaiting review.  Multiple annotations may exist at the same time.

As I also mentioned the last time:

Since these changes and enhancements are explicitly meant for Your Use,
Dear Fellow Chairs, it would be very good if you would read and comment
on the document.  Excluding boilerplate etc. the actual content is 6
pages long, so it should be manageable, especially if you check the
diffs (see links below).

The document is available from the internet-drafts repository:
  http://ietf.org/internet-drafts/draft-ietf-proto-wgchair-tracker-ext-01.txt

Diffs between -00 and this version are available here:
  http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracker-ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.diff.html
  http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracker-ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.wdiff.html

Please send comments to this list, with Cc: to [email-masked] .

Thanks,

	Henrik

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jan 2007 17:32:08 +0100

> 
> (B) As a document shepherd, I regularly find myself writing draft RFC
> 	Editor Notes, and I believe that the responsible AD finds this
> 	very useful, as it's more effective to have someone who knows
> the
> 	doc well draft RFC Editor Notes.  Currently, these notes have
> 	to be sent to the AD for the AD to put into the tracker.  Would
> 	it make sense for doc shepherds to be able to put proposed RFC
> 	Editor Notes into the tracker?  

That is probably a design challenge, since they are mixed in with
other parts of the AD's ballot writeup. I wouldn't insist on this,
in case it would need some expensive re-working of that part of
the tracker. It could be an optional requirement?

     Brian

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 23 Jan 2007 18:36:27 +0100

> the tracker. It could be an optional requirement?

Aha.  So the comment I just sent off regarding this was wrong.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 23 Jan 2007 18:34:19 +0100

Hi David,

on 2007-01-23 16:49 [email-masked] said the following:

> I looked at the -02 version of the draft, and have a couple of
> suggestions:
> 
> (A) Drafts don't atomically transition from WG Last Call to Submitted
> 	for publication.  I don't know about other WG chairs, but I
> can't
> 	always produce the PROTO writeups instantaneously (among other
> 	things, I always reread the draft as part of producing the
> 	writeup).  An annotation tag to indicate that the WGLC is
> complete
> 	probably suffices for this situation, and the overall state
> should
> 	be called "Working Group Last Call" as opposed to "In Working
> 	Group Last Call" so that this tag makes sense.

Ah.  Good point.  So tweaking your suggestion a little bit, I think we
maybe should have two states for this:

	* In WG Last Call
	* Waiting for Document Shepherd Writeup

Works?

> 	Editor Notes into the tracker?  There would need to be a cutoff
> 	at some point prior to the telechat to make sure that the IESG
> 	has seen the notes, or perhaps a warning that draft RFC Editor
> 	notes entered too close to the telechat risk document deferral
> 	to the next telechat due to lack of time for ADs to review them.

Works for me (and doesn't require any document changes, I think, since
the document on purpose leaves access open when not explicitly restricted.

	Henrik