also sprach Lucas Nussbaum <leader@debian.org> [2015-03-16 10:39 +0100]:
> I think that it is the role of the DPL to break ties in that context,
> under "Make any decision for whom noone else has responsibility.".
> Of course, that should be done after hearing opinions, including from
> teams such as the press team and the www team that are likely to be
> affected by many of the perks.
You say the DPL would break ties "of course […] after hearing
opinions". How is that different from a delegate making decisions
after hearing opinions?
Obviously, perks affect other teams and designing them would require
being in touch with those teams. The goal should not only be to sell
perks that don't "sell out our soul", but also perks that we can
actually fulfill, and unless the fundraising team wants to also
become the fulfillment team, we'll need to have all the other teams
on board, identifying with our product(s) and having felt part of
the process so that they are motivated later on to fulfill the
promises we made.
But this design process will need active driving and decision-making
all along, and while we have all the time in the world to discuss
technical decisions until we get stuck and have to call the CTTE,
fundraising won't work this way, and I wouldn't feel particularly
motivated to engage, to be honest.
It really all boils down to one question, IMHO:
Assuming there's a team with good knowledge of Debian (the
"product", as well as the project's values) —
Are we as a project ready to delegate design, implementation and
further management to said group in full trust that they will
- always stay faithful to the project,
- engage with the stakeholders involved (e.g. press team, web
team, the community) for feedback,
- act without an agenda though still enabled and willing to drive
the process and make decisions,
- get up after making mistakes and learn from them?
To me, the role of the DPL in this should not be to be the tip of
the scales at the end of the design process, when dozens of strongly
held opinions have been formed and you can basically only choose
whom to go against and lose. To me, the leader should make such
decisions before the process, be ready to defend these decisions and
back the efforts with support by the project — this is all assuming
that while mistakes will happen, none are breaches of trust or harm
the project.
But Lucas, I am not trying to put you on the spot here, nor any of
the candidates. The issue at hand is about money, and we all know
that as soon as money gets involved, we all recall history and go
into hyper-defensive mode over our and the project's ideals, which
is GOOD; asking the DPL to simply step beyond this would be unfair,
and unrealistic as well.
Yet, if we wanted to create a cash flow with the goal to be able to
hand out budgets to teams such as DSA, sprints, DebConfs, outreach
programmes and what not ("make better use of our money"), then
I *think* the only way to do so is to approach it with
entrepreneurial freedom.
--
.''`. martin f. krafft <madduck@d.o> @martinkrafft
: :' : proud Debian developer
`. `'` http://people.debian.org/~madduck
`- Debian - when you have better things to do than fixing systems
"der glaube an den kausalnexus ist der aberglaube"
-- wittgenstein
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)