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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf