Re: List of members

[Giacomo Catenazzi <cate@debian.org>]

On 02.09.18 17:49, Paulo Henrique de Lima Santana wrote:
> Hi,
>
> Can we have a page listing Committee members and teams members (staff?) like video, registration, sponsorship/fundraising, content, and so on?
> I believe it's important to know "who is who".
>
> I'm not sure if it should be here:
> https://wiki.debian.org/DebConf
> or here:
> https://wiki.debconf.org/wiki/DebConf_Committee
> or here:
> https://wiki.debian.org/Teams/DebConfGlobalTeam

Hello Paulo,

Finally I took some time to answer. Initially I wanted to reply to you 
via IRC, because it seems there is some incomprehension about teams, but 
I think it is good to archive the discussion somewhere, so a long boring 
email.

Note: You will find in this mail my personal opinion (and my personal 
view of DebConf). Every person see DebConf differently, and DebConf is 
also evolving every week.  So all you find here is just to start the 
discussion with other people. It is absolutely not to see it as absolute 
truth.


DebConf has not a very well defined structure, we attempted to give some 
more structure in the past, but we failed (and this "we" is very 
personal, I was one of the old delegate who tried hard to try to 
structure better the DebConf).

The only official team is the committee (or delegates), which are 
officially delegated by DPL, and they off-load DPL from day to day 
management.  **DebConf is Debian**, so committee check that DebConf is 
handled according Debian rules, and Debian money is spent in the right 
manner (Debian is a non-profit organization, so we need some compliance 
rules). DPL approve large budget changes, but with help of committee (on 
both side, helping orga team to get a good budget, and to DPL to explain 
why some number are so).  Note: if you look on wiki, you may see 
"DebConf committee as an other team: the team which "decide" the 
location of next DebConf (and delegates will confirm such decision). But 
now the "committee" are the delegates.

The other teams are much less defined.

You listed e.g. "video-team".  The membership in such team is open. One 
just join the IRC channel and possibly the meeting, and s/he is member 
of the team.  There are various roles: during DebConf: locally: handling 
cameras, directing, sound; and possibly remotely: cut, check, and 
publish videos. These job are pure voluntary and requires just a very 
short training. Before DebConf there are a lot of preparation, but the 
group is very open, just join IRC.  There are some leaders, but mostly 
because they are the people who do most of the work.

Infrastructure is an other special team. Now most of the infrastructure 
is handled by DSA (so directly by Debian). Local infrastructure is a mix 
between DSA, DebConf volunteers, local team, local administrators. The 
ratio of the mix changes every year. But this is one of the team I know 
less. Local team will be surely involved.

Fundraising: this is also a long term team, because it is easier to have 
the same contact person with sponsors. There were some talks to move 
fundraising in Debian. In any case local team must participate: perks 
and level are defined according local budget; local sponsors need to be 
contacted by local people (also because of language), sponsorship 
brochure and in general fundraising is pushed from locals: they have the 
higher interest to have quickly more money (which helps all subsequent 
budget questions).  Because of confidential information (contact person) 
and opportunity (not to shame potential sponsors), much information are 
keep private, so there is a formal membership.

The other team are practically formed again after every DebConf. Usually 
there is a natural leader: the person who did most of the job on 
previous DebConf (which often was not the natural leader at the 
beginning of such DebConf). The old theory: people learn at DC-1, do the 
real work on DC, and they will mentor new people on DC+1. We are not so 
formal, but there is a large turn-over of people, so be prepared do 
start as learner, and become the leader after few months (which is 
usually bad, because it put a lot of pressure on deciding and on 
handling errors).  Local team must enter on most of the teams. Bid teams 
are also encouraged to join the teams. Often on global team meeting 
there are call of for participants (and more often call for volunteers 
to take over many tasks).

A quick review of teams:

- registration: membership via email alias. Scope: answer people email, 
help on registration, coordinating special needs and numbers to other 
teams. There are mail all year around, but most of the member should 
join before registration open.

- visa: membership via email alias. Handling visa question, writing 
invitations. Often only locals could sign invitation letters.

- content: main job is to review and rate talks. This should be done 
quickly after (and maybe also before) closing CfP. Then there is ad-hoc 
talks and scheduling, which is handled by fewer people.

- bursaries: main job: rating bursaries: Also this should be quickly 
after closing bursaries registration. Because of private financial 
information, such team is closed, but there is a call for new member 
before or during registration. The team should be as diverse as 
possible. Few members will handle the discussion with accounting and 
DPL, on getting more funds, and on handling paperwork to get refunds.

- publicity: handle public information. Usually coordinated with Debian 
publicity team, but locals are needed (either for local media, local 
language, but also because they are the people who should push for 
publicity).

- accounting: this is often one person job (and the only orga job of 
such person). A hard and intensive task. There are many deadlines, so 
such person should guarantee many hours every week. This is often a 
local person (being locally is nearly a must, for local payments, 
handling papers, etc.)

- venue, food, events, etc.: these are mostly handled by local team (but 
for budget consideration, committee or DPL should approve major expenses).

- wafer: content is handled with salsa, everybody could propose changes 
(but a local person should preferably coordinate changes, to give a good 
website structure). Developing: also without a clear membership, one 
contributes to patches.

- ... and a lot of ad-hoc tasks. Usually one get them by following local 
team meeting or global team meeting. Often there is no official call for 
such tasks, but one should volunteer if there is a task that should (or 
could) be done now, and not assigned.


In general, one person is part of DebConf-team just by following the IRC 
channel, the email, and possibly the meeting. There is no membership. 
Decision are often takes after some discussion on email (and usually on 
IRC meetings), by consensus. When discussion go to long, or no consensus 
one should take the decision. There is no real definition on who is 
empowered about it. One should be brave and accept consequences (like 
paying and not getting money from Debian, inviting 1000 people and not 
having room for such people, ...). But with discussion, one get idea on 
worst case, and usually nobody take responsibility of totally crazy 
ideas.  So at the end, also without a fix structure, people behave 
reasonably. [Worse case, Debian will not pay and Debian will not allow 
you to use DebConf name, but to reach this point, one should really gone 
crazy. DPL and committee will try hard not to go so far]


I just recommend organizers not to try to structure too much debconf and 
teams. Usually it will not work, and orga people should be able to help 
other teams quickly (in winter local and global people will lose 
interest. Try to do meetings and some task to keep people interested, 
but you cannot command real life).  Do not be authoritarian: there is a 
lot to do, and people will volunteers much more if they feel in a team 
and in charge.  Ask help. Early. This is general in Debian: nobody 
should feel forced to do things. On DebConf we are strict deadlines, so 
if there is some problem, so no delay too much to ask help, or to ask 
someone to replace you (you will still considered orga team, and you 
will find a lot more DebConf jobs later, especially if you were very 
well involved earlier on orga). Try not to split local and global team 
(all local are also global team, but "bid team" has some more power to 
set the style of DebConf. Do not overdo. Most of attendees already 
participated other DebConf, and they expect some things (WiFi, a sort of 
bed, some food, talks, hacklabs). You may find a lot of extra activities 
for attendees, but you risk they they will ignore it (not because these 
activities are not great, but just because a flame discussion about 
severity of a bug is occupying all force of developers. Priority is your 
health, not DebConf... and a lot of other "errors" in previous DebConf. 
But do not worry: the next DebConf (so for now it is yours) will be the 
best one. (and unfortunately the sad thing: it will be the best, mainly 
because of attendees, orga will make debconf less chaotic and more 
enjoyable, but your attendees are best).

ciao
     cate

PS: and I should really finish here, merging various unsent mails, and 
finally sent it (so sorry, no second review of this mail, or it will 
remain on draft for few months more).