Martijn Faassen 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
>> 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 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 infrastructure and content are hard to find. A leaner,
> meaner, separate might find more people that want to be involved.


> As Benji said, we want to market to non-Zope 2 developers with this as
> well, and we can link to 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.
> could be to what Zope 3 is to Zope 2. We could
> cherrypick the content in 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 Over time, more and more
> of the useful content gets moved, until finally and
> are essential the same website about Zope. At some stage we flip a
> switch and turn into

This does sound quite reasonable (and it's the first real concept about
all this that I've seen laid out here...). However, I would very much
tend to having a leaner, meaner fromt he beginning instead of a
cherry-picked Cherry-picking on our side will also make the
Zope brand appear weirder because stuff that will inevitably concern
Zope 2 through Five will be on while other docs (e.g.
installation guide) remains on Also, once we have a leaner,
meaner, I can already see Andreas putting Zope 2 tarballs
there because the old is getting too much in his way (which it
really is, and not just into his way, but also ours)... Maybe my view is
just too pessimistic, but I foresee more chaos in separation than structure.

> I have a slight preference for something like as compared to
>, as I think that makes the separation a bit clearer. Of
> course, could be technologically separated from the rest
> of too.

I'm not actually saying that Zope 3 should have it's own section of the
site. I'm saying that the site should be about Zope 3 altogether. should have docs about Zope 3 too,
contains Zope 3 tarballs, contains Zope 3 issues, is be a development area for both Zope 2 and Zope 3. Some
of that is already reality, actually (downloads, collector).

If something would *have* to live under some directory, I think it
should be Zope 2 (, not Zope 3 (

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

Not arguing with you here.

> 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 works out.

Yes, I just wonder whether we have to think about stuff like this at
this stage. I think the lack of WYSIWYG capability is the *least*
problem people have with right now...

Zope3-dev mailing list

Reply via email to