[Zope-dev] Re: My thoughts on the development process

[Paul Everitt]

I've taken a while to respond on this, because I wanted to talk it over 
with folks here, to think about the specifics of what different ideas 
would mean, etc.

In summary, your last paragraph says: "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."

We agree, and it's my job to get us there.  Here's the next level of 
specificity:

1) Lighter weight process.  Brian and I have talked about it, and we 
agree that we should investigate ways to lower the bar on ceremony, 
*without* abandoning organization.  However, we both feel that, as you 
noted, the ultimate issues lie elsewhere.  Thus...

2) Improve the tools.  There's merit to the argument that the state of 
the fishbowl isn't very discoverable nor usable.  Folks on zope-web know 
that we're proposing work that we'll do.  Also, we are open to work that 
others will do.

3) Delegate leadership.  This is, IMO, the most important thing.  We 
need more people in the core, leading important areas and making 
decisions.  For ZC, this really means that we have to trust the 
trustworthy and accept the paragraph of yours I quoted above.

4) Find the leadership.  We can't sit passively by and say, "We opened 
CVS and nobody's done anything."  Somebody has to work specifically and 
repeatedly to bring people in, make sure they know what to do, and 
perhaps even prod them occassionally to get working.  This takes 
publicity, promotion, cajoling, communications, and all kinds of other 
things to get the momentum going.

I've signed up for the last part.

In general, I'm sure everyone is pretty talked out on this subject and 
ready to see some action and results to go with all the voluminous 
emails.  Me too.  So let this general "state of the problem" discussion 
rest for a while, and let's work on some of the good ideas already 
discussed.

--Paul

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
> itself.
> 
> 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.
> 
> Regards,
> 
> Martijn
> 
>