Wikipedia:Village pump (proposals)/Archive 13

Village pump
- Policy
- Technical
- Proposals (persistent)
- Idea lab
- WMF
- Miscellaneous

Village pump (proposals) archive

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Make it easy to remove external links

Hello, Im kind of new here but I am trying my best to make wikipedia a better place. I was told that one way to help out was removing pointless youtube links. After doing it for a while I thought make it easier to delete external links. After about the 100th time of having to listen to a crappy garage band youtube link and then having to search the article to find it I was getting sort of bored. Why not make it so external links can be removed right from the http://en.wikipedia.org/w/index.php?title=Special%3ALinksearch&target=www.youtube.com page. This feature could only be allowed by asking permission from an admin. It would make it a lot easier to keep track of irrelevant pointless links. Thank You for your time and have a Happy New Year!! KingsOfHearts (talk) 18:10, 31 December 2007 (UTC)

I think that would be a bad idea, because it pulls the editing away from the context of the article. In some (admittedly rare) cases there might not be pointless and these might get accidently removed. The editorial proces should preferably always be part of our methodology when working on these kinds of issues. --TheDJ (talk • contribs) 14:46, 1 January 2008 (UTC)

I think it would be useful mainly to remove youtube links which have been placed on a ton of pages were there is no need for them. KingsOfHearts (talk) 15:07, 1 January 2008 (UTC)

Disparity between signature (~~~~) toolbar buttons and character map

The toolbar button for signatures provides: --~~~~ while the sign your username in the character map (below the edit box) provides ~~~~. Is there a reason for this incongruence or is it just something that was overlooked? I'd like both options to be consistent, with both producing the full --~~~~, since the two dashes serve to warn a reading user that they have reached the end of a post and should pull-up to avoid collision. --Seans Potato Business 13:04, 1 January 2008 (UTC)

I think that in the toolbar the '--' should be removed actualy. Many people have allready eddited their signatures to include preceding dashes and some people would not want proceding dashes at all. -Icewedge (talk) 16:03, 1 January 2008 (UTC)

Oh when will this madness end?! --Seans Potato Business 19:30, 1 January 2008 (UTC)

I've filed bugzilla:12472 about this. Please comment there. —Remember the dot ^(talk) 20:00, 1 January 2008 (UTC)

I wasn't sure if I had anything relevant to say so I just voted for it. --Seans Potato Business 21:04, 1 January 2008 (UTC)

The developers tend to ignore bug reports unless people make a fuss about it, so additional comments on bugzilla would be welcome. —Remember the dot ^(talk) 21:53, 1 January 2008 (UTC)

Done. I hope Icewedge joins in the fun. :0 --Seans Potato Business 01:05, 2 January 2008 (UTC)

There is no need to waste the developers time, this can be delt with by any admin. The source for the panel below the page can be found at MediaWiki:Edittools, I am not sure exactly where the source for the buttons above the page can be found, you will have to ask someone else for that. -Icewedge (talk) 02:25, 2 January 2008 (UTC)

The extra toolbar buttons are generated by JavaScript in MediaWiki:Common.js. However, I believe the signature button is a standard button from within MediaWiki. The fact that there is a MediaWiki:sig_tip message would seem to support that. I think the code for that button would have to be modified by a developer, or somehow overridden by JavaScript from the wiki pages (I don't know how to do that). Tuvok[^T@lk/_Improve] 03:05, 2 January 2008 (UTC)

RFC closed, and a new proposal

I have closed Wikipedia:Requests for comment/Wikipedia:Requests for adminship, as agreed on Wikipedia talk:Requests for adminship. Since I don't know how this process is supposed to work, I may have done it wrong. If my closing comments belong at the bottom of the page and not the top, then anyone is free to move them.

Based on a suggestion at the RFC by TomStar81 and Warlordjohncarter, I have started a proposal at Wikipedia:Requests for adminship/Proposal to add a discussion period before voting begins. Please comment on that proposal's talk page.

I hope everyone will understand that my decision to close the RFC is not "the last word". My goal was to summarize the suggestions that were made, and to observe that none of these suggestions has garnered consensus. Further discussion is welcome, as always, in the usual forums. With best wishes for a happy new year, Shalom (Hello • Peace) 18:24, 1 January 2008 (UTC)

Black Wikipedia

Why not have an edited black colored wikipedia to conserve energy? google has blackle. why not have wikiblack.com or blackipedia.com. just a suggestion for all of us who would like to help save the environment slowly but surely :P —Preceding unsigned comment added by 75.86.146.156 (talk) 21:52, 18 December 2007 (UTC)

This is relatively easy to do by using user CSS pages to change the colour. Most of the interface on Wikipedia has CSS classes attached to it. Any registered user has a personal user CSS page (such as mine at User:Nihiltres/monobook.css), or I believe that there are ways to achieve the same effect while using Firefox. If you don't know how to write CSS, there's a guide on Wikibooks. Nihiltres^{t.l} 22:25, 18 December 2007 (UTC)

Also, note that Blackle is not technically affiliated with Google. Mahalo. --Ali'i 22:30, 18 December 2007 (UTC)

Very interesting idea! I know it has been briefly discussed previously, on the Tech. VP I think. Maybe this should be easy as changing your skin, rather than manually adding code to the CSS. - Rjd0060 (talk) 22:47, 18 December 2007 (UTC)

This has been proposed several times, and it might be worth it for Wikipedia's graphical designers to collaborate and create such a skin. Gracenotes^T § 00:47, 19 December 2007 (UTC)

Check your facts. I thought I saw someplace that black consumes more electricity on some displays. LCDs, maybe? -- SEWilco (talk) 01:55, 19 December 2007 (UTC)

LCDs use a little bit more power to display black than to display white, somewhere in the nanowatt to microwatt range. If you're worried about power consumption, consider that the electricity used to debate black versus white is greater than the power saved by a "low power" colorscheme. Consider also that one person turning off their computer for the night will save more power than an entire city switching to such a colorscheme for their computers. --Carnildo (talk) 05:51, 19 December 2007 (UTC)

PPPhhhheeeewwww, for a second I thought this was a proposal to introduce apartheid on Wikipedia... A ecis^Brievenbus 18:19, 20 December 2007 (UTC)

One can save more electricity by simply typing faster then turning the computer off. Remember, less consumption uses less energy than recycling. Archtransit (talk) 19:34, 20 December 2007 (UTC)

It also saves a lot of effort to ridicule a proposal rather then discussing it's merits. I for one wouldn't be opposed to adding a black style css. Martijn Hoekstra (talk) 19:43, 20 December 2007 (UTC)

How about giving users the opportunity to choose their own background colour? Some might prefer orange, others might prefer green, etc. A ecis^Brievenbus 20:19, 20 December 2007 (UTC)

Suggesting to wiki users that they may help the environment by using a black backgrouond is contrary to the purposes of Wikipedia, i.e. to disseminate free knowledge. (I haven't checked, but I believe the posts above saying your savings are marginal or negative.)--Niels Ø (noe) (talk) 21:22, 21 December 2007 (UTC)

How is it contrary to disseminating free knowledge? A ecis^Brievenbus 23:40, 23 December 2007 (UTC)

Yeah Niels, I'd like to hear more on that one too. Being environmentally conscious is no different than being socially conscious.

Equazcion •✗/C • 23:58, 12/23/2007

This is pointless for energy reasons. Black websites saving energy is a semi-myth. Some TFT monitors actually use more energy to display black. CRTs use very slightly less energy to display black, but it's really a tiny amount we are talking about (a few watts). CRTs are also being very rapidly replaced in most countries by TFTs. Doing it for accessibility reasons might be more valid. As someone who gets migraines a lot, I do prefer dark UIs slightly. I don't feel strongly enough about it to support this though. If I did care, I'd just override the CSS on my end. Gigs (talk) 13:46, 28 December 2007 (UTC)

You'd save far more energy by turning down the brightness of your backlight one level. Displaying solid white requires only a tiny bit more energy than displaying solid black. This is microoptimization. Dcoetzee 18:50, 2 January 2008 (UTC)

Reminder page for unregistered users

"Please make sure your entry is supported by a valid or referenceable source. Thank you for helping improve Wikipedia."

(Or ending with, "Thank you for helping keep Wikipedia reliable.")

How about a page that appears for unregistered users when they click "edit". The friendly note says what is expected, and then redirects to the edit section. --Boozerker (talk) 10:40, 30 December 2007 (UTC)

A notice is a good idea, but redirects are annoying, and they rely on Javascript (usually), which is an accessibility issue. I would rather it be some large bold highlighted text on the edit page somewhere, rather than a redirect. Equazcion •✗/C • 10:59, 30 Dec 2007 (UTC)

Honestly, MediaWiki:Anoneditwarning is already 4 or 5 times longer than it needs to be.. adding anything else to it flies in the face of m:Instruction creep.--69.118.143.107 (talk) 22:44, 30 December 2007 (UTC)

That sentence isn't overkill. But why not just fix the MediaWiki:Anoneditwarning as shown below?

__(begin)...

"Please make sure your entry is supported by a valid or referenceable source. Thank you for helping keep Wikipedia reliable."

Since you are not logged in, your IP address (which is linked to its originating network/corporation) will be logged in this page's edit history. It is sometimes possible for others to identify you with that information. If you create an account, you can conceal your IP address and get other benefits. Messages sent to your IP (rather than username) can be viewed on your talk page.

Please do not save test edits. If you want to experiment, please use the sandbox.
___..(end) --Boozerker (talk) 18:31, 1 January 2008 (UTC)

Would you want to scroll through 8 lines of text every time you went to edit a page?--69.118.143.107 (talk) 20:55, 1 January 2008 (UTC)

Not quite accurate. My fix has the same number of lines as currently exists in the MediaWiki:Anoneditwarning page, but it's easier to read and even has two blank lines where the current page has just one blank line. See the next entry below. --Boozerker (talk) 21:39, 1 January 2008 (UTC)

__(begin)...
Please make sure your entry is supported by a valid or referenceable source. Thank you for helping keep Wikipedia reliable.

Since you are not logged in, your IP address (which is linked to its originating network/corporation) will be logged in this page's edit history. It is sometimes possible for others to identify you with that information. If you create an account, you can conceal your IP address and get other benefits. Messages sent to your IP (rather than username) can be viewed on your talk page.

Please do not save test edits. If you want to experiment, please use the sandbox.
___..(end) --Boozerker (talk) 21:39, 1 January 2008 (UTC)

How bout "Please don't be a jackass. We know where you live." Equazcion •✗/C • 21:42, 1 Jan 2008 (UTC)

:) On another note, we could make it so that readers could toggle a hide/show box link on and off, so if you don't want to read it again, then shrink the info by clicking it and to read the info later click it again.

You could make the entire MediaWiki:Anoneditwarning just three lines or fewer if we link to the appropriate pages for more info. For example, instead of defining what it means for your IP to be shown, frame the warning as follows.

__(begin)...
Since you're not logged in, your IP address will be shown. To avoid this, see here.
___..(end)

The bolded parts would be links. The first takes users to our policy for unregistered/registered users, and the second link explains the privileges a user gets from registering. Heck, one link could explain both.--Boozerker (talk) 22:06, 1 January 2008 (UTC)

Agree about letting people hide the notice -- no reason they'll need to see it more than once (at least per session). This notice is pretty good but I have doubts that people will actually follow the links. Might be better to spell it all out right in the notice, especially if we're giving them the ability to hide it. I still like my version best though, as it's the most concise. Equazcion •✗/C • 17:22, 2 Jan 2008 (UTC)

Allowing people to hide the notice would require setting cookies to a lot of anonymous users. This would cause a significant performance impact because whenever a request is made to the servers with a cookie, the cache layer would automatically be bypassed bringing increased load on servers. Tra (Talk) 17:44, 2 January 2008 (UTC)

I'm not sure why the cache layer would be bypassed in those instances, but if so, it would only happen for the anonymous users who edit, and only when they click the edit button. There's no other time during their session when cookie data would need to be checked. Equazcion •✗/C • 17:53, 2 Jan 2008 (UTC)

I'm not 100% sure exactly why it causes problems but it does. I think what happens is that all en.wikipedia.org cookies are sent on every page load, whether they're needed or not, and when the request gets to the cache layer, it sees that cookies exist and automatically assumes that the page that's displayed needs to look slightly different to what anons see usually, therefore casing the request to be sent to the servers that handle logged-in users, and the extra load on those servers may get too much. Tra (Talk) 18:05, 2 January 2008 (UTC)

Okay, I don't entirely get it but it certainly does seem to be a problem. Oh well... Equazcion •✗/C • 18:36, 2 Jan 2008 (UTC)

They don't need to follow the links, since it's pretty much spelled out by "Your IP address will be shown." But if more is needed, then change it to "Your computer's general location will be revealed for others to view. To avoid this, see here." Again, the bold parts would be the links. --Boozerker (talk) 18:37, 2 January 2008 (UTC)

Section 0 (article lead summary) edit shortcut on article?

Section edit refers to editing a particular section (separated by a heading dividor such as two or three "=" marks.). All sections other than the summary have an [edit] link in the article, allowing an editor to click it and edit that section only. It allows the author editing only the section they need, reduces chance of edit conflicts (as opposed to both editors editing the entire article), makes tracking changes easier, and reduces WP bandwidth load.

However, the very first section, which is the "summary" section, the section above any headers, and titled "section 0", does not have a quick edit link. You can still go there manually by typing &section=0 at the end of the edit link, but the quick shortcut is missing. I also know you can change skins or add javascript or use a FF addon or whatever to make it visible, but the point is that the majority of WP editors won't have the link, and most of whom either won't know it even exists or will not bother typing the URL. These editors will then have to use the full article edit link at the top of the page, bypassing all the benefits of section edit outlined above.

Why not add an [edit] link to the summary section? Place it right under the article name. Here's a proposed way of how it looks.

http://img195.imagevenue.com/img.php?image=35619_edit_122_347lo.jpg (if someone registered wants to reupload this image to WP, feel free)

Since the proposed lead section "edit" link is in a separate place from the full article edit link, is worded differently from it, and worded similar to all the other inline "edit" links (such as other sections as well as templates), I don't think there'll be ambiguity that this edit refers to the summary and not to the whole article like the top link, to anyone experienced enough to know what the other inline "edit" links mean.

Consider the fact that since the summary section is most visible and read first, more people will read (and be inclined to edit) the summary section than any other section. Adding a convenient summary "edit" link should thus be most beneficial compared to full page edit, than any other edit link in the page. 24.83.195.130 (talk) 01:13, 2 January 2008 (UTC)

I believe one of the "gadgets" recently added to Special:Preferences will do just that. Unfortunately, you'd need to register to use it. In terms of adding it for all users, would the distinction between "edit the lead section" and "edit the entire page" be clear? – Luna Santin (talk) 01:15, 2 January 2008 (UTC)

Just as a side note, there has been a bug about this in Bugzilla for a long time (since August 2004). See bug 156 in the Wikimedia bug tracker. Tuvok[^T@lk/_Improve] 01:33, 2 January 2008 (UTC)

There are also several scripts at Wikipedia:WikiProject User scripts/Scripts#Scripts that do this, displaying the link differently. –Pomte 01:44, 2 January 2008 (UTC)

Malay wikipedia uses a tab with an up arrow ↑ on it for the interface. This is in their site javascript; which would at least enable it for anons who can use javascript. Should probably be added to mediawiki itself to enable it without js, though. —Random832 16:34, 2 January 2008 (UTC)

That's actually not a bad interface, Random832. Want to suggest it at the Bugzilla entry I mentioned, or should I? Tuvok[^T@lk/_Improve] 18:57, 2 January 2008 (UTC)

"Cite web" template needs "authors" parameter

At present the "cite web" template does not appear to accept an "authors" parameter, only "author". I discovered this when I noticed that a ref for which I'd specified "authors" did not show the names. Of course the work-round is to use "author". But supporting "authors" would help editors by making citation templates more consistent. Philcha (talk) 13:52, 2 January 2008 (UTC)

Well I don't know enough about templates to put in the redundant information, but {{Cite web}} also has a parameter co-authors which allows the same functionality. I don't know what you mean by consistent, as {{citation}}, possibly one of the most basic citation templates around, doesn't seem to declare a paramter of authors. --Ybbor ^Talk 17:00, 2 January 2008 (UTC)

current events needs better supervision

The quality of Portal:Current events is dropping in my personal opinion, especially where it concerns things that are not about the last 7 days. I think its time we started doing something about it, and you are invited to discuss it here. --TheDJ (talk • contribs) 18:11, 2 January 2008 (UTC)

Add link to Wikipedia:Upload for uploading logos

I've requested at Wikipedia talk:Upload#Please add "logo" to the list to add an option to the upload form for uploading non-free logos. This change would bring us one step closer to making sure that logos are uploaded with all the necessary information. —Remember the dot ^(talk) 01:24, 3 January 2008 (UTC)

WP:Reference Desk should be split off into its own separate project

I finally discovered Yahoo! Answers today, and frankly while playing with it I feel that I'd rather use the Reference Desk. Unfortunately, nobody knows about the Reference Desk because it is cloistered away in the nether regions of W: space. Making the Reference desk into its own specific project will bring several benefits: other than higher profile it will also enable us to dedicate a different page for each question, which will make formatting a little easier than it is now. 211.25.16.132 (talk) 01:26, 28 December 2007 (UTC)

The Ref Desk is mentioned already in the Main Page, under "Other areas of Wikipedia." bibliomaniac 1 5 01:31, 28 December 2007 (UTC)

It is also listed in the Department directory and has a place in the help toolbar (a series of links at the top of help-related pages). Waltham, The Duke of 02:10, 28 December 2007 (UTC)

Ultimately, whatever the merits of the proposal, creation of seperate projects is an issue that needs to be discussed at Meta, specifically m:Proposals for new projects. GRBerry 02:32, 28 December 2007 (UTC)

I believe the original intention of the Reference Desk was that if you wanted information on something which WASN'T in Wikipedia, but should be, you asked there. Really, it needs maintenance so that questions which ARE answered within Wikipedia get deleted, and questions which aren't, upon being archived, are transferred to their respective articles. So in that way, it is an integral part of Wikipedia. -- Chuq (talk) 02:43, 28 December 2007 (UTC)

The Reference Desk has been controversial in the past - many editors didn't think it really helped the project. A large percentage of questions are for practical advice ("how do I do ..."); because Wikipedia is not a how-to guide, most of the answers are therefore not appropriate for articles. My (personal) sense of the matter is that the RD remains in place because (a) some people like to work there who wouldn't otherwise work at Wikipedia at all; and (b) the ability to say "go to the RD" rather than "go away" is a plus for the project, when irrelevant questions show up on pages, in terms of how editors feel about the project, and in terms of recruiting editors (whose first experience may have been getting an answer at the RD).

Having said all that, I don't think that the RD should be given any more prominence than it is now. We really don't want the first thought of people when someone says "Wikipedia" to be "That's the website that has the great free service for getting questions answered." And as for a separate project, the Wikimedia Foundation exists to generate free content for the world; I don't think the Foundation board - which has to approve all new projects - would see an answer-providing service, particularly one in direct competition with other websites, as being within their mission. -- John Broughton (♫♫) 13:41, 28 December 2007 (UTC)

Ah, that kind of project... I initially thought of WikiProjects! Well, no. No, no, no, and again no. I fully agree with Mr Broughton here: the Reference Desk is a complementary feature of Wikipedia, the last bastion of defence against futile searches that have not yielded results either because the reader has not been able to search well enough to find them on their own or because the relevant information is not in Wikipedia at all. As in real-world buildings, the reference is near the exit—only that, in contrast to them, it is not the entrance as well. And, besides, one would think that a side of a project is already high-profile enough to split off its parent. I should not say that the Desk has ever been especially prominent. Waltham, The Duke of 14:32, 28 December 2007 (UTC)

The Reference Desk does generate free content as all the answers are GFDL licensed. Christopher Parham (talk) 14:57, 28 December 2007 (UTC)

There have been a number of cases in which information provided at the RDs has been used to update and, in some cases, create brand new articles. In particular, much of the information provided by User:Clio the Muse goes into Wikipedia articles, because Clio does not edit articles. In addition, it's frequently used when people are trying to find something but can't find the place within Wikipedia where the information might be available. Corvus cornix_talk 17:42, 28 December 2007 (UTC)

And I, for one, certainly support the continued existence of the RD, in its present form. I'm glad to hear that editors who answer RD questions are adding information from answers to Wikipedia articles, when appropriate; that's a good reason - though, I think, not the strongest argument - for keeping the RD in place. -- John Broughton (♫♫) 15:58, 30 December 2007 (UTC)

John, can we clarify one point. The mission of the WMF is "Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment". It is definitely NOT to just generate free content. If it's mission were to simply generate content, then we might as well pack up shop now as the Googles of this world could duplicate everything done up to date in weeks, and provide access to content at much higher speeds, probably with much nicer interfaces. Thankfully, although many commercial orgs would like to think it, knowledge is not just about "delivering objects". It's about sharing an understanding. I.e. answering a question.

I think our anonymous friend might not have chosen the right words here. What might have made more sense is to say "the reference desk should incorporate all WMF projects". They are, after all, one part of a larger library. All we're talking about then is how we are to classify its contents to become most useful. As far as answering questions, I think the WMF must start to reach out a collaborate with other non profits if it is going to attempt it's impossible dream. This is just one obvious one. Note The para about the Global Reference Network. Seems that the WMF already has encouraged the network, but it could sure use some more good reference librarians.--Simonfj (talk) 23:23, 3 January 2008 (UTC)

Creating a shortcut to automatically substitutes a template

I have been kicking this around for awhile unsure how to proceed. Regarding templates that must or should be substituted (such as {{prod}} or {{uw-vandalism1}} respectively), is there some way a shortcut can be created that will do this automatically? For example, if I were to type {{T:PROD}} on an article page, it would go to a shortcut that would recall {{prod}} and automatically substitute it for me. I can see at least 2 benefits from this: saves time and reduces confusion. However, I cannot figure out the coding to do such a thing. I tried <includeonly>{{subst:prod}}</includeonly> but that just subst's it on the shortcut page (my sandbox). It also would need to somehow recognize the the "reason" parameter which would appear after a pipe. I was hoping for some input on this to see if it is possible with the current code available or if something new would need to be developed. Regards.--12 Noon ^2¢ 19:59, 3 January 2008 (UTC)

Its currently impossible. The only way to get a template to expand into its actual code is to subst it. Mr.Z-man 20:07, 3 January 2008 (UTC)

Er... your example only saves you typing four letters ("t:" instead of "subst:", meaning you're only dropping "subs"). That's not much of a time-saver. EVula // talk // ☯ // 21:41, 3 January 2008 (UTC)

Hmmm, I think you are missing the point, EVula. The point is not the shortcut, it is the auto-substituting.--12 Noon ^2¢ 22:19, 3 January 2008 (UTC)

Your mention of {{prod}} is interesting. If you fail to subst that template, you get a rather glaring error message. If every template where substituting was intended had the same error message, the problem would go away. -- John Broughton (♫♫) 22:25, 3 January 2008 (UTC)

Looks like the same thing to me.↔NMajdan•talk 22:25, 3 January 2008 (UTC)

Ah, sure enough, I skipped that part. My bad. EVula // talk // ☯ // 23:25, 3 January 2008 (UTC)

Pronunciations

I use wikipedia a lot and sometimes have trouble pronouncing certain keywords and names. I then copy the words and look them up on merriam-webster because they have audio pronunciations of the words. I’m suggesting that you add a similar feature, especially for names. —Preceding unsigned comment added by 155.229.83.41 (talk) 16:19, 2 January 2008 (UTC)

A few articles have these, for particularly long or difficult-to-pronounce words like Pneumonoultramicroscopicsilicovolcanoconiosis - I think many more should. Pretty much anything the pronunciation of which isn't obvious. Dcoetzee 18:41, 2 January 2008 (UTC)

Basically, we'd love to have an audio pronunciation for more articles, but someone needs to record, and upload these audio clips. Merriam Webster pays those people. Those on Wikipedia are volunteers, and there seems to be a lack of them. Anyway, there should always be the IPA pronunciation. Puchiko (Talk-email) 15:10, 3 January 2008 (UTC)

I was thinking of the same issue just recently. Couldn't some computer software be written or obtained that read off (in a computer generated voice) whatever the phonetic alphabet spelling was? IronGargoyle (talk) 21:52, 4 January 2008 (UTC)

Promoting or Removing Proposals

I'd like to propose doing exactly the same thing as has been suggested on the top of meta's Proposals for New Projects page = redoing the proposal system.

Just looking down this page it's pretty clear why the existing approach can't work. E.g. penubag has done some really good work on formatting how a Simple English link would work. His/her previous discussion got lost when the page got archived (like this one will). It takes time to develop and/or talk through a good idea. So this stupidity of talking all you like, until a page runs out, then throwing the golden stuff away and starting again later, is just ludicrous.

This really comes down to choosing the right tool for the right job, and in this case a wiki ain't it. Whoever suggested splitting out the reference desk as a separate project is getting close, although i would have said, "put a reference desk on every project's proposal page" might be a better way to start an improvement.

Ultimately these referenced Proposal pages could be the beginnings of relieving some of the frustration Jimmy goes on about when talking about the Foundation email list becoming a sewer. And it's not as if suggestions haven't been made about to improve things. If there isn't a clear way for wikimedians to suggest something, then over time, find and gather some interested people who can give it legs or put it to bed, we can't blame them for flaming.

So before this proposal is buried in last month's archives along with the others, could we give some consideration to choosing some kind of forum tool, which might keep and reference the threads of a similar or related proposals together, while enabling another project's people to discover if someone hasn't suggested their "original idea" in the past. It's getting very tiring watching their still birth.--Simonfj (talk) 21:44, 3 January 2008 (UTC)

This is an issue, and why for my major proposals I tend to create a userspace page for discussiona nd reference it by link from places of interest. An idea might be along the lines of something I saw on the VP Proposals Talk page that suggested subpages for each proposal with a one line description on this page. That way proposals could remain in an easier to resuccitate manner and also be removed when their implmented/rejected as impossible. MBisanz ^talk 15:16, 4 January 2008 (UTC)

Signing

Just out of interest, why don't we automatically sign comments? Or to put it another way, why not automatically add " ~~~~" to the end of everyone's comments on any talk space, and only require it be done manually if it is not a talk space (i.e. in votes). This is more or less what "Signbot" does and would be much more efficient. Ferdia O'Brien ^(T)/_(C) 17:25, 4 January 2008 (UTC)

False positives. Suppose you want to edit your own comment, or to put {{blp}} on a talk page, for instance... --ais523 18:11, 4 January 2008 (U T C)

Here's an idea. If you wanted your comment not to be signed, you'd check a little box, right next to the minor edit. Or you'd include <nosign> in the edit summary. I'm sure there's a way to make this work, the current situation is troubling. Puchiko (Talk-email) 21:02, 4 January 2008 (UTC)

Wikipedia:Task of the Day

Based on a discussion on WP:AN located here about fair use images tags done by bots, and the pending fair use deadlings from the Foundation, I've started this proposed policy/project/change at WP:TODAY. Please check it out and weigh in. The specifics as discussed above about a run for the Images problem we have is at Wikipedia:Task of the Day#Early 2008 trial run. Lawrence Cohen 16:58, 4 January 2008 (UTC) copied by MBisanz ^talk 19:10, 4 January 2008 (UTC) arguing for the inclusion of my own bio, but with full disclosure at least. --LDC (talk) 16:44, 8 December 2007 (UTC)

Linking to other wikis, pre-proposal

I've been trying to format the proposal at Wikipedia:Linking to other wikis, and wanted to see what other ideas people have before the asking the community to comment on which ideas they like and which they don't like. If nothing new comes up in the next day or two, I'll tidy up the page and pimp the proposal out. -- Ned Scott 04:10, 5 January 2008 (UTC)

Wikicite?

Based on an article in this month's edition of Communications of the ACM, the following idea came to my mind. Citing reliable sources is one of the key pillars on which the whole Wikipedia construction rests. My feeling (based on my limited experience) is that the way sources are cited is rather messy and lacks consistency. There is also a lot of redundancy in citations. Each time an article is cited, in different articles, the citation is most of the times recreated from scratch. One consequence of this is that 1) citations of the same article in different places tend to be different, with significant variations (title mispelled, truncated, capitalized differently; list of authors incomplete, abbreviated differently, names mispelled, initials or first names in full, etc.), spanning a very large number of possibilities; 2) when an editor takes the trouble of correcting a citation, to make it accurate and conform to established standards, this only applies to the article on which he/she works, while this valuable contribution could benefit all instances of the specific citation, in all the articles which reference it.

One solution might be perhaps to have a Wiki for citations (Wikicite?), where each individual citation would be treated like a full article (including a discussion page). The lead section of the main page would consist of a citation template, duly filled out, which would be used to generate the citation each time it is used in plain Wikipedia articles. Citations of articles could refer to citation of journals or books in which they appear, and so on. The citation article could contain other sections, with comments about the citation, backed by sources which would be other citations. Such a solution would factor citations across Wikipedia articles. It would have other side advantages, such as finding all articles in which a given citation is used.

Perhaps not a new idea, or perhaps not realistic, but I needed to sound others' opinion about it. --Dessources (talk) 21:39, 4 January 2008 (UTC)

See the lengthy (and inconclusive) discussion at Wikipedia:Village pump (technical)#Is there a centralized bibliographic database for wikipedia? Is there a way to make citations just by giving an universal ID instead of copying a full citation template? -- John Broughton (♫♫) 23:08, 5 January 2008 (UTC)

A solution to the backlogs

As demonstrated by WP:BACKLOG, Wikipedia has some really quite long and severe backlogs such as CAT:CLEANUP, CAT:WIKIFY and Category:Articles with unsourced statements and there is no sign of these being reduced. In short, if we continue as we are doing Wikipedia will be permanently plagued by backlogs which could never possibly be cleaned up. However, we do have very large number of people visiting the site.

I therefore propose that we attempt to encourage backlog clearing by the use of MediaWiki:Sitenotice and/or {{Main page banner}}, possibly including a "maintenance month" long the same lines as the fundraiser month but with the emphasis on editing and backlog clearing and not donations. This should vastly improve the readability and quality of the encyclopedia. GDonato (talk) 11:53, 5 January 2008 (UTC)

A very similar idea has been drafted into a proposal very recently (last few days actually). See WP:TODAY. .:Alex :. 12:43, 5 January 2008 (UTC)

Hm, yes, that seems like a very good proposal. GDonato (talk) 13:21, 5 January 2008 (UTC)

I like it too. Equazcion •✗/C • 13:37, 5 Jan 2008 (UTC)

Proposed template change

I'm proposing an additional category in the Template:Editabuselinks to reduce the number of posts at WP:AN and WP:AN/I, please feel free to comment here User:Mbisanz/TemplateSandbox. MBisanz ^talk 13:19, 5 January 2008 (UTC)

Create an article on Wikipedia vandalism

I was wondering who thinks it would be a good idea to create an encyclopedia article on Wikipedia vandalism at the page Wikipedia vandalism (currently a redirect to the page Wikipedia:Vandalism). I think the subject matter may be notable and significant enough to merit an article. What do you all think?--Urban Rose (talk) 01:50, 6 January 2008 (UTC)

Well the conventions that would apply here are Wikipedia:Self-references to avoid and Wikipedia:Notability (web). Its a good idea, but I'm not sure that Wikipedia vandalism is any more notable than hacking any other major website. MBisanz ^talk 01:58, 6 January 2008 (UTC)

I disagree and think that it is quite notable. I mean, we've got references from major news sources all over the place. —METS501 (talk) 02:06, 6 January 2008 (UTC)

My suggestion then would be to be WP:BOLD and create a new, sourced article on it. You might do it in your userspace and then move it to the mainspace once you've got it to a point your comfortable with. That would maximize the chance of surviving an AfD. MBisanz ^talk 04:38, 6 January 2008 (UTC)

Two tiers of adminship

I suggest that we consider two tiers of adminship, junior and senior. The current admins would be grandfathered into the senior level. Junior admins would have a limited set of powers, such as only blocking for a maximum of 12 hours or so, or some other restrictions. This would allow us to have more admins as we grow, and make it easier to give adminship tools to people who are more borderline. It would create an effective training program before giving admins a huge set of powers with less restrictions. It would give another option instead of just de-sysopping senior admins; demotion to junior admins. Comments?--Filll (talk) 00:30, 29 December 2007 (UTC)

That's about the billionth time that's been suggested, so it's not likely to happen. Although it has some merit in my opinion. Equazcion •✗/C • 00:42, 29 December 2007 (UTC)

It's certainly a good idea, but it would be complex to implement. I'd personally advocate allowing people to have single-tool flags (e.g. only having delete/undelete.) Nihiltres^{t.l} 02:24, 29 December 2007 (UTC)

We should be able to trust those we promote to admin to have the full extent of admin powers. If we can't trust them with it all, they shouldn't have been promoted.↔NMajdan•talk 02:52, 29 December 2007 (UTC)

We're not talking about demoting current admins (unless they deserve it). We're talking about allowing for the possibility to promote other people to a tier that is not fully admin, in case we trust them to do certain tasks but not necessarily others. Relax, no one's trying to take away your power :) Equazcion •✗/C • 03:27, 29 December 2007 (UTC)

I dunno, it seems like a good idea, but I'm not sure if I can think of that many situations where I would trust someone with one tool but not the others. Mr.Z-man 03:50, 29 December 2007 (UTC)

As the OP suggests, it could be like a training or trial period. Give an editor a more limited set of tools and see how he uses them before making him a full admin. Equazcion •✗/C • 03:57, 29 December 2007 (UTC)

I proposed exactly this about two years ago. I still think it would be an excellent idea, particularly if it is engineered so promotion from junior admin to senior admin were to be done as a matter of course if the junior admin used the tools properly for a relatively brief period (say, two months). bd2412 T 04:04, 29 December 2007 (UTC)

Well, one of the complaints about the current system is that there's no easy way to demote admins. So, we'd be introducing a new type of admin, plus try to set up some de-adminship system, both of which have dozens of failed attempts to their credit... aside from the unlikelihood of this happening, I'm not entirely sure it's a great idea anywhere than in theory. I can't think of a time when I'd trust someone to make blocks, but not over a certain amount of time. EVula // talk // ☯ // 04:11, 29 December 2007 (UTC)

I've got to agree with EVula here, a mark on one's block log, whether from a junior or senior admin, for an hour or a year, is probably just as damaging to one's Wiki-reputation. One idea I've supported before is decoupling the various Admin tools. Like a junior admin could only protect pages (not unprotect, block, or delete), but it would lead to a second RfA process, which as Z-Man has pointed out before I believe, would not be a good thing. Mbisanz (talk) 04:29, 29 December 2007 (UTC)

I think the specific tools given to junior admins could be things that senior admins generally don't "like" doing and that there's a backlog of. It would be like in real life -- if you want to move up the ladder you have to pay your dues. It could be deletion closings, move/merge requests, answering help question (if that's something admins do someplace)... stuff like that. I don't know about editor blocks and page protects, as those are touchy subjects that require delicate handling, and carry a much larger chance of pissing off the community. Semi-protect would be ok, just not full-protect. Equazcion •✗/C • 05:03, 29 December 2007 (UTC)

The only things admins can do is protect/unprotect, delete/undelete, see deleted content, block/unblock, edit the MediaWiki namespace, and edit a user's monobook.css and monobook.js pages. The thing that has the biggest backlog is deletion related, and there's no easy way of splitting that sort of stuff up (no technical way to enforce a "you can only deal with XfD closures" policy). EVula // talk // ☯ // 06:17, 29 December 2007 (UTC)

I wouldn't object to a less experienced user being able to protect pages, since thats reversible and doesn't have a lasting harm. Undeleting is dangerous because then we'd need to expand the use of Oversight to stop deleted BLP material from reappearing. Editing MediaWiki space is pretty serious since someone dropping a meg of data into the watchlist header could wreck havoc. Editing user's css and js doesn't seem serious, but I do know of one user getting locked out of editing due to a faulty script. Really most of the tools require discretion, and RfAs seem like the only way to ensure that. I saw a stat somewhere that only ~25 admins left under controversial circumstances this year. 25/1400 is an enviable churn rate to me. Mbisanz (talk) 06:23, 29 December 2007 (UTC)

I don't think anyone was suggesting that they don't require discretion. There's no admin tool I'd hand to just anyone who requested it -- what sense would that make? There would obviously need to be some kind of preliminary process to get the "junior" admin status. As for the particular tools to give the "juniors", I'd say deletion would be fine, since that's also reversible, and access to peoples' css and js files would also be fine. Remember, these aren't being given to just anyone. It would be determined beforehand that these people were trustworthy for what we're giving them. Equazcion •✗/C • 06:32, 29 December 2007 (UTC)

That draws the question of who do we trust. Setting an edit count level would lead to editcountitis and could let in vandals who make lots of tiny edits. Length of service has the same issue. Going the standard consensus route would be an RfA-like voting system to me. And anything else (eg: x admins approving a user, verifying information, creating featured content) seems to variable or burdensome to work. Mbisanz (talk) 06:36, 29 December 2007 (UTC)

I don't know exactly what the process would be, but it could just be another RfA with less stringent standards, and the final RfA would be more stringent and look at the editor's record with his junior tools. Equazcion •✗/C • 06:44, 29 December 2007 (UTC)

I haven't been through an RfA, but I've seen how intense they can get. Even if it was say a 50% for consensus and only say 1000 edits with no FC, I'm not sure how many newbie users would want to go through that, only to be more strictly scrutinized later on, after they've had the chance to enforce policy (ie: mess up in good faith). Mbisanz (talk) 06:48, 29 December 2007 (UTC)

If you don't want to be scrutinized you shouldn't be an admin. People with power, and especially people who are running for positions of power should be scrutinized, and should be prepared for that. If I were interested in being an admin I think I would accept that reality: If I want this, I have to do what it takes. This would also alleviate some of the "popularity-contest" views of RfA. Equazcion •✗/C • 06:55, 29 December 2007 (UTC)

(unindent) That is a good point, there is never a valid argument for less scrutiny of those we trust with tools. I still have concerns though of creating more red-tape, letting in vandals, or just bloating the bureaucracy. The biggest admin backlogs I've seen are RFDs (which is also an issue of a lack of users expressing opinions) and image issues (BCB/Orphan tags). Maybe if we could restrict the namespaces that a junior admin could delete (only image and main, no talk, etc), I'd see more value in the proposal as addressing a backlog Mbisanz (talk) 07:01, 29 December 2007 (UTC)

The tools could be restricted by namespace but I don't really see the value in doing that. It wouldn't address the bureaucracy concern or make the backlog go away any faster. And as for vandalism, I don't think article deletions are much less serious than any other kind. If someone passed a preliminary !vote, I don't see what's wrong with giving them access to all namespaces. Deletions aren't permanent. If they start blatantly abusing their semi-powers, those powers can be taken away immediately. It wouldn't be like full admins who would need arbitration to be demoted. Juniors would be on probation by default. Equazcion •✗/C • 07:19, 29 December 2007 (UTC)

It'd still require a steward to demote the junior admins, just as even ArbCom has to turn to stewards to do the actual bit-flipping now. Sorry, but I'm seeing a lot of work being needed for something with a nominal amount of payoff. EVula // talk // ☯ // 07:44, 29 December 2007 (UTC)

I guess thats what I was getting at indirectly. If we have admin backlogs that we could trust to a junior admin (image deletion, etc), then why not only trust those backlogs to them. I'm assuming the whole reason we're discussing this is that some users feel there are not enough admins to handle the work. So let senior admins have the full mop and give the junior admins only the broom that gets the cobwebs out of the high ceiling corner (to make a bad analogy). Maybe even structure it that a crat could de-sysop a junior admin? Still though I'm hesitent of what criteria would be used and how junior admins would be viewed by the community. Mbisanz (talk) 08:05, 29 December 2007 (UTC)

That's not exactly why I like the idea. I like it because I think it's just a better system for choosing admins. I think RfA sucks and I think a lot of people think that. I think a good number of people want to see reform there as it comes up often as an aside remark, but I think no one wants to do anything about it because of all the "work" involved. I also think this carries benefit for the ordinary editor community a lot more than it does for current admins -- it would affect future RfAs and make editors more comfortable with the people getting promoted -- while I don't think current admins see a benefit, generally, because for them there isn't as much. I'm not sure how a steward's involvement means that this isn't feasible. It doesn't take long to switch off a privilege. And please, don't be sorry. Seriously. Equazcion •✗/C • 11:02, 29 December 2007 (UTC)

While consensus can change, if often doesn't: see Wikipedia:Perennial proposals#Hierarchical structures. -- John Broughton (♫♫) 21:55, 29 December 2007 (UTC)

Just a comment from someone who has declined to be nominated for adminship. I don't want the whole kit and kaboodle of admin powers, as there are some I simply have no interest in being expected to use as needed, but I could see myself being willing to accept being nominated to wield a limited subset thereof. Caerwine Caer’s whines 22:42, 29 December 2007 (UTC)

Realistically, unless someone here is willing and able to code it, another access level that can only block for certain times or delete in certain namespaces isn't going to happen. You can request it on Bugzilla, but unless you provide actual code it could be years before it gets done (bug fixes have a higher priority over feature requests). Giving out individual tools on the other hand is possible with the current software (sort of). It might be a good idea, the only issue I can think of is with blocking. Deleting and protecting can be given to people who clearly have experience in those areas, but people who want blocking would have to be experienced in many areas (vandalism, sockpuppetry, edit warring, etc) that they would probably be able to get full adminship (would that still be an option) if they were qualified. Mr.Z-man 04:12, 30 December 2007 (UTC)

I've worked a bit with the code and a change in group permissions would not be very hard at all. I could do it in half a day. But what's the point? It would make more sense to simply have a probationary period for every new admin (say 6 months) with full powers, after which they need a reconfirmation vote. That doubles the RfA load, as does nearly any scheme along these lines. I see nothing wrong with raising perennial discussions perennially. If a billion people bring the subject up, perhaps a billion people support a change. Wikidemo (talk) 05:05, 30 December 2007 (UTC)

Hear, hear. Good point, a probationary period/reconfirmation is really what this seems to be leading to. Equazcion •✗/C • 05:06, 30 December 2007 (UTC)

(undent) If you look at Wikipedia:User access levels#Table, you'll see that it's a relatively minor change to add a column (say, "Junior Administrator") and to specify which rows apply to that column (as Mr. Z-Man suggests, protecting pages and deleting pages - since deletion is a reversible action in Wikipedia - are the most likely candidates). I personally would support that, while I think the reconfirming new admins isn't going to ever get community support, because (a) it doubles the number of RfAs, as noted; and (b) many if not most editors are going to think that if someone is trusted with admin tools for 6 months, why not just trust them indefinitely (until/unless they mess up)? -- John Broughton (♫♫) 15:53, 30 December 2007 (UTC)

I think predicting the community's response is a bad idea. Let's just offer our own opinions on the proposal. I think initial votes with reconfirmations after a set probationary time period are a good idea, because it gives the !voters more on which to base their decision. What do you think? Equazcion •✗/C • 23:38, 30 Dec 2007 (UTC)

I - personally - agree with the arguments at Wikipedia:Perennial proposals#Reconfirm administrators. Wikipedia has a whole lot more important problems - recruiting and educating new editors, quality of articles, making it easier to cite sources and edit in general, and more bots to handle mundane stuff come to mind immediately - than trying to convince the community that a significant number of admins are a problem (I, for one, don't agree), or that changing the RfA process in this way wouldn't make the situation worse, not better. -- John Broughton (♫♫) 13:57, 1 January 2008 (UTC)

I've heard there are some negative perceptions, due to this being on of the few projects (afaik) where admins get essentially lifetime appointments; but I really don't like the junior/senior naming. I do think having some kind or provisional sysop similar to other projects with annual confirmation, a less painful process, and maybe even lesser access rights would be helpful. Lesser rights may not need to be technically enforced, they could just be advised not to do things that would make enemies and derail reconfirmation, which I understand is the main argument against requiring reconfirmation; that some admins need to do those things. The argument about steward involvement seems circular, essentially that we can't change the policy because it's against policy; a non-permanent sysop should of course be revocable by bureaucrats. -Steve Sanbeg (talk) 23:56, 3 January 2008 (UTC)

There's plenty of precedent for the multi-tiered concept, going back at least to the BBS days, when there were typically sysops, co-sysops, etc. with each having the minimal set of powers needed to do their jobs. The idea was that there might be a lot of users whom you would trust to delete posts, delete files, etc. but there's probably only a few people (at the most) whom you would want to allow to drop to DOS. I would say, if we're going to have multiple tiers, let's take the tasks that we know from experience cause the most havoc when misused, and reserve those for a subset of admins. 71.63.88.166 (talk) 21:02, 6 January 2008 (UTC)