discuss: Thread: To or not to Wiki, a summary [Was Re: small demo page]

I want to contribute to improving tldp, but I don't clearly understand 
where it is heading. So as a first attempt, I have tried to summarize 
this long fruitful(?) thread, I am just going to write down my 
understanding of what people are thinking. I may have misunderstood 
something, please correct me, if so.

Problem: Many HOWTOs are out-of-date and authors seem to have forgotten 
about them. Updates are slow and (tldp) world is coming to an end. (Is it?)

There are many ways to tackle this, and a few are listed on TARPL[1] (I 
like the Ticket Tracker that's how I want my HOWTO to be extended).

Some people think that a full-fledged Wiki (not simple commenting 
mechanism) is more useful, as that allows other people to directly 
change the HOWTO. This is certainly useful for 'bringing some howtos 
back from dead' as mentioned by Yaroslav [2].

jdd put up a demo page with editable and non-editable pages at [3]. The 
idea is to allow readers to change the editable page at will and later 
autor/tldp maintainers can see the differences and merge with a stable 
non-editable one. Perhaps, we can convert the stable version to docbook.

Wiki advantages:
*) Quick updates - anybody can improve as they are reading the HOWTO and
    find mistakes. It also doesn't have to go through the slow/length
    TLDP review process.
*) Easier updates - It's much easier to edit a Wiki page than an .sgml
    file. The learning curve with sgml tools is sttep. For begineers
    there's HOWTO generator [4], but later updates have to be in SGML.
*) Easier management - Once setup it can work on its own depending on
    the readers interest.

Wiki disadvantages
*) Connecting Wiki with docbook as a backend is difficult. If this is
    not possible, we have to find a better way to convert to print
    formats etc.
*) Vandalism problems - Do we simply throw the HOWTO on a Wiki and hope
    that it turns into a master piece? or let the author tightly control
    the content by allowing only comments?
*) What happens to the flow of a long document if it is edited by a lot
    of people? I am quite uneasy with this, as all the hardwork put in by
    the original author for the HOWTO organization etc. goes waste.

There are some general issues like

*) Copyright issues. Who owns the content once it is on the Wiki?
*) How do you wikify existing content? There was some work on this by
    Blake [5]. I am not sure about the current status.

Ok, that's all I can think of right now.

1. http://www.nyx.net/~sgjoen/tarpl.html
2. http://lists.tldp.org/index.cgi?1:mss:9567:200508:pedejonpkemjljkegodm
3. http://dodin.org/mediawiki/index.php/Tldp_demo_page
4. http://www.nyx.net/~sgjoen/The_LDP_HOWTO_Generator_ng.html
5. http://lists.tldp.org/index.cgi?1:mss:9116

-- 
Pradeep Padala
http://ppadala.blogspot.com

Pradeep Padala wrote:

> I want to contribute to improving tldp, but I don't clearly understand 
> where it is heading. So as a first attempt, I have tried to summarize 
> this long fruitful(?) thread, I am just going to write down my 
> understanding of what people are thinking. I may have misunderstood 
> something, please correct me, if so.


Actually, we seem a little adrift, a strong focus might start the
process to make TLDP more current again.

> Problem: Many HOWTOs are out-of-date and authors seem to have forgotten 
> about them. Updates are slow and (tldp) world is coming to an end. (Is it?)
> 
> There are many ways to tackle this, and a few are listed on TARPL[1] (I 
> like the Ticket Tracker that's how I want my HOWTO to be extended).


Thanks for your support, I believe you are the first one to
agree with my on that approach, at least in public.

> Some people think that a full-fledged Wiki (not simple commenting 
> mechanism) is more useful, as that allows other people to directly 
> change the HOWTO. This is certainly useful for 'bringing some howtos 
> back from dead' as mentioned by Yaroslav [2].


If the document license allows it and there is nothing to lose
it might be a good idea. License, as ever, remains a problematic
area, especially since 10 years of such discussions have not yet
reached a clonclusion.

> jdd put up a demo page with editable and non-editable pages at [3]. The 
> idea is to allow readers to change the editable page at will and later 
> autor/tldp maintainers can see the differences and merge with a stable 
> non-editable one. Perhaps, we can convert the stable version to docbook.


The conversion to wiki was not optimal, I spent an hour or so redoing
a lot of tags and strange characters resulting from accented letters.
I believe it should be easier to use now.

> Wiki advantages:
> *) Quick updates - anybody can improve as they are reading the HOWTO and
>    find mistakes. It also doesn't have to go through the slow/length
>    TLDP review process.
> *) Easier updates - It's much easier to edit a Wiki page than an .sgml
>    file. The learning curve with sgml tools is sttep. For begineers
>    there's HOWTO generator [4], but later updates have to be in SGML.


The wiki markup is so simple I guess a one-to-one conversion either way
with LinuxDoc might work with only abstract and indexing tags as the
exceptions.

Re-editing with the Generator would require a little extra work on
my part to make possible. I asked some time ago if there was any
interest in that but never got any replies.

> *) Easier management - Once setup it can work on its own depending on
>    the readers interest.


This part is important since we have few resources.

> Wiki disadvantages
> *) Connecting Wiki with docbook as a backend is difficult. If this is
>    not possible, we have to find a better way to convert to print
>    formats etc.
> *) Vandalism problems - Do we simply throw the HOWTO on a Wiki and hope
>    that it turns into a master piece? or let the author tightly control
>    the content by allowing only comments?
> *) What happens to the flow of a long document if it is edited by a lot
>    of people? I am quite uneasy with this, as all the hardwork put in by
>    the original author for the HOWTO organization etc. goes waste.


[snip]

I made a summary about a week ago and just HTML-ified it and put
it up on TARPL. It contains a few  more points that also have to
be considered, mainly on the process side of things:
	http://www.nyx.net/~sgjoen/Wikipedia.html

Regards,
    Stein Gjoen

Since this was addressed to me (with a copy to tldp), I felt I should try to 
respond--I may have, in some cases, forced a response where none was really 
necessary.

On Sunday 21 August 2005 12:45 pm, Pradeep Padala wrote:
> I want to contribute to improving tldp, but I don't clearly understand
> where it is heading. So as a first attempt, I have tried to summarize
> this long fruitful(?) thread, I am just going to write down my
> understanding of what people are thinking. I may have misunderstood
> something, please correct me, if so.
>
> Problem: Many HOWTOs are out-of-date and authors seem to have forgotten
> about them. 

At least, many authors have not responded to the recent inquires from (iirc)  
Machtelt.  (And, from what I understand, this has been an ongoing problem.)

> Updates are slow and (tldp) world is coming to an end. (Is it?) 

Presumably, but my understanding is we have a few billion years left.  ;-) (I 
plan to make the most of them. ;-)

> There are many ways to tackle this, and a few are listed on TARPL[1] (I
> like the Ticket Tracker that's how I want my HOWTO to be extended).

Interesting.  We could do something like this (really, a workaround) by having 
two pages in the wiki (TWiki) (as jdd has), one editable and one not, and 
convince the user to display those two pages in two different browsers side 
by side (and page them simultaneously).  Cumbersome, but a way to "prove" the 
concept.

> Some people think that a full-fledged Wiki (not simple commenting
> mechanism) is more useful, as that allows other people to directly
> change the HOWTO. This is certainly useful for 'bringing some howtos
> back from dead' as mentioned by Yaroslav [2].

As mentioned in another post, I like this idea.

> jdd put up a demo page with editable and non-editable pages at [3]. The
> idea is to allow readers to change the editable page at will and later
> autor/tldp maintainers can see the differences and merge with a stable
> non-editable one. Perhaps, we can convert the stable version to docbook.
>
> Wiki advantages:
> *) Quick updates - anybody can improve as they are reading the HOWTO and
>     find mistakes. It also doesn't have to go through the slow/length
>     TLDP review process.
> *) Easier updates - It's much easier to edit a Wiki page than an .sgml
>     file. The learning curve with sgml tools is sttep. For begineers
>     there's HOWTO generator [4], but later updates have to be in SGML.
> *) Easier management - Once setup it can work on its own depending on
>     the readers interest.
>
> Wiki disadvantages
> *) Connecting Wiki with docbook as a backend is difficult. If this is
>     not possible, we have to find a better way to convert to print
>     formats etc.
> *) Vandalism problems - Do we simply throw the HOWTO on a Wiki and hope
>     that it turns into a master piece? or let the author tightly control
>     the content by allowing only comments?

In the context of a dead HOWTO with no current author, his original text is 
locked (not editable), so we only worry about damage in the "scratchpad" 
wiki.  As others have mentioned, I prefer that the wiki require registration, 
and further, that users register with something close to their real name, and 
perhaps verified by requiring them to provide a valid email address and 
respond to a confirmation request (email).  

Yes, spam/vandalism can be a problem.  And poor writing can be a problem.  
Several wikis still maintain their "excellence" with self-policing by their 
"members".  TWiki continues to work on ways to deal with vandalism.  If 
things get bad we can lock all pages or something similar.  (In TWiki, 
specific users or groups of users can have permission to edit specific pages, 
excluding all others from editing those pages.)

I don't think we should give up because of the potential for vandalism.  
twiki.org, WikiPedia, Ward's Wiki, and many other wikis are "maintaining 
their own" in the battle against vandalism.

> *) What happens to the flow of a long document if it is edited by a lot
>     of people? I am quite uneasy with this, as all the hardwork put in by
>     the original author for the HOWTO organization etc. goes waste.

Again, in the context we're talking about here (I think) (that is, 
resurrecting dead documents), the original document is locked.  The rewrite 
process may be messy, but, if necessary at some point, maybe one person (or 
small group) has to take the the (potentially messy) results of that process 
and clean it up.  Then, for the next revision cycle, their product is locked 
just like the original (missing) author's was, and a revision can start on an 
editable copy of their work.

> There are some general issues like
>
> *) Copyright issues. Who owns the content once it is on the Wiki?

That can be defined.  On WikiLearn (all of twiki.org) and several other wikis, 
the content is noted as belonging to the author / contributor  (several 
people may share "overlapping" copyrights on some pages).  Some other wikis 
require contributors to agree to some license terms prior to contributing.  
(One I've looked at recently requires contributions to be licensed under the 
GPL, and includes a statement to that effect next to the save button, iirc.)

There could even be different licensing terms for different documents (if, for 
example, authors cannot all agree on the same terms).

Without remembering exactly how tldp handles the copyright on documents in 
general, I'm sure we can find an approach that does not impede the use of the 
content by the tldp in ways similar to the current uses.   (I seem to recall 
that the tldp allows some flexibility to the author with respect to the 
licensing of his work, or, at least, they were not required to agree that if 
they could not be located by some reasonable process in some reasonable time 
frame, the copyright would be transferred to the tldp ;-)

> *) How do you wikify existing content? There was some work on this by
>     Blake [5]. I am not sure about the current status.

Again, in the current context (resurrecting dead documents) and with TWiki, it 
becomes fairly easy, as TWiki can display most, if not all, (X)HTML.  For 
other scenarios we may have to develop other approaches.  But, let's start 
with some "dead" (but interesting) HOWTOS.

> Ok, that's all I can think of right now.

Good!  (But I'm glad you brought them up for discussion, although I think some 
have been touched on before.)

regards,
Randy Kramer


>
> 1. http://www.nyx.net/~sgjoen/tarpl.html
> 2. http://lists.tldp.org/index.cgi?1:mss:9567:200508:pedejonpkemjljkegodm
> 3. http://dodin.org/mediawiki/index.php/Tldp_demo_page
> 4. http://www.nyx.net/~sgjoen/The_LDP_HOWTO_Generator_ng.html
> 5. http://lists.tldp.org/index.cgi?1:mss:9116

Randy Kramer wrote:

> Interesting.  We could do something like this (really, a workaround) by having 
> two pages in the wiki (TWiki) (as jdd has)

Randy, I went two hours ago through old bookmarks and find 
my own tkwiki account 
(http://twiki.org/cgi-bin/view/Main/JeanDanielDodin) :-)

as ever the problem is I have not yet updated my howto, so 
this address is unknown :-(. That is why such a	 wiki must 
be "official" (tldp advertised) if definitively accepted of 
course.

>> jdd put up a demo page with editable and non-editable pages

as one said I should go ahead, I asked sourceforge for a 
tldpwiki project (experimental). This don't mean I dislike 
tkwiki, I only know better mediawiki. I have no preference. 
why not test the two ones?

however I think we should see the wiki as _an other_ media, 
not a replacement for anything, thus accepting some 
drawbacks to have some advantages.

For example, the license issue. _I know_ the debate, I 
followed it. but given the collective and partly anonymous 
nature of wiki work, we could force for an unique licence 
given to the tldp. mediawiki, by default, is LGPL. Licence 
could be owned by tldp. of course authors don't liking this 
license could use any of the classical way.

I _don't say_ we must do this, only _we could_

as of the unmaintained HOWTO problem, I don't see any 
solution. using the old one as a model may be seen as a 
license infringement. I'm not a lawyer, though.

jdd

-- 
pour m'écrire, aller sur:
http://www.dodin.net
http://valerie.dodin.net
http://arvamip.free.fr

>> Problem: Many HOWTOs are out-of-date and authors seem to have 
>> forgotten about them. Updates are slow and (tldp) world is coming to 
>> an end. (Is it?)
>>
>> There are many ways to tackle this, and a few are listed on TARPL[1] 
>> (I like the Ticket Tracker that's how I want my HOWTO to be extended).
> 
> Thanks for your support, I believe you are the first one to
> agree with my on that approach, at least in public.

You are welcome. For my HOWTO (and probably for some others), all I 
needed was to collect comments and do an update containing a lot of 
small changes once in a while. The ticket tracker is the simplest, and 
easiest and doing something like this even with a Wiki (meaning locked 
page allowing comments only) would be useful.

-- 
Pradeep Padala
http://ppadala.blogspot.com

>>> jdd put up a demo page with editable and non-editable pages
>  
> as one said I should go ahead, I asked sourceforge for a tldpwiki 
> project (experimental). This don't mean I dislike tkwiki, I only know 
> better mediawiki. I have no preference. why not test the two ones?

Great ! let me know if you need any help, once it gets approved. We can 
start with the dead, but useful HOWTOs (Networking HOWTO for instance) 
as that's where Wiki seems to be most useful.

-- 
Pradeep Padala
http://ppadala.blogspot.com

Pradeep Padala wrote:

> Great ! let me know if you need any help, once it gets approved.

for shure :-)

  We can
> start with the dead, but useful HOWTOs (Networking HOWTO for instance) 
> as that's where Wiki seems to be most useful.
> 
look at the license, just in caes.
thanks
jdd

-- 
pour m'écrire, aller sur:
http://www.dodin.net
http://valerie.dodin.net
http://arvamip.free.fr

On Sunday 21 August 2005 07:53 pm, jdd wrote:
> as one said I should go ahead, I asked sourceforge for a
> tldpwiki project (experimental). This don't mean I dislike
> tkwiki, I only know better mediawiki. I have no preference.
> why not test the two ones?

No problem.  All I (anybody) need(s) is an HTML version of the document 
(preferably divided into pages of a reasonable size) (and no legal or similar 
impediments).

The Network HOWTO that someone mentioned might be of interest to me (I 
recently got Samba and NFS working reasonably well on my home network).

> as of the unmaintained HOWTO problem, I don't see any
> solution. using the old one as a model may be seen as a
> license infringement. I'm not a lawyer, though.

I wonder if someone can comment on that authoritatively?  I'm fairly sure 
there is no problem (with copyright) if I read someone's document, then 
(possibly with a time delay) write a document using the knowledge gained 
there.  (If that document were a work of fiction, I might have more problems, 
like if I used a too-similar plot or characters.)

Anybody know of a set of guidelines as to what's permissible and what is not 
(assuming that:
    (1) we can't get permission from the original author (because we can't 
contact him), but 
   (2) we do have sufficient permission to publish his document on a wiki 
(part of his original permission to allow the tldp to publish his document), 
and 
   (3) his document is read only (we won't be editing his document).
   (4) other necessary conditions??

(Attempt at defusing any offense re: gender specific pronouns with lame 
attempt at humor: Of course, I realize that if the author is female we'd have 
to revisit each of these points ;-)

Randy Kramer

> (Attempt at defusing any offense re: gender specific pronouns with lame
> attempt at humor: Of course, I realize that if the author is female we'd have
> to revisit each of these points ;-)

You raise a valid point, one that is far from trivial. I have found attempts to
avoid gender-specific language in technical writing to be a rather challenging,
worthwhile goal.

At any rate, this subject matter was addressed by members of the
####@####.#### mailing list a few years ago (I discovered this via google.)
The opinions expressed at the time were rather interesting (to me, at least.)

I also found the links listed below with google. Their content seems rather
apropos:

http//en.wikipedia.org/wiki/Non-sexist_language
http://fedora.redhat.com/participate/documentation-guide/sn-tech-docs-fundamentals.html

Cheers,
JA

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sun, 21 Aug 2005, Randy Kramer wrote:

> > Problem: Many HOWTOs are out-of-date and authors seem to have forgotten
> > about them.
>
> At least, many authors have not responded to the recent inquires from (iirc)
> Machtelt.  (And, from what I understand, this has been an ongoing problem.)

Just to update you all: in many parts of the world, summer holiday
continues to be a communication problem, at least until the end of
September.  I will wait a couple more weeks longer before making the
"offical" list of unmaintained works public, so as to give everybody the
time to reply to my enquiry.

Tille.

- --
Machtelt Garrels                ####@####.####
Review Coordinator    	 	http://www.tldp.org/authors/

My Penguin, my freedom.         http://tille.xalasys.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFDDD1qsIIUbMXbBA8RAiZuAKCLqSsc4PeSF/xtOfnddQCWCZ6UUwCfXZqZ
y8289LqWCzWKLk5eEoFlOOc=
=n7LG
-----END PGP SIGNATURE-----