also sprach Giacomo Catenazzi <cate@cateee.net> [2015-02-15 10:04 +0100]:
> Usually we were sending the two announces in parallel. (but
> I don’t remember discussions, so maybe it was only for technical
> reason)
The advantage of sending separate ones is "buzz", i.e. reminding
people and staying in their heads.
> No, it is not true. Last year, until few days before closing first
> CfP, we had very few proposed talks.
People had very little time last year. I don't think it's a useful
comparison.
> I remember that I was actively encouraging “institutional”
> entities to give a talk. But at first CfP deadline we had already
> to much talks (BTW I think we had also fewer slots).
But we *want* as many talk proposals as possible so that we can
select for quality and diversity, no?
> BTW we have few problems with early proposal of talks (and IMHO also
> for sprint):
> - DPL election (OK, we can reserve a DPL talk anyway)
> - release: I think it is difficult to release team, and also other teams, to
> talk about (and to do sprint about) future releases/transitions/
> changes/etc. before we do a release.
I think the DPL and release team talks are a given and will/should
receive prominent slots even during the Open Weekend no matter
whether the teams write a proposal or not ;)
> For these contingencies, I recommend content team not to push to
> much on the “first-served” basis, for this year, but only to start
> testing it for DC16.
In general, I think first-served basis is not a real guideline we
should use. We might allocate e.g. 10% of slots to very early
submissions if we feel like it's beneficial to have some events to
be able to advertise with (like last year). But in general, I think
that we should select for quality and diversity, as stated above,
between all proposals submitted by the deadline.
--
.''`. martin f. krafft <madduck@debconf.org> @martinkrafft
: :' : DebConf orga team
`. `'`
`- DebConf15: Heidelberg, Germany: http://debconf15.debconf.org
DebConf16: Cape Town: https://wiki.debconf.org/wiki/DebConf16
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)