Re: xemacs wiki

ok.  one thought i had in mind is that a combined GNU Emacs/XEmacs wiki could
actually be a very good idea, as it would lead to more collaboration.  much of
the current hostility is due to a "we don't exist" attitude partly because it's
[probably] actively emanating from rms but mostly just from the fact that people
don't see us!  Being present in a joint wiki would give us a lot of visiblity.
It could certainly give a lot of exposure to xemacs to the gnu folks, and maybe
even get them to start thinking about trying more seriously for a merge.  also,
a lot of duplicate info could be avoided.  much of the more introductory stuff
there applies to xemacs as well as gnu, and we could just change the parts that
didn't.  integration would come totally for free [instead of yet ANOTHER fork]
and we'd automatically get the extra eyes updating the info on the other side.

also, uses for a wiki:

1] i have some suggestions for things that can be done to xemacs.  some are more
pressing than others.  i go create a section on work to do, and sub-sections on
the various ideas, each with some ratings: e.g. importance, difficulty, what
sort of skills needed, etc.  others with their own ideas can refine my ideas,
create new sections, etc.  also, for some stuff that i've partially written but
maybe can't finish for lack of time, like the "behaviors" functionality for
providing a simple, uniform interface for packages, i can put the code into the
system [with appropriate ifdef's/whatever], make a wiki page in which i describe
what it's good for, what i've done, how it's structured, what needs to be done,
etc.  people frequently come along saying, i've just discovered xemacs, i want
to help, what can i do?  we can point them to this to-do section.  others may be
hunting around for something useful to do and can look there.  the KEY is that
this stuff is on the web in one place, and EVERYONE can edit it -- trivially.
you might say that all the developers can edit our own web pages, but [a] only
people with CVS access can do so; lots of other users of XEmacs would very much
like to contribute, off and on, and others may just get the urge to do
something; [b] making the change is not so easy.  even assuming i've got the
right CVS access set up [which is difficult to get right and may change from
time to time!] if i see a problem on the web i've got to go figure out where the
source is located, then find the source corresponding to that actual page, make
sure i understand the whole back-end system so i modify the right file, then
make the change, try to figure out how to rebuild, etc. etc.  With a wiki-type
interface edits are real-time, "just like that".

2] the FAQ's.  another prime example of something that needs to be developed in
a decentralized fashion.  different people have different knowledge.  with a
wiki system, anyone who encounters a solution to a faq can go and just add an
entry right there.  anyone reading a faq and who sees something wrong or out of
date can just fix it or at least mark it or send out email about it.  again,
it's the extreme ease of use [catch you when you feel like it] and collaborative
nature that really wins out.  the alternative, as we have it, is to have a "faq
maintainer" who never has much time, and so the faq is always out-of-date.  the
faq maintainer may not be knowledgeable in various aspects covered by the faq,
so what do they do?  this collaborative mechanism is *especially* important in a
situation like xemacs where we are so incredibly not-even-funny-any-more
strapped for manpower.

the key thing i'm trying to get across is that collaborativity, esp. from large
number of part-time or occasional users, **lives and dies** on **how easy** it
is to contribute info.  wikipedia is actually the second attempt by this guy to
create such a thing.  the first attempt he implemented peer-review, and access
controls, we need to vet you first before you become part of the group, similar
to what we've got for code in XEmacs -- and it was an utter flop.  8 articles in
2 years.  wiki is TOTALLY open.  you don't even need to log in to make changes,
and you can change anything other than pages temporarily locked down due to
excessive vandalism.  when i first saw this i was amazed people didn't just go
fuck everything up constantly.  yet they don't, and in fact the result is
amazingly good!  (and growing extremely fast due to the ease of contributing.)
this was a real epiphany moment.  although the unforgiving nature of code means
you do need some of these controls, this doesn't apply at all to text.  no one's
program will crash, and you just go fix the bad stuff.  the real epiphany was
that given an extremely permissive system, people will tend to automatically
respect the system and not take advantage of it -- even when the various people
working on it are going to be complete strangers.  suddenly, in fact, you've
just given them responsibility, and thus you may actually get BETTER results
because of this.

stephen mentions problems e.g. the disorganization of the to-do section of zsh.
but these are easily fixable -- anyone can just go in and create a format and
put everything in it.  after that people will tend to follow.

stephen mentioned my.gnus as a possible model.  i looked at it and it appears to
have the same problem of putting obstacles in the way of access -- you need to
become a member, etc.  can't just make the change right then.  furthermore, it's
based on semi-custom software used only in a few sites, which needs lots of
development work.  one big advantage of working with wiki, warts and all, is
that it [a] does most of what we want fairly well [yes, it does have history ...
at least, wikipedia does], and [b] [all important!] it appears to be the leader
of the pack -- most-used, most-in-active-development of any of the products.
from a practical standpoint there is nothing worse than using some random
fly-by-night piece of software that we then have to maintain ourselves.
problems like difficulty in rearranging the structure beyond just one level will
probably be fixed in future releases of the wiki code.

i would propose [a] using the emacs wiki, and [b] doing it incrementally.  start
with the to-do development projects i've been thinking of.  integrate docs
sitting in my machine and the architecting-xemacs stuff.  then consider moving
the faq over to wiki-land.  after that, think about whether or not it would make
sense to provide summaries of discussions and solutions reached, and what to do
more in general about the idea of a common fount of xemacs knowledge,
collaboratively maintained.

stephen, what are the other problems you have?  e.g. FDL?  what is it and why is
it a problem?



----- Original Message ----- 
From: "Stephen J. Turnbull" <[email protected]>
To: "Ben Wing" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, November 06, 2003 5:05 AM
Subject: 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.
>