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