[ZWeb] Zope.org and New zope.org status
Sun, 12 Jan 2003 12:32:28 +0100
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.
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
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
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
> 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
> 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
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,
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.