Philipp von Weitershausen wrote:
Here's my 2 cents, even if I might be too late (but hey, when should
I have brought this up?): I think it's a *bad* idea to host Zope 3 on
its own site, because:
a) It will be yet another systems we need maintainance volunteers
for. As it seems we don't even have enough for the current zope.org
right now. If we had more volunteers with more time on their hands,
they would have already been on the matter and the dog-slow system
would have been improved a long time ago (note that I'm not
necessarily saying replaced). A zope3.org will eventually need some
caching, it will eventually need user management, etc. We already
have a human resource problem on the development side, what makes
everyone think we won't have it on the maintainance side?
A counterargument to this would be that volunteers to maintain the
present zope.org infrastructure and content are hard to find. A leaner,
meaner, separate zope3.org might find more people that want to be involved.
Sorting out the content of zope.org, which has been carried around for
more than half a decade, is a job I wouldn't volunteer for. Helping to
write some content for a fresh new site and figuring out what fits where
is something I *am* volunteering for.
b) It is exactly the opposite of what we've been trying to do for the
last couple of months: convergence, not divergence! If we want Zope
3 and its Component Architecture to be recognized by people, it needs
to be a first class citizen on zope.org, not some separate site. Why?
Because Zope 2 will soon incorporate lots of Zope 3 technology (it
already does incorporate some), making it all look like two separate
worlds is far from reality.
As Benji said, we want to market to non-Zope 2 developers with this as
well, and we can link zope.org to zope3.org. Placing some distance
between Zope 3 and Zope 2 is useful in order to convince people who've
been scar(r)ed by their previous Zope 2 experiences, or at least
received the meme that Zope 2 is something Python programmers don't want
to mix with, to take another look at Zope 3 now.
Perhaps we can come up with a similar scenario as what we think is going
to happen with Zope 2 and Zope 3. Zope 2 is the old, hard to maintain
system here, Zope 3 the new cool system. We intend to improve Zope 2 by
adding in Zope 3 pieces, and eventually start replacing parts of it with
Zope 3 technology. In the foggy future, Zope 2 and Zope 3 become
profiles of the same Zope system, until the differences have gone away.
zope3.org could be to zope.org what Zope 3 is to Zope 2. We could
cherrypick the content in zope.org that is about Zope 3 and want to have
in the new site. Eventually we may start building up a section about
Zope 3 in Zope 2 as well on the new zope3.org. Over time, more and more
of the useful content gets moved, until finally zope.org and zope3.org
are essential the same website about Zope. At some stage we flip a
switch and turn zope3.org into zope.org.
I have a slight preference for something like zope3.org as compared to
zope.org/zope3, as I think that makes the separation a bit clearer. Of
course, zope.org/zope3 could be technologically separated from the rest
of zope.org too.
The new thing is, that Wikipages should be editable with a WYSIWYG
editor after the migration. I hope that there will be an option to
choose structured text too.
Putting WYSIWYG integration into a list of first-class todo items
seems like wrong prioritization to me (I'd rather have a stable
backend first), but I'm not going to get into that now. It seems that
community input wasn't wanted (and I would love to be proven wrong on
I think it's important to try to separate the content
production/technology aspect of things, which the sprint apparently
focused on from the actual site content aspects.
From what I can see, the sprint focused on using Zope 3 technologies to
build a Zope 3 site. To use Zope 3 for a Zope 3 site seems a good idea
from the marketing perspective already -- we want to demonstrate we can
eat our own dogfood. The idea seems to have been to use a wiki for this,
something which also has a predecent within the Zope community, as well
as in the open source community at large. The whole WYSIWYG HTML-edit
wiki thing is a neat idea involving using HTML as the wiki markup
language instead of something else. We'll just have to see how that
Zope3-dev mailing list