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 > _______________________________________________ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team