-----BEGIN PGP SIGNED MESSAGE-----
On 03.03.2009 15:37 Uhr, Kent Tenney wrote:
> On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer <du...@qwer.tk> wrote:
>> Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro:
>>> On Tue, Mar 3, 2009 at 00:16, Martijn Faassen <faas...@startifact.com>
>>>> 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
>>> 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
>> 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.
>> 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
> I'll chime in as a newbie.
> It seems many of the comments preferring ad-hoc to structure
> come from "we know what we are doing, we can take care of ourselves"
> I think Zope has the goal of attracting new users, and the proposal
> has potential to make Zope more inviting to the uninitiated.
> Zope is very diffuse, making it a challenge to grasp. I know I would benefit
> from any initiative which sought to provide an overview role.
I started up with something for zope2.zope.org in order to bring
sort out the various things a bit:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
org:ZOPYX Ltd. & Co. KG
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -