Dear Moray, chairs, team,
Thanks for the list, I greatly appreciate the impetus and to me it
looks like a step in the right direction.
The real work will be to kick this off and make it work smoothly
without killing any efforts in their tracks through
over-engineering. The main purpose of these roles should be to ease
decision-making, for instance by defining areas of competencies
within which the team *can* freely make decisions, while fostering
a culture where people don't have to be afraid of waking the
bikeshedding-monster if they want to seek input from others.
So there's work ahead, but we are well on our way. I do have a few
comments:
> - Content: schedule scheme, CFP, talk/session selection and
> scheduling, inviting guest speakers, anything related to the
> content of the conference
I think we ought to be careful not to prevent any innnovation if
we're going to have a team sticking to/defining known-good
approaches. We should ensure that new ideas should be considered and
tried, e.g. such as happened for DC14. Some of the ideas e.g.
regarding schedule scheme were already around before the DC15 bid
was even selected and I would find it rather unfavourable if big
teams were discouraged to come up with their own ideas, or unable
later to see (some of) them through. We move DebConf to a different
continent (more or less) each year, and IMHO, it'd be very
interesting to allow local teams to give "their" conference
distinguishing touches (within the realm of the plausible, of
course — this is what the content team should ensure…)
> - Facilities: accommodation, food, venue negotiations and venue
> arrangements, including for social events: cheese and wine, formal
> dinner, day trip, and any other semi-formal gathering
I feel like there ought to be "facilities" and "events".
For your questions:
> - Should we have a separate "Communication" team, with {press and
> PR, website content, publishing the CFP and general announcements,
> dealing with feedback@dc}? There could be benefits, but equally
> I worry about trying to create our own version of the Debian
> publicity team, and about going against the "avoid overlapping
> roles between subteams", since other teams would have to work
> closely with this one if it is to have a real purpose.
The Debian publicity team is understaffed and we cannot expect them
to create the buzz we want/need. So while I think we should be
working with Debian on this (just like with fundraising, and
infrastructure, etc.), we're definitely going to be the ones who
need to bring up the guts and the stories and the initiatives. So
I think there ought to be a team for press work, website content,
social media channels, announcements, blog, buzz, etc., and I think
its job should be to do their work together with Debian publicity.
> - In the slightly longer term, should we make subteam leads
> automatically/ex-officio become members of the DebConf Committee,
> for venue decisions etc.?
I think we should keep the bid decisions team rather small and
comprised of people who have a lot of experience, ideally because
they've seen DebConf organised many times. Those people should
ideally be working *with* the bid teams before their bid is
submitted, so that when the bid decision is made, it'll be possible
to arrive at a well-informed decision in limited time, without
requiring there to be much talk or consensus.
The current committee, which basically every past or current
organiser can join and then show up or not is not really ideal. I'd
want to see e.g. 5 people committed to developing bids and making
a decision, and those 5 people should have a firm grasp on the
organisation of DebConf, and ideally represent some of the sub-teams
we are creating, to be able to better examine specific aspects of
bids, e.g. venue suitability, finances, travel, etc.
--
.''`. martin f. krafft <madduck@debconf.org> @martinkrafft
: :' : DebConf orga team
`. `'`
`- DebConf15: Heidelberg, Germany: http://debconf15.debconf.org
DebConf16 in your country? https://wiki.debconf.org/wiki/DebConf16
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)