On 26/04/14 at 12:45 +0200, martin f krafft wrote: > also sprach Lucas Nussbaum <leader@debian.org> [2014-04-26 11:37 +0200]: > > 1) Respective governance & decision making of DebConf, DC15 and > > the DC15 legal entity > > > > 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): > > Is this draft up for discussion? Yes. > Even though zack's delegation left much to be interpreted, it was > also wise in that it did not overregulate at this early stage. For > instance, chairs cannot ensure success of DebConf, and were > I a chair, I would run away if you asked me to be "ultimately > responsible" for that success. Heh, note that this part is directly inspired from Zack's delegation, which said: "the chairs will be responsible to the Project for the organization of DebConf and how Debian resources are used to that end." > I especially don't think that the chairs should be "helping to > create decision-making structures" in new-formed local teams, but > let them self-organise. Obviously not all local teams can do that > and need help, but others do not. Specifying that the chairs should > help all teams is going to exascerbate the problems we are facing > these days. Of course there's an implicit "if needed" there. Chairs shouldn't be expected to help when there's no need for help. > It's even worse than that, actually, and specifically affects the > chairs, which is why the following aspect must be taken into account > in any delegation: as long as the chairs do not re-organise > themselves in such a way that one or two of them handle DCX while > the third concentrates only on DCX+1, we'll have a situation where > two very critical periods overlap: the final lap leading up to DCX, > and the pre-sponsoring, legal entity, contract negotiation etc. > period for DCX+1. The proposed delegation does not specify any internal organization for the chairs. If they feel that splitting up that way is the right thing to do, why not. But I don't think that the delegation should impose any specific organization on the chairs (or on the debconf team). > Local teams are really project teams, self-contained in many ways > and up to a certain point, within a larger team. They are charged > with a task *because they are trusted to perform that task* and > unless we see DebConf as an exercise in bureaucracy, they should > have as much freedom as possible to carry out said task. There > should be transparency and reporting standards, limits in the powers > (e.g. the budget), and everything else that makes up a good > governance. But there should not be top-down control. That may have > worked in your mulitnational corporation in the sixties, but it > doesn't work there nowadays anymore, and it sure doesn't work in > a volunteer-driven project, such as DebConf. What you are asking is that Debian trusts the DebConf team with an event that is crucial to the success of Debian, and an amount of money that is much more than what we receive in donations during a typical year (excluding DebConf funding). Without any top-down control. I'm sorry, but I wouldn't be able to sleep at night if I made that decision :-) Over the past years, we have had very different DebConf teams, and also very different DebConfs. I agree that the DebConf team should be given as much freedom as possible to organize their own DebConf, but at the same time, I believe that we need some project oversight, because this is also a way to ensure that more people can actually organize DebConf, and not just teams where all people with 10+ years experience in Debian. Of course, the balance is tricky to find between "too much oversight" and "not enough oversight", because both bring clear problems. That's why the DebConf chairs role is an important and difficult role. :) > But what I am trying to say is that we should really spend some time > doing conceptual work to figure out a good way in which our > volunteer team can organise 2–3 conferences at any one time in > parallel and make sure that the team is trusted by Debian as a whole > such that there's no need for liasions who are held responsible… but > who are not supposed to take authoritarian steps because everyone > was supposed to get their advice in advance… but when they have to… > without that being made clear what it actually means… then they can > veto… without that being clear either (e.g. you won't be able to > veto a contract once it's been signed…)… > > It seems to me that this would be digging the hole deeper from which > the current frustrations stem. > > Therefore, I think it would be better to not fire prematurely at > this stage. > > However, you are the DPL and you get to do what DPLs do. If you > decide that your delegation is a good step, then you get to lead the > way. However, as DC15 team member, I would appreciate if you gave us > a clear statement about whether this new delegation retroactively > applies to DC15 organisation, or whether it'll be in effect for DC16 > for the first time. It would apply to every DebConf-related matter (DC14 and DC15). And actually, I don't think that it is very different from the current (Zack's) delegation. Lucas
Attachment:
signature.asc
Description: Digital signature