Re: [Debconf-team] On the "local team"
Note: this mail was written more than a week ago, but real life delayed
it. So I'll sent it now, but I've not yet read the follow-up of previous
mails (I saw there are some but...), and maybe there is some repetition.
But now I'll stop writting and I'll send it, and I go full immersion
again to real life.
Hello Ganneff, madduck, marga, maxy, azeem, OdyX, hug, RichiH, fil,
highvoltage, indiebio, stefanor
On 22.09.2015 01:29, Joerg Jaspert wrote:
> Hi,
>
> The term "local team" has become loaded in DebConf history, and we might
> just want to avoid using it.
>
> But it'd be wrong to deny the underlying concept, the existence of a
> group that identifies primarily with the organisation of a particular
> instance of DebConf at any given point in time, no matter what you call
> that group. This group assembles around the bid team, and does the early
> work. Over time, more and more people join, including volunteers from
> the region and people from other countries that also care about the
> conference.
Nobody want to deny the concept.
AFAIK DC10, DC11, DC12, DC13, DC14, DC15 and now also DC16 is driven by
locals.
Was a "debconf rule" for organizers: DCX-1 as apprendice, DCX you do the
work, for your DebConf; and in further years one mentor new organizers.
So locals had strong power on flavor of their debconf. Also on the
meetings, locals' opinions have priority. Experienced people comments
what went wrong on past DebConf, and try to convince people not to make
the same errors.
> There is no arbitrary distinction (like explicitly "splitting off the
> local team"), but it's a fluid, natural separation, and as the
> conference draws nearer, the distinction fades, though never entirely.
> For instance, it's usually still the same people that write daily
> announcements during the conference, and handle other details.
>
> It's important to try out things every year, otherwise DebConf would
> stagnate. And the vision and ideas shared by people submitting and
> winning a bid constitute an important part of their motivation.
Right, but it is also done always in such manner.
Also because locals are more involved and they do more jobs, so they
tend to be naturally the responsible.
And bid team has every year innovated DebConf. No DebConf is like the
previous. Some experiments failed, but it helped future DebConf.
> Clearly, the people behind a winning bid should never just charge ahead
> without looking around, but rather should help everyone stay up-to-date
> even if they are not actively involved, and facilitate their catch-up
> when it's time.¹ Full consensus cannot be achieved for every decision,
> but the information available needs to enable everyone to trust that
> decisions are made with all things and people involved considered.
Full consensus is never "desired", and really I don't want votes on
meetings. Just important decisions should go to -team, so that
everybody could give opinions (and telling about past experienced), so
that decision could be taken with right information.
> Due to various reasons not subject of this mail, the members of the DC15
> team ended up either leading or being a fundamental part of most of the
> teams. It worked out, but there was collateral damage resulting from
> integration difficulties. To avoid this in the future, it would help to
> establish equal expectations all along over regarding who takes the lead
> (and what that means), and how we all cooperate.
It is not really because of chance. Locals have usually many important
jobs (as I wrote on the top: either because it is their conference, and
because they are done most of the job).
So I think we agree very well until this point.
> We still have high doubts about the requirement of having to join an
> existing, long-lived sub-team in order to do work, or that all work must
> happen within a sub-team in general. This presents a high barrier of
> entry to newcomers, and it also seems paradoxical to fit stuff relevant
> only to one conference (i.e. "local" stuff) into sub-teams that should
> persist across multiple conferences. Also, many of the little tasks
> cannot be clearly associated with any one of the existing team.
The high barrier for newcomer is really a problem, but I'm not sure the
team structure is the cause.
The teams exist because of request of team (in DC14, I was not there,
and I could not follow discussion because it was decided at last minute
not to stream it).
What we want to solve:
- Experience that survive after DebConf. Previously we had many tasks
done by single persons, which had no documentation, and it gave trouble
when this person had no time to explain past work.
- Coordination: it was assumed that most of coordination will be done
inside teams (coordination team was not "invented"). We all remember
how it was in past, where nobody know about tasks (see above), who is
responsible, what are expected difficulties/timelines.
- No deadlock: on structure it was stressed to have always a replacement
person, so in case of necessity someone could step-in with information
and how-know, to avoid such deadlock. (as you write on the bottom, this
was a problem, and really also in DC14 we lost half of leads/shadows).
- Delegation: there was also a huge request to delegate decisions to
sub-teams. We think that too small teams doesn't have enough
"experience" and large view (about interaction of every task) [no single
person has such large view, but summing people experiences on various
fields we get it. Lacking documentation (and for DebConf also the
"source code") ...].
[Note: video team inside infra was done for such reasons: note that
teams are defined only for the period before conference, so -video could
self organize during DebCamp/DebConf, but as we know, in last years
there were some organisational problem about what budget was needed by
video-team, about transportation of material, etc., but at the end it
is preferable a chaotic organization then coordination help from people
not inside the video-team]
> Moreover, not everyone involved with DebConf as a whole can muster the
> same availability and energy to the organisation of the next conference
> as early as those behind a bid (which can certainly include non-locals,
> as is the case for DC16 and also DC17 already). We should ensure that
> active people are not dependent on less active folks, especially in the
> early stages. The fresh energy brought to the table by the bid team,
> their ideas and their motivation should be channeled directly towards
> progress, instead.
Is not yet the case? In general locals had much freedom, and nearly all
possible freedom on designing their DebConf, which happens on bid time
and on the period of "previous DebConf" organization period. DC13
choose own style (~ camping and communal accommodation, more in style of
first debconfs), DC14 choose not to have DebCamp, DC15 had many innovations.
But I still recommend the apprenticeship model (DCX-1 apprentice, DCX
master), so that much of knowledge is inside locals, so less dependence
of "others", and trying not every DebConf to have the NIH attitude. We
don't need to engineering the things were already good (maybe not
perfect), but improve things were not optimal, and innovate.
> This might well mean that they'd be better suited to run the teams,
> where applicable,² i.e. organise meetings, keep track of things,
> communicate appropriately in all directions, and ensure that everyone
> involved is on the same page. It would give less active people the space
> they need to still offer their help, advice, experience, and generally
> provide input.
I mostly agree with this. But since few years it is so. I think during
DC13 orga period chairs stopped to chair meetings, and local orga were
in charge (before that there were various meeting-chairs, usually mixed
chairs and locals). OTOH I don't see problem if other people help the
locals on such tasks. Why marga should not be able to chair meetings,
if she volunteer? And I don't think there is strong opinion against it.
Just like all things, locals have much more weight on all decisions (by
nature). Just try to express opinion individually. Last year Martin
acted as speak person of local team, but many time it was not clear if
he represented other opinions or if he was discussion own opinion. We
should avoid this (and IMHO having the meeting duddle in DC16 channel
was good, to give precedence to local choices.
> But we should also not expect every bid team to be able to take full
> charge of the whole process, because some years there will be teams
> without the necessary people power. Then, obviously, the rest of the
> team needs to step up and some people might need to become more active
> than they'd otherwise be.
Somewhat confused. But possibly because of different interpretation of
note [2].
On one hand attendees expect some continuity (innovation right, but not
revolutions). And this is a very important part. We are organizing
DebConf for Debian not for us. DebConf is sucessfull, yet. So no need
to revolutionize it. We are a different conference. I feel shame to
copy from the big professional conference. [I think Debian maybe with
Ubuntu could have one, and will not be in competition with DebConf, but
it is a different question].
Additionally every DebConf lacks of manpower, so why not use all
resources (and experience) available? I'm sure that if bid team agree
on some issue, also "external" people (new locals, members of other
bid/future bids, then-locals, or just volunteers) will agree. There is
no votes or veto, locals have always priority [also in the past]
We really don't want to make old-locals to lose motivation on helping:
again every DebConf have manpower problem. Also DC15 were not without
problems (lack of man power, and lack of experience, NIH).
And I see some problem on leaving global team to fill job locals are not
willing to do. I'm doing [and done] a lot of boring works for DebConf,
because nobody want to do. I tried several time to outsource them to
the "local team", but nobody want boring stuff. And for sure if my
tasks in DebConf are only boring stuff I'll go away doing other
interesting stuffs.
On the metric "burn-out", this DebConf was successful: most of locals
are still working on DebConf, unlike DC7 and DC10 where DebConf was
"reinvented", thus causing a huge effort on locals. I think most of the
changes in DebConf (and creation of chairs) was done to avoid
reinventing things at every Debconf, so having many burn-outs. Now
chairs are less involved on knowledge sharing, but we need really not to
lose information and people of past DebConfs.
Without a proper apprenticeship (or documentation) it is very difficult
to know all the problems and required times, and many locals don't have
such experience, so the "take-over" is usually restricted on few
teams/tasks.
> Because this is the important point: while people behind a given bid are
> organising "their" conference, and driving things towards deadlines they
> know best, they are backed up by the entire team, including people who
> don't need an explicit "team leader hat" to oversee the efforts,
> influence decisions, or be able to stop problematic developments in the
> interest of DebConf. Anyone with limited time would probably rather help
> shape DebConf than be responsible for the day-to-day organisation of
> team(s).
Note: I really don't like "team leader" (and BTW also the official "team
lead"). DebConf works is done by people wanting to do the work (so
unfortunately we have much stepping into others feet). Leads should
know what is going on, and be able to find replacement people, in case
of MIA. I never required permission (but initially) to nattie or
RichiH. Possibly I wrote my plans before doing it, so to stop me before
I did stupid things, and documenting (IRC, git logs, ..) what I did.
But also on other teams it seemed that "lead" were not a problem
stopping people doing the work.
On the spirit of Debian and also of DebConf there is still big traces of
anarchism and do-ocracy, teams and -team are there only to improve
communication, intra-team coordination (and check for
volunteers/help/MIA). Don't overestimate structures, delegations and
legalism. For this reason I'm also a lot annoyed of continuous
meta-discussion (who take decision, how to take decision, where, which
structure, etc.): at the end they have little effect on DebConf orga. A
perfect structure will not solve time and volunteer problems.
> We should therefore treasure the idea of the "local team" (though maybe
> call it something else), and strive to leave them the space they want
> and provide the support they need.
I think we all agree on the substance, just the form make us "discuss".
We prefer (AFAIK) locals driving the teams from inside (and let's them
to "exploit" "experienced" people from t0), possibly gaining experience
on previous DebConf (apprenticeship).
Just what make sense to globals? [so the note 2], and how much a local
team can change DebConf from one year to the next?
But I find also disturbing that we speak about local team, and Martin is
trying to dilute the meaning of local team from inside. He is local in
DC15, DC16 and it seems it try to be local on one bid of DC17 [curiously
where lives are also much experienced DebConf people, and one chair].
So what it is local team? I think many of us are helping bid teams,
giving opinions but trying to avoid the conflict of interest, and givint
true local the decisions [in spirit of this mail], contrary of Martin
work. So if we do the contrary: global team will be included in local
team, things are really better? [bids teams usually look for many
DebConfers, and are not picky during bids].
> Our humble opinion, based on our experience,
>
> madduck, marga, Ganneff, maxy, azeem, OdyX, hug, RichiH, fil,
> highvoltage, indiebio, stefanor
Chairs should be supportive of local teams, but many comments of chairs
have really a reason. I use personal names, to give the context
(perfect world had better way to deal DebConf problems), but this should
not shame people: if there are problems, the shame will go to -team and
chairs, not to solve them, and not to people.
I was in dc13 bid team, and we designed a different style of DebConf
(thanks to support of char holger), but we tried also to improve all
team and sub-team structure: at the beginning we had much time, but it
has proved to be wrong approach: we designed and redesigned many things,
without really knowing how thing were working, so patching and patching
until we approached the previous method. If we were less stubborn,
probably we could use better our time. We lacked a real coordination
team, so when Odyx and gaudenz had real life [winter period, few thing
to do], much of information flow was lost, and thing were rediscussed
[so losing people]. We tried to implement a new registration system and
we failed, so we open the registration very very late, for very short,
we had a short reconfirmation period (2 weeks, and we need to extend
because many people didn't received bursaries status). On my side, we
tried to rewrite the questions to users, small improvement, but it
seemed simple. It worked because now we are still using some of our
innovation. But I regret that. for a small improvement (where there was
really no problem), I made my life harder, having to redesign all
scripts, not being able to compare numbers from previous DebConfs, etc.
[we were late on all the process, so also no really time to improve
communication to users.
Just if we had been more integrated with globals, I think we had less
stress and a yet better conference [which it was in any case very
successful].
DC15 had also many problems, which causes chairs troubles and some NO to
extra stuffs
- visa team: we looked several months before to have a working team, and
after resignation of the only local, we waited more weeks before to
answer. So local teams was not so "rich" in person-power, which should
give an alarm bell, not continuous requests of much additional "strings".
So is it good for globals to try to convince locals not to do additional
(not-essential) works? [globals know that as locals, we tend to
underestimate the works in the few months just before DebConf.
Personally I gave up many dinners and beers, and books, and programmings
because of DC15, much more manpower on essential task would have
improved my life] [It was told me that there were lack of coordination
meetings (between teams) because also lack of manpower.]
- Martin had too much tasks. This gave chairs much troubles: a big
single point of failure. What if he find a new job, health, if he run
for DPL, or just he had other interest? You, Ganneff, were at center of
discussion many time (during last year) because of this (and IIRC also
Martin was against such SPOF): every solution that make a bus problem
not cause much trouble to us. It took time, but it was solved (and
inside local DC15 team). But do you think global team were comfortable
that martin get (and "stole") many tasks and he was continuously trying
to get new stuffs?
Who could solve such problem? All inside locals? How did you tried to
avoid such problem? [to my surprise many locals were not really aware of
much things, so I think we had not real replacement. Luckily no need for it.
Then the common pattern: we underestimate the work on last months and
during DebConf, so DC15 were chaotic on registration site, because of
lack of support. Martin had budgets updated every 20 min in February -
April, but during DebConf we didn't track how many mugs were given to
professional and corporate people (which it seemed essential for tax
purposes) and how many were sold. How many people do we had? I think
nobody registered the band members, and so they were not tracked for
food and other stuffs. [but it seems they were tracked for rooms and
their were provided with badges, without notifying front desk, cooking,
etc.]
Again: I was also trapped in such lack of time, but so, is it so wrong
if global people try to *discourage* locals to overdo things?
- publicity: we do a conference for Debian contributors, but we failed
to tell people about innovation of DC15. People come for DebConf (in
classical sense), and found several nice add-ons. What is the point of
starting organizing much things, if we cannot properly finish
organization and telling people about them? How many people were at
first concert? How many people knew that there were a concert?
To conclude:
"local team" exists (since the first DebConf), they usually have own
mailing-list, own IRC channel, own in-person meetings, etc. Nobody
tried to remove such concept / tool.
But hiding information and organization into a local team is wrong: we
lose experience (and we need to motivate experienced people to remain)
and we are going to do again the same errors. OTOH I think chairs and
global team never blocked (vetoed) a decision where there were consensus
on local team (also after *listening* experienced people opinions).
[really there is not such big differences on opinions between locals and
"globals"].
And I'm annoyed that we continuously check procedures, and nobody really
check how thing works. Not about how much power local team has on the
"wiki", but how much real power (and it is really big) the local team
has. We have an anarchic spirit, so don't over-estimate the rules (also
if you speak German ;-) ).
ciao
cate
>
>
> Footnotes:
>
> ¹) Along with communicating a decision, we should provide the
> background, describe how a decision was made, and give
> a rationale. This takes a lot more time, but in hindsight of
> DC15, it'd have been better use of our time than some other
> aspects of DC15 organisation. We recommend DC16 focus especially
> on this. For this to work and for the team to keep it up, it's
> necessary, however, that we refrain from challenging a decision
> once it's made, or else people will prefer not to share.
>
> ²) This might not work for all teams and also needs not happen the
> same everywhere.
> Infra/video immediately come to mind as exceptions…
>
>
>
> _______________________________________________
> Debconf-team mailing list
> Debconf-team@lists.debconf.org
> http://lists.debconf.org/mailman/listinfo/debconf-team
>
Reply to: