Excellent points Martin, I completely agree. Perhaps we can chat over a beer how similar these comments are to my experiences! TEDx are independently organised events, running into, I can't remember the numbers, but thousands across the globe. And everyone had their own idea what TEDx is and should be - even in our team these were different! I agree the brand created some sort of common vision, but the power of the brand also brought a LOT of ego, and there wasn't a common goal, like Debian has. (TEDx is about feel good fluffy, not actually doing stuff. But I digress) This was why I left. So yes, DebConf will have different issues, but in some ways those are better to have, I hope. :)We tried to solve these issues, with varying levels of success, by trying to get to the drivers of the behaviours and choices, always asking WHY. So rather than putting a 'to do' list, have a set of questions in the checklist to get everyone on the same page. Anyways, this will grow and develop over time. Excited to get my hands dirty with this again, see if I learnt anything from before :)I don't see these docs as copy paste and change the names. I just see these docs as pointing in one direction to get a conversation started.BOn Thu, Feb 19, 2015 at 12:03 PM, martin f krafft <madduck@debconf.org> wrote:also sprach Bernelle Verster <bernellev@gmail.com> [2015-02-19 07:57 +0100]:
> These are the resources TEDx uses to guide their volunteer teams.
>
> I intend to work through this and adapt to DebConf, as I understand it,
> mostly to just get my mind in gear, it's been a while :) but here's the
> link if you feel like browsing.
>
> http://www.ted.com/participate/organize-a-local-tedx-event/tedx-organizer-guide
Bernelle, this looks like a fantastic resource. I can only dream
about having something of similar spirit applicable to DebConf, and
I'll edit a shared document in Google with you (once!) if you pull
this through! ;)
There is one thing to keep in mind though: the TEDx organiser guide
seems to be created by an organisation that rightfully has the claim
to "own" TED/TEDx, or maybe managed to formulate a concrete vision
and set the ship off to sail.
What I am trying to say is simply: there is a body out there that
gets to answer questions such as "what's a great talk" or make
statements along the lines of "this is the way it's been done" in
general. Correct me if I am wrong.
This is not the case in DebConf. DebConf is organised by all of us.
Every single one of us gets to shape it, introduce ideas and add
their own touch. While we surely have some ways to learn to better
incorporate new ideas, we're on the right track. We do have a vision
and principles, but they are *much* more abstract and cannot really
be used to build a comprehensive conference "how-to" in this way.
It's been tried…
A DebConf resource as such can only ever be a collection of
experiences. The problem with attempts to document those in the past
has always been that the list only ever grew and it was hard to
consolidate. At the same time, since nobody did consolidate, the
ever-growing list of experiences became less and less relevant to
decision-making processes.
So if anyone were to approach this task for DebConf, this would be
my advice: build a skeleton of typical decisions that are to be
made. Don't do this in your basement, but engage with the people
working on the tasks. Getting them on board early might make things
harder short-term (we are all very opinionated and protective of the
our very own images and dreams of our conference), but not doing so
will just mean that your resource will never be accepted.
Once you have such a skeleton of decisions, populate it sparsely.
Maybe it makes sense to have somewhere deep down a list of every
DebConf and how they addressed a question and what was perceived
good or bad about it; such a list can also grow and grow as people
add their memories. But at the first level, pick out only 2–3
salient experiences.
For instance, right now, DC15 is discussing general scheduling.
There are ideas about starting each day with a plenary (keynote,
lightning talks, etc.) and only to disperse into smaller events
afterwards. This would be a first for DebConf.
Similarly, DC14 got rid of DebCamp and introduced the idea of having
"hack days" or "hack time" in general, interspersed with programme.
Some people liked it, some didn't.
Before that, schedules would mostly be square and crammed, and
I think a lesson learnt was that this was too rigid and left too
little space for ad-hoc events and social interaction.
Why am I writing all this? Because I feel that this sort of
experience is what's really relevant when it comes to DebConf.
Nobody is going to be able to just put their foot down about the
schedule for DebConf16, but it's also not going to be the decision
of the local team alone. Yet, we are striving towards a culture
where we are able to entertain new ideas and embrace change (I
hope…). It'll be much more likely for the whole dc-orga team to
adopt ideas if these are built on existing experience. So mentoring
is important, but having a resource available that tried to convey
this knowledge would also be invaluable.
Hope this makes sense.
--
.''`. 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