Eric Gray wrote:
I'm not sure that I would say that Philadelphia was
worse than most meetings, but it may have been from your
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
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
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:
(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
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
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",
The first step is to acknowledge that there is a problem, and to make a
commitment to addressing
the problem in a systematic fashion.
IETF mailing list