Emacs Wiki Revision History
Volkan YAZICI
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.
Nikolaj Schumacher
> (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?
IIRC, the Emacs wiki saves only a limited history due to resource
constrains.
regards,
Nikolaj Schumacher
Drew Adams
> emacs wiki[1], unfortunately saw that most of the entries are lost.
> (The oldest history record appears something similar to "UTC Revision
> this something to be recovered in a near future, or totally lost?
Xah
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
☄
Alex Schroeder
> 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.
Don't waste your time. :)
> 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.
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.
ack
> > 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.
>
>
> > install MediaWiki, and copy emacswiki.org content over.
> >
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
> > whoever does this do emacs community a service.
>
Xah
Xah
«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:
> 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.
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/
☄
Xah
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/
☄
Xavier Maillard
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
Paul R
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
Bastien
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
Xavier Maillard
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 Maillard
In the meantime, thank you Alex for running emacswiki, a precious
ressource.
+1
Nothing to add.
Alex Schroeder
> 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.
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.
> 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.
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.
> 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.
> In the meantime, thank you Alex for running emacswiki, a precious
> ressource.
Thanks! :)
Alex Schroeder
> 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.
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.
Alex Schroeder
> The two main advantages I see with dokuwiki are: flat files and
> documentation-oriented wiki. See the Ubuntu documentation wiki.
I wonder what that means. What is documentation-oriented software?
Alex Schroeder
> 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.
Yep, switching wiki engine will not improve the text. People still
have to write it.
Alex Schroeder
> IIRC, the Emacs wiki saves only a limited history due to resource
> constrains.
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
Bastien
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
Xah
Xah Lee wrote:
«(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.»
Alex Schroeder wrote:
«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. :)»
Alex Schroeder wrote:
«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.
Alex wrote:
«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.
Alex wrote:
«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?»
Alex wrote:
«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/
☄
Alex Schroeder
> The "doku" from "dokuwiki" tells it: it was first designed with the
> purpose of letting people write good documentation collaboratively.
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. :)
> 1. Export a page in .odt format
> 2. Display a page as a S5 presentation
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.
Alex Schroeder
> 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.
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.
> “Complaining” is not necessarily inferior to “doing”. A
> healthy, prosperous community, needs both.
I disagree. A community with people that keep complaining without
contributing is a community that I don't want to contribute to.
> 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.
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.
> 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.
Sure. But such is your freedom. And you don't have to grab it quietly.
I invite you to do it. Please do it.
> 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.
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.
> 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.
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.
> 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)
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.
> 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.
Excellent. You seem to be well suited for the job! This is a great
opportunity.
> 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.
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.
> 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.
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!
> 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.
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.
> 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. (seehttp://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.
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.
> 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.
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 writing about your unhappiness. And then you start a party. Collect
people that will vote for you, assemble a team of people that can take
over maintainership. Fortunately in the electronic world, we can try
the new government before we kick out the old government. You can
prove your worth before people need to choose. You'll agree that this
is much better than what we have in our world of Realpolitik.
> 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.
I hope that all the time I've spent arguing with you has paid off at
last and that you understand the reasons why I reject your two
suggestions. Not only do I reject them for the reasons above, I also
went above and beyond my social obligations in order to show you a way
out of this impasse: There is a way for you to get the cake, and eat
it too.
> 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.)
Sure. I just don't agree with your guidelines and that's that. See
above for a way out.
Good luck
Alex
PS: Why was this discussion crossposted to both g.e.help and c.emacs?
It seems like a waste of bandwidth.
Lennart Borgman
> On 23 Okt., 16:35, Bastien <bastiengue...@googlemail.com> wrote:
>> The "doku" from "dokuwiki" tells it: it was first designed with the
>> purpose of letting people write good documentation collaboratively.
>
> 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".
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.
Bastien
> On 23 Okt., 16:35, Bastien <bastiengue...@googlemail.com> wrote:
>> The "doku" from "dokuwiki" tells it: it was first designed with the
>> purpose of letting people write good documentation collaboratively.
>
> 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".
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
Paul R
I think there is something in the emacs active hackers community now,
that has been here for a long time now, and that can be simply
formulated . A lot GNU/Emacs active developers develop emacs for their
own needs of emacs gurus. Those are concentrating all their efforts on
what bog them the most. It's like it has become for them a solitary
pleasure, or necessity, to hack on emacs. Doing so, they tend to
neglect to clean up and facilitate the steep and hard path going from
the state of total newbiness to emacs, to the state of being able to
appreciate the work being done at the moment. I am sure they enjoy
what they do, as they are highly skilled developpers spending time on
what they feel important. But over the time, Emacs from the outside
tends to look like a wall, an old rough wall that as been there for
ages. Behind the wall, there is the magic treasure that grows with the
number of people benefiting from it. But almost nobody is tall enough
to see the jowels. Most new comers to emacs I can observe look at this
old wall, give a try to climb it, hurt their hands on it and give up.
After all, they don't doubt they can find some other jowels far easier
to pick up, no matter how beautiful they are. And while hackers enrich
the treasure inside, newcomers can't cross the wall, don't feel really
welcome, and turn heels.
It is in some ways similar to the lack of guidelines in emacswiki.
Power users don't mind the relative mess resulting of this policy, and
they enjoy the very high freedom they have to drop code here and
there, and to start a discussion right in the wiki below the code. But
for a newcomer, finding what (s)he looks for will be hard.
I think Alex has done a great job at doing what he wanted to.
Emacswiki is undoubtedly a success for emacs hackers to put code, tips
and to discuss. I guess it was never meant to be a portal to the emacs
world, designed to suit newbies needs above all.
Maybe what you want, Xah, is such a portal, with very structured
information, no duplication, one-problem-one-solution, aimed at being
accessible above all. Why not, I'm sure it would be a good thing,
although you are probably aware of your current own difficulties at
being "accessible", to say the least. Alex has said it all when he
sincerely encouraged you to do it. We all do encourage you to do it.
But making emacs more accessible to the newcomers is a whole project
in itself. Emacswiki, in spite of its relative mess, is clearly a step
in this direction. Though, I'm afraid there is not so much room for
improvement in this area as long as core developers show constant
reluctance to change the defaults of emacs, which are most of this
high, rough, wall.
--
Paul
Alex Schroeder
> But making emacs more accessible to the newcomers is a whole project
> in itself. Emacswiki, in spite of its relative mess, is clearly a step
> in this direction. Though, I'm afraid there is not so much room for
> improvement in this area as long as core developers show constant
> reluctance to change the defaults of emacs, which are most of this
> high, rough, wall.
You are right. If you look around Emacs Wiki, you'll notice that
there's a set of pages reachable from the SiteMap that is geared
towards newbies. It tells them how the wiki works, how to navigate,
how to search, how to learn Emacs, and so on. Most of this area is the
work of Drew Adams. It is this kind of effort that is required. Thank
you, Drew Adams!
I hang out on #emacs a lot. Whenever there's an Emacs related question
that has no answer on the wiki, I try to write a wiki page instead of
just answering it. Or if I cannot I'll give the person whatever help I
can and tell them to put the solution on a wiki once they figured it
out. Sometimes that works. It's a way of growing the wiki in
directions that people actually use.
On #emacs, we also have a bot called fsbot, who knows the names of all
Emacs Wiki pages, it knows all the names of the manual nodes, and it
has a lot of user-level redirections and cross references. Together,
fsbot and the wiki make a very impressive team.
I guess that Google and the wiki should be equally good, but since I
rarely google for my Emacs problems, I can't tell.
My point is that looking at the Emcs Wiki on its own might be short-
selling it. It often works as a text resource for other services --
web search, IRC bots, and maybe mailing lists and newsgroups. It has
been a long time since I posted a lot on gnu.emacs.help... :)
Oh and one last thing: Some defaults were in fact changed in Emacs 23.
I was confused. But I'm willing to make that sacrifice if it attracts
some new users to Emacs. Let's hope we're on the right track.
Alex Schroeder
> Still, I think many of the functionalities/extensions of
> dokuwiki are here because of the need for collaborative documentation.
Well, if there is anything in particular that you would like to see
for Emacs Wiki, let me know. I still develop new Oddmuse extensions
every now and then. :)
Paul R
Alex> You are right. If you look around Emacs Wiki, you'll notice that
Alex> there's a set of pages reachable from the SiteMap that is geared
Alex> towards newbies. It tells them how the wiki works, how to
Alex> navigate, how to search, how to learn Emacs, and so on. Most of
Alex> this area is the work of Drew Adams. It is this kind of effort
Alex> that is required. Thank you, Drew Adams!
Yes, thank you Drew for constantly trying to look through newbies
eyes. It often gives good results.
Alex> My point is that looking at the Emcs Wiki on its own might be
Alex> short- selling it. It often works as a text resource for other
Alex> services -- web search, IRC bots, and maybe mailing lists and
Alex> newsgroups.
Yes, the content in EmacsWiki is very valuable. Yet, I undertand there
is room for improvement for finding documentation, and putting in in
shape to ease learning. But the most we talk about it, the more
I think it would be best as a separate project, working
collaboratively with emacswiki, picking some precious informations and
putting them in shape to provide information in a more comprehensive
shape for external readers.
Alex> It has been a long time since I posted a lot on
Alex> gnu.emacs.help... :)
and I'm glad to read your posts.
Alex> Oh and one last thing: Some defaults were in fact changed in
Alex> Emacs 23. I was confused. But I'm willing to make that sacrifice
Alex> if it attracts some new users to Emacs. Let's hope we're on the
Alex> right track.
Yes, some. Obviously emacs 23 will have some improvements in this
area, but it is hardly enough to qualify emacs as a friendly tool for
beginners.
Also, I would bet you can revert your copy of emacs to the old beloved
behaviour in a matter of seconds, just because you know what you want
and you know how to set it up. That is why I don't see the point of
preserving defaults to suit experienced users. Defaults, really, must
strictly stick to what a *new* user expects, or at least to *common*
usability guidelines.
--
Paul
Lennart Borgman
> Yes, the content in EmacsWiki is very valuable. Yet, I undertand there
> is room for improvement for finding documentation, and putting in in
> shape to ease learning. But the most we talk about it, the more
> I think it would be best as a separate project, working
> collaboratively with emacswiki, picking some precious informations and
> putting them in shape to provide information in a more comprehensive
> shape for external readers.
I think some people call that second project "Emacs" ;-)
Why not work on improving the documentation inside the Emacs project
along those lines? Or is there some problem doing that? Even if most
of the documentation in Emacs are in Info format there are links to
other documentation too, in html format.
Paul R
Lennart> I think some people call that second project "Emacs" ;-)
Lennart> Why not work on improving the documentation inside the Emacs
Lennart> project along those lines? Or is there some problem doing
Lennart> that? Even if most of the documentation in Emacs are in Info
Lennart> format there are links to other documentation too, in html
Lennart> format.
For users, Emacs documentation state is bound to an emacs release.
This documentation can't change between release, that is why this
project would have slighlty different goal.
But I agree, the flow of information could be :
EmacsWiki ----> Online emacs documentation portal ----> Emacs Info
--
Paul
Lennart Borgman
I wonder if that could be enhanced in some way. Maybe it would be
possible to contribute to Emacs Info for the next Emacs release and
then link to that documentation from EmacsWiki?
Xavier Maillard
Hello Lennart,
Lennart> I think some people call that second project "Emacs" ;-)
Lennart> Why not work on improving the documentation inside the Emacs
Lennart> project along those lines? Or is there some problem doing
Lennart> that? Even if most of the documentation in Emacs are in Info
Lennart> format there are links to other documentation too, in html
Lennart> format.
For users, Emacs documentation state is bound to an emacs release.
This documentation can't change between release, that is why this
project would have slighlty different goal.
But I agree, the flow of information could be :
EmacsWiki ----> Online emacs documentation portal ----> Emacs Info
I pretty like this idea. We would have to get tag support in
emacswiki to ease information retrieval process. I hope we could
make this happen with the help of the emacswiki community.
Xavier Maillard
>
> Lennart> I think some people call that second project "Emacs" ;-)
>
> Lennart> Why not work on improving the documentation inside the Emacs
> Lennart> project along those lines? Or is there some problem doing
> Lennart> that? Even if most of the documentation in Emacs are in Info
> Lennart> format there are links to other documentation too, in html
> Lennart> format.
>
> For users, Emacs documentation state is bound to an emacs release.
> This documentation can't change between release, that is why this
> project would have slighlty different goal.
> But I agree, the flow of information could be :
> EmacsWiki ----> Online emacs documentation portal ----> Emacs Info
I wonder if that could be enhanced in some way. Maybe it would be
possible to contribute to Emacs Info for the next Emacs release and
then link to that documentation from EmacsWiki?
How do you envision to do that practically ?
Alex
> EmacsWiki ----> Online emacs documentation portal ----> Emacs Info
>
> emacswiki to ease information retrieval process. I hope we could
> make this happen with the help of the emacswiki community.
Tag support could be added to the wiki. I think a "forward index"
would be even better, though. Currently our category pages work as
such. They work just like menu pages for texinfo, and therefore it
would be easy to translate a subset of pages into a texinfo fragment.
In fact, many years ago, I had a script that translated the entire
Emacs Wiki into a texinfo document. Eventually, however, I decided
that it wasn't worth the effort to maintain. If you think otherwise,
we could resurrect that piece of code.
Part of the problem is that the code needs to write a wiki to texinfo
rule for every wiki to HTML rule it has, and the wiki engine used
allows users to plug in an unlimited amount of new rules. Before
doing all that work, I would therefore like to get a pretty good idea
of how useful this effort is. How would integration into Emacs itself
work? What does emacs-devel say to this? Who will be responsible for
maintenance? Who will act as a filter? Perhaps we'll have to introduce
more tags to indicate which pages not to include (eg.
CategoryHomepage?). Who will decided how to deal with images, how
about mixed licenses of the resulting product (most text pages are
FDL, most code pages are GPL), and so on. I'd love to see these
organisational issues answered before writing any actual code.
Also, I'll be checking my email rarely these days as I'm travelling in
Costa Rica. ;)
Ted Zlatanov
A> Tag support could be added to the wiki. I think a "forward index"
A> would be even better, though. Currently our category pages work as
A> such. They work just like menu pages for texinfo, and therefore it
A> would be easy to translate a subset of pages into a texinfo fragment.
A> In fact, many years ago, I had a script that translated the entire
A> Emacs Wiki into a texinfo document. Eventually, however, I decided
A> that it wasn't worth the effort to maintain. If you think otherwise,
A> we could resurrect that piece of code.
For Gnus specifically, we could use it to automatically pull the
Gnus+GMail pages from the EmacsWiki into the manual periodically.
Ted
Reiner Steib
> For Gnus specifically, we could use it to automatically pull the
> Gnus+GMail pages from the EmacsWiki into the manual periodically.
As we don't have copyright assignments for the content on EmacsWiki,
we cannot do this. Does EmacsWiki have a reliable history mechanism
that allows to find out who has done a change?
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
Lennart Borgman
> On Tue, Nov 04 2008, Ted Zlatanov wrote:
>
>> For Gnus specifically, we could use it to automatically pull the
>> Gnus+GMail pages from the EmacsWiki into the manual periodically.
>
> As we don't have copyright assignments for the content on EmacsWiki,
> we cannot do this. Does EmacsWiki have a reliable history mechanism
> that allows to find out who has done a change?
I am not sure that is important since if something on EmacsWiki is to
be included in Emacs it needs to be rewritten to fit into Emacs
manual.
Reiner Steib
> On Thu, Nov 6, 2008 at 9:11 AM, Reiner Steib <reinerst...@imap.cc> wrote:
>> On Tue, Nov 04 2008, Ted Zlatanov wrote:
>>
>>> For Gnus specifically, we could use it to automatically pull the
>>> Gnus+GMail pages from the EmacsWiki into the manual periodically.
Beside the copyright issue, I would object to automatic inclusion
because the quality and correctness of EmacsWiki pages isn't always
sufficient.
>> As we don't have copyright assignments for the content on EmacsWiki,
>> we cannot do this. Does EmacsWiki have a reliable history mechanism
>> that allows to find out who has done a change?
>
> I am not sure that is important since if something on EmacsWiki is to
> be included in Emacs it needs to be rewritten to fit into Emacs
> manual.
AFAIK, that doesn't matter.
Thien-Thi Nguyen
() Fri, 24 Oct 2008 10:31:14 +0200
A lot GNU/Emacs active developers develop emacs for their own
needs of emacs gurus. Those are concentrating all their
efforts on what bog them the most. It's like it has become for
them a solitary pleasure, or necessity, to hack on emacs.
Doing so, they tend to neglect to clean up and facilitate the
steep and hard path going from the state of total newbiness to
emacs, to the state of being able to appreciate the work being
done at the moment.
facilitate the hardness -- what does that really mean?
to make things more pretty dirty, or to make them more ugly clean?
mayhaps those hackers are deserving of pity,
newbie wonder absconded, they grate on the gritty,
trying to recapture the big awe of the big wall,
trying to refracture their jigged maw w/ their rigged saw.
too precise now, focused instruments thwart them;
original curiosity formless, now lost to the short zen.
harden the facility -- when is culture just overgrown moss?
does the stone monkey even remember five centuries lost?
strike out in one direction to cross monsters and rivers,
keeping in tow the untoward human that shivers,
every hair just a jump from the thousand league mountains,
yet plodding on course, burning oils, flowing fountains.
return of the fruitful, swift and unforgotten,
is wisdom the hand that clamps down, does not soften?
thi
Lennart Borgman
>>> As we don't have copyright assignments for the content on EmacsWiki,
>>> we cannot do this. Does EmacsWiki have a reliable history mechanism
>>> that allows to find out who has done a change?
>>
>> I am not sure that is important since if something on EmacsWiki is to
>> be included in Emacs it needs to be rewritten to fit into Emacs
>> manual.
>
> AFAIK, that doesn't matter.
What do you mean?
Reiner Steib
> On Thu, Nov 6, 2008 at 9:29 PM, Reiner Steib <reinerst...@imap.cc> wrote:
>>>> As we don't have copyright assignments for the content on EmacsWiki,
>>>> we cannot do this. [...]
>>>
>>> I am not sure that is important since if something on EmacsWiki is to
>>> be included in Emacs it needs to be rewritten to fit into Emacs
>>> manual.
>>
>> AFAIK, that doesn't matter.
>
> What do you mean?
In general[1], in order to include non-trivial content[2] in Emacs,
the author has to assign the copyright to the FSF. If we don't have
an assignment, we cannot include it.
I don't know what kind of rewriting your thinking about. If it's only
adding texinfo markup and minor changes, then I think we still need an
assignment from the original author.[3]
Bye, Reiner.
Footnotes:
[1] there might be some exceptions
[2] code or documentation
[3] IANAL; I don't speak for the FSF; If you want to know for sure ask
the FSF copyright clerk or on emacs-devel.
Lennart Borgman
> On Thu, Nov 06 2008, Lennart Borgman wrote:
>
>> On Thu, Nov 6, 2008 at 9:29 PM, Reiner Steib <reinerst...@imap.cc> wrote:
>>>>> As we don't have copyright assignments for the content on EmacsWiki,
>>>>> we cannot do this. [...]
>>>>
>>>> I am not sure that is important since if something on EmacsWiki is to
>>>> be included in Emacs it needs to be rewritten to fit into Emacs
>>>> manual.
>>>
>>> AFAIK, that doesn't matter.
>>
>> What do you mean?
>
> In general[1], in order to include non-trivial content[2] in Emacs,
> the author has to assign the copyright to the FSF. If we don't have
> an assignment, we cannot include it.
>
> I don't know what kind of rewriting your thinking about. If it's only
> adding texinfo markup and minor changes, then I think we still need an
> assignment from the original author.[3]
Thanks, I see.
My idea was to let someone who have signed FSF papers for contributing
to Emacs do the rewriting. I meant a complete rewrite using the ideas
from the EmacsWiki pages, but not directly the content itself.
tyler
>
> As we don't have copyright assignments for the content on EmacsWiki,
> we cannot do this. Does EmacsWiki have a reliable history mechanism
> that allows to find out who has done a change?
>
The wiki is licensed under GPL 2, according to the footer on each page.
This being the case, what's to stop anyone from lifting content for
inclusion in other documents with compatible licenses?
If such activity actually requires individual contributors actively
assigning copyright, then the footer is wrong and needs to be corrected.
Personally, I have always assumed that material I provide on any wiki is
subject to a Free license. Wikipedia is GFDL, and they've never
requested a copyright assignment from me. If that's not the case for the
EmacsWiki it should be stated clearly somewhere.
Cheers,
Tyler
--
Paul R
tyler> This being the case, what's to stop anyone from lifting content
tyler> for inclusion in other documents with compatible licenses?
As far as emacs code is concerned, the FSF wants the code to be under
a free licence, but it also wants to hold the copyright. Why ? Because
the FSF makes new licences on a constant basis, ans only the copyright
owner is allowed to change the licence.
tyler> If such activity actually requires individual contributors
tyler> actively assigning copyright, then the footer is wrong and needs
tyler> to be corrected.
No, the footer is right, GPLV2 is all about distribution permissions,
not about copyright holding, which is the real problem I suspect.
But I'm not sure, anybody to confirm that the FSF applies the same
policy for documentation ?
--
Paul
tyler
> tyler> This being the case, what's to stop anyone from lifting content
> tyler> for inclusion in other documents with compatible licenses?
>
> As far as emacs code is concerned, the FSF wants the code to be under
> a free licence, but it also wants to hold the copyright. Why ? Because
> the FSF makes new licences on a constant basis, ans only the copyright
> owner is allowed to change the licence.
>
Given that the Emacs Wiki expressly allows that the recipient
"may choose to receive this work under any other license that grants
the right to use, copy, modify, and/or distribute the work, as long as
that license imposes the restriction that derivative works have to
grant the same rights and impose the same restriction"
The FSF would have to come up with a new license that is a drastic
departure from conventional copyleft to violate this condition. Still,
I'm beyond the limit of my legal understanding, so that's probably a
good time to stop.
Cheers,
Tyler
--
Research is what I'm doing when I don't know what I'm doing.
--Wernher von Braun
Ted Zlatanov
TN> harden the facility -- when is culture just overgrown moss?
TN> does the stone monkey even remember five centuries lost?
I can assure you that the stone monkey (in fact, *any* stone monkey)
does not remember anything.
TN> is wisdom the hand that clamps down, does not soften?
Wisdom is your own mistakes giving you a reach-around, so yes.
HTH
Ted
Ted Zlatanov
RS> On Thu, Nov 06 2008, Lennart Borgman wrote:
>> On Thu, Nov 6, 2008 at 9:11 AM, Reiner Steib <reinerst...@imap.cc> wrote:
>>> On Tue, Nov 04 2008, Ted Zlatanov wrote:
>>>
>>>> For Gnus specifically, we could use it to automatically pull the
>>>> Gnus+GMail pages from the EmacsWiki into the manual periodically.
RS> Beside the copyright issue, I would object to automatic inclusion
RS> because the quality and correctness of EmacsWiki pages isn't always
RS> sufficient.
I understand. Technically it's possible but that doesn't make it a good
idea.
Ted
Rupert Swarbrick
> My idea was to let someone who have signed FSF papers for contributing
> to Emacs do the rewriting. I meant a complete rewrite using the ideas
> from the EmacsWiki pages, but not directly the content itself.
Are you sure that this doesn't already happen to some extent? I mean if
I were a documentation writer and I saw something relevant to my
software on a wiki, no doubt I'd be inclined to put that information in
the documentation with the next edit I made.
That said, I suppose that if I wrote a certain piece of emacs, I'd be
unlikely to be browsing the emacswiki looking for examples about
it. Hmm.
Rupert