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

[Paul Everitt]

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.

Thanks for getting this discussion started, Guido.  It's a healthy sign.

Some points:

1) I think one of reasons for lack of volunteering is the absence of 
final decision maker.  Back in May, we worked well together as 
volunteers because there was an active BDFL that could make the final 
decision on both zope.org and new.zope.org.

I don't think Sidnei can make such decisions on czo (current) or nzo. 
Am I incorrect on this?

I'm not sure who makes the final decisions on current zope.org.  Several 
of us have asked this question quite a few times since August, without 
response.  Guido, are you the BDFL?  Jeffrey?  Martijn?

Volunteers are more effective when the BDFL is known, active, and 
*directly* involved in coordinating the work.

2) I don't have the impression that we, the zope-web community, are 
empowered in the same way as the Python, Zope 2, CMF, and Zope 3 
communities.

Based on the status report, there is a lot happening behind the scenes 
that we don't get to see.  We need to get closer to the fishbowl process.

Thus, in addition to giving work to zope-web people, I suggest that 
zope-web operate like Zope: discussions in the open and consensus 
decisions. And when no consensus emerges, an active and visible BDFL 
makes the papal edict.

It may be that there is a different, and better, process suggested for 
working with the community.  Either way, this is a good discussion, 
thanks for bringing it up.  We need to figure out how (or even if!) 
zope-web participates in the decision-making of zope.org.

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

I'm not sure what it means for ZC to help.  My guess is that ZC is 
booked with customer work.  That was a difficult point for zope.org in 
2002, as you saw with python.org.  Has there been a change for 2003?

In fact, this is exactly my Plone point: based on history, there is more 
reason to expect help from the Plone community than help from a 
single-entity such as ZC.  The Plone.org site is at least a hundred 
times more actively-maintained than either zope.org or the dogbowl, and 
I'm probably being conservative on that estimate.

I might be wrong, though.  Is anybody from ZC working directly with 
Sidnei in the code, making checkins, etc.?  If so, that would support 
your point.

IMO, Zope.org's long-term interests are best served by leveraging the 
work of greatest common knowledge.  One of current zope.org's biggest 
problems is that nobody knows where the bodies are buried.  And thus, 
people would rather create zope3.org than improve zope.org, because it 
is an orphan that nobody understands.

I worry that is happening again for nzo.  It is a hot potato passed from 
one contractor to another, each doing it as a second job on an interim 
basis.  I realize this is just my opinion, and I have no idea if it is 
shared by others.  But it concerns me, and I care a lot about zope.org.

>   Plone-related problems were to crop up.  When we started Sidnei's
>   contract, we discussed this with him and decided not to use Plone.

IMO, these discussions should have happened in a fashion more like 
Python, Zope, CMF, and Zope 3, fishbowl style.  Even if somebody at ZC 
is the BDFL on zope.org, the BDFL *still* engages the community's opinion.

Your first sentence pondered why it appeared the community was being 
ignored.  IMO, this might be an example to learn from.

>   I believe the reasons for that decision still stand, and in any case

Could you review the reasons?  I outlined the pros and cons for going 
with Plone.  Like you, I'm convinced my reasons stand.  Others agree 
with some of my points.  Others disagree with some of the points.

ZC could dispel the appearance of ignoring the zope-web community by 
putting the Plone decision up for community discussion.

>   I don't want to jeopardize the alpha (planned 3 weeks from now!) by

Clearly we all want a *good*, *sustainable* site in production.  IMO, 
Plone is the fastest way to accomplish this.  Otherwise, everything is 
silently on the shoulders of one person, who then will throw that 
mysterious bag of stuff over the wall to the next contractor, until 
there's nobody on the other side of the wall (czo).

But here's a proposal to address this concern.  You currently are 
scheduling based on a single resource, right?  (Is anyone at ZC besides 
Sidnei doing checkins?)

As you asserted above, ZC is open to community participation.  So we'll 
take some resources that don't affect the schedule and do a Plone-based 
Pilot.  If we get a pilot working before the alpha, and it is better 
received than the other approach, would ZC "allow" zope-web and nzo to 
go in that direction?

Doesn't impact the schedule at all, plus, it proves that nzo is open to 
the community.

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

BTW, Olivier from Ingeniweb based it on Plone (per the comments in the 
CSS).  Of course, Plone has since advanced, improved, fixed bugs, etc. 
None of which zope.org benefits from. :^(

> - Download mirroring.  The downside of using SourceForge is that it
>   requires explicit synching of selected downloads.  How about setting

Yep, that downside was outlined in my proposal.  In addition to the 
upsides. :^)

>   up a set of community-run mirrors of the zope.org download bits?

Sure, a new Zope-based download system would be a good addition.

After I finish the SF-based download center, I'm personally interested 
in working on such a Zope-based system.  As you know, I failed miserably 
at the first Python SIG, the whole Python-CPAN "locator-sig".  I'm still 
trying to redeem myself. :^)

>   This could be done as follows: when downloadable contents is
>   uploaded, an extra copy is made to somewhere on the filesystem.  (Or
>   maybe a nightly cronjob hunts through ZODB for downloadable contents
>   and copies it.)  This section of the filesystem is then made
>   available to mirrors through ftp and rsync (I don't know what mirror
>   sites prefer; for python.org, we support both, although rsync seems
>   more modern).  The zope.org webmaster maintains a list of mirror
>   sites, and when you select a file for download, you are offered a
>   menu of links directly to the mirror sites, with their geographical
>   locations.  There needs to be a way to collate download stats from
>   the mirrors, and there needs to be a way to provide feedback on
>   mirrors that are in decay, so the webmaster can remove them from his
>   list.  None of this should be rocket science, and since Sidnei is
>   writing a new product for downloadable content anyway (boy did the
>   old one suck :-( ) it shouldn't be too hard to integrate it in
>   there.

Presumably you're proposing work on this after launch, right?

But still, if a Zope-based download system arrived, it would obviously 
be a beneficial addition to the SF-based one (and all the others, 
Debian, etc.).

We should probably fix the zope.org download page to also point to the 
RPMs, Debian, Windows, Fink, etc. done by the community.

> - Zope3.org.  Since the Rotterdam sprint I've been fairly active in
>   Zope3 (and expect to be much more so, with others at PL, in the next
>   half year), and I think a separate site for Zope 3 developement is a
>   great idea.  Obviously, once Zope 3 is ready to replace Zope 2 for
>   production work, zope.org should be the place to learn about Zope 3
>   (and zope3.org could remain as a site for Zope 3 developers).  I'm
>   doubtful whether Zope 3 is currently capable of serving such a site
>   itself: too many things are in still flux or not yet working, there
>   are no content-specific products, searching and indexing doesn't
>   work yet (it's a shallow problem), and it's veeeeerrrry slllloooow.
>   But according to the "eat your own dogfood" theory, we should
>   attempt to do this ASAP -- maybe we should strive to transfer all
>   Zope 3 developement knowledge to zope3.org a month from now.

I agree with what you're saying, all of it.  I think we can brainstorm 
the right kind of thing to pursue that balances the desire to eat 
dogfood with the obvious constraints.  I have a bunch of ideas, I'm sure 
others do as well.

Primarily, I think that choosing a narrowly-focused site, focused on one 
kind of thing, would be a good choice for a Zope 3 site.  Maybe it's 
Wikis.  Port ZWiki to Zope 3, then create wiki.zope.org.  (Kind of makes 
sense, since all Wikis are in a separate storage on Zope 2 anyway.)

Another choice: mailing list search archive.  This has the nice benefit 
that, if everything died, we wouldn't be upset (because the data could 
be recovered.)  Seeing the "this checkin requires you to delete your 
Data.fs" messages on zope3-dev validates this point. :^)

It would be *really* a benefit if this zope 3 site was hosted out in the 
community.  ZC's sysadmin resources are spread thin and focused on 
paying customers.  This would be a good, small step towards distributing 
the work around.

--Paul