wiki sites, wiki software, how do we go forward ?

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Mar 23 12:42:41 UTC 2005


Simon Michael <simon at joyful.com> wrote:
> goran.krampe at bluefish.se wrote:
> > Yes, unfortunately it is "hard" to rename a Swiki (can't be done AFAIK).
> > But I will see what we can do - we should move all that stuff to box1
> > anyway... I have thought of moving it all to minnow too, but having it
> > separate has a few good points too.
> 
> Thanks Goran. (I think your mails are missing the content-type... 
> iso8859-1 header ? My mailer defaults to utf-8).

Hmm, I should upgrade my Celeste, perhaps this has been fixed. :)

> Since you mention it, what are people's thoughts these days on central 
> wiki versus separate wikis ? And on swiki vs. smallwiki vs. picowiki 
> vs... ?
> 
> I raise this again because everything I want to do in squeak seems to 
> lead to the documentation issue; which leads to the squeak wiki at 
> minnow. It is full of excellent content, but always feels hard to work 
> with - like rock rather than clay - because: 1. it lacks modern wiki 
> conveniences, primarily natural urls and external editing, and 2. it's 
> not being visibly & actively developed, and I expect getting patches 
> installed there would be difficult.

My personal experience (we use Swiki internally at our company and we
have hacked it quite a bit) is that Swiki is a bit tricky to hack. Notw
also that Jochen has recently actually made a new release of Swiki.

And I also posted recently a patch to run it in 3.7 with latest
KomHttpServer (which I sent to Jochen btw).

Now, wiki's are good and bad IMHO. :) The bad is that they often grow
without a "plan". The structure is less obvious. I would actually favor
a hierarchical documentation for Squeak, like a "proper" manual. As an
example, take a look at the manual for Slate. I have also "toyed" with
an idea I called the Magic Book earlier - an interactive documentation
inside Squeak (of course).

But creating a manual is a big task, and for something like that to
succeed we would need to really take care on how to organize it and how
to make sure the structure is "self sustaining" so that it doesn't turn
into a hodgepodge mess over time.

There have been attempts in the past, using various approaches. All have
AFAIK "faded" away. A primary reason is of course that the documentation
should be:

1. Available directly in Squeak. Thus it would be the "official" one.
2. Tied to the code somehow. I have posted earlier about an idea to use
unit tests for that, if a unit test is updated or fails - then the
"chapter" concerning that code should be marked as possibly stale.
3. Tied to packages so that we get a "distributed ownership" of the
various chapters.
4. Use a strict style/model, so that even if we have hundreds of editors
it still "fits together".

Well, enough blabbering.

regards, Göran



More information about the Squeak-dev mailing list