Re: xemacs wiki

>>>>> "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 ...

There have been a number of proposals for evolving the web site.
Robin Socha wanted to basically take it over, and create a
my.xemacs.org, like my.gnus.org.  There have been several proposals
for wikis.  I don't have any objection to having a wiki if someone
else does the work :-), and is careful to integrate existing resources.

I personally found all the wikis I've used to suck from the point of
view of finding what I needed to know.  Eg, the emacswiki needs to be
browsed first, then later I may remember, oh, something like that was
on the emacswiki.  One wiki broke my account, so that I can't log in
properly.  Is the technology really mature yet?  I would definitely
want help in configuring my browsers to use XEmacs as an editor; no
browser I have used yet has a tolerable text widget.

I've been told by wiki-keepers that it is a massive pain in the ass to
reorganize them if reorganization that crosses more than one page is
needed.  So it sounds to me like there is no chance that a wiki could
really replace the web site as such, and I wonder if it's a good idea
as a planning medium.

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?

I don't think a wiki would make things better for me personally,
trying to track everything at once.  I don't think a wiki would really
help most people trying to look things up; they've already got Google.

I can see how it would help you, since you could just keep the
particular threads you're working on bookmarked, and it would be very
convenient to say "OK, well post a wiki thread", I admit.

I'd like to hear from Norbert, with 114 packages and lots of random
stuff in at-first-not-obviously-package-related threads he need to
track.

    Ben> we always complain about losing information

It's not lost, it's just inaccessible.  They are _not_ functionally
identical from the point of view of seeding the next generation
interface.

    Ben> and are frustrated that valuable info in mailing lists just
    Ben> floats away into the archive and becomes invisible -- well,
    Ben> just create a wiki entry based on the important stuff in the
    Ben> mailing thread, and you can essentially continue the thread
    Ben> on the wiki itself ...  and then it's permanent, and
    Ben> organized in the right place.

I think "right place" is seriously wishful thinking.  See below.  And
"permanent" is false by definition of "wiki".  We would definitely
need to worry about that if our workflow is going to move to a wiki in
any great degree.

    Ben> the interface is extremely easy, no web programming needed
    Ben> (but you can put in links and other stuff as needed).

But will people put in the links and other stuff?  My experience with
other wikis (admittedly small) is "no, not very much."  Mostly they
seem to degenerate into a tree, at best (wikipedia seems to be an
exception; I'd like to know why), and often they look like a sparsely
linked collection of blogs.

    Ben> i think we TOTALLY need this.

What we totally need is a real tracker.  My preference is Roundup, and
that's what I'm working on.  I've already demonstrated that we can
import our mbox archives wholesale; I need to (1) show that it can
scale and (2) add some interface sugar so that the massive mess of
ancient history will not be in people's faces when it goes live.

    Ben> adrian, or someone, would you be willing to set up something
    Ben> like this? take a look at zshwiki.org.

Case in point.  It's tiny, and in 5 minutes I discovered it's already
broken from the point of view of "collaborative development", cf.

http://www.zshwiki.org/cgi-bin/wiki.pl?ZshWanted

The page is supposed to be for questions, but already it is full of
answers and half answers.  There are other "answer" pages full of
questions.  People simply cannot stick to the proposed disciplines.

    Ben> also take a look at www.wikipedia.org for the HUGE wikipedia,
    Ben> with more than 170,000 entries added in only 2.8 years on
    Ben> every subject you can imagine.

wikipedia is much more impressive, at least in the economics topic
(shrug; why not? more seriously, I expected it to be broken, knowing
economists and their fellow travelers, and it wasn't).

I will definitely look into wikipedia and see if their process can be
adapted.

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.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.