Re: [Debconf-team] talks team reportback (and block on meeting results)
Hi,
On Thu, Jun 03, 2010 at 03:47:52AM -0400, Daniel Kahn Gillmor wrote:
>
> 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 have been following talk/discussion in talk@debconf.org and this list.
And being unaware of possible discussion about talks stuff in real life,
I was expecting yesterday's meeting going much more smooth.
From my POV, no everybody was in the same page, I do not know if it was
because some things should have discussed more via email or because no
everybody has read (and participate) in all the threads relatives to talk.
Also, I think you were worrying too much about how the scheduling should
work in advance. Ideally, the team doing the schedule should have been
following the talks team or being a small set of the talks team, but
as I see it the first step is accepting the talks that seems to be good
and fitting for debconf and after that, then you worry how to schedule
them.
Finally, the new idea of tracks seems to have added some extra complexity
to the already complicate mix.
> 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.
>
Could you explain here what do you mean here with a "block": "ask for a
block", "set my block"? I got an idea of what could mean but I want to
be sure :)
> 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]
>
All fine here.
> 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.
Here is the problem we hit on previous years and lead in the creation
of the infamous "unofficial" track:
we reject your talk but you can do it "unofficially". There is not
difference with the "official" talks. At least not with the ones
schedules from the beginning (difference here: video recording)
> 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 I understand here: you were worrying about scheduling again instead of
looking what talks should be accepted and what talks should not be.
Also that we have available 3 or more (small) talk rooms.
I think we should not accept all the talks and we should not use more
than 2 rooms and in some cases just 3. My explanation about this in the
following part.
> 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.
As mentioned, we should not do talk selection and scheduling (room talk
allocation) at the same time. Firstly, we just should select the talks we
see fit and seem good for Debian and reject all that does not fall in this
category. Then we worry at how use the resources we have.
We have got very few submissions this year and plenty of talk room space,
that does not mean we have to accept stuff we are not fully convinced is
good. I prefer having 2 rooms with good stuff that 3 rooms with this good
stuff mixed with the no-so-for-debconf. (For posible speakers reading this
some stuff is good, just it is not debconf type according to this year's
talk selection commitee).
Also, we have plenty of last time stuff from ideas people come up during
the weeks previous to DebConf (sometimes even during DebCamp and DebConf),
and most of the time this last minute bofs/talks are very *good*. I think
this side of unconference of DebConf is very productive for atteendess.
So if we end accepting only 70 talks, do not worry, we won't have "empty"
places in the schedule, some proposals that will come last minute can go
there. We should reserve some space for this last minute/weeks talks.
I regret now last year I did make copies of the "first draft ideal" agenda,
the agenda in the 2nd/3rd day of debcamp and the final agenda. Then you
could compare those with the final agenda and it would explain my idea
very well.
Finally, I could so some number comparisons about number of talks,
number of attendees and number of talk attendees per year. Since I do not
feel like gathering numbers, I will just add that what I have perceived,
is 2 talk rooms and in some slots 3 talk rooms is what seems to work.
Answering to "What should we do?" my suggestion:
- Accept 65-72 talks we believe are good for debconf. Send accept/reject
email. Publish list of accepted talks without scheduling. To rejected
talks add we are studying the possibility of a extra unconference talk that
does not need to be necessarily recorded and still to be decided.
- Keep allowing late submissions in penta.
- Gather talks requirement and schedule the accepted talks in the 2 main rooms.
- In some moment, maybe 1 week before debconf look at the late submissions,
see if something late minute is worthwhile to be added to the main set of track.
Usually this is interesting debian stuff that would benefit of being record.
Look at the what there is left and study how to organize the unconference
track in a 3rd room. extrasuggestion: This does not need to be a schedule
organized in penta.
This suggestion is assuming we only have video in 2 main talks, we tried to
put there the best material and we still allow and encourage last minute
talks without stress to video team because it is not recorded, and no stress
for the scheduler team because they do not need to update penta every 2 hours.
Finally, I have not seen any reference in the logs to what happens with
the DebianDay that must be the first day in the "main" room after the opening.
We discussed this here:
http://www.mail-archive.com/debconf-team@lists.debconf.org/msg03957.html
> 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.
I do not understand this part sorry. As said above, could you define what you
mean with your "block".
Finally, my analysis here is mixed with my opinion personal and experience of
previous years, so do not take it as something that tries to be subjetive.
Ana
Reply to: