also sprach Lucas Nussbaum <lea...@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
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)