Hi debconf folks-- Ever write a bunch of code to solve a problem, get to the end of it, and then realize there was a much better way you should have done it?
The dc10 talks team had a long meeting tonight [0], which i'm now pretty
convinced we did the Wrong Way, thanks mainly to my so-called
"leadership" and my lack of foresight and understanding.
I am reluctantly (and unilaterally) asking for a block on acting on
nearly all the results of the meeting. If any talks team member
(present at the meeting or not) reads this and says "what happened was
the right thing; go forward with the conclusions of the meeting as they
stand", i will set my block aside immediately.
What we did
-----------
We tried to decide which talks would be scheduled for the two main rooms
("interschool" and "davis") during daytime hours, addressing it as a
challenge to "cut" proposals based on (a) the ratings in pentabarf, and
(b) the number of time slots we expect to be available for those rooms.
We set aside those proposals which did not belong during daytime hours,
and we divided the remaining proposals into "accepted for scheduling in
the two main rooms" and "not accepted for scheduling". We started by
accepting the highest 50 of the ranked proposals, turning down the
lowest 20, and then went into a deliberative process over the remaining
middle as to whether they should be accepted or not.
We then worked on wording for mail that would be sent to the authors of
the two categories of proposal. [1]
What we missed
--------------
In writing up the mail for the "not accepted for scheduling" proposals,
it became apparent that we would encourage the authors of those
proposals to schedule their proposal in some other room -- it became
apparent that 414 Schapiro seems a likely candidate, and we might even
be able to get other classrooms.
Given the number of proposals, the number of time slots in a day, and
the number of rooms (if you include 414 Schapiro), we actually have more
than enough slots to host all proposals.
And since it seems unlikely that we would want to *stop* someone from
giving a serious, sane talk if space is available, we are actually
effectively accepting all talks.
The important differences between the two main rooms and the other
facilities we have are:
a) the main rooms are bigger (davis and interschool accomodate 200 and
75 people, respectively. 414 Schapiro and other classrooms seat ~20),
b) video-team can only realistically cover 2 events concurrently, so
the main rooms get video coverage, but the others don't.
However, our division of talks into "two main rooms" vs. "other" was
done based mostly on in-penta scoring, which is *not* the criteria we
should be using to decide room placement. Two examples of potential
problems:
0) we have both "main-room" and "non-main-room" proposals that were
desired to be part of tracks. We had talked about wanting tracks to run
in contiguous time slots in the same room. Do we want folks to have to
shuffle from room to room to follow a track?
1) we have some "non-main-room" proposals that seem likely to attract a
large crowd and probably warrant video (e.g. 532), while some excellent
"main-room" proposals will almost certainly be small and not want or
need video (e.g. 573). This is seems precisely wrong.
What should we do?
------------------
I think we should send an acceptance e-mail to all serious, sane,
non-withdrawn proposals as soon as possible. This e-mail should not
specify which room the proposal will go in.
Following that, we should try to allocate them to different rooms, based
on the following criteria:
0) how many people we expect to attend
1) what resources are needed (video-team coverage is the main thing i'm
thinking of here)
2) the max number of attendees the presenter(s) are willing to accept
3) membership in a track
These allocations wouldn't be perfect or fixed in stone, but would help
whoever does scheduling to see where they might fit best.
What was OK?
------------
I said i want to block "nearly all the results" of the meeting-- i think
our decisions about what proposals should be plenaries (i.e. having
nothing scheduled opposite them) were reasonably done, and i don't see a
reason to object to some of the in-track merge suggestions we came to.
I'm very sorry about this, and sorry that my block here makes the talks
deadline slip still further. Please tell me if i should withdraw my block.
As part of my debconf10 organizing work, i will try to gather opinions
and document how we *should* have gone about things in hindsight, so
hopefully others can learn from our mistakes.
--dkg
[0]
http://wiki.debconf.org/wiki/DebConf10/Meetings#talks_team_meeting_Wednesday_2010-06-02_23:00UTC__.287pm_NYC_time.29
[1] http://wiki.debconf.org/wiki/DebConf10/TalkDecisionEmails
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
