Wikipedia:Village pump (proposals)/Archive

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Crypticbot (talk | contribs) at 00:10, 9 June 2006 (Automated archival of 2 sections older than 7 days from Wikipedia:Village pump (proposals) and removal of 1 section older than 14 days). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Village Pump - Archive

DO NOT EDIT OR POST REPLIES TO THIS PAGE. THIS PAGE IS AN ARCHIVE.

Discussions older than 7 days (date of last made comment) are moved here. These discussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.

Post replies at Wikipedia:Village pump (proposals), copying or summarizing the section you are replying to if necessary.

Note: Please add new material at the bottom of the page. Preceded by the following: =Sections archived on ~~~~~ =


Sections archived on 00:13, 3 June 2006 (UTC)

Wiki Currency

Similar to the barnstar and user templates, this is a counter that keeps track of Wikipedia "currency." Currency is earned automatically for different actions (such as page edits by byte count), but is meant more as a reward or gift. One can give others currency for helping with an article, finding information, or some other action, which can be put up as a request and accepted by others- once the task is completed, the originator can "accept" to pay the user for the task, adding currency to their counter. Creating a "task" template allows the payer to specify an action and close the task when the payer sees the task is finished.

Currency would also be given for acts of notoriety, resolving disputes, and other honorable actions. Since the currency is kept track of server side on a different server, users cannot edit their total, but can add or subtract by giving or paying to a specific user by typing the username and amount and hitting submit. Hopefully this will bring a sense of unimaginable chaos. Ihavenolife 01:55, 15 May 2006 (UTC)[reply]

  • Definitely see the article on Wikipedia:WikiMoney. Now, I agree that having a currency system would be potentially beneficial; however, we need to figure out why wikimoney didn't work the first time around. I think that keeping the currency data protected and having a standard method of distribution would be an improvement over the previous attempt. --Mlandau 02:45, 15 May 2006 (UTC)[reply]
  • What could the WikiMoney be spent on, however? Andrew 22:51, 18 May 2006 (UTC)[reply]
    • The original wiki money seems to have been spent on article requests, which ain't a bad idea. I'm not sure what else it could be spent on, though of course, I'm partial to owning shares of articles. But what good would that do? Bragging rights? Voting power? I think it could serve a useful function, but I don't know what that is, though bringing order to chaos seems useful enough. --Mlandau 03:07, 19 May 2006 (UTC)[reply]
    • For prestige in the WP community, similar to the list of contributions of each editor. -Pgan002
  • A good idea, but we should put this discussion somewhere where it might get some more views. Felixboy 18:36, 23 May 2006 (UTC)[reply]
    • Agreed, and I just thought of one possibly useful function of wiki money: dispute resolution (oops, should have read above, Ihavenolife beat me to the punch, but here's one way it could work). If it's worth 100 wikis for me and my compadres to maintain position X, and worth only 90 wikis for those against X, then me and my compadres would win because we value X more, but would have to give the opposing side 90 or so wikis because that's what they valued their opposition at. --Matthew Benjamin Landau 04:12, 24 May 2006 (UTC)[reply]

WikiTeX

Can we include some of this on Wikipedia? WikiTeX It would really be awesome, especially for music and chemistry-related articles. —Mets501talk 22:20, 24 May 2006 (UTC)[reply]

I don't know what the problem is, but I think people have been asking for this for years. I could be wrong, though. Ardric47 02:14, 25 May 2006 (UTC)[reply]
It would really be useful. I wonder what the problem implementing it is. —Mets501talk 02:53, 25 May 2006 (UTC)[reply]
Wow, I remember that. Devs, any comments? I totally want this feature. Comments can be made at http://bugzilla.wikimedia.org/show_bug.cgi?id=1792 Ingoolemo talk 03:02, 25 May 2006 (UTC)[reply]

Holy carp! Just looking at that example page makes my mouth water! It's awesome! Especially the music: I didn't know it was that easy to typeset music readably. Brilliant!--Slashme 10:24, 25 May 2006 (UTC)[reply]

But it's not that easy [on Wikipedia], because it's not available! Ardric47 00:37, 26 May 2006 (UTC)[reply]
Great feature, should be added Pcu123456789 02:52, 26 May 2006 (UTC)[reply]

Good Citizen

I was going over the perennial proposals, and I saw the conflict over semi-protecting the entire project. After much thought, I wanted to add to the discussion. I found that, since I was using a school computer, I was blocked.

Blocked. Yes, some immature idiots, probably at a middle school (my school's IP adress conducts an entire school district), have gone and vandalized Jesus, and we—all ten thousand of us!—have been blocked. This naturally frustrates the living daylights out of me.

This got me to thinking—Why? I understand the need to prevent vandalism, but surely there's another way. I think there is.

If the software allows it, I propose that we have a new category of Wikipedians, called, for the moment, "Good Citizens". These are REGISTERED WIKIPEDIANS, who have never (or almost never) been cited for vandalism or maliciousness, who have at least, say, 100 edits to their names. Nomination could be by anybody, including oneself, and then reviewed by a sysop to certify that the applicant meets the standards.

Now what would a "Good Citizen" do? Essentially, the only thing that would distinguish a "Good Citizen" from any other Wikipedian is that, since this "Good Citizen" is exactly that, he/she would be given the right to edit from computers with blocked IPs when logged in.

I know what some of you might think—this creates an "aristocracy" in which most Wikipedians will be discriminated against. On the contrary, I think that most Wikipedians meet this standard. It would prevent the unfair blockage of good editors—for example, there have to be a few good editors out of ten thousand people in one of the best school districts in the state of Michigan—so long as they register and qualify. Perhaps a better term would be "Certified Non-Vandal", but "Good Citizen" is just as good in my opinion, and has a better ring to it.

And for those of you concerned about vandals getting "Good Citizen" status, any "Good Citizen" is on a policy of strict nonvandalism. Any "Good Citizen" who is cited for vandalism can, should, and will have his or her "Good Citizen" status revoked summarily. Perhaps, after a time, the status may be returned, but it would take a long time, a deep investigation, and a good explanation.

With that, I present my proposal to the WikiPublic. Lockesdonkey 20:38, 25 May 2006 (UTC)[reply]

See Wikipedia:Blocking_policy_proposal, think someone is working on it but when it will be implemented I do not know. Stefan 08:27, 26 May 2006 (UTC)[reply]

Question = When an IP gets blocked, does someone who is logged in but connects via that IP also get blocked? 'Cause if so that's lame. --Username132 (talk)

Yep. Lockesdonkey 19:37, 26 May 2006 (UTC)[reply]

This happened at my work too, a company of over 60,000 employees, a large percentage of which have high potential for being good contributors. I could've just waited for the block to run out (most blocks are short), but since I'm an admin I tracked down the party responsible and discussed the situation with them. It was just a misunderstanding and I unblocked them. I marked all the IP pages in our web proxy block with warnings that they're shared between many people, but these kind of things really only go so far. Deco 21:19, 26 May 2006 (UTC)[reply]
See Mediazilla:550. —Simetrical (talk • contribs) 21:52, 26 May 2006 (UTC)[reply]

Whose in charge of deciding to implement proposals?

There are plenty of great ideas on here, but who is in charge of deciding to okay it? (for example, my syntax highlighting idea above)--Max Talk (add) 22:46, 25 May 2006 (UTC)[reply]

It varies based on what the proposal affects, but nearly always involves some Wikipedia:Consensus process somewhere. Your syntax highlighting proposal should be taken to MediaWiki talk:Common.css. Requests for software changes end up as entries in Wikipedia:Bugzilla. Policy changes end up on the talk page of the affected policy (see Wikipedia:How to create policy). -- Rick Block (talk) 23:55, 25 May 2006 (UTC)[reply]
I read that Jimbo Wales and someone else have over-ruled concensus before, and went ahead and did what they wanted. --Username132 (talk) 18:54, 26 May 2006 (UTC)[reply]
Jimbo is the founder and Chair of the Board of Trustees of the Wikimedia Foundation, which is the non-profit foundation that owns and operates Wikipedia. I don't think he overrules consensus lightly, and when he does so it is in his capacity as the Chair of the Board of Trustees. User:Danny is Jimbo's assistant and occasionally executes decisions on behalf of Jimbo. -- Rick Block (talk) 19:49, 26 May 2006 (UTC)[reply]

A solution to some major problems

Some discussions which recently took place on Wikipedia talk:Featured article candidates found some support for the idea of a static version of wikipedia, and the notion that the tools that work so well for developing articles become our enemy when considering articles which can be considered finished. WP:STABLE proposed the marking of revisions in the article history; a new idea is under development which goes a step further and seeks to separate the finished articles from those in development by creating static versions of finished articles which would be the default view for visitors, and which would only be editable by a subset of users. A 'live' version would still exist and improvements could be incorporated into the static version.

The incentive to vandalise that comes from seeing the results instantly would be removed, for articles with static versions. The authoritativeness of static versions would be greater than live versions because the reader could be sure that no vital facts had recently been changed maliciously.

Details of the idea and full discussion of the numerous advantages it could bring are at Wikipedia:Static version. Your comments are invited. Worldtraveller 00:20, 26 May 2006 (UTC)[reply]

Not all stable version proposals are based on marking revisions in the history. I largely agree with this proposal, but disagree strongly with the idea that an article can be "finished" or at a point where it only gets worse, not better. I like to compare a stable version to a release version of a piece of software. Although it's mostly static, even released software gets hot fixes, patches, and service packs for critical issues - articles should too, just as you propose incorporating changes from the editable article. However, software also gets new releases that incorporate large changes, corresponding here to large addition of content or article refactoring that has had time to stabilize. I also don't take a side on which version should be the default view - the argument that hiding the editable view discourages editing is compelling. Deco 10:19, 26 May 2006 (UTC)[reply]
Well I usually put finished in inverted commas when discussing this idea, because I do agree that perfection is rarely attained. I think articles do reach points where changes are more likely to be harmful than positive though - what's really making me keen for a static version is my experience with helping to bring Sun and Mercury (planet) up to featured status - the former has attracted masses of poor quality revisions since featuring, the latter less so but it is so frequently vandalised that its edit history is dominated by vandalism and reverts.
It would seem very odd to me to have a static version and then not have it as a default view. The static version would be guaranteed vandalism-free, and would have been in some sense validated and approved. User preferences could easily include an option to change the default view to the live version, and a clear link to the live version from the static version, something like 'work on next update', would still encourage editing, I think, while taking away one of the major incentives to vandalise. Worldtraveller 10:53, 26 May 2006 (UTC)[reply]
It's an interesting idea and I would not dismiss it out of hand. I would favor it more for preserving the quality of articles than for stopping vandalism because it would initially be used on only a small percentage of articles, as few are complete and some of those that are about contemporary topics and are subject to more rapid aging. It would help to preserve article quality by stopping bad, but good faith, edits that decrease article quality and it would reduce the small percentage of vandalism never caught or not caught for a very long time on that article. It would also increase confidence in Wikipedia's accuracy. Having a link to the stable version rather than prohibiting changes to the article might be a good compromise. I think that Wikipedia is eventually going to have something like this as it matures. -- Kjkolb 11:46, 26 May 2006 (UTC)[reply]
Yes, it would definitely be aimed at preserving quality - a reduction of vandalism would just be a very positive side-effect. There would always be an editable version of any article, but changes to the live version would not be visible immediately. Worldtraveller 13:09, 26 May 2006 (UTC)[reply]

New Proposal

A new proposal regarding Trivia sections in articles has been created. Input is appreciated! --Osbus 00:59, 26 May 2006 (UTC)[reply]

HTML tag extension

Someone should write an extension and enable on Wikipedia a <html> tag. The nowiki tag not only disables wikitext, but also disables html tags. The html tag should allow users to directly code html for whihc wikitext and templsates are insufficient. E.g. they could create a custom form by simply adding this text to a wikipedia page.

<!-- This displays a random wikipedia image in place of google logo on google wikipedia search -->
<html>
<div style="width:130px;float:left;text-align:center;position:relative;top:-8px">
<a href="http://www.google.com/" style="padding:0;background-image:none">
<img src="http://en.wikipedia.org/wiki/special:random/image" alt="Google" style="border:none" /></a></div>

<form method="get" action="http://www.google.com/search" style="margin-left:135px">
  <div>
    <input type="hidden" name="domains" value="en.wikipedia.org" />
    <input type="hidden" name="num" value="50" />
    <input type="hidden" name="ie" value="utf-8" />
    <input type="hidden" name="oe" value="utf-8" />
    
    <input type="text" name="q" size="31" maxlength="255" value="gsgs" />
    <input type="submit" name="btnG" value="Google Search" />
  </div>

  <div style="font-size:90%">
    <input type="radio" name="sitesearch" id="gwiki" value="en.wikipedia.org" checked="checked" /><label for="gwiki">Wikipedia</label>
    <input type="radio" name="sitesearch" id="gWWW" value="" /><label for="gWWW">WWW</label>
  </div>
</form>
</html>
This will never become a reality, period. HTML is too dangerous. That would allow Flash/Javascript/ActiveX and goodness knows what else, all of which can be easily used for malicious purposes. Disabling specific tags out of the HTML stable would be another way, but it would require about as much work as adding wiki equivalents of specific HTML features when and if needed, which is what we do at the moment. Sure it's slower, but it's safer in the long run. GarrettTalk 11:55, 26 May 2006 (UTC)[reply]
The Mediawiki software already supports raw html inside a <html> tag, but it's disabled on the Wikimedia projects, for the very good reasons outlined by Garrett. Worldtraveller 13:06, 26 May 2006 (UTC)[reply]

Sections archived on 00:11, 4 June 2006 (UTC)

Syntax Coloring

Currently, source code in Wikipedia looks rather dull:

/*
 * This is fake Java code to demonstrate syntax coloring.
 * */
public static void main(String[] args)
{
  String s = new String("This is a test");
  char ch = 'c' + 123;
}

Would it be better if syntax coloring could be applied to the code? Here is an example:

/*
 * This is fake Java code to demonstrate syntax coloring.
 * */
public static void main(String[] args)
{
  String s = new String("This is a test");
  char ch = 'c' + 123;
}

To implement this, I had to use several <span> tags to achieve this, which makes the code almost incomprehensible. What I am suggesting is a modification to MediaWiki:Common.css or MediaWiki:Monobook.css. We would define styles for various types of words in a syntax block:

/* CSS code */
syntax key {
color:blue;
font-weight:bold;}
syntax string {color: maroon;}
syntax char {color: orange;}
syntax number {color: teal;}
syntax comment {color: green;}

In the source code, we could simply write out:

<syntax>
<comment>/**
this is a comment</comment>
<string>"Hey there!"</string>
</syntax>

This makes future editing much simpler. If a certain user wished to customize the colors and styles, or turn them off, all he would need to do is modify his own CSS file. This would also pave the way for a possible syntax highlighting tool, much like the <math> tool. The parser would already have the styles in place.

Please, relay your thoughts to me. --Max Talk (add) 04:04, 23 May 2006 (UTC)[reply]


In general, there shouldn't be much source code in Wikipedia. Nor should there be much HTML markup. --John Nagle 05:22, 23 May 2006 (UTC)[reply]
What are you talking about? What a poor excuse to not include a potentially very useful thing in the Wikipedia code. So you're against including it because "there shouldn't be much code"? Says who? What's the problem with a lot of code? This actually reduces the amount of code in articles themselves because people no longer have to make style tags in case they want syntax highlighting. People who copy Wikipedia content simply won't have those highlights, but they'll still have the code. It's perfectly transparent and usable this way. —Michiel Sikma, 10:34, 23 May 2006 (UTC)[reply]
There shouldn't be much code because code obfuscates the source, making it difficult for people who don't understand the code to edit. Christopher Parham (talk) 21:01, 23 May 2006 (UTC)[reply]
I find the idea great. I'm totally for implementing something like this if it's possible to do so (are there free resources available on how to do syntax highlighting in PHP?) It would certainly greatly increase the quality of articles about programming. —Michiel Sikma, 10:34, 23 May 2006 (UTC)[reply]

Instead of modifying the Common.css and Monobook.css, wouldnt it be practicable to use an extension such as this. You can find samples here --Oblivious 11:12, 23 May 2006 (UTC)[reply]

My thoughts are that both would be used. We would modify common.css like I suggested above, which would allow us to color code without the PHP extension. The PHP extension would use the CSS styles to format the text, which would still allow users to customize it to their own tastes, or turn it off. If the extension did not support the language, we could still use the styles to manually format it.
As for Nagle's comment, there already is a ton of source code in Wikipedia, in articles like Java programming language, C++, Java syntax.--Max Talk (add) 15:27, 23 May 2006 (UTC)[reply]
I've written an extension ("codeblock") for Wikimedia at my own wiki that performs syntax highlighting in many languages. The regular expressions are editable right on the wiki. This is a lot more flexible than your solution, but requires software changes. Visit any article at http://literateprograms.org/ to check it out. You can also view the regular expressions. You can view the source of my extension, which is released under the same license as Mediawiki. Deco 21:23, 26 May 2006 (UTC)[reply]
It might turn out that it doesn't matter. The folks on MediaWiki talk:Common.css#Syntax highlighting proposal don't seem as eager for the idea.--Max Talk (add) 00:09, 28 May 2006 (UTC)[reply]

Whitespace handling

One thing that bothers me about how this wiki handles whitespace it handles newlines. One single newline is ignored and two newlines means a new paragraph, but once it becomes more newlines then it starts to behave odd. It starts to add <br/>s and paragraphs containing <br/>s. I think that the behvior is on purpose but I still think that it is odd. It's probably there to make one newline in the source to mean one newline in the html, but is that a behaviour the editors want to have?

What this behaviour means is that additonal empty lines between papragraphs in the source will show up when the html page is generated, which I don't think that most editors desire. It's not often one wants to force newlines (other than to separate paragraphs) and in those few cases I think that <br/> would do.

What I propose is that addtional line breaks other than the first two will be ignore. 100 empty lines will be the same as one empty line. But one single line break should be handled as now. I think that this is the way LaTeX does it and also what I think is easiest for the editor since he doesn't have to care exatly how many empty line he has between paragraphs. And this changes wouldn't affect the readers other than making the layout more consistent. Another plus would be that my suggest behaviour makes more sense than the current with skins that separate paragraphs in other ways than newlines.

I have been around Wikipedia for some time now and I haven't seen this discussed anywhere. I personally think it is a quite major issue since it is easy to add too many newlines between paragraphs. Is this a no issue? What do you think about my suggestion? Jeltz talk 15:27, 26 May 2006 (UTC)[reply]

I would agree strongly with this. Especially in the presence of templates, I often come across unsightly paragraph spacings that are larger than intended. They're rarely useful, and in those instances advanced users can bring in HTML tags. Deco 21:11, 26 May 2006 (UTC)[reply]
Yes, I agree that this is likely a good idea. More than two linebreaks can be added manually if desired. I do have to question why the software makes the assumption that a presentational double-<br /> is equivalent to a semantic <p>, though (try setting something like p { text-indent: 4em; padding: 0px; } in your personal stylesheet and see how many things look bizarre). —Simetrical (talk • contribs) 22:17, 26 May 2006 (UTC)[reply]
Haven't tried it myself and never thoguht of that way of styling (it's rare in html documents) Wikipedia until I started writing this proposal. Indented prargraphs should really look weird when users have extra linebreaks. It would also somewhat break the styles for users who have other margins between paragraphs than the default in their skins. Jeltz talk 22:53, 26 May 2006 (UTC)[reply]
I like this idea. I would add that HTML comments (the <!-- --> kind) should be ignored by any code that implements this to avoid strangeness. (It would also allow comments to be nicely formatted, instead of requiring careful placement of the opening and closing tags to avoid introducing unsightly whitespace as they do now.)
I would suggest that this section be linked to at or moved entirely to Wikipedia:Village pump (technical) to get the developers' attention. — Saxifrage 01:16, 27 May 2006 (UTC)[reply]

Landforms by country

Comments regarding a proposal at Wikipedia talk:Naming conventions (categories) that would make "in country" the naming convention for Landform by country categories would be very appreciated prior to a cfru. Kurieeto 22:24, 27 May 2006 (UTC)[reply]

Hello, all: I've written up Wikipedia:Quasi-protection policy, a proposal similar to semi-protection that would effectively limit sleeper accounts used to vandalize articles linked from the Main Page. I know that I've written a lot, and at first glance, the proposal may seem daunting. However, I truly believe that this would immensely improve Wikipedia and implore you to read it through and offer your thoughts on the talk page. Thanks! Flcelloguy (A note?) 22:49, 27 May 2006 (UTC)[reply]

Sections archived on 00:10, 5 June 2006 (UTC)

What about removing permanently the "redirect button" from the editing tools?

I'm asking for this action since I have the feeling Wiki users fail to see hidden information because of automatic redirection. A simple link to the page where the first page is redirected to would do better in my point of view, since you would always first stop at that word which you really entered. Different opinions? Suggestions? Have a nice day! --Tom David 16:18, 10 May 2006 (UTC)[reply]

You mean users should be forced to click an extra link on every alternate spelling or shortcut, rather than being automatically redirected? I don't follow. —Simetrical (talk • contribs) 03:17, 11 May 2006 (UTC)[reply]
Yeah, that's not working for me either. I think the fact that it says at the top of the page where you were redirected from is enough. —Mets501talk 11:09, 12 May 2006 (UTC)[reply]

Why this should be such a big problem to make one single click more? Yes I mean that the user should be forced to click an extra link. The information that one has been "redirected" is so small and almost invisible that every second user doesn't remark it. Well, think what you want. I don't like the automatic redirection. If you correct somebody always automaticaly, I'm not sure whether he will be able to correct himself one day on his own. --Tom David 07:44, 15 May 2006 (UTC)[reply]

In any case, you can always return to the redirect page by clicking the "redirected from" link just below the title. I think it makes more sense to keep articles easy to find by putting automatic redirections on pages with alternate spellings/names, and giving those users who wish to access the redirect pages a way to do so by using the "redirected from" link. The reason why its small is because people wouldn't normally need to access the redirect pages. I think we'll have to agree to disagree here :-) Andrew 22:55, 17 May 2006 (UTC)[reply]

I have the feeling that some articles you can't find because of the automatic redirection, especially if you are a fast user (then you don't see everything), but it looks like everybody has to make his own experience concerning "being automated" :) --Tom David 09:37, 18 May 2006 (UTC)[reply]

I have two points to make:
  1. Disabling automatic redirection would break several templates, whose transclusion links point to the redirect page.
  2. I find it incredibly annoying when I click on a page and get a double-redirect. I know that I could easily click the link, but it is unexpected and confusing for some.
--Max Talk (add) 03:27, 23 May 2006 (UTC)[reply]
People get redirected by web servers all the time, perhaps without noticing it. For instance, if you type en.wikipedia.org to your browser, the server redirects you to en.wikipedia.org/wiki/Main_Page. I suspect we'd all get real tired real fast if we had to click through something in that case, and I don't see how wiki redirect pages are any different. —johndburger 02:09, 26 May 2006 (UTC)[reply]

Well, if web servers are regarded as encyclopedias, ok. Nevertheless, clicking on a link is not the same as entering a word in a search mask. It's clear that links should always point to the correct address. Anyway, perhaps it's better if one doesn't need to click too many times. Just let's make sure not to bury something useful behind a redirection... --Tom David 17:34, 28 May 2006 (UTC)[reply]

Portal:Browse

duplicate post, answered at Portal talk:Browse, -Quiddity 09:26, 28 May 2006 (UTC)[reply]

Categorization of location

I have just created Wikipedia:Categorization of location, proposing a hierarchy of location-based categories. Once widely employed, these will allow the reader to quickly find articles about locations that are near that described by the article they're currently reading. All feedback welcome, as always. AxelBoldt 03:02, 28 May 2006 (UTC)[reply]

This is a fantastic idea! But create categories only as necessary: most of the planet is just water (and ice). I'm in full
support! -- Michael Janich 03:33, 28 May 2006 (UTC)[reply]

Sections archived on 00:15, 6 June 2006 (UTC)

Opt-in ads on pages

I suggest giving people the ability to have ads, such as google adwords. This would be good for 2 reasons, it would generate some more money to help run wikipedia, and often the ads are relevant and useful. I recomend that it be optional, and off by default, with something simple like a checkbox in preferences. I personally would turn them on as they are often useful, and people that dislike ads could choose not to turn them on (and unless they check their preferences every day, may not even know they can have them). A vertical ad block would fit quite nicely under the toolbox.

Absolutely not. Wikipedia has done fine with donations so far. Voluntary ads would only raise a small amount of money, but they could have a catastrophic effect on people's willingness to donate. I suspect that most donations come from the small minority of users who are registered (less than one percent based on comScore data), so these are the most essential financial supporters of the project. Bhoeble 13:45, 26 May 2006 (UTC)[reply]
Why can't it be tried? I don't think wikipedia is fine at all. The pages fequently take a long time to load if at all so I think it's worth a short. I personally would have ads turned off. I don't see how anything useful could come out of being advertised to whilst I read about intermediate filaments or whatever, but it doesn't harm me if someone else is using them. --Username132 (talk) 18:53, 26 May 2006 (UTC)[reply]
If ads are going to be turned on, I would tend to agree that they would have to be mandatory, at least for anons. If those were implemented, Wikimedia's budget would increase by at least several times even if everyone stopped donating. User:Robchurch estimated a billion hits a day for Wikimedia projects, and even at the pathetically low rate of one cent per thousand page views, that works out to about $3.8 million dollars a year, something over four times the current Wikimedia budget. I think server lag would become a nonissue at that point.

But a ton of people are virulently anti-ad, for some reason that's always baffled me, so the basically trivial income that voluntary ads would produce would in fact probably be outweighed by the backlash. —Simetrical (talk • contribs) 22:11, 26 May 2006 (UTC)[reply]

Advertising corrupts. It is extremely difficult to maintain neutrality in any medium supported by advertising.Dpbsmith (talk) 00:43, 27 May 2006 (UTC)[reply]
Agreed. It's hard enough keeping spammers out of our articles now-- imagine them saying "Whadaya mean I can't add my external link to this page-- I'm paying for this site!" There's no such thing as free money. -- Mwanner | Talk 01:03, 27 May 2006 (UTC)[reply]
But wikipedia wouldn't need to advertise spammer's services? I don't see why wikipedia would need to bend over backwards to maintain sponsorship - they pay, they get a space on the website and nothing more. They mess around/try to influence the things that go on, they're gone and let someone else who wants the space have it. Plus it'd be further incentive for anonymous users to register. --Username132 (talk) 11:09, 27 May 2006 (UTC)[reply]
Using Google AdSense to deliver relevant ads would be good for Wikipedia. These ads would be useful for users. For example, if I went to the Free web hosting service article, the ads could suggest me some free web hosting services. Some people would go to the webmail article, for example, to find a webmail provider. In addition, Wikipedia could form a partnership with Google. What about Google Wikipedia Search? --J.L.W.S. The Special One 15:58, 27 May 2006 (UTC)[reply]
You're kidding, right? Like it's really difficult to find Free web hosting services or webmail providers? Wikipedia does not need to be a replacement for Google and other search services-- they're good at what they do, we're good at what we do. -- Mwanner | Talk 16:15, 27 May 2006 (UTC)[reply]
I don't think wikipedia is quite good at what it does. For example on this university internet connection where I've seen download speeds in excess of 800 kbit/s, it took 10 seconds for this edit page to load. If wikipedia has got the money, spend it; if not, get it (and then spend it). --Username132 (talk) 14:39, 28 May 2006 (UTC)[reply]
I don't see any way that advertising could possibly corrupt Wikipedia. You do understand how AdSense works, right? We get advertisements, no question (Google will never threaten to withdraw ads based on our content; they just ensure we don't cheat). Advertisers could, in theory, withdraw their ads from being displayed on Wikipedia, but a) there are so many AdWords customers that it would probably make a negligible difference, and b) we, the editors, are not receiving money under any circumstances, so it wouldn't significantly affect our judgment. Similar schemes exist in all reputable ad-using services: the authors are completely separate from the advertisers, and neither know nor care what ads will end up in their product. Admins who ban people for posting spam will have no interest in whether the advertiser withdraws money, providing policy says to ignore such threats (possibly add it to WP:NLT, in fact). —Simetrical (talk • contribs) 05:21, 29 May 2006 (UTC)[reply]

Prioritizing Wikipedia cleanup

I'm fairly active in trying to copyedit the massive amounts of articles at Category:Wikipedia articles needing copy edit and I've found that there is no good way to prioritize them; no way to know which ones have been unchanged the longest. So I looked around the whole Cleanup section and the closest we have to that is {{cleanup-date}} which is still limited to the month. So I was wondering if Wikipedia had DynamicPageList, and it doesn't. There is a modified version of the DPL called DPLforum that was originally made to be a forum. However, at Uncyclopedia, we also use it for the categorization of maintenance articles. They can be sorted by last edit, and provide a link to the page, the history, and display the last author. I think that this would help with prioritizing cleanup, but I recognize it is not the most efficient way of doing this. I'd like to propose that Wikipedia install an extension like this one for automating cleanup and such. I can easily contact the author of the extension if modifications are proposed, and if someone wants to write an extension similar but more effective (and less intensive on the database), that'd also be appreciated. Thoughts? --Keitei (talk) 08:47, 28 May 2006 (UTC)[reply]

You could probably download a database dump and come up with a suitable SQL query. There's also Special:Ancientpages. Deco 10:20, 28 May 2006 (UTC)[reply]
Thanks, but that's not what I was asking. I want to know what people think about using DPLforum on Wikipedia. </clarify> --Keitei (talk) 09:44, 29 May 2006 (UTC)[reply]

replace "recent changes" link with "new pages"

I thought it might be more useful to have "New Pages" easier to click on at the top left. Recent changes is useful to have in a smaller wiki where theres only a hundred or so changes a day, but whats the point in having it there to see hundreds of changes every minute? --Astrokey44 03:29, 29 May 2006 (UTC)[reply]

If you're interested, you can change that in your personal .js. It'd take a lot of deliberating to have it changed for everyone, but you can try it out now! :] Add the following lines to your personal .js (User:Username/skinname.js), such as User:Astrokey44/monobook.js, and then do a hard reload.
window.onload = Main;
function Main() {
    changenavbox();
}

function changenavbox() {
    document.getElementById('n-recentchanges').firstChild.innerHTML = 'New pages';
    document.getElementById('n-recentchanges').childNodes[0].href = 'http://en.wikipedia.org/wiki/Special:Newpages;
}
It's actually easier to change for the whole site, but there'd need to be a lot of consensus. :] --Keitei (talk) 13:44, 29 May 2006 (UTC)[reply]
thats cool I didnt expect a solution so quickly. though I changed it but it doesnt seem to be working. did I get it right? I held down shift while refreshing in firefox and it still says recent changes --Astrokey44 15:56, 29 May 2006 (UTC)[reply]
Try Ctrl-F5 instead (shift may also work but I always use the Ctrl method). At the least you'll need to hard-refresh your user JS, but you may also need to hard-refresh a page you want to see the change appear on. Also be sure you used "monobook" rather than "Monobook". GarrettTalk 22:43, 29 May 2006 (UTC)[reply]

Computing Reference Desk

I feel that Wikipedia is in dire need (ok, not quite) of a computing reference desk, simply called, the computing desk, (not Computer Science or whatever) because of the immense number of programming language questions and people requesting advice on purchases, using the Science and Mathematics Reference desks out of lack of alternatives. It is not easy to find a suitable place to ask a computing question to a first time wikipedian, and as such, they tend to be distributed across all the desks... Simply make a computing desk. --Eh-Steve 05:01, 29 May 2006 (UTC)[reply]

I agree that this would be useful, but would it be specifically about programming or would we be spammed with "I need to use powerpoint for a presentation HELP!!!!"? Well, the spamming would probably happen either way, so rather, would we allow those questions? I'm not sure that we're prepared for an onslaught of PEBKAC questions, but I'm all for it anyways. :] --Keitei (talk) 13:56, 29 May 2006 (UTC)[reply]
Whoops, apparently PEBKAC is an insult. I just mean questions which are such that it is difficult to answer through wiki or online even, due to it being a problem of perception or assumption, and not with the computer. --Keitei (talk) 15:31, 29 May 2006 (UTC)[reply]


I suppose it would be for all computing questions, including the mundane powerpoint advice questions. But I think it should be turned into a project ASAP --Eh-Steve 18:35, 29 May 2006 (UTC)[reply]

Sections archived on 00:17, 7 June 2006 (UTC)

This is a proposal for the purpose of making it easier to identify the edit revision in an article's edit history at which point it has received/lost its featured status.--Conrad Devonshire Talk 04:28, 30 May 2006 (UTC)[reply]

Sections archived on 00:12, 8 June 2006 (UTC)

Forums

Its difficult to continue discussions on wikipedia and some dedicated forums that kept a list of links ("subscriptions") where I had posted would be valuable and stop me from having to look for the page I'd posted on (usally a few clicks in itself), scroll down the TOC for the thread I posted on and then, scroll down to see the most recent comments. I keep leaving messages and forgetting where I left them and I leave so many messages in so many different places, it's difficult to continue discussions. I may very well not make it back here to read people's negative responses and argue my point... --Username132 (talk) 17:51, 26 May 2006 (UTC)[reply]

In my opinion this is but one of many problems that would be solved by modifying the software to organize talk pages as message boards. Our culture is already so strongly against editing or deleting the comments of others that it makes little sense to give us the flexibility to do so, and we spend altogether too much time dealing with manual archiving and formatting our responses with appropriate indentation and so on. Wiki just doesn't make sense for discussion pages like this. Deco 21:07, 26 May 2006 (UTC)[reply]
I have to agree, but it's going to be low-priority. It's just too much work for something that works now (albeit imperfectly). —Simetrical (talk • contribs) 22:19, 26 May 2006 (UTC)[reply]
The advantage of the current system is that it does make that you have to learn wiki markup. Garion96 (talk) 22:36, 26 May 2006 (UTC)[reply]
It's a lot of work yes, but it's one-time work by a few people that produces an ongoing benefit for many people. As for wiki markup, there's no reason it can't be used within messages. I'm considering implementing a prototype of this sometime on my own Wikimedia server - maybe they'll take a patch from me. As for vandalism, I think letting admins delete messages is probably sufficient - it doesn't really matter how long it sits around on talk pages, they're not the "product". Deco 00:25, 27 May 2006 (UTC)[reply]
I find that discussions on Wikipedia are very difficult to follow and too long. I think there should be some sort of threading system. Or we could have a Wikipedia forum hosted on Google Groups (I wrote the Google Groups article - please give feedback at Wikipedia:Article Feedback Desk). I will be happy to own/manage the group. --J.L.W.S. The Special One 15:54, 27 May 2006 (UTC)[reply]
The devs have rejected usage of a forum as too unsecure for our purposes. (Although maybe this was just specifically meant for phpBB.) Anyway, the current system works fine IMO. If it ain't broke, don't fix it. Shouldn't this be among the perennial proposals anyway? Johnleemk | Talk 16:12, 27 May 2006 (UTC)[reply]
It seems silly to assert that a discussion board is insecure (although phpBB might be) - it's just a different interface that provides useful functions for organizing and navigating discussions among people, which is what we do on talk pages and discussion pages. The current system is workable, but has an array of disadvantages:
  • It's difficult for new users to use. How many times have you seen an anonymous user post something at the top of a talk page, or misformat a reply, or screw up merging an edit conflict, or forget to sign their post using the magic tildes?
  • It's annoying to painstakingly correctly format replies, especially with nontrivial formatting, or when the replies get deeply nested and the indenting has to be "reset". In large threads it's soon impossible to tell who is reply to who.
  • Pages become very large very quickly and have to be manually archived, requiring constant attention, otherwise they become too slow to edit. A forum interface would allow deeply nested replies to be hidden and only recent posts to be displayed.
  • A forum would be user configurable so a person could choose whether to view recent or old posts at the top, how many recent posts to display, how deeply nested replies to view. It would allow them to watch threads of interesting to them (rather than just entire pages), highlight their own posts, get e-mail notifications of updates, and so on.
  • A forum would not have edit conflicts. The concurrent replies would just be simultaneously attached to the thread.
  • Discussion pages are ugly, which makes them even less pleasant and more difficult to read.
In short, yes, it is broken. Yes, we should fix it. I barely even use forums but the advantages are painstakingly obvious here. Deco 21:04, 27 May 2006 (UTC)[reply]
As a frequent user of forums and someone who programmed a barebones forum myself, I disagree - for our purposes on Wikipedia, talk pages work better because they are organic. And as I alluded above, this is indeed a perennial proposal. Johnleemk | Talk 10:23, 28 May 2006 (UTC)[reply]
An idea isn't bad, just because its been suggested before. The current system of talk pages is a total mess. It's rediculously wasteful to have to watch a talk page with lots of unrelated edits, so that one can see the single reply to a message of interest. Plus, the current system, just can't scale properly. When lots of people are editing at the same time, you get those stupid "edit conflicts", which is silly. I'm not editing another person's text, so I shouldn't get an edit conflict. Also, we have absurd expectations of newbies, to be able to understand how things work. --Rob 10:53, 28 May 2006 (UTC)[reply]
I understand if you take that perspective, but really, while we may edit our own posts, or occasionally reformat threads, most of the time we treat it like a message board anyway - flexibility you don't use isn't useful. But the proof is in the pudding - eventually I'll get a prototype of this going and see how that works. Deco 12:06, 28 May 2006 (UTC)[reply]

How long until we can vote on it? I really think more people would welcome the change than oppose it. The discussion functions are the worst thing on wikipedia (or maybe co-worst with the slow page-loading that sometimes occurs). --Username132 (talk) 14:49, 28 May 2006 (UTC)[reply]

I don't think a mere vote is adequate for such a disruptive and difficult software change. It needs to be first established as effective in at least one case study external to English Wikipedia. Deco 08:08, 29 May 2006 (UTC)[reply]
When do you estimate your prototype to be ready? --Username132 (talk) 11:22, 29 May 2006 (UTC)[reply]
I'm afraid it'll probably be a while. I'm just one person and got lots of other things to do. Deco 23:26, 29 May 2006 (UTC)[reply]
I'd suggest you post at Mediazilla:1234 to note that you're taking up the bug, if you plan to seriously work on this (even if it's a long timeframe). I doubt the devs are going to suddenly take this up, but it's good to keep people informed to minimize the risk of duplication of effort. —Simetrical (talk • contribs) 05:54, 30 May 2006 (UTC)[reply]
Thanks for the link and the suggestion. Deco 23:57, 31 May 2006 (UTC)[reply]

Thingy with Warhammer 40,000 Imperial Guard section

If saberwyn reads this I just hope he accepts my sincerest apologies. I should have been more careful about reading the policies and it was stupid of me to add this article without consulting those policies. In my defense, this was my first article and I was rather enthusiastic. I'm really sorry for the mess. Sqrlaway 01:07, 31 May 2006 (UTC)[reply]

No need to apologize...mistakes happen to the best of us. Alas, it has even happened to me! Btw, if you want just Saberwyn to read this, its a good to drop a message on Saberwyn's talk page. --Osbus 01:55, 31 May 2006 (UTC)[reply]
Ok, thank you.

Sections archived on 00:10, 9 June 2006 (UTC)

Proposal: Articles with featured article status are automatically semi-protected

As Wikipedia moves towards being a more and more finished encyclopedia in many of its articles; it would be useful not to waste as much energy fighting off vandals. i recommend Articles with featured article status are automatically semi-protected. 4.250.132.134 15:44, 27 May 2006 (UTC)[reply]

User:Raul654/protection. Johnleemk | Talk 16:24, 27 May 2006 (UTC)[reply]
Also, featured articles are not strictly the ones on the Main Page, so this is even less desirable in that respect.--Sean Black 17:23, 27 May 2006 (UTC)[reply]
See also Wikipedia:Static version and Wikipedia:Stable versions, two similar but much broader proposals. Vandalism is a pain but usually quickly reverted - more problematic is well-meaning but misguided edits which degrade an article's quality over time. Worldtraveller 01:31, 28 May 2006 (UTC)[reply]
Who says Wikipedia is moving towards "being a more and more finished encyclopedia"? Reminds me of the 19th century patent office official who proposed closing the patent office since everything possibly invented had already been. User:Zoe|(talk) 01:40, 28 May 2006 (UTC)[reply]
If we semi-protect our best (and most popular) articles (and the ones newbies are most likely to see), we may as well semi-protect the whole encyclopedia. Not necessarily a bad idea... Captainj 17:33, 29 May 2006 (UTC)[reply]
Only semi-protect those articles linked to from the Main Page. Pcu123456789 01:34, 1 June 2006 (UTC)[reply]

For Warhammer 40,000...

Everybody probably still remembers me as the kid who screwed up on the Imperial Guard article, but I just thought it'd be neat if somebody ran an article on the big Dark Crusade campaign that started recently, like what it's about and a basic storyline... any volunteers? Sqrlaway 11:31, 31 May 2006 (UTC)[reply]

We didn't know you were a kid then. Was that screw-up what started the infamous headlong retreat in disarray and chaos of the Imperial Guard at the Battle of Waterloo, lighting a panic running through the French lines ("The Guard retreats. Save yourself if you can!"), thereby leading to the total French defeat? Anyway, that is history, and we're willing to forget it. Hopefully you've grown up since. --LambiamTalk 13:49, 1 June 2006 (UTC)[reply]