[ZWeb] Re: light blue touch paper and stand back (was Re: Re: NZO, was Re: Zope 3 branding)
Jeffrey P Shell
Mon, 3 Feb 2003 12:28:00 -0700
On Saturday, February 1, 2003, at 08:30 AM, Simon Michael wrote:
> Jeffrey P Shell <email@example.com> writes:
>> I want to encourage more explicit linking - I want people to make less
>> small pages and to focus more on single documents that are easier to
> Yes, this can be a good thing. I made a similar post recently:
>> (And I want CamelCase to die - 'McDonough' shouldn't be a Wiki link,
>> I shouldn't have to go in there and escape it every time I mention
>> something about Chris just so that damn question mark will go away).
> Well, don't toss it away too lightly. I assume you've read about it's
> advantages at WikiWikiWeb. Also I find no problem with linking in code
> fragments which you mentioned earlier, because code fragments are
> quoted (', pre, ::, etc).
They're not always quoted - in the case of API documentation, for
example, method signatures may be headers or list items. STX's rules
of quoting are mediocre at best - I still get surprised by them. And I
still get surprised by when I have to escape a Wiki name and when I
In any case, Wikipedia has a good case against camel case that I think
applies to what I envision a Zope.org megawiki to be:
Because even worse than seeing 'McDonough' turned into a link is seeing
Zope spelled "ZoPe" or Python spelled "PyThon" or Perl as "PeRl". It
makes Baby Jesus cry :).
> But yes, zwiki should support that policy choice. I want three types of
> linking to be enabled/disabled on a per-wiki basis: WikiNames, [...],
I'm especially for the last one mentioned. I see many occurrences
where people show a tiny piece of Python code inline, unquoted, and
suddenly the  turn into a STX footnote or Wiki link. I like how ReST
_ deals with this situation by making footnote/citation links
explicit by adding a _ after the .
> Anyway - are you against the idea I put out (one prominent zope wiki to
> absorb some of the lost ones) ? I'm not sure.
I'm not dead set against it, but I would like to see a clearer proposal
of what Wiki's are affected and what you expect this prominent Wiki to
be. And I'd especially like to see why you'd think that TalkBack
Books, Documents (with comments), tips, how-tos, and other potential
content types (books, etc), all properly categorized with common
metadata and subjected to a simple review process can't do the same job
instead. Very few Zope.org wikis seem to be collaborative. For some
reason, people seem to be much more comfortable leaving comments on
pages, with the collaborative efforts only really seeming to show up in
major Projects like Page Templates or Zope 3 (or, gods willing, NZO).
A wiki is so different from the rest of the site (promoting having
funny things in a document like WikiBadges or PageMaintainers listed in
lieu of real metadata and/or workflow) that there's a potential for
confusion when someone just wants to write a how-to document - "Do I
put it in my folder, or find a place in the wiki for it?" I think
there's potential for duplicate content between the wiki and the rest
of the site, since some people will put information in one place and
others will put it in the other.
The megawiki that you described as "default catch-all wiki and
jumping-off point, free-form encyclopaedia, etc. for all things zope"
wouldn't necessarily be a bad thing, but I (personally) think that it
only makes sense of the great majority of the site is going to be the
megawiki. Wikipedia, WikiWikiWeb/Portland Pattern Repository,
ZWiki.org, the great Squeak wiki, are all the dominant user-managed
documentation centers for their projects. If we turned off a lot of
the member-folder features of Zope.org / CMF, then maybe a large wiki
would be a better idea.
But I think that CMF Objects provide us with a better solution - at
least for Zope.org. With decently managed keyword vocabularies,
assorted workflow processes, etc, we could get an even more usable site
that follows a decent structure but allows for a lot of contributions.
I can think of a couple of pages I've had to do some maintenance on
recently - Mailing Lists and Zope Solution Providers. By some Wiki
thinking, those might be good wiki pages. But these are two situations
where I would like to see NZO offer up the ability to have ZSP and
MailingList content objects that have a workflow that encourages the
reviewer to ensure that the solution provider or mailing list in
question really have something to do with Zope. Then, of course, we
also get searching (find ZSP's in ...), batching, etc. I want to have
a page that lists Zope related RSS links. The CMF 'link' object with
the keyword 'RSS Link' would probably suffice here.
In that light, I see the megawiki being a "last resort entry/search
point" instead of the "jumping-off" point you describe. I would love
it if someone actually ran a big Zope encyclopedic Wiki as a web site
that was all One Big Zope Wiki. I just don't see such a Wiki fitting
in with what the rest of Zope.org could/should be.
Jeffrey P Shell, firstname.lastname@example.org