Hello Lucas, On Sat, Apr 26, 2014 at 11:37:29AM +0200, Lucas Nussbaum wrote: [...] > As you know, there is an ongoing (slow) discussion about DebConf > governance. I believe that my position is best summarized by the excerpt > from the draft delegation below (for DebConf chairs): > > ---------------------------------------->8 > DebConf is organized by the DebConf team (aka DebConf organization team), > that gathers many Debian contributors, both from the general Debian > community and from a local team. > > The DebConf chairs are Debian Project delegates who act as a liaison > between the Debian Project and the DebConf team to ensure the success of > DebConf. > > Specifically: > > * The DebConf chairs are ultimately responsible for the organization of > DebConf and for the use of Debian resources (e.g.; money, Debian > trademarks) to that end; > > * The DebConf chairs advise the DebConf team and share their experience > of DebConf organization; > > * The DebConf chairs help the DebConf team define a structure (esp. in > terms of sub-teams and roles definition) and decision-making processes > that suits the requirements of DebConf generally, and of a specific > edition of DebConf; > > * The DebConf chairs monitor the progress of DebConf organization and > ensure that the defined team structure and decision-making processes > remain functional and sufficiently efficient to ensure a successful > DebConf; > > * When necessary, e.g.; when the DebConf team's inability to make a > decision has an important impact on DebConf organization, or when a > decision taken by the DebConf team is perceived by the DebConf chairs > as creating serious risks for the organization of DebConf, the DebConf > chairs can override the DebConf team for a specific decision. > ---------------------------------------->8 > > To put it differently: DebConf chairs have the power to veto any decision > made by the DebConf team. However, ideally, they should never have to use > that veto power, because the DebConf team should have listened to their > opinions and advices beforehand. On the other hand, the DebConf team must > have some freedom to make implementation choices that empowers them to make > their own, very special, DebConf: the chairs are here to make sure that > those implementation choices are not threatening the success of DebConf. > > (Note that this is already the case in the current delegation. The draft > above just makes it a bit more explicit.) > > Reflecting this repartition of powers in the bylaws of a local entity is > quite challenging (similar to when a TO needs to codify that decisions about > Debian funds held by a TO are ultimately made by the DPL). I don't think > that this strictly needs to be written in stone in the bylaws, but rather > that the people involved are in agreement with it. (also, I cannot comment > on the proposed bylaws for the DC15 legal entity -- my mastering of German > is nowadays mostly limited to knowing what my name means, and answering > 'I kann nicht Deutsch sprechen' to the occasional emails in German ;) ) > > There's further work to do DebConf governance. But I'd rather see > incremental suggestions based on the above proposal, rather than > completely independent proposals. (I only speak about my experience at DC13) Well, you position is not to change anything and to validate current governance practice in a new delegation. I was expecting something different. Probably because DebConf team members generally agree that decision making process or DebConf governance is the most inefficient and frustrating experience that you can imagine. Not blaming anyone here. I won't fight for a big change in DebConf governance but here is an idea (I am sure there are other forms of governance that could fit us): a) DPL delegate to a local association to organize DebConf b) DPL delegate to trusted and experienced team of organizer to be watchdog The watchdog team review budget, participate to team meeting, advise and help. The association decide and organise DebConfX. In case watchdog detect an issue, they report it to association and then, if needed to DPL. Cheers, Raphaël
Attachment:
signature.asc
Description: Digital signature