[rgchairs] Re: 65th IETF - WG/RG/BOF Scheduling

[Henrik Levkowetz <[e-mail]>]

Hi Allison, 

on 2006-01-17 17:09 Allison Mankin said the following:
> Hi, Henrik,
> 
> I've taken [e-mail] off the cc list so we don't keep generating
> tickets for them while we discuss the tool design.  Or should we move
> to tools-discuss?  I think this mail will get to the tool developer.

Immediately when I got the response from [e-mail] I thought
'Oh, dear, I should have taken them off the list..."  But we can add
tools-discuss.

>> Also, I have lists of conflicts from previous years, which I use as a
>> base for the request this time.  I'd love to be able to just type
>> in the list, but the tool forces me to use the drop-down list.  A bit
>> awkward.
> 
> The purpose of this tool (I understand) is so that simple initial machine
> processing can be done on the WG chairs' scheduling inputs, before the
> human brain (the brilliant Marcia!) NP-complete effort of making the 
> actual schedule.
> 
> Having seen a lot of the Chairs' unstructured requests, I know they are
> very varied, even to the form of the lists for conflict avoidance:
> misspellings, shorter names than the real short names, SIP/PING
> instead of both names, descriptive terms.  It's understandable
> but hard to use.

Yes, understood, and I would expect exactly this filtering to be done
by the request tool - but that can be done by validating the manually
entered list by a javascript snippet before submission, or by a server-
side script on submission; and in both case returning the user to the
original form for correction of his/her input.  Doing things the current
way makes life easier on Marcia, which I absolutely support, but it makes
the task harder than necessary on the chairs.

The tool author is already using javascript for various tasks in the
form, so moving to a pre-submit validation model instead of a constrained
entry model shouldn't be impossible.

> What I'm wondering is whether at IETF 65, the session will come
> up pre-configured with the previous conflict list, and allow the chairs
> to edit that...

Sounds like a good idea - and that would also work better with a
pre-submission validation, instead of the current constrained entry :-)

>> The tool forces me to skip that and list first-priority conflicts
>> before I may list second-priority conflicts.  Is that necessary?
> 
> I agree, you should not have to do this.   Something for the fix list, IMO.

Ack.


	Henrik

_______________________________________________
Rgchairs mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rgchairs