[Zope-CMF] Re: Plone participation in the CMF list

[Tres Seaver]

-----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-----