[Zope-dev] the Zope Framework project

[Christian Theune]

Hi,

On Tue, 2009-03-03 at 08:52 +0100, Lennart Regebro wrote:
> On Tue, Mar 3, 2009 at 08:42, Christian Theune <ct at 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 · ct at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090303/ec7b82c5/attachment.bin