also sprach Giacomo Catenazzi <c...@debian.org> [2014-04-28 14:53 +0200]: > You focus too much on quick decisions, but then you will find your > team alone when approaching DC15.
There's a fundamental problem here to which you are alluding, and the way to solve it is not by delaying decisions and involving everyone, but by setting clear expectations and roles. I think we all agree that DCX orga needs to start a lot earlier than has been done in the past, namely well before DCX-1 is taking place. I even think that making a decision for DCX should be done earlier than at the end of Q1 of the year X-1, if we want to broaden our options. But this does not scale well in the current setup and the entire dc-team gets split and frustrated over early heat, which results from frictions that are IMHO not the result of "focusing on quick decisions" (I think that is a necessity to stay on top of things, to be taken seriously by contractual partners, and to score the best deals), but from a lack of governance. > Also for tax exception, do you really think you are the first and > only team with such problems? Germany could have different laws, > but not so much different than in the other European countries, so > asking for opinion, you can have some feedback on problems you are > not yet realizing. Of course we are not the first DC team to get tax exception, nor did I ever claim we were. However, the last conference in the EU was DC9 and it was a somewhat special case. DC7 had a British Limited (not EU), and given how the law evolves, I do not think there's any use in learning from how DC5 was done in Finland, or look further back in time. There are strong parallels between Swiss and German law, and Philipp is being super-helpful and we are grateful to be able to draw on the experience of the DC13 team. But in the end, there are subtle differences between the laws and too much "global advice" might actually become a hindrance, as the tax authority employees actually care more about these subtleties than what could be called common-sense (and which would make things *so* much easier). > Putting so much distinction on local and global team, > hiding/delegating decision for speed would inevitably trash > knowledge. I agree that the distinction between local and global team must go. Whatever our future governance model may be, it needs to be centred around the idea that we are all one team working together. Decisions must be delegated. That does not trash knowledge, at least not if we manage this knowledge, either supervisory or procedurally. And there must not be any hiding going on, that's right. At least DC15 does everything in public, and we try to do everything in English. However, the place to discuss DC15 right now is not dc-team, but dc15-team, not because the teams are separate, but because there is no value in using the same medium for DC14 and DC15 in parallel — quite the opposite, in fact. And instead of us forming consensus on dc15-team and then presenting that to dc-team (thereby disturbing dc14-team orga), I would appreciate if people with insights and experience would be on dc15-team to guide us along. The whole process, pre-bid until post DCX-1 could be vastly improved if some sort of "official" entity from dc-team were actively involved… first assisting bidding teams, then coaching the team's early steps and helping with processes such as establishing a legal entity… rather than to expect the bid team to somehow know how and when to do that by themselves, and to present this to dc-team, not too early, but also not too late… and then endure weeks of discussion. Holger quit because the same topics get discussed over and over again. DC13 orga members have stated similar. The way to solve this is not to inhibit the discussions; the way to solve this is through the formalisation and documentation of processes, and through clear definition of roles and powers. Once we have that in place, we can focus on discussions that move us forward, not that hold us up. Ever since we published the bylaws, we've had feedback and made changes. However, I don't think we substantially improved the association. We didn't make it worse, but the gain was marginal. Yes, it now closer reflects the values of DebConf and Debian, but since we weren't ever planning to use it for DebConf organisation, it feels like we spent a lot of time polishing a car that will never be driven on a public road during daytime anyway… at the cost of not having been able to get pre-authorisation by the tax bureau before our prospective foundation date, which means that we now have to work on the basis of more "if-then-else" constructs that could have been avoided. And people have been all held up nitpicking stuff about trusting legal entities and whether they are fiduciaries or what-have-you and using trademarked names, with the effact that few people have had a look at the contract term sheet for Heidelberg. I don't want to sound like a cynic, but I am not looking forward to having all those discussions only in a few weeks time, closer to the deadline… > You were in orga team of DC7 (IIRC), and other German people were > also previously involved on debconf, which IMHO is good and quasi > a pre-requisite. So if we want future DebConf (DC16+), we really > need to involve more people on all processes. Yes, we do, and this requires us to be (a) more open and receptive to new people, and (b) more respecting and accomodating of "old" people. I think that a good governance and proper documentation of all interfaces and processes will go a long way in achieving both. We may lose some people on the way, but any change will bring that, I am afraid. We'll lose people too if we don't change anything. -- .''`. martin f. krafft <madd...@debconf.org> : :' : DebConf orga team `. `'` `- DebConf14: Portland, OR, USA: http://debconf14.debconf.org DebConf15: Heidelberg, Germany
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
_______________________________________________ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
