Re: NUDGE: WG milestones tool requirements:draft-ietf-genarea-milestones-tool-00.txt

[Robert Sparks <[e-mail]>]

Paul -

The current draft paints a history (or at least a current state of things) that is just not true - if we're going to leave the description of the current state  in the draft (my preference),
please capture it more accurately with the next update.

In particular, it has long been the case for me as a chair and as an AD that the creation and modification (which includes deletion) of milestone text requires AD approval.
Changing dates, and marking things done, has not.

I would argue that if the tool allows different policies (which I think  the threads support), that the defaults represent that policy - I would be disturbed by a policy change inflicted by a tool design.

As I noted above, sometimes milestones are deleted - that needs to be added to the set of things the tool will support.

Thanks,

RjS

On May 7, 2011, at 12:20 PM, DRAGE, Keith (Keith) wrote:

> As regards the milestone changes, I've been sending date changes and indicates that the milestone has been completed direct to the IESG secretary for the last 6/7 years and there have never been queries as requiring AD approval.
> 
> All changes of the milestone text, all new milestones, and all deletions of milestones have been to the IESG secretary copied to the AD and the AD has approved.
> 
> As regards the automatic completions of milestones, I see two options.
> 
> 1)	If adding the relationship between the deliverable and milestone means the milestone database has to be amended, then I see no real issue with adopting a specific type of milestone that in format that is tied to that deliverable and has a specific fields that relations to indicate the type of deliverable and the state the deliverable has to be in to allow completion to be declared. 
> 
> 2)	If the structure of the existing milestone database is sacrosanct, then at least automatically give the chairs a notification and a link to update the linked milestone when the deliverable enters the publication request state.
> 
> As regards other comments from Paul, I fail to see why anybody would want a working group milestone to be tied to completion of any IESG action after a deliverable had been publication requested. Such actions are built into the ID tracker, are completely outside the control of the working group, and the ID tracker prompts the AD to make sure they are complete, and tells everyone how long the AD is taking to do that task. The milestones represent the actions the working group can be in control of. There are some valid arguments that there might be separate deliverable milestones respresenting getting the document ready for working group last call.
> 	
> 
> 
>> -----Original Message-----
>> From: David Harrington [mailto:[e-mail]]
>> Sent: 07 May 2011 00:09
>> To: 'Paul Hoffman'; DRAGE, Keith (Keith)
>> Cc: 'IETF WG chairs'
>> Subject: RE: NUDGE: WG milestones tool requirements:draft-ietf-genarea-
>> milestones-tool-00.txt
>> 
>> Hi,
>> 
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Paul Hoffman
>>> Sent: Friday, May 06, 2011 5:28 PM
>>> To: DRAGE, Keith (Keith)
>>> Cc: IETF WG chairs
>>> Subject: Re: NUDGE: WG milestones tool
>>> requirements:draft-ietf-genarea-milestones-tool-00.txt
>>> 
>>> On May 4, 2011, at 10:28 AM, DRAGE, Keith (Keith) wrote:
>>> 
>>>> I think part of the issue regarding the level of approval
>>> of changes is the length of time that this sometimes takes.
>>> If the AD is absent, then certainly a new milestone is not
>>> going to get approved until they return. In the distant past
>>> it sometimes took me several months to set a milestone,
>>> because the AD was unresponsive, and when they did finally
>>> respond, I had to find time to go and remind myself what the
>>> issue was.
>>> 
>>> This can probably be dealt with by a new requirement: that
>>> requests that are not accepted or rejected cause a (weekly?)
>>> reminder being sent to the chairs and AD that there pending
>>> requests, and list them.
>>> 
>>> Does that work for you?
>> 
>> This can be addressed by the chair sending an email to the AD.
>> If the AD is unresponsive to personal emails from his chairs, why
>> would he be responsive to machine-generated spam?
>> I recommend you find out his IM address or his phone, and call him
>> personally.
>> 
>>> 
>>>> I guess the proposal in section 4 at least gives us the
>>> opportunity for trialling a tool and seeing what works.
>>> 
>>> It sounds like you are wanting to see what doesn't work. :-)
>>> 
>>>> Of your 5 bullets,
>>>   o  create new milestones
>>> 
>>>   o  change milestone descriptions
>>> 
>>>   o  change milestone due dates
>>> 
>>>   o  change which Internet-Drafts are associated with a milestone
>>> 
>>>   o  assert that a milestone is completed
>>>> I would note that in my understanding, 3 and 5 do not
>>> currently require AD approval, and I would prefer the default
>>> to retain this.
>>> 
>>> Our impressions differ. I do not think and a WG chair can
>>> make changes to an of those without an AD agreeing to it.
>>> Further, even if you are right, I suspect some ADs would find
>>> that to be an oversight, not a feature.
>> 
>> I believe an AD currently needs to approve milestone changes.
>> Assuming the changes are non-controversial, the AD typically approves
>> quickly.
>> 
>>> 
>>>> In section 5, I would like the linkage to i-ds to be linked
>>> to completion of milestones as well, i.e. that if we have a
>>> milestone of the form "Submit xxxx to IESG as proposed
>>> standard", and that is associated with one or more i-ds, then
>>> when the appropriate state change or changes occurs in the
>>> tracker, then the milestone is automatically marked as
>>> complete (subject to anything in section 4 of course). An
>>> alternative would be to prompt the WG chair for completion.
>>> 
>>> 
>>> This makes a faulty assumption, that milestone text like
>>> "Submit xxxx to IESG as proposed standard" is
>>> machine-interpretable. Today, it is not, and probably cannot
>>> be done easily. In some WGs I have been in, there has been
>>> disagreement about whether such a milestone is met when the
>>> submission starts, or when the the last @#$% DISCUSS is
>>> finally cleared.
>> 
>> My impression is that this is met when the doc becomes offically
>> "publication requested".
>> That's when it is entered into iesg database tracking. YMMV.
>> 
>>> 
>>> Is such automation really needed? Shouldn't WG chairs be
>>> looking at their milestones every month or so to see if any
>>> need to be dispatched? A middle ground might be that when a
>>> draft that is listed in a milestone moves between post-WG
>>> states, mail is sent to the WG chairs noting that fact. You
>>> can then decide when to propose a milestone change.
>> 
>> I think prompting the chair to mark the milestone complete provides
>> more flexibility and awareness.
>> 
>>> 
>>> --Paul Hoffman
>>> 
>>> 
>