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

Jeffrey P Shell jeffrey@cuemedia.com
Sun, 12 Jan 2003 13:50:14 -0700


I have a lot of messages to go through, and I still haven't even eaten 
yet today (and am actually recovering from a couple of days of birthday 
drinking and eating), so I'll try to make this quick and hopefully I'm 
understanding everything that is happening.

On Sunday, January 12, 2003, at 06:05  AM, Sidnei da Silva wrote:

> On Sat, Jan 11, 2003 at 02:45:03PM -0500, Guido van Rossum wrote:
> | Lots of issues to respond to.
> |
> | - Volunteers.  I regret that it appears as if offers to volunteer are
> |   being ignored.  That's not supposed to happen!!!  Zope.org (old or
> |   new) can't work without volunteers.  The volunteers need to be
> |   coordinated, and for the NZO transition, that's Sidnei's job.  He
> |   has asked for volunteers once, and one was even officially sworn 
> in,
> |   but I don't know what happened after that; I haven't heard Sidnei
> |   reporting that any volunteers were doing anything.  Maybe Sidnei
> |   dropped the ball?  (He spent three weeks in the hospital, which may
> |   have had something to do with it.)  Several people have said they
> |   would volunteer; to cut things short I suggest that they write 
> again
> |   directly to Sidnei (cc'ing me) offering their help.  One thing:
> |   before you can get access to the management side of the site, you
> |   need to sign a non-disclosure form, because you have access to lots
> |   of privacy-sensitive data.  But that shouldn't hold you up more 
> than
> |   a day.
>
> I think this one deserves a real good explanation. The NZO project,
> negotiated between me & ZC says clearly that the work will be done
> by me, which make use or not of volunteers, and would result on a
> migration procedure and a mostly working setup with a mostly working
> skin for NZO. From this point on, we will have a transition from CZO
> to NZO where volunteer work will be essential for success. There are
> some reasons for this:
>
>   - Many people from the community *want* to help, but are often too
>   busy to coordinate. Its not easy to coordinate work and keep
>   milestones on sight if you never know when your volunteer will be
>   available to finish that skin, or fix that bug that is preventing
>   you to complete your milestone.

I agree.  This seems to affect the Zope community more than others, 
maybe it's just that everyone seems to have to work harder (especially 
in the web development business) to earn their money.  As soon as 
there's free rent and free food to go along with free software, it will 
probably be easier to contribute.  But I doubt we'll see markets like 
that anytime soon. :)

>   - The new Zope.org will use lots of software besides Zope. Many
>   people helped (and others could help but havent) by fixing those
>   pieces of software. Namely, Andy and Kapil, which made the first
>   stab at CMFBackTalk and Simon, that made the ZWiki upgrade very
>   smooth, added some features from WikiForNow and improved
>   CMF-compatibility.

The one thing that I will beg for for NZO is to cut down on Wiki 
proliferation.  Wikis are their own moral universes with their own 
workflow and content organization.  It works for some purposes, but not 
all.  I would love to see the new fishbowl proposals become single 
documents with REAL workflow attached instead of ne'er maintained 
WikiStatusBadges or something like that.  I think that will be a lot 
easier for those who have to review the proposals to actually review 
them and pass judgement.  If individual projects want to use a Wiki to 
collaborate development after a proposal has been accepted, that's 
fine.  But I think we should cut down on the number of wikis used for 
other purposes.  Most ZWiki documents really seem to be single-author, 
many-comments.  I think that the discussions tool for the CMF and "edit 
this page" functionality that the CMF actions tool provides should cut 
down on the need for wikis.

>   - The main problem behind Zope.org is not the software, but how
>   content is organized. *That* will be the hardest task to be done,
>   and thats something that will need consensus. Its not a task for a
>   single person. If a script takes around 8 hours to migrate Zope.org,
>   I imagine a single person taking from 2-3 years to put Zope.org in
>   good shape regarding content. So *thats* where we will need
>   volunteers, and *lots* of them. Divide and conquer!

I agree.  I think that the content structure should be simplified.  The 
basic content structure that's on Zope.org isn't necessarily bad, it's 
the proliferation of content (how-to's, tips, etc) in member folders 
that needs evaluating; especially out of date documents - do we keep 
these?  We should ensure that the "modified date" metadata element 
doesn't change between CZO and NZO.

> | - Plone.  Whether or not it's compatible with CMF is anybody's guess,
> |   but it's certain that Zope Corp couldn't help Sidnei if any
> |   Plone-related problems were to crop up.  When we started Sidnei's
> |   contract, we discussed this with him and decided not to use Plone.
> |   I believe the reasons for that decision still stand, and in any 
> case
> |   I don't want to jeopardize the alpha (planned 3 weeks from now!) by
> |   switching now.  Once we have the new site up, I'm all for making a
> |   plan to improve the look and feel if needed, but our first priority
> |   should be to get the new site in production.  Note that we *have* a
> |   winning design for a skin (designed by Nicolas from IngeniWeb by 
> the
> |   way -- I forgot to mention that last time).
>
> I need to schedule another run of the migration script anyway, so I
> will use a Plone site again this time and make the Plone skins + CMF
> skins + NZO skin available for choosing. Its just a matter of set your
> preferences to see the difference. Plone has a lot of features and all
> those features are tied to the Plone skins. If you *dont* use those
> features and use the CMF skin instead, its the same thing as using a
> CMF site *even though its a Plone site*. But I will not take the
> decision alone. I can make a Plone site or a CMF site available in the
> same amount of time. No delays or whatever. But Im worried about who
> will keep the site working after it goes live.

I do think that some of Plone's features (automatic ID generation - 
with the ability to disable ID entry!) are nice for community sites.  
I'm sure many on the Zope.org Reviewers list have seen plenty of 
strange Ids come through (including ones that end up with trailing 
spaces, etc).  ZopeZen works this way, and it's nice - add a news item 
and just enter the title.  It actually is kindof sucky to have to think 
of an id for a news item.

So Plone does add some nice features, regardless of what one thinks of 
the UI (I do think that <http://zope.ch/> is much nicer to look at than 
most Plone sites (especially in Apple's new Safari browser, which 
doesn't render Plone's tabs well).  Fortunately, UI is replacable.

Another thing I'd recommend (in case this hasn't already been done) - 
NZO should stick with released software wherever possible, and avoid 
running on betas or even release candidates (and Plone is still at RC1 
status) and should definitely avoid running on CVS checkouts.  Meaning 
- if Plone is wanted, we should make sure that we test heavily against 
what's there and try to help them get to a bug-free 1.0 release (RC1 
has a couple of bugs that are easily fixable (and are fixed in CVS)).

There also seems to be some decent update/customization tools for 
Plone.  The other thing that the NZO software should take into 
consideration is upgradability so that it doesn't get stuck on a 
heavily modified version of Zope 2.6.1 for years :).  Again, I'm sure 
this thought has crossed everyone's mind.  Plone and ZopeZen seem to 
have made some progress in this area offering Tools to aid in executing 
update / configuration scripts.

*Whew*.  It's now an hour and a half later, and I still haven't eaten.  
But the zope.org/Documentation page is looking a little bit better!

--
Jeffrey P Shell
jeffrey@cuemedia.com