[ZWeb] Re: light blue touch paper and stand back (was Re: Re: NZO, was Re: Zope 3 branding)

[Jeffrey P Shell]

On Saturday, February 1, 2003, at 08:30  AM, Simon Michael wrote:

> Jeffrey P Shell <jeffrey@cuemedia.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
>> maintain.
>
> Yes, this can be a good thing. I made a similar post recently:
> http://zwiki.org/ExcessiveLinkingConsideredHarmful.
>
>> (And I want CamelCase to die - 'McDonough' shouldn't be a Wiki link, 
>> and
>> 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 
> always
> 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 
don't.

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:

http://www.wikipedia.org/wiki/Free_Links

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, [...], 
> and
> [[...]].

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 
[1]_ 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, jeffrey@cuemedia.com