Wikipedia-l September 2002

wikipedia-l@lists.wikimedia.org

66 participants
316 discussions

Re: Re: [Wikipedia-l] order of lists of works & prizes
by Daniel Mayer 29 Sep '02

29 Sep '02

On Saturday 28 September 2002 05:33 am, tarquin wrote: > This has been hanging around for some time, with most people in favour, > and only 1 1/2 objections. > > In answer to Toby, I think we should choose a standard because > consistency of presentation is important in a body of work such as an > enclyclopedia. (The information itself is more important, of course.) > If I found in a paper encyclopedia that the list of Nobel Laureates went > one way, but Pulitzer Prizes went the other, I would be pretty unimpressed. Perhaps LDC is so used to logs (where it is logical to have new items at top) that this is clouding the issue at hand. My vote is to have list chronological with the earliest item listed first. If the list gets too long thus forcing readers to page through old items to get to new ones, then it is time to break up the list into / pages. Of course, anything with the explicit word "log" in the title should list new items at the top. This should make it clear. -- Daniel Mayer (aka mav)

1 0

Re: Re: [Wikipedia-l] generic markup and miscoded templates
by Daniel Mayer 29 Sep '02

29 Sep '02

On Saturday 28 September 2002 05:33 am, you wrote: > The genial and hardworking Ram-Man, by the way, has already fixed all > the city, county, state, and whatever templates to work correctly in > the future without any fuss. > > That naive and cranky guy, > > Tom Parmenter > Ortolan88 I kinda prefer the simpler and more obvious syntax of == meaning H2. However I have used === because == is rendered way too big. I will change === to == whenever I see it is wrongly used if and only if == is rendered smaller. Whatever we do it should be consistent and decided upon -- either way there are thousands of pages that need to be fixed. -- Daniel Mayer (aka mav)

1 0

generic markup and miscoded templates
by Tom Parmenter 29 Sep '02

29 Sep '02

I have started a conversation in [[Wikipedia talk:WikiProject U.S. Counties]] about the fact that the templates for country, state, county, and city all use the wrong markup, that is, sections headed with === instead of ==. I think this is important, but god knows there are going to be a lot of erroneous articles. I wish I'd noticed before there were so many counties done by the redoubtable Ram-Man. Tom Parmenter Ortolan88

5 10

Re: Policy
by Larry Sanger 29 Sep '02

29 Sep '02

A few more things need to be said about this: (1) Most, if not all, of the most important policy decisions have already long since been (at least tentatively) settled upon and formulated. (2) Most statements of policy, especially if they've been around for long, have been looked at again and again by Wikipedians new and old. (3) Unlike the case in the first few months of the project, when a lot of the most basic policy was being decided on, there are now scores of people who are *very* familiar with the finer points of policy, and with their justification. Each of these points individually implies that any significant change to a long-standing statement of policy *probably* demands some prior discussion. And such prior discussion probably should happen on the mailing list, mainly because that's where those who know and care about policy happen to expect policy decisions to be made. I can think of some exceptions; for example, if some (for whatever reason) clearly and uncontroversially defunct policy statement still hasn't been updated, it's just a public service that the policy be changed, and a talk: page comment is probably all that's needed. Larry

1 0

Re: Re: Re: [Wikipedia-l] Helga banned
by koyaanisqatsi＠nupedia.com 28 Sep '02

28 Sep '02

You Wrote: >At 2002-09-10 18:09 -0700, koyaanisqatsi(a)nupedia.com wrote: >>Jaap wrote: >>Yes, it would be possible. It, however, will not be practiced, at least by the person you are directing this part of your message to. I have very particular reasons to mind my privacy, none of which I'll discuss, thank you, because I won't be convinced otherwise. > >This sentence doesn't contain a valid argument. It does. You don't agree with it. >>I certainly don't expect anyone who's done their homework to believe that koyaanis qatsi is my real name, > >That's not the issue. You're right. The issue is this: 1) you want me to use my real name, or a less obvious pseudonym. 2) I don't care. kq

20 44

Re: Re: [Wikipedia-l] "In memoriam"
by lcrocker＠nupedia.com 28 Sep '02

28 Sep '02

> It was suggested to me that they be moved to another domain, > and if there's consensus for that, I'd gladly host them on that > domain. Either something like 911tribute.wikipedia.com or > www.whatever.com, which I would gladly buy. > Even so, I'd like to keep as much as we can, if it can be made NPOV. Since you asked for references to specific pages, I went looking, and I'm now more ambivalent. I think what people have a problem with is pages like "William M. Feehan", which is just effusive praise and tearful reminiscence. But then there are also pages like "Brady Howell", which is a perfectly ordinary biography that I'd have no problem with at all. I'm already on record that I support allowing biographies of anyone at all in Wikipedia, with no regard to whether their accomplishments or fame would merit their inclusion in a more traditional reference. As long as we take care with namespace issues, and those biographies are not mere self-aggrandizement, I have no problem with including any anyone cares to write--including those about 9/11 victims. But I also think that some people used these pages not for "biography" but for "eulogy", and that's not appropriate here. I have nothing against eulogy--I created http://www.piclab.com/sasha for a friend of mine, for example-- and I would like to see a biography of him here as well. But I wouldn't put the memorial comments from my site into the article.

10 19

Re: [Wikipedia-l] Stub detector
by rose.parks＠att.net 28 Sep '02

28 Sep '02

Members, In regard to Mr. Manske proposed "stub dtector" scheme, below, I really thought that color coding was out - because it is inaccessible to blind people. I think this scheme is not a good idea without some alternative "stub detector" detectable by blind people. In addition, I am reading the test page in Opera and there are no green underlining or words, only blue and red. Are we coding for Opera?? As Ever, Ruth Ifcher -- On Fri, Sep 27, 2002 at 03:44:15PM +0200, Magnus Manske wrote: > An initial version of "stub detection" is running at Lee's test site. > Links to stub articles (less than 500 chars) are shown in green. > REDIRECTs are shown as normal links. For example, try > http://www.piclab.com/wikitest/wiki.phtml?title=Biology > I suggest to > * make the minimum size for a "real" article a user option > * set it to zero as standard

2 1

Re: Re: [Wikipedia-l] Stub detector
by Daniel Mayer 28 Sep '02

28 Sep '02

On Friday 27 September 2002 10:47 am, you wrote: > But please make the default setting say 250 chars. This will find the > most gratuitous stubs, without affecting many real articles. > > Neil 250 is way too low to be at all useful and can never be consider to be anything other than (at most) a definition. At 500 chars there is far more space to actually start having encyclopedia articles. Compare; http://www.wikipedia.org/wiki/Subnational_entity 250 chars With; http://www.wikipedia.org/wiki/Hecale 500 chars The first is just a definition, but the second actually has a definition /and/ some encyclopedic information. -- Daniel Mayer (aka mav)

2 1

Re: Stub detector
by Daniel Mayer 28 Sep '02

28 Sep '02

On Friday 27 September 2002 10:47 am, Magnus Manske wrote: > An initial version of "stub detection" is running at Lee's test site. > Links to stub articles (less than 500 chars) are shown in green. > REDIRECTs are shown as normal links. For example, try > http://www.piclab.com/wikitest/wiki.phtml?title=Biology This is way cool! Magnus to the rescue again. :) What about the total article count? It has also been suggested that {{NUMBEROFARTICLES}} should exclude anything less than 500 bytes. Perhaps we could then have {{NUMBEROFENTRIES}} that would use the current, far too permissive detection criteria. > I suggest to > * make the minimum size for a "real" article a user option > * set it to zero as standard > which means nobody gets this special mark-up, except they choose it in > their prefernces. That would avoid confusion, especially among newcomers > (blue links? and red ones? and green ones?). > Also, everybody can decide how large an article has to be at least... I could definitely see the utility of making this a user modifiable preference. But having the global default set to zero kinda defeats the "truth in advertising" argument that started this whole thread. New contributors and readers quickly figure out what edit links are and I think they will be able to quickly figure out what green (or !) links are. Something that could state this very clearly would be a non-editable boilerplate on each sub-500 byte article that said something like; "This is a [[Wikipedia:How to write the perfect stub article|stub]] (very short page) and is therefore not counted in our total article count." But that would be icing on the cake. -- Daniel Mayer (aka mav)

1 0

Re: Re: [Wikipedia-l] Stub detector
by koyaanisqatsi＠nupedia.com 27 Sep '02

27 Sep '02

Magnus wrote: > PLEASE, gimme feedback, or I'll implement it as is! (just so the "hate > it" can register in time, for once...) > > Magnus > > P.S.: Same goes for the "Special:Maintenance" page at the same place, > while you're at it :-) Two comments about the "stub" links: they're green, ok, that's cool, but they're not underlined. All other links, regardless of color, are. At first it just looks like colored text and is not immediately apparent as a link. [[Talk:]] pages should be excluded, probably. I go there if I need to talk about something, regardless of how many people have talked there before me. The maintenance feature is cool. Will it be a simple matter to add to this page when a new feature comes about? Best, kq

1 0

Jump to page:

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 September 2002