[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Debconf-team] Report from the talks team



Hi everybody,

This is a quick summary of how the talks team worked this year. This mail only
describes the talk selection process and scheduling. The scheduling of the
ad-hoc talks was done by Michael Banck so we'll let him comment on this regard.
Also, some personal comments from members of the talk team extending some of
the points might follow.

=== Overview ===

The talks team had a slow start because we needed to adapt the new conference
management system. Despite this, it was all fine because we did the talk
selection quite fast. The deadline for talks submission was July 7, we
published the accepted talks on July 19 and the final schedule on August 3.

We received 115 event submissions and we only had space for a maximum of ~ 84
or so. Still we needed to accept less events and keep some space for
rescheduling and last minute talks. We accepted 80 events. We published a post
about this: http://blog.debconf.org/blog/2014/07/21#talks-review-finish

The period to submit events was opened for 4 weeks. The first two weeks were
very slow and some of us were concerned about not getting a lot of events.
However, it's true that plenty of people wait until last minute, specially
after the last reminder. Instead of just sending plain reminders, we accepted
some talks and published an announcement. This worked well, but we will never
know if it was because of the reminder or because people got inspired.

We sent a last reminder 3 days before the deadline and we got a bunch of
submissions after this. Something like a 30% of the submissions came in the
last days. We think this was because of the deadline and because the conference
dates were close and people have started making plans.

== Talk selection process ==

We didn't use summit to do the talk selection. We used a different system:
people in the committee checked a CSV dump with the list of talks individually
and only marked those talks they thought that shouldn't be accepted or needed
some discussion before being accepted. Then we assembled the data of all
the members in one spreadsheet. The talks without any mark were directly
accepted.

Finally, we had a 2.5 hour IRC meeting, where we discussed all the talks that
some member of the team had already marked to discuss and we discussed them
one by one. We realized that we have marked as accepted more than 80 talks
and therefore we need to cut down.

Post meeting, by email, we discussed which talks were candidates to reject
or merge.

== Tracks ==

Similar to previous DebConfs, we associated some thematically-related talks
together into tracks. We started with some tracks used by previous DebConfs,
and we also created new tracks once we found more than 3 different talks on
a similar topic. We also encouraged people interested in a topic to submit
their tracks.

When scheduling, we tried to have all the talks of a track scheduled the same
day, except in the case where we have to put a talk in another day due to other
constrains. This helped some attendees organize their participation in the
conference,  However, some people mentioned that spreading the associated
sessions throughout would have worked better for them and avoided thematic
burnout.

== Scheduling ==

The first draft of the schedule was done taking into account the arrival/departure
date of the speakers, then it was scheduled based on tracks, one track cover a
full session of several related talks, empty space was important, some gaps
were intentional as noted before.

Later on, we moved some talks based on the feedback of the speaker and taking
into account the size of the rooms.

Some live rescheduling was performed during the conference, usually to address
the capacity of the rooms. We didn't have an exact number of expected attendees
per talk, but  we could estimate based on the summit's information of the talk.

== Conclusions ==

* We must find a way to make submitters to make better talks descriptions. Bad
or incomplete talks description made to waste a lot of time to both the talks
team and attendees.

* Publishing the list of accepted talks ahead and taking the time to schedule
seems to be a good idea. There are plenty of people making travel plans at
the last minute and allows last minute additions.

* To take better advantage of Summit's interface, probably we should provide
the list of talks still without scheduling, and wait for people to fill in
their talk interests and use this data for better scheduling.

* Doing the talks selection off-line without having to rely in the web interface
but still with all the data about the talk, seemed to work fine.
But we might want to study betters way to implement this that a big CSV dump.

* We don't know if accepting some talks ahead was good for encouraging events
submission or not, but it created some buzz around the conference. It also
makes some of us wonder if there was a skew of the criteria used to select
the talks accepted before the deadline and if this was a sensible bias or not.

* When scheduling tracks we need to know what's the best temporal organization:
- the "intensive day" approach
- the "repeated theme" approach through the full conference
- or just making sure the associated talks do not run concurrently.
Having a designated coordinator for any given track can help us make
the relevant decision for future conferences.

* Some of us wondered if the tracks should not have been presented for people
to choose from during event submission, or if they were, they need to be clearly
marked as "optional" or "any" -- when we added tracks partway through
the conference, we should have been able to try to group the tracks later.
Another possibility would have been encouraging people to type in 3 or 4
keywords about their proposal to make it possible to have a tag cloud that
would "bubble up" ideas for possible new tracks.

* Finally and not less important. We also wondered a lot about the length of
the talks slots. Some talks didn't seem to need a full 45 min slot and some
others seemed like demos to us and we directed them to do a demo. This also
leads us to merge all the GSoC talks in 2 long sessions when maybe some
projects would have been OK with a 20 min session and others with a 45 min
session. We need a more worldwide discussion about this.



== Links ==
Call for talks: https://lists.debian.org/debian-devel-announce/2014/06/msg00000.html
https://bits.debian.org/2014/06/debconf14-cfp.html

First reminder: http://blog.debconf.org/blog/debconf14/cfp-published-talks.dc
Second reminder:   http://blog.debconf.org/blog/debconf14/cfp-published-talks_second_batch.dc
Data:  http://blog.debconf.org/blog/debconf14/talks-review-finish.dc
Schedule available: https://bits.debian.org/2014/08/debconf14-schedule-available.html


Reply to: