[Zope-dev] the Zope Framework project

[Hermann Himmelbauer]

Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough:
> Tather than reply in kind here, let me summarize:  I'm glad we agree more
> than we disagree, and I apologize if I've attributed to you beliefs that
> you don't have.  It's heartening to hear that you're in favor of most of
> the things I'm also in favor of.  But we do have real differences in
> opinion I think.  I'd rather be constructive than obstructionist here: at
> the end of each item below I ask for an opinion based on a suggestion.
>
> 1)  I'm not in favor of a single steering group for the *entirety* of all
> Zope software.   We've tried a similar thing in the past (via the
> foundation structure); it didn't work and I'm not sure how we'd expect
> things to turn out any differently this time.  Instead, perhaps the focus
> of groups should be on some much smaller subset of Zope-related software
> (e.g. the
> zope.interface+zope.component group, the zope.schema group, the ZODB group,
> etc).  Could we consider this?

What I don't see in your proposal is, how these subset-groups would be 
coordinated, which leads to the following:

- How would these groups be formed? If there's nobody who encourages people to 
do so, 

- Higher level package/groups may have a hard life in case basic 
packages/groups are not coordinated and all "go their own way".

- How does some foreigner know, if a package is actively supported, 
umaintaned, deprecated etc.? How does he know, what packages exist, what they 
are good for and the like? For instance, I yesterday wrote that I use 
lovely.remotetask, then I was asked on the list why I did not use the (maybe 
better) zc.async package. Know why? I did not know that it existed.

- I think, Zope 3 is not only about some seperate packages, but about a 
complete "programming experience". Thus there needs to be some integrating 
force, that draws together all these packages, writes some documentation / 
tutorial / website etc.

- Newbies won't be attracted by single packages. Instead, they want something 
complete. Who would be interested in Plone if it would consist of various 
packages that people would have to draw together by themselves, without 
decent documentation?

To my mind, one key point is attracting more users. And that can only be done 
if we try to view things from an external, newbie-perspective. Some Ruby on 
Rails / Java / Turbogears programmer will only be attracted by some "big 
picture" but probably not by a collection of some subpackages.

So, my impression is that there is a need for some steering group, that will, 
however, encourage people to form groups around packages and maintain them.

Best Regards,
Hermann

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