also sprach Ana Guerrero Lopez <ana@debian.org> [2014-09-16 22:19 +0200]:
> * 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.
Yeah, I can see this very well. We should make sure that people put
at least as much time into making a submission as it takes us to
evaluate it.
Some additional ideas to make our job easier might include:
- Ask participants to provide links to previous events or videos,
allowing us to evaluate the quality of the speaker. Note that
I am not talking about witty audience magnets only, and I have
seen fantastic(ally prepared) speakers who presented in their
!first language and didn't have perfect slides.
- We have not really been collecting feedback on speakers, but
starting this for DC15 would probably make things easier in the
future.
- If we decide to introduce other talks formats, then we should
not be afraid to suggest to people that their event should be
resubmitted for a different format, e.g. a shorter slot, or
a workshop etc.
> * 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.
It'll also attract people to the conference.
> * 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.
This will be hard to present in a tangible way. But I could imagine
having a page for the different tracks, and listing the talks for
each track.
Yes, having attendee "stars" in summit might well allow us to
semi-automate the scheduling, at least let an algorithm do the first
version for fine-tuning by hand.
> * 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.
For bursaries, we had a simple interface allowing us to vote on each
participant with between -3 and +3 points. This would be trivial to
do for events too, I guess.
The actual scheduling would be best done with drag-n-drop, I feel,
but someone will need to implement this on top of Summit. No idea
how hard this is going to be, but it doesn't sound easy.
> * 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.
I think it was great and the buzz is good.
I do not understand your second sentence. Could you please
elaborate?
> * 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.
I think the intensive day approach is going to be too intense, and
we also risk conflicting between tracks in general, i.e. some people
might want to go to "Debian Culture" and "Cloud Computing", which
just happen to be on the same day, so multiple conflicts are
preprogrammed that way.
A track coordinator is a good idea and could even help with
talk selection up front!
But in general, I think it might be better to just schedule
chaotically, ideally based on attendee feedback to minimise
conflicts for those who participate.
> * 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.
My personal thought: it was a nuisance to figure out which track is
best, and none of my submissions really fit anywhere.
So I think we have to chose either to have a pre-defined set of
tracks (with a coordinator knowledgeable in the field) for each,
and then be strict about it… (this can help guide people's decisions
on what to submit)
… or just accept it all and see if we can create any tracks after
selecting the talks we want.
We do not *need* the concept of tracks at all.
> 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.
Nice idea!
--
.''`. martin f. krafft <madduck@debconf.org> @martinkrafft
: :' : DebConf orga team
`. `'`
`- DebConf14: Portland, OR, USA: http://debconf14.debconf.org
DebConf15: Heidelberg, Germany: http://debconf15.debconf.org
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)