Re: List of members
On 02.09.18 17:49, Paulo Henrique de Lima Santana wrote:
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:
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
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
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
- 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).
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).
- List of members
- From: Paulo Henrique de Lima Santana <firstname.lastname@example.org>