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

True.

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

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 zope.org fromt he beginning instead of a
cherry-picked zope3.org. 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 zope3.org while other docs (e.g.
installation guide) remains on zope.org. Also, once we have a leaner,
meaner zope3.org, I can already see Andreas putting Zope 2 tarballs
there because the old zope.org 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 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.

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.
zope.org/docs should have docs about Zope 3 too, zope.org/downloads
contains Zope 3 tarballs, zope.org/collector contains Zope 3 issues,
zope.org/dev 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 (zope.org/zope2), not Zope 3 (zope.org/zope3).

>>> 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 zope.org right now...

Philipp
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to