[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Debconf-team] On the facilities team (was: Patch to DebConf orgateam structure)



Briefly, up front… you say:

> We believe that mentoring is helpful and should be encouraged,
> specially when the bid team has no much of DebConf experience. It
> is good to remember though that bid teams do not need to have all
> their communication proxied by a mentor, and the earlier they
> establish direct communication with core teams members, the
> better.

The role of a mentor should certainly not be that of a proxy, I am
not sure where you got this idea from. But mentoring involves
helping the bid team members figure out exactly what needs to be
talked over, with whom, and at what time. This is ever more relevant
the more complex an organisation is.

That said, I want to respond to the following part earlier in your
mail:

> Another request was to replace Facilities team by a "Bid
> Assistance Team", which would follow bid teams since their early
> stages and would work together with them in venue arrangements
> until the conference happens.

(not quite accurately summarised, but it's close enough… see below)

> We would rather keep the facilities team as it is defined now and
> expect that bid teams interact with not only facilities people,
> but with all the other teams when they have doubts about a certain
> aspect of the conference.

I think the facilities team is a dead-end, and my sentiment is
amplified by the fact that said team never came to exist. I was
asked once whether I'd have an interest in assuming the lead, but it
was also made clear that I was only one possible lead of many.

In the end, I declined, and here's the mail I sent to the chairs on
2014-11-25. I have not received a single response to this mail until
today, when I read that you "would rather keep the facilities team
as it is defined now".

Previously, I've refrained from sending this because I wanted to
give you the chance to handle this input as you see fit. As you now
sent a request for comments, I feel the time's right to share.

----- Begin forwarded message -----

Date: Tue, 25 Nov 2014 00:20:58 +0100
From: martin f krafft <madduck@debconf.org>
To: chairs@debconf.org
Cc: margamanterola@gmail.com
Subject: On the "Facilities Team"
Message-ID: <20141124232058.GA30764@fishbowl.rw.madduck.net>

Dear chairs, dear Marga (as coord team lead),

The following summarises my contribution to scrollback tonight, and
also picks up on the discussion with Tincho from last week in which
I questioned the purpose of the Facilities Team (FT) as you had
proposed.

After further discussion and much thinking, I am starting to see
a consistent picture. It's not exactly the picture you're drawing,
but a version slightly modified in the way FT and the coordination
team interface and work together.

Let me try to paint it in the hope that I can convince you of this
view.

There are tasks beyond venue negotiation that you ascribe to the FT,
but let's just focus on venue as the big, main task, which it is.

Ideally, venue negotiation starts before a bid decision is made, for
time reasons, but also because it's instrumental in negotiations to
be able to say that e.g. a price needs to come down for a bid to
have a chance.

Therefore, the FT would already be working with bid teams and coach
them during venue scouting and initial negotiations and I am led to
believe (by ana) that the potential leaders of FT are already
working with the DC16 bid teams.

A DebConf bid is usually built around a venue idea or two.
Therefore, developing those details during the pre-bid phase is
generally the main work that needs to be done. This raises the
question of what the bid mentors — and yes, I think we should have
active bid mentors — would do and how one could ensure that bid
mentors and FT members don't step on each other's feet — in some
years like DC15, venue will include food, network, most everything,
while in other years, the situation is much more complex and the
overlaps not clearly defined.

So instead of an artificial separation and two cooks^W teams working
on more or less intersecting tasks, I would like to suggest to merge
the two into one team. The team (let's call it MT(¹)) would at first
be in charge of assisting bid teams develop their bids, including
venue scouting, looking for/ensuring the basic requirements and
engaging in preliminary negotiations.

Once a bid decision for DCX has been made, MT assists with the
actual venue negotiations (and e.g. conference dinner scouting
etc., put your other FT tasks here), as well as budget preparation.

Ideally, by the time DCX-1 comes around, the most important stuff
(venue, maybe conf dinner, budget, etc.) will already be well on its
way and becoming more and more the domain of the coordination team
to oversee the execution of DCX.

Now MT can start developing the DCX+1 bids, but we'll obviously
still be available for DCX, although the amount of guidance needed
by the bid team should be ever decreasing at this point as they'll
be working rather closely with all the other teams by now.

There are a number of decisions that need to be made along the way
of MT and the bid team working together. It would also be the MTs
job to ensure that what needs to be dicussed on dc-team (or whatever
the best place will be) should be done so, and in a timely manner,
by which I mean coaching the bid teams to send proposals to the list
where appropriate, and asking for feedback with a reasonable
deadline before moving on.(²)

It is also conceivable, maybe even advisable, to have regular
correspondence and/or meetings with the coordination team to discuss
current issues in the various bids. This will not only help prevent
problems, but it also familiarises the coordination team with the
bid teams, one of whom will most likely be organising a DebConf to
come.

Hoping that this all makes sense and I was able to convince you,
then I'd be highly motivated to work on this team (MT).

I would also try to be a good leader, although I don't really have
aspirations here (and I don't think leaders should be designated).

Whether or not I'd be appointed, I'd try hard to do my part helping
MT be perceived as a valuable resource, as a partner with whom the
bid teams want to work, motivating them to spin their bids in the
best possible way. I don't think MT should be about making decisions
and we don't really need to have any powers beyond being in charge
of what we do. Our goal would be to engage people interested in
organising DebConf, see them off to a good start, help new ideas
find fertile ground and make sure that the winning bid team knows
how dc-team works and how to work with them/you/us. Oh, and
obviously help negotiate good and reliable deals.

I really just want to help make DebConf progressively better, and
I think I can contribute both in terms of assisting bid teams
getting off to a good start and helping organise the nuts and bolts
of DebConf.(³)

Good night,
-m



1) "Coaching Team" or "Mentoring Team" or "Bid Assistance Team" or …

2) Look back at how DC15 was handled in this regard, and how we
   meticulously tried to be transparent about everything. It'll
   obviously be a good strategy to err on the side of caution in the
   beginning, but the long-term goal should be to establish a pretty
   firm understanding within MT of what will fly and what might not.

3) I don't really need/want to work on treasury/accounting, thinking
   that this should rather be the domain of Debian auditors anyway.

   And if we manage to establish a culture were ideas are allowed
   percolate from bid teams all the way through the actual DebConf
   without being extinguished on the way (e.g. DC14 "integrated
   DebCamp", or DC15 "morning sessions, talk slot lengths, more
   lightning talks, etc."), then I'd also have no real aspirations
   to work on the events team.

-- 
 .''`.   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

Attachment: digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Reply to: