[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