also sprach Lucas Nussbaum <lucas@debian.org> [2015-08-25 17:13 +0200]:
> That's just wrong.
I'm sorry, re-reading my last mail, I noticed I pointed a finger at
you, which was not my intention, and I also don't really want to
talk about the past. I've also made plenty of mistakes, especially
regarding the budget approval process, and I hope we can face
forward and try anew.
By now, I am almost convinced that the root of the problem is in
differing interpretations of the goals and priorities of DebConf
orga (see footnote 1 further down). Some in our team think that our
top-most priority should be to enable as many people as possible to
attend our conference, meaning that we pay for as many as we can.
But then this would mean that we cannot spend any money on anything
until we paid for everyone's travel and stay. Not only would this
reduce the conference to the bare essentials, I also think it would
cause /less/ people to consider paying for themselves, sending us
into a downward spiral.
Instead, I think we should incentivise everyone who can to pay for
their own stay, and encourage profs/corps to pay higher fees, so
that we can use more money towards bringing people to the conference
who could otherwise not go.
To get there, I think we'll need to cater to those self-paying
people, e.g. by providing thank-you-swag, and other excitements
during the conference, like the conference dinner, entertainment,
and other perks — none of which are exclusive to paying people, as
we had agreed to make the swag also available for sale. Obviously,
knowing that money gets used towards bringing people to the
conference is also an incentive for some to pay for themselves and
more, but probably not enough of an incentive for everyone.
I still believe that a proper budgeting procedure will help us in
solving this Gordian Knot, and ultimately allow us to bring more
people to who could otherwise not afford it. Having a budget
procedure would also help reduce last-minute stress and allow for
lower prices to be negotiated (more time == more options == less
cost).
Budgeting is an iterative process during which a team asks for
a certain budget and then the final amount gets negotiated. Once
negotiated, the team can spend up to that amount of money — which
does *not* mean it has to or will spend this money.
For the bursaries team, this means gauging how much travel
sponsorship they'll need/want to give. It's a lot easier to do this
when you have actual numbers/requests in front of you, but before
these numbers are ready, pretty much everything else depending on
the budget needs to be put on hold.
But it's possible to plan a budget even without these numbers, as no
budget ever gets set in stone. Bursaries could claim e.g. 30k from
the DC16 budget (or even more, it depends a lot on circumstances and
the goal we're pursuing, see above). We then fix this, and all other
positions in the budget, and everyone can get on with their work. If
bursaries discover that they need more money to achieve our goal,
they can ask the DPL for more.
IMnsHO, we should strive towards having our first approved, highly
conservative budget before this year ends. Highly conservative does
mean that there might not be a band playing, or karaoke, that the
day trip is mainly walking and the conference dinner might be
reduced to a slightly more fancy dish at the venue, with linen table
cloth, while the 30k travel sponsorship are fixed (if we consider
this a priority).
It's not difficult to imagine that this will also incentivise the
team to gear up the fundraising, so that as the outlook improves on
the funding situation, the budget can be grown a bit in all
directions. It still won't mean that there'll be funds for all the
cool stuff people want to do right away, but things keep coming into
reach as the income situation improves.
So how does the following process sound?
1. Bursaries (and all other teams for themselves) gauges the
amount of money they'd like to have in their budget. This
is difficult and will take a few iterations, especially since
we're all new at this, so let's not wait too long…
2. We try to allocate budgeted funds in a sensible way, and
get the result approved as the first budget.
3. Now the teams can work within the funds available and progress
can be made on all fronts. While the income situation is
unclear, some positions will be budgeted more conservatively
than others, but things can keep moving, or at least it's clear
what can and cannot be done while not enough funds have been
raised.
4. When teams encounter that their needs are outside of budget,
they apply for a budget extension. In the case of the day trip
or entertainment, the answer might only be yes if the income
situation allows for it (requests should be processed
altogether at defined points in time). But in the case of e.g.
video team or travel sponsorship needs, Debian funds might get
allocated if the DC fundraising income does not provide for it.
To give a simple example, yet one that I think will be all too real
very soon: if we all agree that diversity outreach is a worthwhile
goal, but not as important as travel sponsorship and video, then
we'll probably allocate very little funds to it in the initial
budget, say $500.
But we've witnessed this year that outreach could really benefit
from much of an earlier start than we managed for DC15 (this is not
a stab at the outreach team, it was our fault for not communicating
this). Yet, they won't get very far with $500 and the whole
endeavour might only make sense if the budget gets bumped to $3000.
In this case, the DPL could back up the endeavour with a promise of
Debian funds ($2500 augmenting the budget). These need not
necessarily be drawn, for if DC16 raises enough money themselves,
the backup won't be needed. But having the backup means that the
team can get started.
The same probably also applies to travel sponsorship as we know
we'll need to fly a certain bunch of people to DC16 anyway. Those
funds could well be backed by Debian, easing the whole situation
a bit.
The point of budgeting is to avoid lines at the cash register, so to
speak. If every team has to queue up in some order of priority and
wait until everyone in front of them gets served, they are (a)
losing time, and (b) might not get anything, in which case they lost
more time even thinking about a task.
A well-designed budget gives everyone something to work with, and
when augmented by a clearly defined process on how to ask for more,
it means that single teams won't need to block on the work of other
teams, because funds aren't just made available serially.
Does this sound like something we could try?
--
.''`. martin f. krafft <madduck@debconf.org> @martinkrafft
: :' : DebConf orga team
`. `'`
`- DebConf16: Cape Town: https://wiki.debconf.org/wiki/DebConf16
DebConf17 in your country? https://wiki.debconf.org/wiki/DebConf17
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)