[Zope-dev] the Zope Framework project

[Martijn Faassen]

Hi there,

Lennart Regebro wrote:
> On Tue, Mar 3, 2009 at 00:16, Martijn Faassen <faassen at startifact.com> wrote:
>> Who is going to make that decision to encourage this? Allow this? You?
>> Me? Who? Right now, *nobody* is making such decisions and nobody can
>> properly get away with saying they allow it. Leadership is a way to get
>> out of it.
> 
> I think open source in general has shown two things:
> 
> 1. Communities can mostly take decisions without having official
> authorities to do so. This is hyper democratic.
> 2. When they can't, usually committees can't either. In those cases
> somebody with a deciding vote is needed. This isn't democratic at all,
> but efficient.

Can you stop using the word "committee"? I didn't use it. A committee is 
a bunch of people who has regular meetings, behind closed doors, to make 
decisions. That's not what the Steering Group is designed to be. I 
thought I was reasonably clear about this in the document.

It's simply a way to distribute the leadership work over multiple 
people. Perhaps you're arguing the optimum size of any such group is 1 
individual. I'm not convinced that's the case, and in any case I don't 
see this individual.

 > I think we should think about have offical groups, but for clear
 > tasks. Such as a "Zope 3.6 Release Task Force" as a hypothetical
 > example. It needs to be more than just Stephan Richter. But it should
 > be for a small, well defined specific task, and they are responsible
 > not for steering, but for kicking ass! (Their own or others. [So
 > things get done, you see. {Small joke there. Wasn't very funny was it?
 > Ah well.}])

I'd be quite interested in exploring such options, but I think long-term 
leadership still needs to be there. For instance, who defines the 
specific task for a task for to work on? Who determines who is in the 
task force? Who reminds people of the need to maintain the launchpad 
issue tracker?

>> +1, though a simple discouraging of utterance can't accomplish it by
>> itself. What you need is active leadership that encourages such
>> experimentation.
> 
> I don't know about that. I agree with you that there hasn't been
> active leadership for a while. But look what has happened without this
> active leadership.
> * We have two cool new Zope 3 based frameworks. One which throws out
> the whole concept of ZCML for doing configuration by radical code
> introspection, and as a result making the Zope Framework immensely
> more accessible. And another one which experiments with revamping the
> way Zope publishes things, and a related effort of rewriting the whole
> publisher. Both frameworks have during these experimentation reached
> big audiences and gained widespread if still experimental acceptance
> in the community.

Do you think these frameworks just happened without active leadership? I 
can assure you that I've seen lots of leadership from Chris and Tres as 
far as Repoze is concerned, and lots of leadership from me as far as 
Grok is concerned.

Grok and Repoze are in part *workarounds* for the deficiencies in this 
community. For Grok I'm very sure it's a workaround, as I had quite 
something to do with it and this was explicit in my mind. It's not 
*only* a workaround, but it's definitely a community hack, too.

I see the workarounds as an indication that things in our community 
don't work right, instead of signs that it's working. Grok has been 
picking up a lot of balls that the zope-dev community had left on the 
floor for years (say, an actively maintained website).

That isn't to say groups of people shouldn't move into another space to 
do experimentation or go off on a tangent. They should do so. But it 
also doesn't mean everything's just fine here. Some of this 
experimentation needs to make it back into the common core.

[snip a few examples that are not directly Zope Framework related, but 
could be seen as the community adopting "Zope Framework" technology into 
various projects]

> I think experimentation has been if anything more wild than any time
> before in my life as a Zopista. I don't think active leadership is
> needed to encourage experimentation. I think all that is needed it
> what we already have: A less monolithic framework where you can do
> wild stuff, together with some seriously smart and wild people.

I think you underestimate how monolithic the Zope Framework currently 
is, and how much work the *Grok project* put into making it less 
monolithic a month ago (and various others, I was gratified to see; 
setting a good example is part of leadership). I think it's important to 
have someone around who knows what is going on, what people need, and 
remind everybody of this regularly and make decisions in the light of 
having that overview of what's going on.

> And we don't need leadership to say which of the experiments to make
> non-experimental. That will come automatically. We do need leadership
> for making decisions where the community ends up 50/50. In those
> cases, most committees will as well. And no, a 3 against 4 vote in a
> committee is not a success.

That's why we don't want a 7 member committee sitting in a back room 
making decisions. We want 3 or 5 people who do active steering on the 
mailing list. Most of the time 2 will be busy with something else 
anyway, so if one of them says +1, it's a go. Decision will be recorded.

The steering group members will have to figure out ways to anticipate 
disagreements so they don't just finalize the decision (by recording it) 
without some discussion first, and how to resolve disagreements. That 
might mean a quick vote, but at least it results in decisions. That vote 
will probably just be "okay, multiple steering group people disagreed in 
this thread, but we've worked it out and the decision is +1, go ahead" 
with the result recorded.

>> Who decides to kill something off?
> 
> If it doesn't get maintained, is dead. 

Tell that to the ZMI. :) (I know. It's not exactly dead, but it's hardly 
a project that lots of people think about improving)

> I guess you want somebody to
> make it official.

> I'm not sure it's necessary in a component based
> reality. With Zope 2 eggified for example, ZClasses gets a separate
> module, and it lives as long as somebody maintains it. It's then just
> a matter of deciding if it should be a part of the release or not,
> which the release manager(s) decide.

In a fantasy world where dependencies are perfect and don't pull 
everything else in, perhaps. :)

Given my experiences, I'm pretty sure it's necessary to explicitly kill 
things off in a component-based reality. A cleaner dependency structure 
can make it easier to cordon off and identify unused code. But 
frequently in order to do so you need to do work. If you wanted to 
declare the Zope 3 ZMI dead for instance, you'd need to do a lot of 
refactoring to split off the stuff you wanted to declare dead into its 
own modules.

Think about a Zope 2 without DTML, for instance, and how hard that would 
be. If it was decided this were a good idea (I'm not saying it is, just 
an example!), then you'd need to coordinate quite a bit of effort to get 
there.

>> Who decides we should have a documentation website for a widely used
>> component.
> 
> Those who writes the documentation in question. :)

That's worked incredibly well! I'm so grateful that we have 
zodb.zope.org. buildout.zope.org is also a great site for beginners to 
get started learning about buildout. Anyway, zodb.zope.org isn't, and 
buildout.zope.org isn't very helpful to beginners.

>> To people who are suggesting we don't need a steering group nor a name
>> for the Zope Framework, please answer the following questions:
>>
>> * how will the community make hard decisions where lots of people
>> disagree?
> 
> How does the steering committee make hard decisions where lots of
> people disagree?

Come on, it's easier to come to an agreement between 5 people that know 
each other than it is in a room with a lot people just stating their 
opinion whenever they feel like it.

> If we can't get a serious consensus on something, and
> it MUST be decided, then we have a problem no matter what we do. The
> traditional open source solution is a benevolent dictator. If that's
> not decided, then in worst case have a vote amongst committer members.
> How often has this been a problem the last couple of years?

I regularly get frustrated by this myself, actually, and typically avoid 
it by solving it within the context of Grok. Recently I discussed 
methods to separate ZCML implementations out from packages. Consensus 
was hard to find.

>> * who reminds us of necessary tasks and directions we're going into?
>> Sometimes the community collectively decides on moving forward.
>> Sometimes it doesn't. Are we really maintaining our issue tracker well, say?
> 
> No, but then a person should get some sort of responsibility for that.
> Note: A person. Not a committee. A committee means a bunch of people
> are responsible, which is the same thing as saying that nobody is.

I'm talking about a group of people who act as if they're responsible, 
not your mythical committee. We should be able to find a bunch of people 
with a sense of responsibility, right?

> Yeah, yeah , I know. My answer is all peace and love and fluffy
> kittens and everybody does whatever they want, but amazingly, it tends
> to work! :-) Freedom baby yeah!

I think we don't do a good job in attracting newcomers to our 
technology, and we have had a lot of stagnation in the Zope Framework. 
In the last month we've had a tremendous outburst of activity as various 
people had more time and started to take more responsibility. I think 
that's great, but I'd like there to be mechanisms to sustain it and not 
lose direction in the slow times.

Regards,

Martijn