Re: [charter-tool] Fwd: I-D Action:draft-ietf-genarea-charter-tool-04.txt

[Paul Hoffman <[e-mail]>]

On 1/24/11 1:25 PM, Robert Sparks wrote:
> Apologies for the shotgun nature of the following comments, but I
> wanted to get what I had to you now rather than later (apologies for
> the delay so far):
>
> In the data for the WG record, should the Secretary(ies) be
> included?

Sure; added.

> The tool shouldn't force the chairs to be populated for anything
> except actual issued charters. Allowing them to be populated is ok,
> but it can't require them.

Done.

> The tool should make it easy to track information and make the right
> changes if the name of the group changes during, or especially at the
> very end of, the BoF and review phase.

Not sure what you mean here. It already allows changes; are you asking 
that someone can look up the earlier name and find the current charter 
proposal?

> When closing groups, documents in flight may end up in other groups,
> not just be withdrawn or converted to individual. There may be other
> possible dispositions as well. I think the text is saying the tool
> should remind the AD to say something, not constrain what the AD is
> going to say. Could you make this clearer? In any case, it should be
> clear if this tool is supposed to go touch document records. (I think
> the answer is no. The responsible AD can use the existing tracker to
> make the appropriate changes to the documents.)

Good call; fixed.

> The charter naming convention was useful for stating search and
> compare requirements, but I would prefer that it be described as a
> way to be precise in stating the requirement rather than declaring
> that the solution (something meeting those requirements another way
> might make tracking name change I discuss above easier for
> instance).

I'm hearing mixed messages. :-) I think a contractor implementing this 
would be much more likely to get it right the first time if we are 
specific. If you want something different for the specific naming 
algorithm I gave, that's cool, but asking a contractor to come up with 
their own isn't likely to work as well as us defining one.

> "Initial IESG and IAB review" does not match the string "Internal
> Review" that shows up in the agendas now.

Correct. "Internal review" does not describe whom it is internal to. 
Part of the purpose here is to make the states more understandable to 
the wider audience who will now be tracking charters. Is the difference 
a problem in this case?

> Instead of "extend the current ballot system", I would prefer a
> requirement that said "use a mechanism similar to the current ballot
> system". (It would probably produce surprising results to have
> ballots for the charters show up in searches across the set of
> ballots for documents. It would add an exceptional case, for
> instance, when trying to build stats across those searches "Standards
> track, Informational, Experimental, and Charter (?!)".

Good catch. Fixed.

> I think we should be really careful to distinguish those parts of the
> document where we are capturing requirements that reflect what we
> currently do vs those parts where we're building the tool to let us
> do something different. In particular, we should try really hard not
> to let a requirements document for a tool be the place where we
> establish process. For instance, " The normal next state is "Initial
> IESG and IAB review" if the idea is accepted, or "WG exists" if this
> attempt to recharter is abandoned. " doesn't map onto existing
> process very well. Things go into Internal Review...

The normal next state is just a suggestion; an AD can move the charter 
to any state. I have now made that clearer.

All these changes now appear in the -05:

	Title           : Requirements for a Working Group Charter Tool
	Author(s)       : P. Hoffman
	Filename        : draft-ietf-genarea-charter-tool-05.txt
	Pages           : 10
	Date            : 2011-01-29

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-genarea-charter-tool-05.txt

--Paul Hoffman