I think Martijn sums up the issue nicely with this message. The
development process is pretty heavyweight at the moment, and only things
that have really high velocity or lots of weight when they hit the
process actually make it in to the core. In some ways, this is the very
purpose of the process -- weeding the wheat from the chaff by ensuring
that what goes through gets its tires kicked and rekicked many times.
But as I see it, it's ultimately ineffective for two reasons, neither of
them having to do with technology:
1. The process does not encourage "hit and run" contribution.
Many folks don't want to contribute major features,
they just want to change tiny things when it suits them.
Lots of times these changes are not detrimental;
usually it's more detrimental to disallow folks from
making them in order to keep Zope "pure" as opposed
to allowing the changes and perhaps accepting some
amount of cruft as a result. Zope is already so
crufty in many places that it's hard to be pious
about it with a straight face. ;-)
2. The process lies. It says that if you follow it, a well-
designed implementation of your proposal
has a good chance of making it in to the core after the
process as its documented is finished. The lie is that one
step of the process isn't documented: it needs to get
past ZC to get in. There's nothing major that has gone into
the core that hasn't at some point needed to go through ZC.
ZC is usually very busy with gigs and cant technically
review everything, thus some very good proposals languish.
It was only because I continually whined that what used to
be CST is now in Zope 2.5, and I work at ZC. It's gotta be
damn near impossible for folks outside of ZC.
No technological solution can really make much an impact on either of
I actually think that with Zope3 in progress, it's a great time to
completely and formally hand off bits and pieces of Zope2 ownership to
folks within ZC and without. This should be the first goal towards
ZC-community collaboration, IMHO.
Martijn Faassen wrote:
> Hi there,
> I've read parts of the open letter threads just now. There's a lot of
> talk about how if only we have better tools the whole process will go
> better and Zope will get more contributors.
> That's a typical hacker response, and I do this myself as well.
> Throwing more technology at a problem doesn't always make a problem go
> away. And though technological solutions to social problems are nice if
> you can have them, and we should look for them, they don't always work.
> I'm not convinced more technology will make the dead fish problem go
> away. I think the contributing process is in fact too heavyweight. It
> should be easier for people to get in drastic changes to Zope. The only
> way for people to take more responsibility if they can actually have it.
> Only a few people will take it, but that's more than what is possible
> now, with possibly the single exception of my taking responsibility for
> ParsedXML. And until recently I was still in the position of doubting
> whether I really had it formally, not just de-facto. I kept asking for
> approval and guidelines from the official maintainers, but they were too
> busy (no blame to them), so I went on anyway and did a release eventually.
> I dread having to go through the fishbowl to add in my 'node path'
> implementation to ParsedXML. I've done the design work,
> I've implemented most of it, and I feel I'd have mostly wasted time writing
> a fishbowl proposal. I hadn't even explored the problem enough to be able
> to do that. I needed to prototype it to understand it. I've discussed some
> issues with people locally and and on the Zope-XML mailing list. And
> I'll probably release a version in a few days.
> Perhaps adding Formulator to the Zope core would be nice eventually. But
> going through the fishbowl bureaucracy would take forever. I only have so
> much time to spend on it, and I'd rather spend time improving the product
> And now look at how the Zope core is actually being developed. Sure,
> there's lots of stuff in the fishbowl about what the Zope future should be like.
> Plenty of stuff, though some stuff is rather hard to find. But I have a lot
> of praise for what the Zope Corp people have accomplished it it; it's a lot
> better than having no such thing at all, even if it's only used as
> a notification service in part.
> The main thinking about the directions of Zope is not done in the fishbowl or
> on the lists, it's in the minds of the talented people at Zope Corp and in
> the brainstorm sessions they hold together. That's the natural way people
> work. I work that way too. Such a process can occur on mailing lists as
> well, but it's very hard to break into it. I've tried several times.
> I'll keep trying as I'm convinced it's possible, but it takes a lot of
> persistence. Time will tell. On the Zope-XML list I just post regular updates
> about my thinking to encourage discussion, and sometimes that works.
> So what am I trying to get at with this mail? One thing is that
> the process is too heavy-weight right now. The other thing is that
> the core coders at Zope Corp are in a position nobody else is in, and
> that should change. They are the only ones that can get around the
> fishbowl if they so desire. They can use the fishbowl in effect as a
> notification service. Not that they want to; I don't doubt their
> good intentions for one minute.
> But I want to be able to use it like that too when I need to. Others
> should be able to as well. I think I and a few other contributors are
> slowly getting to that position, but it happens too slowly and takes way
> too much persistence now. So let's trade in some risks to the Zope core
> development (rash action and messed up stuff happening once every while),
> in exchange for a lot more active contributors.
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope )
Chris McDonough Zope Corporation
"Killing hundreds of birds with thousands of stones"
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -