Hi, On Tue, 2009-03-03 at 08:52 +0100, Lennart Regebro wrote: > On Tue, Mar 3, 2009 at 08:42, Christian Theune <c...@gocept.com> wrote: > > On Tue, 2009-03-03 at 08:35 +0100, Lennart Regebro wrote: > >> 1. Areas that need somebody responsible should get one. We need > >> somebody to bug people about bugs in the bug tracker. That should be > >> one person, for example. Responsibilities need to be well defined and > >> individual. There isn't anybody called Someone here, so if Someone has > >> to do it, that doesn't get done. > > > > That's a valid point. However, the steering group was thought of with > > having "fail over" in mind so that few people would know about the tasks > > at hand and can jump in for each other (in a coordinated fashion). > > Sure. But what happens in those cases is that everybody sits around > waiting for the steering group to do it, so it stops acting as a > failover, and gets swamped. > > > However, the group should be able to make a better job at keeping things > > in flow and focused. > > Well, maybe it should. I don't think it would. Groups generally don't.
For some reason the argument evades me: People randomly doing stuff will end in good things. People (trying) to thoughtfully organize won't. > > As much as I prefer discussing with people in real life, there is the > > notion of "no backroom conversations" WRT to driving development of an > > open source project. > > OK. *Cough*. You and Martijn wrote this proposal. And you asked > Stephan about it. You did backroom conversations. No, you did not do > anything wrong. You did everything completely correct. But forget not > having backroom conversations. That will and must happen. It is > backroom *decisions* that is the problem. When a group will come out > with a decision they made by themselves. This *will* happen when you > have a dedicated group of people making decision. The only way to > avoid that is to not have a steering group, but somehow have everybody > involved in a decision. And that is as noted not always practical > either. I do see the contradiction in this. ;) But as Martijn pointed out for his doing with grok: it's thought of as a hack. We've done this backroom discussion because we felt that zope-dev won't be able to drive a fruitful discussion without preparing as much. However, I'd like that to not be the default or the desired state of things. > > Having major issues resolved in RL meetings will exclude all those whose > > schedules don't match and those who can't afford to travel to Far Far > > Away. > > Aren't we now saying that to avoid excluding some people, we should > exclude all but a steering group? :-) No. The steering group should not have backroom discussions. They should act as open as possible. I think of it as a catalyst. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
