Subject: [Tools-team] Updated Meeting Scheduler Requirements

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Wed, 9 Feb 2005 08:43:16 -0500

Hi,

Attached is my update of the meeting scheduler requirements document based on comments received and our discussions.

My apologies for missing the call last week. Unfortunately, we have an all day project review tomorrow so I may miss that call or only be able to call in briefly.

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

8 Feb 2005
Donald Eastlake 3rd

Inputs:
Required:
	*	Room slots available (times and sizes)
	*	Room requests by chairs (duration and size)
Theoretically Optional but Expected:
	*	Non-conflict requests by
		o	Area Directors (defaults to the WGs and BoFs that AD is responsible for)
		o	Chairs
	*	Day of week 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)
	*	AD and Chair requests for
		o	"not same day" meetings
		o	"near" meetings
	*	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

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?
	*	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.

Discussion:
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: 
Implement some sort of prototype, probably file driven rather than having a fancy user interface, and try it on the data for the upcoming Minneapolis meeting or perhaps an earlier meeting if the Secretariat has the data available.

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 09 Feb 2005 15:29:03 +0100

Don,

have you either talked to Marcia or scheduled a meeting with her to discuss 
the aspects that she takes into account when scheduling?

We should use the resources we have.

                       Harald