Subject: Meeting Room Scheduling RE: [Tools-team] Agenda for the 30 March 2005 Telechat

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Wed, 30 Mar 2005 11:10:34 -0500

I will not be able to make the call today due to some deadlines that fall tomorrow but I have revised the requrements document, including completely changing the "next step", based on the input received from the Secretariat in Minneapolis. See attached (also pasted below as text).

Thanks,
Donald
 =========================================================
 Donald E. Eastlake III       [email-masked]
 Motorola Laboratories              +1-508-786-7554 (work)
 111 Locke Drive                    +1-508-634-2066 (home)
 Marlboro, MA 01752 USA

Meeting Room Scheduler - Requirements v3
30 March 2005
Donald Eastlake 3rd

This version incorporated inputs from the Secretariat, Harald Alvestrand, and others.

Inputs:
Required:
*	Room slots available (times and capacities)
*	Room requests by chairs (number of sessions, duration, and number of participants)
Theoretically Optional but Expected:
*	Lists of other meeting to not-conflict with by
	o	Area Directors (defaults to the WGs and BoFs that AD is responsible for)
	o	Chairs
*	Day of week and time of day requests by
	o	ADs (should be rare)
	o	Chairs
Optional:
*	Manual assignments (used to meet special requirements)
*	Existing schedule (so changes can be minimized on iterations after first announced schedule)
*	Chair provided list of desired attending ADs at a session
*	AD and Chair requests for
	o	"not same day" meetings
	o	"near" meetings
	o	ordering requests (lists of meeting it would be desirable to follow/precede)
*	Attendee requests for (not currently collected but could be added to registration where attendees could list what/when they would like to attend to provide better schedules and better room size estimates)
	o	Non-conflict requests
	o	Day of week requests

Outputs:
*	A schedule
*	A goodness metric, so quality of schedule for different meetings can be compared and perhaps to provide push back that more room slots are needed or the like

Processing:
*	Option 1: Assuming a function that yields a goodness score for a schedule, assign rooms in a heuristically fashion to optimize that score. This is essentially a batch process. The design of this function is an interesting question and requires weighting of the importance of the different inputs. A variety of functions and parameter values should be tried.
*	Option 2: Assume participants are giving a certain amount of fake currency and are permitted to bid any amount up to all they have to obtain certain schedule properties. This is essentially a continuous on-line process. Many variations are possible. The currency involved in the bids for a property is frozen when the schedule conforms to that property but is released if the schedule changes to no longer have that property. Is losing bid currency available for reallocation by the bidder? How is increasing stability assured as the meeting approaches? Does some part of unused currency from a meeting hold over to the next meeting?
*	Various hybrids of 1 and 2 are possible.

Assumptions:
*	Massive single track events (plenary meetings and social) will be scheduled by a separate manual process and not included in room slots available or room requests.
*	Special events, whether one short or continuing (IESG, WG Chairs, Area Directorate Luncheons, PGP Signing, ...) will be scheduled by a separate manual process and not included in room slots available or room requests.

Discussion:
Discussion with the Secretariat indicates that a primary current problem is the inconsistent format and incompleteness of requests. The process could be substantially improved merely with a good web request interface even without the actual automated scheduling.
Option 1 above is pretty much from the point of view of automating the current manual process. Option 2 is more of a bidding or voting model in which ADs would have more currency/votes than Chairs who would in turn have more than attendees (assuming attendees are added to the mix at some point).

Next Step: 
Mock up a simple web interface to improve the completeness and consistency of requests received by the Secretariat.

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