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 > > _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
