[Zope-CMF] Re: Plone participation in the CMF list
Tres Seaver
tseaver at palladion.com
Tue Aug 2 12:55:51 EDT 2005
-----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 tseaver at palladion.com
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-----
More information about the Zope-CMF
mailing list