I also brought this subject up in the Wikipedia itself. I think it's
important to refactor discussions. The key sociological differences between
Usenet and a wiki is that the ability to make instant additions and add to
discussions is balanced by the ability to edit what has come before. If
Larry's correct in worrying about the Wikipedia becoming just another
discussion group, the way we should go about fixing that is to refactor
discussions.
Anyway, I don't buy the argument that since refactoring a /talk page is a
complex issue there are no rules we can apply. For example, I think we can
say:
1) It's generally better to refactor /talk pages to summarize the previous
discussion than to delete that discussion.
2) Refactoring should not take place until the discussion has either died
down, or moved on to a new topic.
3) If there's a long discussion between two people, and it's slightly off
topic, feel free to move it to a new page, and replace it with a link to the
new page (a sub page of one of the involved parties is a good idea.)
4) When refactoring a /talk page, look for content which should be added to
the main encyclopedia page.
If we go back to the origonal post, I agree that talk about a simple
typographical error should not exist, and can be deleted imediately. If you
find a typo, go ahead and fix it, don't just post a gripe.
-----Original Message-----
From: Jimmy Wales [mailto:jwales@bomis.com]
Sent: Thursday, August 23, 2001 1:28 PM
To: wikipedia-l(a)nupedia.com
Subject: Re: [Wikipedia-l] Talk policy
I think you are absolutely correct in all aspects of your reasoning.
In many cases, the /Talk pages should be refactored when the main page
has been changed to the satisfaction of all the talkers. In some
cases, this will not be true.
In some cases, deletions to the /Talk page should wait several days
until all the contentious parties have had a good chance to mull it
over. For example, there might be a 3-way debate. A and B are initially
in agreement, and C dissents. B is convinced by C's dissent and changes
the main page, noting on the /Talk page the reasons. It would be nice if
A had a few days to decide whether to press the issue further, and simply
deleting the talk page on the assumption that B's conversion is tantamount
to consensus might be unwise.
One useful "middle of the road" solution is to *refactor* rather than
*delete*
the /Talk. That is, to rewrite the talk page to sum up the debate that was
held, giving the rationale for the existing version of the page. This
leaves
things a bit more open to further debate, while at the same time "cleaning
house"
in a useful way.
I think that when we come across an old talk page that seems to be about an
uncontroversially corrected error, we should feel free to just delete the
whole
discussion.
All in all, I think that no *simple* policy can be stated. As long as we
have
a friendly and helpful community striving for consensus, then individual
judgment
will serve to guide us quite nicely.
Robert Bihlmeyer wrote:
> Hi,
>
> I often stumble over /Talk pages containing requests for changes,
> clarification, or similar, which are outdated by the main page's
> progress. An example of many is
>
<URL:http://www.wikipedia.com/wiki.cgi?action=browse&id=LISP_programming_lan
guage/Talk&revision=1>:
>
> > Page for discussion ...
>
> Fluff, removed now.
>
> > "... and is therefore the oldest programming language ..."
>
> with arguments why this is false. Notion has been corrected in the
> article. Following is a section acknowledging the error.
>
> > "... and CDR (Contents of Address Register) ..."
>
> Pointing out a typo, which has been fixed. Another section
> acknowledging this error follows.
>
> > Function CAR in LISP program returns ...
>
> I don't know what this is, perhaps a suggested addition to the article?
>
> So, one section is still relevant, the other four or five were used by
> people to showcase problems that they were not sure enough about to go
> ahead and correct them. I'm unsure what should be done about these
> no-longer-relevant bits.
>
> My preferred alternative is deleting them outright, and make the
> following guideline: If you implement a suggestion from a /Talk page,
> be sure to delete the suggestion as well. It is no longer relevant to
> the current revision of the article.
>
> The counter argument that holds me back is that the discussion
> provides background reasoning to changes, especially regarding more
> contentious topics.
>
> (Obviously this does not apply to the CAR/CDR change, so I decided to
> remove that as well, now.)
>
> Thoughts?
>
> --
> Robbe
--
*************************************************
* http://www.nupedia.com/ *
* The Ever Expanding Free Encyclopedia *
*************************************************
[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l
Hi,
I often stumble over /Talk pages containing requests for changes,
clarification, or similar, which are outdated by the main page's
progress. An example of many is
<URL:http://www.wikipedia.com/wiki.cgi?action=browse&id=LISP_programming_lan…>:
> Page for discussion ...
Fluff, removed now.
> "... and is therefore the oldest programming language ..."
with arguments why this is false. Notion has been corrected in the
article. Following is a section acknowledging the error.
> "... and CDR (Contents of Address Register) ..."
Pointing out a typo, which has been fixed. Another section
acknowledging this error follows.
> Function CAR in LISP program returns ...
I don't know what this is, perhaps a suggested addition to the article?
So, one section is still relevant, the other four or five were used by
people to showcase problems that they were not sure enough about to go
ahead and correct them. I'm unsure what should be done about these
no-longer-relevant bits.
My preferred alternative is deleting them outright, and make the
following guideline: If you implement a suggestion from a /Talk page,
be sure to delete the suggestion as well. It is no longer relevant to
the current revision of the article.
The counter argument that holds me back is that the discussion
provides background reasoning to changes, especially regarding more
contentious topics.
(Obviously this does not apply to the CAR/CDR change, so I decided to
remove that as well, now.)
Thoughts?
--
Robbe
[I've had this in my pending folder since the 16th. Forgot about it until I saw JW's post, so it doesn't sound like a direct reply.]
This is trivial compared to most of the requested features, but
I'm submitting it as a trial baloon, so to speak,
the idea being that some sample code might be more encouraging
that just saying "I want this feature" w/o giving any thought
to how it might work.
Really, I just want to know if submissions like this are acceptible,
or if you'd rather not bother with them.
One request was that the ISBN links be more explicit, so here's
the skeleton of a solution.
First, the ISBNLink function in wiki.cgi is simplifed (first
enclosure below); it just creates a link to an external script
that looks like
<a href="/cig-bin/isbn.cgi?nnnnnnnnnn">ISBN nnnnnnnnn</a>
The external isbn.cgi script (DEMO below) produces a page that
looks like:
(standard header here)
global explanation blah blah blah ....
Barnes and Noble - blah blah blah ...
Amazon - blah blah blah ...
Pricescan - blah blah blah ...
(standard footer here)
where the company names are the links to their respective ISBN
lookups and the "blah blah blah" is whatever fixed disclaimer/writeup
that Wikipedia/Bomis wants to use.
Being the lazy guy that I am, the proper coding of isbn.cgi for
security and your local standards is left for someone else (grin).
loh
[this is UseMod 0.92; I've not downloaded the Wikipedia tarball]
---------- replacement for ISBNLink() ----------
sub ISBNLink {
my ($rawnum) = @_;
my ($rawprint, $html, $num, $first, $second, $third);
$num = $rawnum;
$rawprint = $rawnum;
$rawprint =~ s/ +$//;
$num =~ s/[- ]//g;
if (length($num) != 10) {
return "ISBN $rawnum";
}
# LOH: begin modification
# replace direct ISBN links with external script
#
# $first = "<a href=\"http://shop.barnesandnoble.com/bookSearch/"
# . "isbnInquiry.asp?isbn=$num\">";
# $second = "<a href=\"http://www.amazon.com/exec/obidos/"
# . "ISBN=$num\">" . T('Amazon') . "</a>";
# $third = "<a href=\"http://www.pricescan.com/books/"
# . "BookDetail.asp?isbn=$num\">" . T('PriceScan') . "</a>";
# $html = $first . "ISBN " . $rawprint . "</a> ";
# $html .= "($second, $third)";
#
$html = "<a href=\"/cgi-bin/isbn.cgi?$num\">ISBN $rawprint</a>";
#
# LOH: end modification
$html .= " " if ($rawnum =~ / $/); # Add space if old ISBN had space.
return $html;
}
---------- cut here ----------
---------- isbn.cgi ----------
#! perl
##### WARNING: CONCEPT DEMO ONLY - THIS IS NOT GOOD CODE! #####
$query = $ENV{'QUERY_STRING'};
print "Content-type: text/html\n\n";
print "<html>";
print "<head><title>Look up ISBN $query</title></head>";
print "<body>\n";
print "<p><i>standard header here</i></p>\n";
print "global explanation blah blah blah ....</p>\n";
print "<p>";
print "<b><a href=\"http://shop.barnsandnoble.com/bookSearch/isbnInquiry.asp?isbn=$query\">Barnes and Noble</a></b> - ";
print "blah blah blah ...";
print "</lp>\n";
print "<p>";
print "<b><a href=\"http://www.amazon.com/exec/obidos/ISBN=$query\">Amazon</a></b> - ";
print "blah blah blah ...";
print "</p>\n";
print "<p>";
print "<b><a href=\"http://www.pricescan.com/books/BookDetail.asp?isbn=$query\">Pricescan</a></b> - ";
print "blah blah blah ...";
print "</p>";
print "<p><i>standard footer here</i></p>\n";
print "</body>";
print "</html>\n";
__END__
# end
---------- cut here ----------
Just a quick question regarding links.
I have just revised an entry (Blade Runner) which included a link to
"Philip K. Dick/Do Androids Dream of Electric Sheep". I then went and
created a page for "Do Androids Dream...". When I go back and look at
the Blade Runner page again, the link in question still appears as an
edit link, rather than a "normal" link. However, if I re-edit the Blade
Runner page and hit [Preview], the preview displays correctly.
I don't want to re-save the page just to fix the link. Is that what I
have to do? Or am I doing something else wrong? (Or is there a script
which runs through the wikipedia on a regular basis and fixes all these
dangling edit links that are no longer dangling?)
Pete.
Peter Jones <jonespr(a)optushome.com.au> writes:
> I don't want to re-save the page just to fix the link. Is that what I
> have to do?
Yes. I think its a result of how the wiki software caches pages. Add some
whitespace, click "minor edit" and resave...
> (Or is there a script which runs through the wikipedia on a regular basis
> and fixes all these dangling edit links that are no longer dangling?)
I don't know, but its a good idea
--
Gareth Owen
Hello all,
Could someone please send me or put up on a page somewhere just the
wiki.cgi script from the English tarball distro ?
I'd be very much grateful.
Regards,
kpj.
--
Krzysztof P. Jasiutowicz, M.D | Zawsze jestem gotów się uczyć, chociaż nie
Czestochowa, Poland ... | zawsze chcę, żeby mnie uczono. Winston S.
Więcej cytatów : http://www.cytatowo.prv.pl
Bryce (just realized that I had replied just to you rather than the
list): I sympathize, but posting on this list frankly isn't going to
get anything done. I do only a little work directly on the server;
Jason's the man who will have to do this, if this or something like
it is what we'll end up doing, exactly. What Jason might not know
(so, I've cc'd him) is how seriously you all take this. I certainly
would like to see Wikipedia's content easily useable--it will get a
lot of new links back to Wikipedia and it will indeed make the
project more credible, as someone very correctly said. I have wanted
this to be done for months, but, well--our programmers are very busy
with projects that actually make money. :-/
Larry
You Wrote:
>I think what people are trying to politely say is that you may be in
>violation of your license...
>
>My suggestion to get around this with a minimum of time expended
would
>be to set up a cron job to tarball the wiki databases once a week.
>
>Login as www-data or nobody or root or whomever
>$ crontab -e
>0 5 * * 0 /usr/local/bin/tarball_wiki # Weekly Sunday 5am tarball
>
>
>#!/bin/sh
>## tarball_wiki script
>tar cf /tmp/wiki.tar /home/www-data/wiki_db /home/www-data/cgi-
bin/wiki.pl
>gzip /tmp/wiki.tar
>rm -f /home/www-data/html/wiki.tar.gz
>mv /home/www-data/html/wiki.tar.gz /home/www-data/html/wiki-
prev.tar.gz
>mv /tmp/wiki.tar /home/www-data/html/wiki.tar.gz
>
>
>This will keep the current plus previous week's tarball.
>Obviously, you'll have to fiddle the paths to match however your
system
>is organized. You might need to add some chmod/chown commands if
you do
>this as a user other than the web user.
>
>Anyway, IANAL, but I think this little script would get you off the
hook
>regarding the transparency issue.
>
>Bryce
>
>On Wed, 15 Aug 2001 sanger1(a)nupedia.com wrote:
>> I agree completely as well. You all must realize, though, that
the
>> amount of (expensive) paid programming labor Bomis can devote to
>> useful and even essential features like this is less than we would
>> all like. It would be ideal if some programmers would step up to
the
>> plate and actually help bring some of these proposals into being.
I
>> for one would be absolutely delighted.
>>
>> Larry
>>
>> You Wrote:
>> >On Tue, Aug 14, 2001 at 09:56:47AM +0200, Robert Bihlmeyer wrote:
>> >> Jan Hidders <hidders(a)win.tue.nl> writes:
>> >>
>> >> > Because the GFDL allows you to download everything and start
>> your own
>> >> > server.
>> >>
>> >> Well the GFDL also wants transparent copy to be easily
available. I
>> >> don't consider spidering wikipedia to be an option open to
the "man
>> >> from the street".
>> >
>> >FWIW I certainly agree with that, and there should certainly be
an
>> easy
>> >way to download the complete Wikipedia. So you can also add
>> my "pretty
>> >please" :-)
>> >
>> >-- Jan Hidders
>> >
>> >[Wikipedia-l]
>> >To manage your subscription to this list, please go here:
>> >http://www.nupedia.com/mailman/listinfo/wikipedia-l
>> >0
>
>[Wikipedia-l]
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l
When you do a search on Wikipedia or click on a link, the returned
URL looks like http://www.wikipedia.com/wiki.cgi?Poker
If somebody likes this page and links to it, then in principle that
should increase our standing with Google. But Google doesn't like CGI
links. It would be better if the wiki script always returned links of
the form http://www.wikipedia.com/wiki/Poker (actually, I would have
prefered http://www.wikipedia.com/Poker, but that's too late now).
Is the source code of our wiki perl script available somewhere?
Axel
The automatic links to booksellers provided with ISBN numbers are a
good feature overall.
I'd rather have them not point at Amazon, though, since they are
obviously against freedom (keyword: 1-click patent), and didn't
respect my privacy (details on request). I would be more comfortable
with links to other outfits (Barns & Noble, whatever).
Obviously you may differ on this issue, and if the links to Amazon are
kept, I suggest that they use the Amazon Honor System. With this Bomis
would receive payment for every traffic that reaches Amazon through
one of those links (just like with banner ads). AFAIK, the only thing
that must be changed is the base URL used in those links (e.g. putting
/wikipedia/ somewhere in there), and of course registering with
Amazon. If you implement this, please put up some page stating where
the money goes. I'd expect Bomis to earmark the money for the hosting
& maintaining costs of wikipedia, but it's always good to have an
explicit statement.
Perhaps other booksellers offer similar deals, or they could be worked
out individually.
What do others think?
--
Robbe