-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote: > >> The general mindset of most Plone developers, as I perceive it from >> the CMF side, seems to be one of "I'm in Plone code, and I know what >> to do here, and I don't need to look beyond my world". Very few >> developers have a broader view and even think of pushing generic >> functionality or even specific improvements to core functionality >> that originates in the CMF down to the CMF level. It seems easier for >> them to monkeypatch and override directly inside Plone code. > > > I think you're right, at least as pertains to myself. It's not a > concious decision, I have nothing against CMF and the developers I've > met that are in CMF core I get on with well. However, I think this > mentality resides in a lot (if not the majority) of Plone developers. > Some speculations as to why this may be are: > > - There is no clear strategy or leadership on how this integration > should work. What code is CMF worthy? What isn't? Plone gets stuff > done principally because people yell at other people to help out. If > person X in Plone could say "this looks like something that should be > in CMF, send an email to person Y in CMF and get him to take a look", > and then person Y could respond in a positive way immediately, then the > poor programmer would be more likely to feel like he knew what he was > doing. Currently, that happens rarely. Maybe because... > > - CMF is "infrastructure" and low-level. Such code tends to have more > intertia, and the risk of making mistakes is higher, so one may presume > the best thing to do is to "leave it to the professionals" > > - Plone still has a lot of "process" problems, but with the > PloneHelpCenter, the PLIP process, the collector (sucky though it is) > and the active leadership of people like limi and lurker, we have at > least a fairly good idea of how new features get in, how bugs get > tracked, and rough areas of responsibility that emerge. To an outside, > at least, the CMF world seems to be more difficult to slot into. I'm > sure it isn't, just that I don't know where to go to find out how to > behave well in the community. > > - The CMF community feels less active (perhaps for obvious reasons - > it's more of a stable technology; just reading the list intermittently, > it feels like it's in maintenance-and-blue-skies-future mode, which may > not be true, of course). There's always life and excitement on the > plone-dev and plone-user lists, and in #plone on IRC, so our attention > tends to be focused there. We get to know some other developers, we > start helping out, and so our world becomes confined to that one. This > is obviously a self-reinforcing process. > > - It's yet another contributor agreement and bureaucratic process to > go through; in fact, it sounds even worse than Plone's. So, the > marginal cost for a developer to do it "just for one little fix" is too > high (of course over time, it may not be, but that's moot there and then). > > - The release cycles are not synced. We seem to work best to > deadlines, so there's been a great push towards Plone 2.1 in the past > couple of months. Hence, there may not be time to generalise, test, > talk to CMF and CPS and other people and get something reusable into > CMF. A lot (well, maybe not that much) of stuff in Plone is marked > "XXX: Should probably move to CMF". > > - CMF is less sexy. Getting features into Plone typically mean higher > visibility. For those of us who base custom CMS solutions on top of > Plone, it also puts them closer to our own skillset and toolchain. > > - Plone is (probably) better documented and more widely understood > than the CMF underpinnings. It's not that hard when you know Plone, so > it's probably more of a psychological barrier, but it seems easier to > get a grasp on Plone. > > So, I guess my suggestions for what we can do to improve this situation > may be (some of these may already be happening, but it doesn't hurt to > spell it out) > > - Encourage Plone people to read the CMF list > > - Encourage CMF people to read the Plone dev list, and shoot in > whenever something seems to be CMF material > > - Encourage CMF people to be in #plone, for the same reason > > - Have the senior Plone and CMF people work out some guidelines for > how better to encourage cross-pollination of ideas and code, and > follow through on it day-to-day. > > - Make the CMF contribution process as seamless as possible > > - Produce "how to be a good CMF contributor" documentation that's easy > for a Plone developer to grasp without taking the whole weekend off > reading logs, code and lengthy manuals (incidentally, we're working on > a similar thing for Plone core. We should collaborate here too. I can > give you access to the in-process document if you're interested in > seeing where we are so far). > > - Work *transparently* and *openly* on the Z3/Five/ECM efforts, with > Plone, CMF and non-Plone CMF users. Cross-post major discussions here > to all relevant lists, and produce easy-to-follow documentation about > the state of discussion and implementation, so that people can > determine whether it's feasible to throw their efforts into an existing > project when they need to get something done, either for Plone or for > their own customers. > > - Set out some overarching guidelines in terms of management and > coding standards for such Z3/Five/ECM efforts. Most Plone developers > seems excited abot Five/ECM, and I think long term we do all want to > end up on Z3, but that process is lengthy and needs both champions and > careful communication and stakeholder management. Those who burn for > this project should expect to have to do some kicking and yelling to > get people in gear. Saying, "our code is great, join us" will give you > a few interesting glances. Saying, "you're duplicating what we're > doing, and we can promise you that if we work together this will work > for you by the time you need it" will get you actual code. > > I'm sure others will have much to add as well. However, I think the > fundamental issue here is that there is some culutral separation > between CMF and Plone (and I presume CMF and CPS, CMF and Silva, CMF > and XYZ consumer of CMF). That separation is probably necessary (even > useful) but it doesn't mean that you have to be in one camp or the > other. To get people to be comfortable working at the CMF level, the > CMF people need to make an effort. So do the Plone pople. And the CPS > people. And the Silva people. And anyone else.
Martin, Thanks very much for the thoughtful analysis. I think you are spot-on for most of the issues, and would like to work your "process" ideas into the roadmap for ongoing CMF development. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC76WX+gerLs4ltQ4RAm/IAKCdvnLrSIIidZDOhAE0VeGHqJEdBwCgwtt4 Sa8VgzjHH+idDw2pxUSbbhs= =kaM0 -----END PGP SIGNATURE----- _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests