ID tracker Balloting and LC processing

[Thomas Narten <narten@us.ibm.com>]

I just spent some time chatting with Michael and Jacqueline on the new
features of the tool.

Executive summary. They/we will continue to use the old way of doing
LCs and Ballots until the new features are more fully debugged. But we
hope to be able to move to the new systems pretty quickly after a bit
more iteration. We MAY experiment and try using the new features (and
they will work), but there are some known issues so we aren't ready to
switch over yet.

There are two new features in the tool: Last Call processing and
Ballot processing. For the LC processing, there is a window where the
system generates boilerplate, the AD (or secretariat) can edit the
text, and then one pushes a button to have the actual LC message go
out.

There are at least two known issues with the LC feature. The default
text that is generated is not entirely correct, or more to the point,
it looks very different than the last call text in messages generated
in the past. This is a known issue and Michael will fix. Likewise, the
default time for LCs is 2 weeks for all documents, rather than 2/4
depending on WG/individual. That will also be fixed.

The secretariat has been using the new system to generate at least
some LCs this week. This will stop, until the fixes are in place and
we have had a chance to review and provide a go ahead. 

Going forward and how to transition to the new LC system: The ADs can
use the new LC mechanism to request LCs (even now), but they MUST
verify that the LC text is correct and the way it needs to be before
clicking on the button that "requests LC". What they see is what goes
out. :-) After Michael applies his fixes, we can test/experiment. 

Until the new LC system has been more fully debugged, the secretariat
will stop using it and continue to do LCs the old way. Just mail in a
request and the usual thing will happens. For ADs that _want_ to
experiment with the new LC system, that is fine, but be warned that
the text that is in the window is what will get sent out. If you use
that system and say "start LC", the secretriat will assume you know
what you are doing and that the LC message is correct. :-) (Clicking
on the "start LC" doesn't actually send the message, there is still a
step in there where the secretariat has to push the "make it so"
button.)

To transition to the new system, the plan is for Michael to apply some
fixes, and then we can play with it. Once a enough of us have reviewed
it and think it works OK, we'll give the secretariat the green light
to do all future LCs using the system. (Indeed, I think what this
means is that the ADs should just use the tool directly rather than
emailing in requests). This is going to be pretty cool, IMO.

Regarding the Ballot system. There are a bunch of old-style
ballots. There are a few new-style ballots (the secretariat started
converting the old ones, but is only 20% done). This raises the issue
of having two different ways of doing ballots, even for the _same_
document and how do you keep them in sync. Here lies trouble (the
current tool even lets you look at both ballots for the same
document...)

Current plan: All documents will use either the old ballot or the new
ballot, but not both. For now, we'll just stick with using the old
balloting system. ID tracker will use the algorithm of "if there is an
old-style ballot, it gets used". If none exists, ID tracker can be
used to create an on-line one. (The secretariate can also convert
old-style to new style when the time is right).

So again, for the time being, we'll continue using the old ones. But
over the next couple of weeks, a few us will send in evaluations to
use the news system. We'll see how that goes, and onces it looks like
its working fine, will move to it more aggressively. But again, for
now, the secretariat will stick with the old ballots, but individual
ADs can chose to experiment with one of the new ones.

Does this make sense?

Thomas