also sprach Lucas Nussbaum <leader@debian.org> [2014-10-14 14:25 +0200]:
> I'm moving here a discussion that started on IRC about the budget
> approval process.
In that case, I want to include my replies too, which I am expanding
given how you've added new content…
> First, I'd like to state that we need to be a bit flexible about
> the budget. We will only have the final budget (final numbers)
> after DC15.
> […]
> Until after DC15 (or shortly before DC15), we can only work on
> projections.
Budget != final numbers. I thoroughly disagree with these
statements. A budget *is* based on projections, by definition.
Even though I do believe that budget revisions will need to happen
as more data become available, a budget is a set of boundaries for
the team, within which they can move freely. As such, a budget is
very useful to the team, by nature of it being fixed (vs. a moving
target).
A budget is also binding until a revision has been approved. Changes
to the budget do require the whole approval process, mainly because
of the potentially huge consequences.
> I'd like to process to be the following:
> - budget team sends the budget to the debconf team, to ask for feedback
> and detect possible things that could have been forgotten. (the budget
> team needs to consider demands and match them with reality -- it's
> possible that not everything can be funded)
I think this needs not be mentioned. We should always involve our
team colleagues whenever we need them or it's appropriate to do so.
This does not mean that consensus has to be established, nor should
we allow for bikeshedding, but nothing about DebConf can be
decided/designed in a cave without involvement of the others, and we
should live this (rather than have it be the proposed process).
At the same time, we are creating sub-teams, or "competence centres"
around people who have more experience in one area than others. And
so if a team charged with task Foo decides that Foo should be done
in Bar way, then this is hopefully based on careful evaluation of
feedback, but in general should not be questioned (unless of course
there's an outcry…).
> - budget team sends the budget to debconf chairs for review (and
> possibly integrates feedback)
> - the debconf chairs forward the budget to the DPL, with their advice
> (ranging from "everything is OK" to "we should be careful about
> that").
> - the DPL considers the debconf chairs' advice and makes a decision
> accordingly.
I find this troublesome in multiple ways:
First, it introduces IMHO unnecessary complexity into the process
and opens doors for Chinese Whispers, while at the same time I see
zero advantage in having such a multi-stage communication process.
Second, it turns the budget team into petty foremen doing the
back-office work, at least that's how I would feel if my sole task
was to prepare a budget that the chairs then present to the DPL,
possibly adding their own feedback, of which I will have no
knowledge.
Third, IMHO, the DPL delegated "constitutional responsibility […]
for the use of Debian resources" to the chairs. This means that the
chairs can approve a budget without DPL involvement.
It is a fallacy to assume that the DPL has to have the final say
here because if the budget is not met, then it'd be an expectation
for Debian to cover any losses. Debian's money as made available to
DebConf is income just like any income from fundraising or attendee
payments. Approving a budget and committing funds from Debian are
two entirely separate steps, and if they've been treated as one in
the past, then I think that was wrong.
If it looks like we'll fail to meet the approved budget (which may
well already include Debian funds as income), then we might need to
investigate the possibility for Debian to commit more funds ahead of
time. Until more funds are committed, the budget won't be met, other
sources of income have to be sought, and expenses cut. This is the
whole purpose of budgeting.
If DebConf e.V. fails to pay bills in the end, then it is primarily
our responsibility to deal with that, not Debian's. We are making
a budget and trying to approach DC15 with all of our professional
experience combined to prevent this from happening. Proper budgeting
(in combination with good books and controlling) means that we (a)
find out about problems before they arise, and (b) can identify
sensible ways forward quickly without scrambling for answers when we
don't have the time.
> In the presented budget, I'd like to see some elements about "risk
> handling": What would happen if we raised 30% less than expected,
> 20% less than expected, 10% less than expected? And the answer
> should probably not be "oh, Debian will naturally pay the
> difference from its reserves" or "we will remove all travel
> sponsorship from our budget". This part doesn't need to be very
> detailed. A list of possible cost saving moves, with estimate
> savings, and priorities, would be enough.
The budgets I've worked with usually come with worst/base/best-case
scenarios. The base case is the one to aim for, but should new
information lead us to believe that we are not going to make it, or
that we could do more, then we can consult the worst- and best-case
scenarios to make suggestions for revisions.
Would this work?
In my experience, identifying concrete cost-saving steps at this
stage is lost effort. It's more important to have a good
understanding of the whole picture, and I think worst/base/best-case
scenarios are best for that.
> Q: So why involve the chairs at all?
> A: The chairs are the ones trusted by the project to know what
> organizing DebConf involves, so they are the best placed to
> advise the DPL on whether the proposed budget makes sense.
Two points to this, and I am not trying to start a flamefest. If you
feel like I am in error still, please reply in a separate thread at
least.
First, the chairs were appointed by the DPL. They may well be
trusted by the project as a whole to fill their role (I am *not*
trying to suggest this isn't the case), but they were not elected by
the project or the DebConf team.
Second, the chairs were almost certainly not chosen only for their
experience with budgeting. This may have been an influence, but I'd
like to think that other qualities were more important. Moreover,
other people know what's involved in organising DebConf who are not
chairs.
So no, I don't think the chairs are the best to advise the DPL on
whether a proposed budget makes sense. In an ideal world, the best
people to do that are those that (a) have experience with DebConf
themselves, (b) know when to ask when things aren't clear, and whom
to ask, and (c) are willing to help organise DebConf by contributing
their experience with budgeting. Why else would you need those
people?
> Q: Isn't the process too complex?
> A: I don't think so. Informing the team feels quite natural. Using
> chairs as proxy too. If there's a discussion between the budget team
> and chairs about some aspects, the thread can simply be forwarded to the
> DPL to avoid repeating the same arguments when the budget is presented
> to the DPL.
One of the core problems that the chairs (and dc-team as a whole)
have had in the past was that they would be involved on all levels,
in all decisions, across all topics.
We are just talking budgeting here and you are already suggesting
that it's the most normal thing to use chairs as a proxy. This means
you are asking the chairs to find the time to deal with budgeting
(in addition to all the other things they have to do), understand
what's going on to the point where they can advise the DPL on the
budget, and be able to channel feedback into modifications of the
budget.
To me, it sounds like this would be exactly the setup we are
currently trying to avoid or move away from.
And hence I'd really rather see the process as being in the court of
the budget team until they choose to go to the chairs or the DPL
— whoever can make a binding approval — and be done with it.
Ideally, the approval comes from the chairs, because then the budget
team can assume that the other party has sufficient DebConf orga
knowledge. And conversely, the chairs know the budget team members,
ideally to the point where they can trust their judgement on the
budget, rather than having to scrutinise it themselves.
--
.''`. 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)