ietf
[Top] [All Lists]

Re: Scheduling unpleasantness

2008-03-24 15:16:49
Eric Gray wrote:
Iljitsch,

      I'm not sure that I would say that Philadelphia was
worse than most meetings, but it may have been from your
perspective.

  

Iljitsch is far from alone, just the earliest and most vocal of us. :-)

      This sort of scheduling problem is very well known
to be NP hard and trying to meet the scheduling conflict 
matrix for 1500 to 2500 people would make the "N" large.
  

Universities have been doing this successfully for class scheduling for 
many years
with great success. I would not necessarily classify it as "hard".

o     you can't reliably expect people to differentiate
      what they "want" from what they "need" when asking
      for this kind of input;
  

There are two key constituents, which it cannot be denied meet the 
"must" category.
WG chairs, and presenters.

I was faced with pre-conference scheduling conflicts for two presentations.
They thankfully ended up not conflicting, because the WG's were both 
split in two,
and my presentation schedule was split across the two time slots.

However, both halves of both WGs were scheduled to be simultaneous - WG-A1
and WG-B1 together, and WG-A2 and WG-B2 together.

I would say some close attention could be paid to the subject matter, 
and to determine
that there is in fact a natural overlap between these groups in particular:

IDR
SIDR
RRG
6MAN
V6OPS

(As they all have to do with global routing, advances in routing 
protocols, and new routing
technologies, each with unavoidable overlap in subject matter and 
participants.)

      One approach to address at least these issues is to
consider (perhaps as an experiment) adding a check-list of
meetings people would like to attend to the registration
form, 

There is certainly a very reliable basis for tracking "interest", and in 
particular "co-interest indices",
based on the "blue sheets".

Here's how to do it:
Track across multiple meetings, using anonymized identifiers, to show 
which WGs have significant overlap.
Similarly, break up into several "pools", those with minimal overlap.

Those should ideally form a set of N pools, where each pool needs to be 
coordinated, but where
no coordination inter-pool is needed. The pools correspond to "tracks", 
in track-oriented
conference-speak.

The first step is to acknowledge that there is a problem, and to make a 
commitment to addressing
the problem in a systematic fashion.

Brian Dickson
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf