Subject: [Tools-team] Meeting Room Scheduler Requirements

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Wed, 12 Jan 2005 11:16:58 -0500

Hi,

Attached and below is what I came up with.

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
			Donald Eastlake 3rd

Inputs:
	Required:
	*	Room slots available (times and size)
	*	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
	Optional:
	*	Manual assignments (used to meet special requirements)
	*	Existing schedule (so changes can be minimized on iterations after first announced schedule)
	*	Non-conflict requests by
		o	Attendees (not currently collected but could be added to registration where attendees could list what they would like to attend to provide better schedules and better room size estimates)

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:
	*	Assuming a function that yields a goodness score for a schedule, assign rooms in a heuristically fashion to optimize that score. 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.

Assumptions:
	*	Massive single track events (plenary meetings and social) will be scheduled manually and not included in room slots available or room requests.

Discussion:
	The above is pretty much from the point of view of automating the current manual process. There are alternative points of view such as more of a "bidding" model where ADs and Chairs (and perhaps later attendees) are each given an appropriate amount of some fake currency and they express how strong each of their scheduling desires is by how much of their currency they are willing to pay to get their way. This implies a relatively continuous on-line bidding system whose results are frozen at some point as opposed to the "batch" system described above.

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: Tue, 18 Jan 2005 12:25:34 +0100

one more class of input:

requests for groupings "near" each other, "not on the same day" and "on 
these specific dates of the week".

the last one, when legitimate, is usually caused by some other organization 
scheduling a meeting that partly overlaps the IETF week.

                    Harald

--On 12. januar 2005 11:16 -0500 Eastlake III Donald-LDE008 
<[email-masked]> wrote:

> 		o	Area Directors (defaults to the WGs and BoFs that AD is responsible
> for) 		o	Chairs
> 	Optional:
> 	*	Existing schedule (so changes can be minimized on iterations after
> first announced schedule) 	*	Non-conflict requests by
> 		o	Attendees (not currently collected but could be added to registration
> where attendees could list what they would like to attend to provide
> better schedules and better room size estimates)
>
> 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:
> 	*	Assuming a function that yields a goodness score for a schedule,
> assign rooms in a heuristically fashion to optimize that score. 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.
>
> Assumptions:
> 	*	Massive single track events (plenary meetings and social) will be
> scheduled manually and not included in room slots available or room
> requests.
>
> Discussion:
> 	The above is pretty much from the point of view of automating the
> current manual process. There are alternative points of view such as more
> of a "bidding" model where ADs and Chairs (and perhaps later attendees)
> are each given an appropriate amount of some fake currency and they
> express how strong each of their scheduling desires is by how much of
> their currency they are willing to pay to get their way. This implies a
> relatively continuous on-line bidding system whose results are frozen at
> some point as opposed to the "batch" system described above.
>
> 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.
>
>