Re: xemacs wiki

"Stephen J. Turnbull" <[email protected]> writes:

>>>>>> "Ben" == Ben Wing <[email protected]> writes:
>
>     Ben> my intention was to use it much more for collaborative
>     Ben> development, containing the sorts of info found on our web
>     Ben> page, just more so ...

   <--stuff cut-->

> I'm not sure what you mean by "collaborative development."  I would
> almost surely not be willing to participate in a wiki-mediated
> workflow, at least not with any of the wiki engines I've seen.  This
> worries me:
>
>     Ben> finally you've got a central repository where anyone could
>     Ben> make an entry concerning a patch of theirs, others could add
>     Ben> comments about the patch, make updates, etc.
>
> We have that.  The problem is the existing interface mostly sucks.
> So, how would we import all that data into a wiki?  How do you export
> a patch on the wiki to CVS?

One example of an attempt to do this is the Zope collector, which
collects bug reports.  Is it reasonable?  Sort of.

The only way I see a wiki working is if you leave it open and use a
history mechanism to undo vandalism.  There tend to be very few
vandalisms (personal experience: I'm running 3 "mostly open" ones on
my lab WWW site), but just one vandalism can be annoying and
time-consuming to undo.

To illustrate what I use a Wiki for (in my case, ZWiki on Zope,
thinking migrating to ZWiki within Plone on Zope, similar to
www.mygnus.org(?)), I run an loosely labeled IssueTracker for 2 OSS
projects I'm running, where the interfaces are:

1. mailin to a page
2. click to add a bookmark/link from the current browser page to a
   page of bookmarks, with comment.  This,  from a browser supporting
   javascript in the bookmarks (Mozilla, Galeon, IE, not Konqueror,
   sigh). 
3. mail-out of edits (which can be mailed back in)
4. public anonymous addition of comments and new pages, but locked
   editing (this would have to change -- passwords are annoying, I
   need to use a NetID or PubCookie framework or similar for
   authentication).  ** THIS IS THE "TRADITIONAL" WIKI INTERFACE,
   though traditionally it's open.
5. use of XEmacs to directly edit pages via ftp/webdav, or via
   ExternalEditor (a Zope product)


I have to admit, #1/#3 are my primary interfaces (mailing in, or
replying to an edit).  The rest are just fluff.

It does work reasonably well, though, except when it breaks ("fragile,
intelligent users/programmers only").

Search pages are how I find things (i.e. Zwiki auto-catalogs).

Refactoring is annoying, but see #5 for the only way to do it.

> NB.  Wikipedia is FDL.  Yuck.  Licensing a wiki, if it's going to be a
> permanent part of XEmacs in some sense, will be a serious problem.
> The three likely licenses (FDL, XEmacs documentation, GPL) are
> mutually incompatible according to rms, but we definitely will want
> some of the stuff to go into our docs, while code obviously needs to
> be GPL.

This is a use-case issue -- I've found wikis great for temporary brain
dumps until I can restructure what I found, but not really suitable
for much more (though "temporary", when it comes to user help, is a
long, long time...).

best,
-tony

-- 
[email protected]            http://www.analytics.washington.edu/ 
Biomedical and Health Informatics   University of Washington
Biostatistics, SCHARP/HVTN          Fred Hutchinson Cancer Research Center
UW (Tu/Th/F): 206-616-7630 FAX=206-543-3461 | Voicemail is unreliable
FHCRC  (M/W): 206-667-7025 FAX=206-667-4812 | use Email

CONFIDENTIALITY NOTICE: This e-mail message and any attachments may be
confidential and privileged. If you received this message in error,
please destroy it and notify the sender. Thank you.