Hi,

While I was looking at revision histories of some of the pages in
emacs wiki[1], unfortunately saw that most of the entries are lost.
(The oldest history record appears something similar to "UTC Revision
10 . . . . 146.124.141.59 – Rollback to 2008-09-05 00:16 UTC".) Is
this something to be recovered in a near future, or totally lost?

Regards.

[1] http://www.emacswiki.org/

IIRC, the Emacs wiki saves only a limited history due to resource
constrains.

regards,
Nikolaj Schumacher

http://www.emacswiki.org/emacs/EmacsWikiProblems

 petOn Oct 20, 3:54 am, Volkan YAZICI <volkan.yaz...@gmail.com> wrote:

for the love of emacs community, please suggest to it's creator Alex
Schroeder to switch the emacs wiki's software to MediaWiki as the wiki
software, instead of his pet of 4k line of perl OddMuse that doesn't
use a real database.

http://en.wikipedia.org/wiki/MediaWiki
http://en.wikipedia.org/wiki/OddMuse

I have been thinking for a while for doing this ... register a domain,
install MediaWiki, and copy emacswiki.org content over.

whoever does this do emacs community a service.

  Xah

∑ http://xahlee.org/

☄

Xah <xahlee <at> gmail.com> writes:

Don't waste your time. :)

Please do. I invite you to set up a suitable site and when you're done, invite
people voice their opinion. I'm not married to emacswiki.org – if somebody else
will do a better job, I'll gladly hand it over.

Start here and pick your starting point:
http://www.emacswiki.org/emacs/WikiDownload

The SVN repository will give you the raw wiki pages and no history. The Rsync
repository will give you everything including the log files.

Alex.

MediaWiki? You've got to be kidding. A database is by no means a
requirement for such a thing as emacswiki (or most wiki's for that
matter).

Oddmuse works really quite well and it's text formatting is much nicer
than that of MediaWiki in my opinion.

You of course are free to do what you like, but for the love of all
things good and nice, please choose some other wiki (almost any other
wiki) than MediaWiki.

ack

On Oct 21, 1:04 am, Alex Schroeder <a...@gnu.org> wrote:

Thank you for the blessing!

  Xah
∑ http://xahlee.org/

☄

«I have been thinking for a while for doing this ... register a
domain, install MediaWiki, and copy emacswiki.org content over.»

On Oct 21, 5:04 am, ack <ackack1...@gmail.com> wrote:

Wikipedia has been the world top most 10 visited site since about
2005. (see http://www.alexa.com/site/ds/top_sites?ts_mode=global )

«Wikipedia receives between 20,000 and 45,000 page requests per
second, depending on time of day.» — http://en.wikipedia.org/wiki/Wikipedia

«English Wikipedia reached 4,000,000 registered user accounts on 1
April 2007» — http://en.wikipedia.org/wiki/English_Wikipedia

Media has a user base of few million times more than OddMuse. The
familiarity of users is important when it is of that magnitude.
Similarly, tools that works with MediaWiki is some hunderd, thousands,
times more, in various computing langs, than OddMuse.

please see also:
Emacs wiki Problems
http://xahlee.org/emacs/emacs_wiki_problem.html

excerpt:

«
Emacs wiki Problems

The emacs wiki ( http://www.emacswiki.org/ ), started by Alex
Schroeder sometimes in 2005 or before, is great. However, i think it
could've been better.

(1) The wiki software used is Oddmuse, which is a perl script of 4k
lines, using flat files as database. As such, it is not comprehensive
or powerful.

(2) The content, is kinda haphazard. It is somewhat in-between of a
encyclopedia-style treatment like Wikipedia and a chaotic online
forum. Specifically, when you visit a article, half of article will be
dialogues between different users on tips or issues or preferences.

I commented to Alex about these problems. I suggest that it should use
the same software Wikipedia uses, the MediaWiki↗. So that, it is far
more powerful, with large scale programer support, and the user
interface for the wiki will be one that's widely known to millions of
users world-wide. (note: Oddmuse↗ is something written by Alex
himself, a pet love of sorts)

I also suggested that the writing guidelines should follow Wikipedia's
style. Specifically, the content editing should be one with the goal
of creating a comprehensive, coherent, article that gives readers info
or tutorial about the subject. (as opposed to, serving partly as a
online forum between emacs users and maintaining dialogue integrity)

I think there's a lot potential to emacs wiki. It could, for example,
develop into a comprehensive elisp library archive (e.g. CPAN↗).
Listing packages by category, with each package come with a article
that discuss its author, purpose, status, caveats, tutorial, similar
packages ...etc. And the packages needs not just be modes... but
libraries as in most languages. (for example, js2 and nxml modes are
both complete parsers for javascript and xml, each of thousands lines
of elisp code. They should actually be several libraries, so that
these parsers can be widely deployed as language modules, not confined
in use just in one editing mode. Such is largely not done in emacs/
elisp community due to emacs being primarily a text-editor with
relatively few elisp programers... but is slowing happening anyway (it
is something that eventually must happen). A good wiki can be great
help in ushering necessary improvements and increase the speed of
evolution.)

For the above to take shape, the wiki must adopt a style so that
articles aim to be a coherent treatment of the subject (as opposed to
dialogue and random tips). (and this is done by crafting the
contribution guidelines or rules; exemplarily done by Wikipedia) Also,
i'd think the wiki's software should adopt something widely supported
such as MediaWiki, as opposed to one-man's pet project.
»

  Xah
∑ http://xahlee.org/

☄

On Oct 21, 11:34 am, Xah <xah...@gmail.com> wrote:

PS i should've mentioned in previous post, Alex, you really should be
the one. You already started it, and it has become a very useful
website. I am somewhat familiar with your knowledge in sql and elisp
and perl. I think it would take just a day, if you wanted to, to
switch it to MediaWiki. That is to say, i don't think tech know-how is
in the way. I do think switching to MediaWiki is a major benefit, and
thank you for starting emacswiki in the first place.

  Xah
∑ http://xahlee.org/

☄

Hi,

    petOn Oct 20, 3:54 am, Volkan YAZICI <volkan.yaz...@gmail.com> wrote:
   > Hi,
   >
   > While I was looking at revision histories of some of the pages in
   > emacs wiki[1], unfortunately saw that most of the entries are lost.
   > (The oldest history record appears something similar to "UTC Revision
   > 10 . . . . 146.124.141.59   Rollback to 2008-09-05 00:16 UTC".) Is
   > this something to be recovered in a near future, or totally lost?
   >
   > Regards.
   >
   > [1]http://www.emacswiki.org/

   for the love of emacs community, please suggest to it's creator Alex
   Schroeder to switch the emacs wiki's software to MediaWiki as the wiki
   software, instead of his pet of 4k line of perl OddMuse that doesn't
   use a real database.

Now I am sure, you are a dumb troll. MediaWiki is by no mean
what I would recommend for a replacement (if even needed) for the
current EmacsWiki community. Doing so is unlikely to serve
anybody but you.

At the very least, you could try to enhance OddMuse by sending
patches. You could even try to contribute to EmacsWiki before
trying to put your hands on it.

Cheers,

        Xavier
--
http://www.gnu.org
http://www.april.org
http://www.lolica.org

On Tue, 21 Oct 2008 11:55:22 -0700 (PDT), Xah <xah...@gmail.com> said:
Xah> (2) The content, is kinda haphazard. It is somewhat in-between of
Xah> a encyclopedia-style treatment like Wikipedia and a chaotic
Xah> online forum. Specifically, when you visit a article, half of
Xah> article will be dialogues between different users on tips or
Xah> issues or preferences.

This is the only statement I can agree with. But AFAICT, Alex has been
most of the time on his own to create and maintain emacswiki software.
I guess he would welcome some help concerning hosting, development or
administration.

Also, Wikipedia success is mostly unrelated to the wiki engine sitting
below. MediaWiki would be a poor choice for emacswiki, IMO.

Alex, have you considered using a third party wiki engine for emacs
wiki before ? Is there a page where you state your current position on
that ? The only thing I feel concerned about oddmuse is the time you
may have to spend to maintain it, although I have no idea whether it
is high or low, and whether you enjoy doing it or not. In case you are
looking for a good quality free software package that could maybe run
emacswiki, I would point to DokuWiki. Light and powerfull, no
database, very good parsing capabilities hence easy-to-write plugins
for various syntax enhencements. Some dokuwiki-syntax modes are
already around. In many ways it shares design patterns with oddmuse.
I had very good experiences with it for various purposes, and although
I usually have some scepticism with "cool php software", I must admit
this one is reliable and very well written.

In the meantime, thank you Alex for running emacswiki, a precious
ressource.

--
  Paul

http://www.dokuwiki.org/dokuwiki
http://www.dokuwiki.org/features

Yes, the first thing to say in this thread is: thanks!  Thanks for
oddmuse (which is quite a good piece of software, I've used it for
several projects) and thanks for maintaining emacswiki.

I'm not sure it's really worth considering other wiki softwares (I
didn't see any good argument for this) but like Paul, I would also
point at dokuwiki.  

The two main advantages I see with dokuwiki are: flat files and
documentation-oriented wiki.  See the Ubuntu documentation wiki.

--
Bastien

Hi,

   The two main advantages I see with dokuwiki are: flat files and
   documentation-oriented wiki.  See the Ubuntu documentation wiki.

One mandatory thing we should keep is the possibility to edit and
to browse EmacsWiki trough GNU Emacs itself. OddMuse has a neat
mode for that and I do not think that either dokuwiki nor
mediawiki have such modes (or they have, not as good as
oddmuse.el).

Another cool wiki engine (no database, flat files only and a RCS
engine) could be ikiwiki (http://ikiwiki.info). It uses markdown
syntax, uses any RCS you like to maintain your history (Git is
the preferred way but you can use GNU bzr, tla, mercurial, ...).
You can edit thw wiki either from a simple text editor (emacs
comes to mind ;)) or using a CGI wrapper. As you use a RCS tool,
you can browse history for any files/pages and fixing a SPAM
attack is as simple as reverting to old revision using CLI
commands. Wiki can be protected with local account and/or OpenID
logins thus restricting SPAM rushes. Cons: it is unlikely it has
several billions users :)

But, in respect to Alex's work, I think we should keep the
current wiki engine and focus on the "accessibility" of the wiki:
have the information being better organized to make xaahlee happy.

        Xavier
--
http://www.gnu.org
http://www.april.org
http://www.lolica.org

   In the meantime, thank you Alex for running emacswiki, a precious
   ressource.

+1

Nothing to add.

        Xavier
--
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Paul R <paul.r.ml <at> gmail.com> writes:

Indeed, I agree with this statement as well. But that is as it should
be: The
wiki is broken as specified in this respect.

What follows is a short rant on what the Emacs Wiki is and is not. :)

For Emacs, I don't care about a perfect wiki that can replace the
manual. Emacs
is and remains the self-documenting editor. As such, the good stuff,
the well
explained stuff, the carefully thought out stuff, the edited and
checked stuff
should go into the manual -- either the Emacs manual, or the Emacs
Lisp Manual,
or the Emacs Lisp Introduction. I don't care. When I set up the wiki I
was
frustrated with how slow the FAQ was changing and the endless
repetitions on the
newsgroups and mailing lists. That's where the wiki fits in: It
changes faster
than the FAQ, it has less repetitions than the newsgroups and mailing
lists, but
it is not as structured and honed as the manual is.

Comparing it to the Wikipedia, where the wiki is the real thing, or to
the Emacs
manual, is a no brainer. Of course it doesn't compare. But it doesn't
have to.
The wiki is in a separate category.

And of course the Emacs Wiki has the benefit of letting other people
put their
text where their mouth is: If people like Xah feel that the text of
the wiki is
lacking in quality, feel free to step up and work on it. Just like
Free
Software, complaining is far less effective than doing.

The only thing I will oppose very strongly is the setting up of
guidelines and
requirements and all sorts of foolish rules, because that doesn't
improve the
text. It just prevents other people from posting. Way to go, social
skills.

This is the end of the rant.

Actually I am quite happy with how things are going. I spend very
little time on
Emacs Wiki specific things. I like working on my wiki engine; I use it
for other
projects including my homepage, my dad's blog, and so on. If somebody
feels the
urge to write an extension that we should use for Emacs Wiki, feel
free to step
forward. As the spam problem is very much under control at the moment,
there's
also very little to do for administrators. Hosting is costing me EUR
20 a month
which isn't so bad. I'd feel ridiculous accepting donations for that.
I'd rather
people donated to some charity or joined the FSF. Or -- even better --
people
could donate time and energy by improving the actual text on Emacs
Wiki. That's
much more important than the software.

No, never. I use my own software because I know exactly what it does,
I have
full control over the code, and I feel very comfortable extending it.
Switching
to something else would mean more work for me. That's why I suggested
that
anybody interested in it set up their own site, start mirroring Emacs
Wiki page
content, look at all the background jobs, redirects, URL rewrite
rules, text
formatting rules, etc. And when they're finished, handing over the
domain name
will be a trivial thing by comparison.

But I'm not willing to do the work for somebody else. They need to do
it themselves.

Thanks! :)

On Oct 21, 9:01 pm, Xah <xah...@gmail.com> wrote:

Unfortunately, that is not true at all. I've been to various wiki
symposiums and I've spoken to the main developers of many wiki engines
including the guys from Mediawiki and Dokuwiki. I know of performance
issues, scaling issues, caching issues, proxy issues, text formatting
rule incompatibility, and so on.

This is a step in the wrong direction from my perspective. And it's a
huge effort as far as I can tell. I'm not going to invest a single
second for this perceived loss of value. I'm just posting my reactions
here in the hopes of silencing any speculations and spelling out what
future volunteers will need to consider.

On Oct 23, 12:45 am, Bastien <bastiengue...@googlemail.com> wrote:

I wonder what that means. What is documentation-oriented software?

On Oct 23, 10:25 am, Xavier Maillard <x...@gnu.org> wrote:

Yep, switching wiki engine will not improve the text. People still
have to write it.

On Oct 20, 2:30 pm, Nikolaj Schumacher <m...@nschum.de> wrote:

I thought I had answered that but it's not showing up, so let me
repost that.

The reason I'm expiring old revisions is not resource constraints.
It's a conscious decisions made based on some thoughts discussed in
the early days of wiki. You can read more about it here:
http://www.usemod.com/cgi-bin/mb.pl?KeptPages

In short, the idea is that we want to forgive and forget, no be record
keepers of other's mistakes. We don't need to support old versions of
the code, and therefore we do not need access to all the old
revisions. Our focus is on polishing the the current revision of the
text.

Cheers
Alex

The "doku" from "dokuwiki" tells it: it was first designed with the
purpose of letting people write good documentation collaboratively.  The
main use of dokuwiki I'm aware of - Ubuntu website - seems to illustrate
this, but "documentation-oriented" was not an ontological statement.

Two nice extensions that go into that direction:

1. Export a page in .odt format
2. Display a page as a S5 presentation

--
Bastien

2008-10-23

«(2) The content, is kinda haphazard. It is somewhat in-between of a
encyclopedia-style treatment like Wikipedia and a chaotic online
forum. Specifically, when you visit a article, half of article will be
dialogues between different users on tips or issues or preferences.»

«Indeed, I agree with this statement as well. But that is as it should
be: The wiki is broken as specified in this respect. What follows is a
short rant on what the Emacs Wiki is and is not. :)»

«For Emacs, I don't care about a perfect wiki that can replace the
manual. Emacs is and remains the self-documenting editor. As such, the
good stuff, the well explained stuff, the carefully thought out stuff,
the edited and checked stuff should go into the manual -- either the
Emacs manual, or the Emacs Lisp Manual, or the Emacs Lisp
Introduction. I don't care. When I set up the wiki I was frustrated
with how slow the FAQ was changing and the endless repetitions on the
newsgroups and mailing lists. That's where the wiki fits in: It
changes faster than the FAQ, it has less repetitions than the
newsgroups and mailing lists, but it is not as structured and honed as
the manual is.»

Now the emacswiki has been there for a while, we can think how to make
it better and work toward that goal, as opposed to what the original
intention was.

«Comparing it to the Wikipedia, where the wiki is the real thing, or
to the Emacs manual, is a no brainer. Of course it doesn't compare.
But it doesn't have to.  The wiki is in a separate category.»

«And of course the Emacs Wiki has the benefit of letting other people
put their text where their mouth is: If people like Xah feel that the
text of the wiki is lacking in quality, feel free to step up and work
on it. Just like Free Software, complaining is far less effective than
doing.»

Criticism is not complaining, and even complaining is a significant
form of contribution when done naturally. A significant contribution
of major philosophers to society throughout history, is to criticize
or complain. “Complaining” is not necessarily inferior to “doing”. A
healthy, prosperous community, needs both.

in the tech geeker's open source community, there's a major problem of
the mindset of “contribution”, where almost anything less than code
contribution is deem by tech geekers as wanton bitching, especially
when it arose in a online discussion turned quarrel. This
“contribution” mindset does lots of harm to the growth and progress of
open source community. To various degrees, it lessens the power of
discussion, spur forking of projects, duplication of coding effort,
proliferation of less quality code.

(See also:
• Responsible Software Licensing
http://xahlee.org/UnixResource_dir/writ/responsible_license.html

• Criticism versus Constructive Criticism
http://xahlee.org/UnixResource_dir/writ/criticism.html
)

For example, why do you fork UseModWiki ( http://en.wikipedia.org/wiki/UseModWiki
) in the first place? In some tech geeker's sense, you are reinventing
the wheel.

if i quietly grabbed your emacswiki content (which is perfectly legal
and guaranteed a right under FSF associated licenses) and shape it in
the way i think is proper (i.e. using MediaWiki), effective a fork,
such deed is often controversial as you must know, and often it spur
animosity among groups and create factions.

whether forking in general does good or bad to society, is a complex
issue and there's no simple answer. When philosophies and vision or
methods between developers differ significantly, forking is probably
the only recourse. And such forked project contribute diversity (as
linux distros), and sometimes ultimately determines which is better
one, or may spur huge competition and change (as Xemacs did to emacs).
But on the other hand, sometimes forking is merely a result of
political animosity. (e.g. “somebody else's” project vs “My” project.)

I can, and i might, take your blessing and create a alternative
emacswiki, or even consume emacswiki.org with your help. That takes a
lot dedication, time, and some money to do it. As i mentioned,
MediaWiki interface is familiar to some one hundred of thousand time
more users than OddMuse, and there are perhaps hundreds times more
tools to work with MediaWiki than OddMuse. With MediaWiki, you also
automatically have a lot features, such as images, math formula
formatting, display of audio, citation, category, syntax highlighting,
language support, each of these far more robust and diverse than
OddMuse if it support it. These features, seemingly not much useful
for a wiki for emacs, but you'd be surprised what people do and how
things grow. (for one example, emacs wiki could use lots of
screenshots, and with that, you'll eventually need MediaWiki's image
annotation and citation features)

one reason you cited against MediaWiki is that it's rather difficult
or complex to install. I agree OddMuse is far more easier to install.
(just one perl file) However, you are a expert in the Web App field,
and so am i. For a web app professional, to install MediaWiki, with
its associated database etc, isn't that hard. Even i haven't done so,
i think you'll agree, that it takes within 1 week man hour to install
it with all content transferred from emacswiki.

As you detailed, OddMuse is pretty much just your pet project. That
and its simplicity is pretty much the reasons you use it for
emacswiki. As project gets large, this cannot be remain so without
hampering the growth of emacswiki.

«The only thing I will oppose very strongly is the setting up of
guidelines and requirements and all sorts of foolish rules, because
that doesn't improve the text. It just prevents other people from
posting. Way to go, social skills.»

I think some guideline is sufficient. The gist is that, someone needs
to provide that guideline, or give a indication that coherent article
is the goal as opposed to maintaining a conversation of wiki editors.
In this case, that someone should be you, because you are the original
creator and thus most suitable and authoritative.

This guideline or indication is important. For example, sometimes i
thought about cleaning out the discussion-oriented texts... which
usually means simply delete them. However, if done, it'll raise a lot
problems. People will revert it, ask why you delete them, considering
it removal of record, resulting quarrel or unease, or even consider it
absolute vandal.

I being already a controversial figure. As you know, i've been ban'd
in freenodes's emacs irc, while you were intimately familiar with the
deal, which is also associated with the emacswiki. (see
http://xahlee.org/emacs/xah_ban_emacs_irc.html ) If i start to, as you
say, “contribute” by editing of the article of removing conversations,
that's not gonna go well. Note the fact that the quality of many pages
there are in very bad quality as considered as a article. The editing
effort will pretty much mean lots of brainless deletions if it is to
be meaningful ... some of these conversation contains valuable info,
but the discussion style makes it hard to extract info or a huge
amount of editing effort.

In short, there needs to be some authoritative guideline. Then, the
conversation styled dialogues of the wiki would wane. Without such a
guideline, and letting tech geekers go freely on what each think is
best, is not likely to make emacswiki coherent anytime soon. Large
projects requires a leadership. Richard Stallman, is a good example
here.

In summary, there are 2 things i'm saying, and have tried to say to
you 2 or 3 years ago, albeit perhaps in a terse manner. One is to
adopt WikiMedia, instead feeling attached to your personal code. (2)
It needs a authoritative guideline for emacswiki to grow.

For (2), please dont think it is some Big Brother heavy hand on
control. The guidelines needs not be harsh, strict, or even enforced.
However, it is necessary, that there is such a guideline, and it be
required reading for emacswiki editors. (think of Richard Stallman's
GNU Manifesto, who actually goes to the trouble of going into
legalities with its GPL and FSF corporation.)

«Alex, have you considered using a third party wiki engine for emacs
wiki before?»

«No, never. I use my own software because I know exactly what it does,
I have full control over the code, and I feel very comfortable
extending it.  Switching to something else would mean more work for
me. That's why I suggested that anybody interested in it set up their
own site, start mirroring Emacs Wiki page content, look at all the
background jobs, redirects, URL rewrite rules, text formatting rules,
etc. And when they're finished, handing over the domain name will be a
trivial thing by comparison.  But I'm not willing to do the work for
somebody else. They need to do it themselves.»

Ok. Thanks for the explanation.

  Xah
∑ http://xahlee.org/

☄

On 23 Okt., 16:35, Bastien <bastiengue...@googlemail.com> wrote:

Hm. It seems that "write good documentation collaboratively" can be
achieved with any tool that allows authors to collaborate when writing
text. I'd be surprised if the software used can make a mediocre text
"good". As you must have noticed, I'm think that the "doku" in
Dokuwiki is excellent marketing, but doesn't make a good argument.

Perhaps I should call my software "Emacs Wiki" -- it's designed with
the purpose of letting people write about Emacs collaboratively,
haha. :)

Ok, that seems like a useful thing to have depending on your needs.
Personally, I don't see to need for these two in the context of Emacs
Wiki, but if somebody really wanted those, then clearly Dokuwiki might
be an interesting option. You get to decide whether to invest time
into migrating the existing wiki or reinventing the wheel in Perl, I
guess.

On 23 Okt., 22:43, Xah <xah...@gmail.com> wrote:

Then again, philosophers don't have the option of doing. The same is
true for public works, governments in general, basically anything that
you can't do in your free time by yourself.

But writing software and writing text is different. The know-how is
there, the ability is there, the tools are free and available.

It's not the same thing.

I disagree. A community with people that keep complaining without
contributing is a community that I don't want to contribute to.

Indeed, why did I? Did you check? Have you read up on the history of
UseModWiki? I guess you haven't, or you'd know.

Sure. But such is your freedom. And you don't have to grab it quietly.
I invite you to do it. Please do it.

Well, it depends. You could start with hosting for USD 5 per month at
hcoop.net and a domain name for EUR 12 a year, as far as I can tell.
And remember, once you've proven that you can do it, we'll have a
vote. If people vote for your site, I'll give you control over the
domain name emacswiki.org. Yes, it'll be a bummer for my personal
page, and for my dad's blog, and for my godchild, but I'm willing to
make that sacrifice because I don't want to stand in the way of
progress. If you can serve Emacs' interest better than I can, then I
want to support you. I really do.

Yes, but who needs them? Oddmuse also has benefits over Mediawiki that
you seem to be unaware of, or uninterested in. That's ok, I don't
mind.

You are right. Then again, Oddmuse also offers many extensions. I
guess I'd be more interested in developing new extensions or improving
existing extensions for Oddmuse instead of migrating it all to
Mediawiki and giving those extensions a try. Really, somebody will
have to do the work of migrating the wiki to Mediawiki. There's no way
around that. No amount of Mediawiki praise will make that work easier.
Somebody has to do it. You could be that person. You should try to be
that person.

Excellent. You seem to be well suited for the job! This is a great
opportunity.

It is a strange conclusion to draw, but that's ok. I thought that the
main problem in wiki growth and maintenance is the text, not the
software. But I could be wrong. Once you have a working site with all
the necessary extensions, URL rewrites, redirections, maintenance
jobs, and interfaces to other systems such as the Emacs Lisp List, it
will be much easier to see whether the new software will allow Emacs
Wiki to grow and improve faster.

Then again, this is not how I want to run a community. If I have any
authority at all, that would not be the way I want to use it. Perhaps
that's why I have some authority – because people know I'll not get on
their nerves. Then again, since I practically never use it, we'll
never know for sure whether I have any.

I think the onus falls on you to lead by your own example; your social
skills and your coding skills will prove your right or wrong. And you
don't even have to do all the coding yourself. With enough social
skills you'll encourage others to join your project and you'll be able
to focus on the usability issues you've identified. I'm wishing you
all the best!

Absolutely. And if you read through Emacs Wiki, you will in fact find
some guidelines. I hope that they're subtle and not too invonvenient.
I fear that what you have in mind will be a lot less inviting, but it
will be up to you to try.

You are right on all accounts. You are controversial, banned, and
editing other people's text needs lots of social skills. I'm afraid I
cannot offer you any help on any of these topics. These are complex
issues and have no easy answers.

Well, we agree in that projects need leadership. But what you're in
fact doing is saying that I am a project leader and I should lead my
project differently. If I am not the project leader you think I am,
then we're back to the previous point about your social skills. If I
am in fact the project leader you think I am, then I'd argue that
perhaps I am because of the way I decided to lead the project –
chaning that policy will be tricky. Who knows, I might end up loosing
my leadership position. That's also why forking is the easier answer.
Note that this is very similar to how oral traditions work. In the
area of martial arts and eastern schools of enlightenment, for
example, we have an oral tradition. Some things are very difficult to
express in words, which is why you cannot write it down. Thus there
are no (good) books to learn it from, and you need a "master" to teach
you. And the master's qualification is again given by his own master.
Thus, knowledge is passed from master to apprentice. This necessitates
the belief that you master is right and knows it all. It leads to
ideas of a gold age when things were perfect, or of enlightened
founders that had perfected a particular technique or school or
thought. In this case, if you discover that you want to change
something, there's no way of doing that within your own school. You
will have to break away and create your own school. You effectively
fork! That's why we have so many martial arts schools. Over fifty
schools of Kung-Fu! And even rather recent things like Aikido have
alreay splintered into different schools.

Thus, oral traditions favor forking. Questions of social capital favor
forking.

But enough of this pseudo science. Back to the business at hand.

You should fork the Emacs Wiki and try your ideas. If you fail, I hope
you'll agree that I'm under no obligation to change either the tools I
use, nor the way I run the project.

Think about it this way. Assume that Emacs Wiki was run by a
democracy. What would be the thing to do if you're unhappy? You start
by ...

read more »

I think EmacsWiki is a very good invention, but there are some things
that I have been missing. Those things falls in between good
collaboration and assisting software.

What I am thinking of is marking advices and code with notes about
where they work or/and are tested. Simple examples are Emacs version,
but it could also be combinations of different kinds (using a minor
mode together with a certain major mode etc).

I believe the wiki software could provide some help for structuring
this but I do not even have an idea for the structure and far less for
what assistance the software could give. It looks difficult but useful
to me.

Perhaps this could grow spontaneously on the wiki with time, perhaps
some assistance by the software is needed. I believe in the latter but
I fear any assistance of that kind might put too much restrictions on
writing.

When I have come that far in my thoughts I am a bit stuck.

You stripped the sentence where I say: "but 'documentation-oriented' was
not an ontological statement."  Which was meant to convey the idea that
I don't think there are wikis strongly more suitable for documentation
than others.  Still, I think many of the functionalities/extensions of
dokuwiki are here because of the need for collaborative documentation.

Anyway, I'm happy with the current emacswiki.

--
Bastien