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

Re: [Debconf-team] Fixing the Debconf Delagation



Bernelle,

It is a long email, so I am not going to reply to every point. But there
a couple of things I believe need to be replied..

On 30/09/15 13:21, Bernelle Verster wrote:

> From Tincho "The power to override decisions ... budgetary decisions,
> sponsors relationships, volunteers motivation, and even some basic
> tenets of the conference were at stake. Every time this happened, it
> was because somebody from the
> local team acted on their own, overstepping other people's
> responsibilities, and without prior consultation."

> I would argue that it may have been because the understanding of what
> was expected was lacking. If there is no structure that makes it
> clear, I would also tend to act in what I believe is the best way. It
> is hugely damaging to then have my best intentions questioned.

The most important thing here, is that there was a clear structure, with
pretty clear responsibilities and boundaries; those were reminded time
and again before these events took place. There were/are many rough
edges and many times clarifications were needed, but things would have
been very different if the reply to a complaint about overstepping was
replied with a 'sorry, I thought this was OK' instead of other excuses
that show understanding but disregard of these few agreed-upon structures.

Yes, it is damaging to have your best intentions questioned, but it
might also be damaging (to other people) if you follow those intentions
disregarding other people's work.


> * The tension between short-term benefit for sponsors (e.g. being
> acknowledged on the website, authorising in-kind donations) vs
> long-term relationships with existing sponsors:
> 
> The issue: There is not enough time for the whole team to find
> consensus on a service that was not considered and therefore not
> discussed before the conference. This happens. There was no way to
> find input quickly, so he made the call.

In this particular case, the service was not considered essential (or
even important) by any of the "core" (if such a thing exists)
debconf-team members. It was surely an useful tool, but requested way
too late for being considered in such a particular case (in-kind
donations are tricky).

Moreover, there was a pretty clear way to resolve this quickly:
contacting the team lead to make the final call. This was a core part of
the teams reorganisation, derived from the well-known problem of how to
take quick decisions when there is no time for consensus building. It
has been documented and explained many times, that one of the main
functions of the lead is to be able to answer any kind of questions and
-if absolutely necessary- take immediate decisions about the team
quickly. Sadly, the team lead only discovered this issue when the
contract was already ready to be signed, and was too late for anything.

> How to fix this: To mitigate the tension, I would suggest that there
> is a clear understanding of what constitutes a sponsor, well in
> advance, with a bigger focus on the very small sponsors. I think a
> bigger issue that needs to be articulated, is how do we acknowledge
> the many, many material things that make a conference happen? I see
> this as a critical issue for the DebConf in Cape Town, because we may
> have many small companies who want to contribute and be part of
> something, but who fall far short of the official perks. We need to
> bring them in somehow - this is our community and directly part of the
> DebConf Goals. I can remember the sponsor being quite sad at how
> things went - we need to think about how to prevent that. (I can't
> find that thread now though).

I don't have an opinion on this, but I believe it should be discussed
with the fundraising team, which has a lot of experience with these matters.

> Then, I would think once there is a decision to be made in crunch
> time, to revert to a/the Chair to make the call. For that to work
> though, I would need to trust that the Chair would make a good
> decision - one that if there was time to bring in the whole team, they
> would agree with and support. I cover trust as an overarching thing
> right at the bottom of this email.

Apart from the obvious lack of trust in the chairs, I don't think the
chairs should need to be contacted much, as the leads were the ones
supposed to make the call (and be trusted in their judgement).

> * The tension on what to spend money on, and the unclear Debconf
> goals. Taking sponsored food and accommodation vs 'more fancy perks'
> as example:

This is a very good question, and not to be taken lightly. Perhaps a
separate mail thread (with a long bikeshedding session to follow) would
be useful.

> * Volunteers participation and motivation was at risk, example used:
> coordinating childcare
> 
> This seemed to be a communication issue, and personpower issue (I read
> all those childcare emails as they happened). The way I am trying to
> fix this is by making people more cooperative (see Asheesh's talk;
> collaborative needs a lot of communication, cooperative can work more
> independently) and clear on communications. These are currently coming

Communication is what failed here. There were people working in the
background, I was also following some of the emails, and I also did not
know exactly what was going on. But the problem is when instead of
asking the people in charge how is it going, what do you need to make
this happen, etc, you just take over and send an external communication
that contradicts some already agreed items.

> * Setting up events external to DebConf, that is still associated with
> DebConf by design or otherwise, with tension of affecting the DebConf
> 'image'. Example: madduck's workship, and for DC16: ShowMeBox.
> 
> How to fix this: Tell the greater team about it, well in advance, and
> get input and then go-ahead, well in advance. Find a  constructive way
> to answer "Is lack of response a yes or no?" We need to understand as
> a team that there are other things happening, linking to, but

You just said it. What you did with the ShowMeBox is the ideal way of
doing things: you propose a new idea, that might be challenged by some
people, well in advance. You send an email in an archived mailing list,
and there is plenty of time to comment on it.

The problem with the workshop was that it was only communicated when it
was already arranged, rooms reserved, webpage prepared.. And it was just
a month before the conference started!

> Another thing that was not mentioned by Tincho, but may underlie the
> 'more fancy perks' discussion is who gets to decide on how budget gets
> spent, when (additional) money is sourced by people in the (e.g.)
> local organisation? If the budget is approved with a certain amount
> committed, and more than that amount gets raised, you need a clear set
> of guidelines (not a policy, but a set of questions to guide
> conversation between the team and chairs and DPL) to get everyone on
> the same page. Said another way, are the people who source extra funds
> in charge of spending it? What about the people who are not involved
> in fundraising but had ideas or feelings about it? Instead of saying
> this group or that group can decide where this money goes, what are
> the priorities that would decide where the money goes? What set of
> questions can make the thinking behind the decisions explicit?

I think it has been more or less agreed that raising money does not give
you the right to decide how to spend it. And if the long-term idea of
merging DC fundraising with Debian fundraising happens, that becomes
even more evident.

At the same time, the local/bid team obviously has a lot to say about
how to spend the money, and in practice it is them who define most of
the expenditure. Formally, it is the DPL with the chairs who sign-off
the budget.

> In closing, people like madduck are enthusiastic and energised, they
> make things happen and we should encourage that. That they make
> decisions 'too quickly' or 'not consultative' is a symptom of the
> organisation needing to give better guidance, and the Chairs are not a
> catch all answer to this (perhaps rather addressing the symptom, not
> the cause). Their behaviour is not the core problem.

I want to point out that the current chairs' plan was to withdraw as
much as possible from the decision making process, and only stay as a
safeguard, considering that the reorganisation would give enough power
to each team to take decisions that are respected.

> I find the power to override decisions damaging to trust. If you need
> this power, you are not doing your job as chair well. Your power to
> override should be the social pressure you can exert because of the
> respect afforded you. I can see how this power needs to be written
> into some agreement for real emergencies, but I am really worried that
> it is a sword hanging over our heads because the respect is not there.
> And respect is earned.

It is true that it is damaging if it is a sword hanging over your head.
And I understand that some people felt that way.

But, as I corrected myself, actually the override power was not really
used (I only recall one occasion, to solve a problem that had been stuck
for months, and it was not even related to dc15). These examples I
provided were not actually overrides, but the chairs exerting pressure
and trying to push people to respect the agreed-upon structures.

Tincho.

-- 
Martín Ferrari (Tincho)

Reply to: