[ZWeb] Zope.org and New zope.org status

[george donnelly]

hi

> I think it's critical to look for ways to lessen the commitment and tap
> into extra manpower.  Thus, I propose that nzo use Plone, for the
> following reasons:
> 
> 1) They've already done a lot of cross-browser work.  IMO, anybody that
> says cross-browser UI styling is someone not responsible for actually
> doing it. :^)

At the same time, making something cross-browser (v4 or v5 and above) *and*
uncomplicated (ie fast and easy to maintain) is not all that terribly hard.
Plone has a lot of javascript-ish stuff that *is* hard to make cross-browser
but at the same time is a PITA and is not always well-loved.

> 2) The Plone community will continue doing such work going forward.
> How much improvement will go into NZO after the launch?

yes but do you want zope.org to be *another* plone clone? zope.org still
needs a custom design.

> 
> 3) If you compare the size of the Plone community to the nzo
> community... :^)

good point

> 
> 4) Plone is built on CMF already, as is nzo.
> 
> 5) Geez, they're a great Zope success story for Zope, it makes sense to
> collaborate with them and show confidence in what they're doing.  If
> not, NIH rears it's head.

very true. it would be great to support plone in this way.

> 
> 6) Plone can accomodate different looks and styles, so we could keep
> the nzo look (which, ironically, came from Plone).

This is true of the CMF as well.

> As an example, Andy recently migrated ZopeZen from his own Zope
> software to Plone, and it doesn't look anything like plone.org.
> ZopeZen is arguably the second most important site in the community.
> If Andy can migrate to Plone, I think zope.org can seriously consider
> it.

i think there would still be the content migration issue. All of the zope
zen content that was migrated was CMF-ish (and a recent version) to begin
with.

> 7) We could take the content objects for nzo and put them in the
> Collective, so they won't (hopefully) languish.

good point.

> 
> 7) With Plone, a better nzo can arrive sooner (obviously a subjective
> statement).

it might be a quicker fix.
> 
> Downsides:
> 
> 1) We introduce a dependency on non-core software.  (BTW, will nzo will
> use anything from the community?)
> 
> 2) Some people don't like Plone.  Like with CMF, it's hard to pin down
> the reasons.

basically because its slow. its just plain slower than stock CMF. also its
still a little immature and prone to occasional problems.

> 3) People claim Plone has a performance penalty.  Not as much as the
> claimed penalty of CMF (which is being used for nzo), but a claimed
> penalty nonetheless.  I don't think there are numbers, unfortunately.
> Maybe we could ask Andy.

i find stock CMF to be faster than plone (i think this is a combination of
zpt vs. dtml and the javascript that plone uses.)

> In summary, given constrained resources, I think the path of least
> effort and most ROI runs through Plone.  And such a choice will
> demonstrate that zope.org is open to working with the Zope community.
> 
> On to the volunteering...A call-to-arms in the Plone community might
> turn nzo from its current status into something we're proud of.  I'm
> personally willing to participate and contribute hours.  We were making
> pretty good progress working together last spring, it could happen
> again.

perhaps another issue might be how are people who have already volunteered
being integrated into the project? I volunteered in the suggested way and
was never contacted.

<-->
george donnelly - http://zettai.net/ - "We Love Newbies" :)
Zope Hosting - Dynamic Website Design - Search Engine Promotion
Yahoo, AIM: zettainet - ICQ: 51907738 - e:george@zettai.net