[Zope-dev] I feel your Wiki Pain ;-)

[Ken Manheimer]

On Thu, 14 Sep 2000 mbel44@dial.pipex.net wrote:

> On Thu, 14 Sep 2000 10:11:56 -0400, Chris McDonough
> <chrism@digicool.com> wrote:
> 
> >A lot of the listed complaints are trying to be addressed by the
> >"WikiNG" proposal, which is (of course) in the Proposals wiki on
> >dev.zope.org.
> 
> Yes, I was aware of that proposal, and I tried to avoid repeating
> issues that are already being discussed there. WikiNG is a better kind
> of collaborative-editing tool, but that seems to be fundamentally the
> wrong medium for debate.

There's a lot in the proposal.  In some cases, there are things
that address the items you mention.  In many cases, they pertain - and 
if i had been doing elaboration rather than inception, i would have
addressed them, because i too am concerned with (and was thinking
about) those issues.  For example, from your original posting (cited
with a '|'):

| 1. No threading. On several occasions I have made comments in a Wiki
| that were subsequently ignored - I guess because they got lost in the

and from the WikiNG proposal:

       For more elaborate editorial and commentary annotations, i can
       see layered documents, using mixin objects that provide a
       tailored view on other or contained objects.  The mixin would
       be a layer by which annotations are associated with text
       passages in the rendered subject document, like "the crit
       system":http://crit.org does for arbitrary web pages.

       Overall, document authors could use a particular annotation
       structure according to their needs.  Eg, discussion objects for
       points which can be discussed, or brief editorial passages to
       give feedback, and author checkmarks for when they've satisfied
       or refute the suggestions, etc.

Annotation is a spiffy kind of threading.

| 2. No personal replies. On several occasions I would have liked to

From WikiNG:

       - Attribution of changes for tracking

With attribution, you can identify and could respond directly to the
author of a particular passage.  It's useful for more, of course.

| 3. No update notification. The one time I was update to keep up with a

WikiNG:

     - Notification - Zope wikis will be able to leverage another generic
       (planned) Zope service, the Observer-pattern based Notification
       service (ZopeInterfacesWiki:ObserverAndNotification).  This will
       implement a general system for notifying user of changes
       according to their registered interests, with added benefits of
       tracking exactly the substance of those changes for the user (see
       History and the last item in Membership, above).

       Notification begins to enable some mailing-list style
       collaboration qualities, with finer-grained content-based
       control.

| 4. Hard to keep track of many Wikis: Each wiki has its own 'whats

The ability to subscribe for notification (above) and/or to track what
you personally have seen, and not, is intended for this kind of thing.

| 5. Too easy to fragment a discussion. On several occasions I have

This is a practice issue, which can be helped with tailored
structuring and policy controls, but which also involves maturation of
convention practices that comes with experience.  We also need a more
interconnectable space, so that references across wikis can be more
tightly coupled, and make it easier to track the interconnections.

| 6. Too easy to miss the creation of a Wiki. On several occasions

My plans for notification subscriptions would be hierarchical, and
enable you to subscribe to events like creations of new wikis within a 
hierarchy - so if you subscribe at the top of the wiki space, you find 
out about any new wikis, while if you subscribe within the developer's
part of the space, you learn about new developers wikis.  Etc.  (This
was not covered in the WikiNG proposal - i was trying to avoid
including too many details, and failed miserably anyway...-)

| 7. Too easy to loose content. On several occasions I have been unable
| to add a comments to a Wiki, either because www.zope.org would not let
| me login, or because its database was full.

That sucks, and should be fixed.  I suppose it is a drawback of wikis
in as much as they need to be available to work on them, while
followups on an email discussion can continue even if the maillist
host is down.  Up to a point, though.

| 9. I never get the structured text quoting of python source right
| first time.

The only quoting you need to know is example::

  The two colons after the word "example" indicate that this contained 
  block is all quoted.

No matter what, there's some learning to be done to encode
presentation/structuring.  Structured Text happens to be the best i've
found for doing that, particularly for naturalness - but i haven't
looked at all the options, maybe there are better.

| 10. There are too many empty pages, because someone has clicked on a ?
| next to word that happened to be a WikiName. Useful pages lie hidden
| behind a sea of links to empty pages.

This is something i couldn't cover in my proposal, because of the
fineness of the detail, but i think everyone agrees that the flow for
creating pages needs to be fixed.  Plus, the security refinements will 
enable policies about who can and can't create, to restrict from
gratuitous creations.  Plus, ownership of pages you create provides
audit, so offenders have some consequences.

Etc.

> >> How about running the 'Discussion' parts of (in particular) dev.zope.org
> >> from ZDiscussions, ZUBB or Squishdot?
> >
> >This may be a good idea...
> 
> What's wrong with a mailing list? Is this just a case of NIH?

As i said in my last reply (but after you posted this, so you couldn't
have taken it into account), mailling lists as they stand don't work
for establishing growing structures.  And i can tell you it's *not* a
case of not-invented-here - i *could* have worked more on mailman, if
i wanted to claim some kind of ownership and thought i could force
mailling lists into this purpose.  But i don't think they are at all
right for what i want to do - collaboratively developed bodies of
documents - as they stand.  (I *do* think the eventual thing - wikis
with elaborate notifications - could be seen as content-oriented
mailling lists.  But they will probably be more recognizable as wikis
than as maillists.)

> This thread has already been more productive than anything Ive done on
> a Zope Wiki over the last year, and taken a fraction of the effort.

The lack of notification, attribution, etc are real problems for
wikis.  However, i *still* find them quite useful for organizing our
thoughts, in ways i can't do with maillists.  (As it is, i'll try to
keep track of this message, so i can at some point go back and reap
the bits of new information for deployment in one of my notes outlines
or in a wiki.  I'd prefer to constructing this as annotations on a
collaborative document, and knowing you'll get a notice when i commit
it.  That way, i wouldn't need to spend all this time cutting and
pasting, and going through contortions to distinguish the different
passages, and so forth - the wiki would be doing that for me.)
Maillists simply can't do that - the need something (like a wiki) to
collect and organize the stories.  I have the sense your complaints
are parly about how the wikis fail to live up to their promise,
because of the missing pieces, than that maillists could be doing what
we're doing with the wikis.  That's my view, though, maybe i'm just
projecting it on you - sorry about that, if so!-)

Ken Manheimer
klm@digicool.com