[Zope-dev] the Zope Framework project

[Hermann Himmelbauer]

Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro:
> 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.

Exactly. And that's what we currently don't have.

> > +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.

True - but to me it seems that this happened because someone took leadership 
in this scenario. 

> * Zope 2 has been eggified.
> * Buildout has totally massacred all other forms of deployment of Zope
> projects.

All that is true and very positive, but what has not happened and maybe never 
will that way, is the aggregation of all those Zope 3 efforts, documentation, 
website and the like. And that is something very important in order to 
attract a broader user base.

> > Who decides to kill something off?
>
> If it doesn't get maintained, is dead. 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.

That's fine for one thing: Newbies don't know which packages are maintained 
and which are not. They find themselves confronted with a bunch of packages 
and don't know what they should use and what not. Example: zope.formlib vs. 
z3c.form.
For instance, I decided to use lovely.remotetask - but I recognized that the 
last commit is quite some time ago and don't really know if it's actively 
used/maintained.

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

In some way, that's already done - nearly every package has some doctest, 
which does often cover the package specifics very well. However, I remember 
the days I looked at z3c.form: I recognized that I needed to get to know the 
following other packages:

- interfaces/adapters
- z3c.pagelet
- z3c.template
- (and quite some more)

This was very cumbersome.

> > * 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.

Yes, that's probably true. So either this steering group is "a person" or has 
some person who decides.

Best Regards,
Hermann

-- 
hermann at qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7