My thoughts on the development process
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
Hi Martijn! Formulator is a good case how things can work. You did the main design work on your own. And that was very good. Then we had the chance to contribute ideas for new fields etc. I now have my own FormulatorExtensions product with stuff I could imagine being part of Formulator as soon as they are really ready for it. Others added multi-page forms support etc. But all that contributing and extending only works because there was a sane architecture at the beginning. So the contributor doesn't have to answer the question "How would I possibly like my forms?", but just answer questions that are much more focussed, like "How can I add a WYSIWYG editor to text fields?". It is possible, but painsome to do design work on the web or via a mailing list ... BTW: Just for the record: FormulatorExtensions currently include: - a Link field that has a Javascript pop-up to fill it with local links from a tree view of your site. The pop-up can be specified as a method. Also works for choosing images from pools - an HTML field with stripogram support (thanks to Dirk Datzert) and an optional WYSIWYG editor (IE only) - an internationalized version of the list field (to be able to translate the list items via ZBabel) - a size field for tables etc. (choose a unit like % or px, and add a value) Joachim
--- Martijn Faassen <faassen@vet.uu.nl> 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 agree, the problem is more social than technological. However, cool technology that saves time rather than wastes it, makes contributing a pleasure rather than a pain, would be a great benefit IMHO. I was actually really down on Zope on Wed and Thurs. I was about ready to go and do something myself. Mostly writing and theorizing at first and then developing. However, Friday turned me around. I don't want to start from scratch, it's too hard. I don't want to "build" a community from scratch, it's damn near impossible. We've already got a tremendous community here, and it hasn't realized its potential even. So, I decided to stay here and do my theorizing and tinkering with Zope stuff, even if I'm not in 100% agreement with the way everything is done. And if nobody likes what I do, then I'll have my own Zope the way I want it thank you. If people like it then fine, they can have it. Nothing technological changed my mind, it was purely social.
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
It will be a slow and deliberate process to allow "outsiders" the ability to make big waves. It has to be in many respects. But I think each contributor will slowly make part of the core their own and take the initiative with it.
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.
Yes, prototypes are extremely valuable, more-so than fishbowl proposals to us hackers. But not everyone can appreciate a prototype, because the audience for feedback is not always hackers. Making a prototype work for non-techies is a lot of work too...
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.
Yup, there needs to be people charged with analysing and taking outside products and integrating them with the core platform. A process to do this should be put in place.
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.
I agree. It's better than nothing.
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.
There needs to be some way to elicit discussion. Again, I think this is a social issue. We need to "market" the idea that the community voice matters, and that feedback is a valuable contribution, no matter at what level it comes from or how it is made. I intend to try to do this in whatever ways I can think of.
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.
That probably won't happen until a significant core module is in the hands of an outside community member. Then I think it can happen readily.
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.
Once the testing framework is totally nailed down so that all the requirements can be accounted for, then I think this might be possible. I don't know how close we are to that tho...
Regards,
Martijn
I think these discussions are incredibly healthy. Lets keep up the dialog. -Casey __________________________________________________ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com
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 these problems. 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. - C 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 - Zope-Dev@zope.org 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 )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
Chris McDonough wrote:
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.
Hang on, surely you mean Zope3 there? What's the point of handing off responsibility for what is essentially dead code already? How would doing that help the progress of the latest-and-greatest Zope? cheers, Chris
No I mean Zope2. That's not in exclusion of handing off bits of Zope3, but Zope2 is still the current stable release and as such isn't dead code. Huge parts of Zope3 are in flux at the moment, and though folks are more than encouraged to contribute, it's not for the faint of heart. Zope2 is familiar and fairly well understood. ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Chris McDonough" <chrism@zope.com> Cc: "Martijn Faassen" <faassen@vet.uu.nl>; <zope-dev@zope.org>; <paul@zope.com> Sent: Tuesday, December 04, 2001 1:06 PM Subject: Re: [Zope-dev] My thoughts on the development process
Chris McDonough wrote:
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.
Hang on, surely you mean Zope3 there? What's the point of handing off responsibility for what is essentially dead code already?
How would doing that help the progress of the latest-and-greatest Zope?
cheers,
Chris
Martijn Faassen wrote:
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 <snip> are the only ones that can get around the fishbowl if they so desire.
Here! Here! Chris
Chris McDonough wrote:
The other thing is that the core coders at Zope Corp <snip> are the only ones that can get around the fishbowl if they so desire.
Here! Here!
Not really. I couldn't, at least.
You guys can use the fishbowl as what is in effect an announcement service. I'm not saying that isn't useful, but nobody else can announce a project in the fishbowl and have a lot of hope it'll end up in the core right now. But if it's okay I'd be glad to use it that way as well. :) Perhaps that's not exactly "getting around the fishbowl". I'm not saying the fishbowl is a bad thing, though. I think it's pretty useful. And I'm slowly learning I should just do stuff anyway, though part of that does include discussion and announcements. The core coders don't have enough time to actively coach me so I should just coach myself. :) Regards, Martijn
There really is a lot more work that goes into the stuff in the fishbowl from the folks at ZC than just an announcement. That said, I agree that a ZC proposal driven by a consulting project will more likely end up in the core than anything else, so I think I understand what you're saying. The problem really isn't that folks at ZC can get around the fishbowl process, it's just that consulting-driven ZC projects currently take priority over just about everything else, and they soak up all available ZC resources. One of the remediations has been to extend CVS commit privileges to folks outside ZC, and we've done that. It's clear we need to do more than that, but it's not clear exactly what needs to be done or how to do it. We know it has something to do with changing the process and spreading responsibility out, but we're still taking baby steps. ----- Original Message ----- From: "Martijn Faassen" <faassen@vet.uu.nl> To: "Chris McDonough" <chrism@zope.com> Cc: "Chris Withers" <chrisw@nipltd.com>; <zope-dev@zope.org>; <paul@zope.com> Sent: Tuesday, December 04, 2001 2:44 PM Subject: Re: [Zope-dev] My thoughts on the development process
Chris McDonough wrote:
The other thing is that the core coders at Zope Corp <snip> are the only ones that can get around the fishbowl if they so desire.
Here! Here!
Not really. I couldn't, at least.
You guys can use the fishbowl as what is in effect an announcement service. I'm not saying that isn't useful, but nobody else can announce a project in the fishbowl and have a lot of hope it'll end up in the core right now. But if it's okay I'd be glad to use it that way as well. :)
Perhaps that's not exactly "getting around the fishbowl". I'm not saying the fishbowl is a bad thing, though. I think it's pretty useful. And I'm slowly learning I should just do stuff anyway, though part of that does include discussion and announcements. The core coders don't have enough time to actively coach me so I should just coach myself. :)
Regards,
Martijn
Chris McDonough wrote:
There really is a lot more work that goes into the stuff in the fishbowl from the folks at ZC than just an announcement
Exactly. But in the end, if nobody responds except internally at ZC, and you implement it, the fishbowl stuff is kind of an announcement, right? And others outside of ZC can't do that. I'm not saying that you want this to be the case, but it's what happens in effect.
That said, I agree that a ZC proposal driven by a consulting project will more likely end up in the core than anything else, so I think I understand what you're saying. The problem really isn't that folks at ZC can get around the fishbowl process, it's just that consulting-driven ZC projects currently take priority over just about everything else, and they soak up all available ZC resources.
And *some* ZC resources, even though just an 'okay go ahead' on a mailing list, are needed at least to get contributors going. I had to ask about releasing ParsedXML several times until I got some kind of 'aye' out of anyone. And it still wasn't clear. I shouldn't have to be that persistent. Of course my ParsedXML contributions are in a large part due to it being necessary for a consulting project -- one of my own. :)
One of the remediations has been to extend CVS commit privileges to folks outside ZC, and we've done that. It's clear we need to do more than that, but it's not clear exactly what needs to be done or how to do it. We know it has something to do with changing the process and spreading responsibility out, but we're still taking baby steps.
Okay, I'm just playing devil's advocate here pushing the poor baby into the direction I think it should be going. :) Perhaps the contributors should start doing the +1 -1 thing over fishbowl projects, sort of like what Chris Withers initiated over at the Zope3-dev list. Still needs someone at ZC to play benevolent dictator though, though an Apache-style core group with veto style might work as well eventually. Anyway, I'm not really complaining about ZC; I have a lot of admiration for what you're doing and the steps you've already taken are not mere baby steps at all from my perspective. Just offering a couple of my eurocents. Regards, Martijn
Martijn Faassen wrote:
a mailing list, are needed at least to get contributors going. I had to ask about releasing ParsedXML several times until I got some kind of 'aye' out of anyone. And it still wasn't clear. I shouldn't have to be that persistent.
Well, and now I'm being devils advocate, this is Open Source. "Just do it" (now where have I heard that before ;-) If you do it wrong, whatever that means, someone will let you know, but you're not breaking any lawas and activity, as you've shown with ParsedXML, is always better than inactivity :-)
Anyway, I'm not really complaining about ZC; I have a lot of admiration for what you're doing and the steps you've already taken are not mere baby steps at all from my perspective.
+5 It feels like Zope's had a huge shot in the arm in the last few days, so I guess we need to send AKM some beer... ;-) cheers, Chris
Chris Withers wrote:
Martijn Faassen wrote:
a mailing list, are needed at least to get contributors going. I had to ask about releasing ParsedXML several times until I got some kind of 'aye' out of anyone. And it still wasn't clear. I shouldn't have to be that persistent.
Well, and now I'm being devils advocate, this is Open Source. "Just do it" (now where have I heard that before ;-)
That doesn't follow these guidelines: http://dev.zope.org/Fishbowl/Introduction.html with unclear ideas on how you actually get moved from Inception to Eleboration to Construction. I need to post to zope-dev and then wait for Inception->Elaboration to happen, and the 'maintainer of the software product in question' (who do I whine to if I don't know who this is in the first place?) will then just listen and pick up on it and do the editorial and technical review. In practice, I am not sure if any identifiable maintainer steps up, though I do get feedback from ZC people. This is more than just an 'aye', and I need to be persistent about that already..
From Elaboration->Construction I just need "if everything is in order, a CVS branch will be created for the project team to start working on". By whom? Do fishbowl proposals commonly make it here?
If you do it wrong, whatever that means, someone will let you know, but you're not breaking any lawas and activity, as you've shown with ParsedXML, is always better than inactivity :-)
I agree that I should just 'do it', but I'm not following the guidelines if I do it, and though I'm Dutch and toleration of not following the rules is institutional here, I also don't think it's the ideal situation. Either we work out who is maintainer for what and the fishbowl process for the *maintainers* is spelled out (the fishbowl introduction focuses much more on the artifacts to be produced than on the human aspects), or we scrap or completely overhaul the fishbowl process as we do something else anyway. Regards, Martijn
Martijn Faassen wrote:
I agree that I should just 'do it', but I'm not following the guidelines if I do it,
Then the guidelines are wrong ;-)
and though I'm Dutch and toleration of not following the rules is institutional here, I also don't think it's the ideal situation.
I think the rules should change then.
Either we work out who is maintainer for what and the fishbowl process for the *maintainers* is spelled out (the fishbowl introduction focuses much more on the artifacts to be produced than on the human aspects), or we scrap or completely overhaul the fishbowl process as we do something else anyway.
Where can I buy my "I'm an An4rCh15T!!" badge? ;-) *grinz* Chris
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
participants (6)
-
Casey Duncan -
Chris McDonough -
Chris Withers -
Joachim Werner -
Martijn Faassen -
Paul Everitt