IMHO one every important point is the lack of an open bug tracking system for Zope development. The collector on classig.zope.org is next to useless and doesn't fit to Open Source development: Apart from the fact that I never received any feedback on things I reported there, it is something like a "black hole" for bug reports: Resolved bugs are visible to everyone, but bug reports that are still unclassified are invisible to the public (well, except the Subject line), and therefore it's impossible for the community to use the collector to verify potential bugs. This kind of system may be fine in a closed development environment, but it won't work for open source projects. I understand that you're working on replacments in Zope (and that there's a big interest in this from the Python community as well). I think if you'd like to improve interaction with the community, that's a very crucial point. Maybe it would be worthwhile to look into proven alternatives like Jitterbug or the Debian BTS. Gregor On Thu, Apr 06, 2000 at 02:39:30PM -0400, Brian Lloyd wrote:

Even better is for the user community to be able to participate in *fixing* problems (and "scratch their own itches" generally).

We are very aware of the problem - resource availability at DC is currently the biggest bottleneck in getting problems resolved, getting features added, etc. And that's just with Zope itself - when you think about the multitude of various database adapters and other components out there, it's obvious that the more popular Zope becomes, the less likely it is that we could possibly keep up with it all, even throwing all of our ever-growing resources at it.

The Answer of course is the decision that we have taken - that Zope needs to truly be developed "in the fishbowl", that we need to open the development process and provide the infrastructure required to allow community members to champion their own issues and remove DC as the bottleneck. People with vested interest in a component such as a particular DA should be able to take the lead on that component, have real ownership and control their own destinies.

"Ok - that sounds great, but WHEN?" you may be reasonably saying to yourself. We made the decision some time ago that this is the way that we need to go, but the resources to make it happen are just now becoming available. We are even now working on figuring out the best way to "get there from here". The devil is, as always, in the details, and I expect to start soliciting opinions from the Zope community soon to resolve some of those devilish details and get to work on implementing the open development process.