Wikipedia-l August 2001

wikipedia-l@lists.wikimedia.org

30 participants
77 discussions

RE: [Wikipedia-l] Talk policy
by Mark Christensen 23 Aug '01

23 Aug '01

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

1 0

Talk policy
by Robert Bihlmeyer 23 Aug '01

23 Aug '01

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

3 2

nifty form to search Wikipedia via Google
by Tim Chambers 23 Aug '01

23 Aug '01

Have a look at http://timothy.swiki.net/39. It's on my Todo list.

2 1

Re: ISBN links
by Larry Olin Horn 23 Aug '01

23 Aug '01

[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 "standard header here\n"; print "global explanation blah blah blah ....\n"; print ""; print "<a href=\"http://shop.barnsandnoble.com/bookSearch/isbnInquiry.asp?isbn=$query\">Barnes and Noble</a> - "; print "blah blah blah ..."; print "</lp>\n"; print ""; print "<a href=\"http://www.amazon.com/exec/obidos/ISBN=$query\">Amazon</a> - "; print "blah blah blah ..."; print "\n"; print ""; print "<a href=\"http://www.pricescan.com/books/BookDetail.asp?isbn=$query\">Pricescan</a> - "; print "blah blah blah ..."; print ""; print "standard footer here\n"; print "</body>"; print "</html>\n"; __END__ # end ---------- cut here ----------

2 2

Question regarding existing links
by Peter Jones 22 Aug '01

22 Aug '01

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.

1 0

Re: [Wikipedia-l] Question regarding existing links
by Gareth Owen 22 Aug '01

22 Aug '01

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

1 0

Just wiki.cgi script - please
by kpjas＠promail.pl 22 Aug '01

22 Aug '01

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

1 0

Re: Re: [Wikipedia-l] Wikipedia teamwork
by sanger1＠nupedia.com 21 Aug '01

21 Aug '01

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

8 13

Making Wikipedia more Google friendly
by Axel Boldt 21 Aug '01

21 Aug '01

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

2 1

ISBN links
by Robert Bihlmeyer 21 Aug '01

21 Aug '01

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

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Wikipedia-l August 2001