Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Jerse (talk | contribs) at 02:25, 18 December 2007 (→Main Page Proposal). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The proposals section of the village pump is used to discuss new ideas and proposals that are not policy related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are listed at Wikipedia:Perennial proposals. If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Before posting your proposal:

  • Read this FAQ page for a list of frequent proposals and the responses to them.
  • If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
  • If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there.
  • If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.



A Support to Wikipedia Indian Editions

This is to bring into notice about a project developed to help Wikipedia in Indian Editions. Even before launching the project, considering the importance of the same DD NEWS (the official news channel of Government of India) did a story about the project and a recorded version is available at

http://mozhi.org/news

You can try some tools (for trying the coding) at

http://mozhi.org/hindi http://mozhi.org/punjabi http://mozhi.org/tamil

We can offer customized search boxes for Wikipedia pages for Indian readers to search in the respective languages and they enter words in the respective Indian language itself. The users can enter words directly in the respective languages and search.

Please let us know if you need any clarification or help in implementation. You can find the contact page in our site for the same.If interested we can launch it extensively and include all the pages.


Green Butterfly : rate products & companies on ecology, fair trade, human rights

Hello dear Wikipedians,

Please allow me to briefly present my project and feel free to post your suggestions. I was discussing ecology with a friend and I was supporting the argument : the consumer has the power. His daily choices direct industries towards ecology or not. Towards quality. Towards fair trade.

Then I thought : wouldn't it be great if a website enabled each user to rate companies and products. I imagined an ecology rate, a fair trade rate, a quality rate, a "workman's rights" or human rights rate. Each internet-user-consumer could share his knowledge and in a way, be the butterfly that changes this world (hopefully, stirring up less violent means than a hurricane).

I have programming skills in PHP, ASP.Net and am currently looking for advice (technical, GUI, ...) and suggestions about this idea. Any colloboration would be of course welcome. Why not a new wikipedia branch ?

Also, if you know anyone who could be interested in this project, feel free to forward this message.

Thanks in advance,

Peace ,

Michael.

(you may contact me on the wikimedia foundation mailing list 'foundation-l@lists.wikimedia.org')

Simple English Wikipedia

This is something that definitely needs to be addressed. The English Wikipedia needs to more recognize the Simple English Wikipedia, not just list it in the in other languages bar on the side, hidden with the other languages alphabetically where only the most dedicated Wikipedians know of its existence. Imagine a little elementary kid needing to do a report on the American Revolution. He goes to Google or Yahoo! and types 'American Revolution'. Of course, the first result is Wikipedia. He clicks on it but, he cannot read its complex english. Wouldn't it be nice if he can actually read it (since we already have a simple english wikipedia). I think that adding a simple template on all English Wikipedia articles that have a Simple English equivalent similar to this one

Village pump edition of Wikipedia, the free encyclopedia

at the end of the article under See also or External links, should solve the problem for the most part.

Why else is this good?

  • helps the growth of the simple english wikipedia
  • helps young people trying to learn
  • no point in having simple english wikipedia if a young kid cannot even find the link

Hopefully this gets implemented somehow.-- Penubag  05:49, 25 November 2007(UTC)

SEWikipedia (and all other language wikipedias) are separate projects. "We" (as in Eng Wikipedia users) are responsible for neither their content nor their advertising. I don't see why that one particular project should get extra attention. - Koweja (talk) 06:38, 25 November 2007 (UTC)[reply]
Read the explanations above why having a SE wikipedia link on English articles would be very useful. Simple English is a part of English even though a seperate project. I just recently learnt about the SE Wikipedia (about a year and a half ago), and had I known of it sooner, I may have been able to use it to its full extent. Also Google French won't turn up Wikipedia english articles so we don't need an extra notification on a french wikipedia page for english articles. And sure, maybe we aren't responsible for them, but just think how much that could help people, everywhere, both kids and English learners. I think just because they are a separate project, it doesn't mean we shouldn't help what can help everyone.-- Penubag  07:03, 25 November 2007 (UTC)[reply]
Agree with Penubag. Koweja, You shouldn't put a limitation of help from us users to just the English Wikipedia. Actually, you should promote other users to join other Wikipedia's if they understand the language. We are all under the Wikimedia Foundation, and even if we are all different websites, we still serve the common goal of a Free reliable informative encyclopedia. Lex T/C Guest Book 07:20, 25 November 2007 (UTC)[reply]
That's his point. We're all under the Foundation, so why should the English wikipedia give special treatment to a specific other project? -Amarkov moo! 07:32, 25 November 2007 (UTC)[reply]
Well, we link to wiktionary even though that is a separate project.-- Penubag  09:16, 25 November 2007 (UTC)[reply]
Because Simple english is derived from English. So, we are like a parent Wiki to them. Thus, it should get special treatment. Lex T/C Guest Book 07:34, 25 November 2007 (UTC)[reply]
Yes, and besides, it can greatly help learners. SE should get special treatment because it helps people looking for an article in the same language. Is that not what wikipedia's main goal is based off of? We need to expand our focus not only who are extremely well fluent and knowledgeable in English, but also on the younger generation, since those are the people that are going through school and those are who most need information in which they can understand. "Knowledge is the result of the cumulation of youth, which is where the doors must be first opened"-- Penubag  07:38, 25 November 2007 (UTC)[reply]
I'm kinda unsure. To begin with, I really don't think the English Wikipedia is that hard to comprehend for 9-year-olds. The articles are usually written quite clearly. This is question almost impossible to answer, but I'll ask it anyway-How many of those who come to the English article find it too hard to read? Sure, little elementary kids use Wikipedia. So do college students. So do adults. Another unanswerable question-How many of our readers will benefit from the link, as opposed to how many will find it annoying/distracting/useless/cluttering?
Finally, the link to the simple English version might not be that useful, it's quite short, POV and has stunning pieces of prose such as ...the colonies totally refused to cooperate with this law. Puchiko (Talk-email) 12:00, 25 November 2007 (UTC)[reply]
Believe me, if you are 9 years old and trying to read an article on the String theory, it is very hard to understand. And whose to say that the SE wikipedia won't grow once we add the templates to English pages. I believe it can come out as good as any wikipedia once it gets more attention. The reason why SE is "quite short, POV and has stunning pieces of prose" is because there are barely any people knowing of its existence, let alone know how to edit an article.-- Penubag  21:13, 25 November 2007 (UTC)[reply]
Are you sure, that a 9 year old kid will understand string theory in SE wikipedia. :) Well perhaps, you are right, reading string theory here, the kid has two difficulties - to understand the difficult english (per kid's standards) and then to decipher the concepts of string theory itself. Atleast the first task would be diluted in the SE wikipedia. But I was wondering how you would convert the intimidating terminology of the theory itself in SE for kids to grasp it better. - DSachan (talk) 21:34, 25 November 2007 (UTC)[reply]
  • Support for Penubag's proposal. English is more than a mother tongue, it is an international communication tool, as well, so it needs a different treatment compared to the other languages. I use English as a foreign language and I think Simple English Wikipedia is a useful project which can become an important information source for the non mother tongue English speakers. At the present, it's articles are stubs, missing or not well written, but it can change in the future. I think that it should become the same rich and high quality than any other Wikipedia. On the one hand, the articles of the English Wiki should be transported to it in a simplified form (simplified linguistically but not for their content!), on the other hand non mother tongue English speakers who use English as an international tool, should write articles in it. (You can maybe understand the difference between my simple international English and the real English of Luna Santin a mother tongue person here: [1]) Back to our topic: I think if there is an article in Simple English Wikipedia which is high quality fot its content, it could be linked from the correspondent English Wikipedia article as Penubag suggests. --Hunadam (talk) 20:45, 25 November 2007 (UTC)[reply]
  • Support yes, we could make a team that copy-pastes English Wikipedia articles into Simple English Wikipedia, and just change the hard words to words that everyone can understand.-- Penubag  21:07, 25 November 2007 (UTC)[reply]
  • Sorry, but no. Just because there's a tight relationship between English and Simple English doesn't mean we should be pushing their articles. There are several other language pairs that are closely related (there are 9 variants of Chinese you can choose from in the preferences, for example). At most, I'd support pushing [[simple:]] interwikis to the top of the list (similar to how the Hebrew Wikipedia puts en: interwikis at the top), but outside of that, I think it'd be detrimental to the project. EVula // talk // ☯ // 21:38, 25 November 2007 (UTC)[reply]
No, not just because there is a tight relationship between English/SE, but for the benefit of young readers. I don't see a the purpose of having a SE wikipedia if no one knows about it. I don't see what's so wrong with letting a bot add a SE template to our english articles. Everyone can benefit from that, no one can seriously be so hurt from it that they don't want to help younger and english learners.-- Penubag  22:45, 25 November 2007 (UTC)[reply]
  • Support The number of non-native English speakers is two or three times the number of native English speakers. If you add a link to the Simple English Wikipedia, it will help the non-native speakers and young children. Also, more people will write articles in the Simple English Wikipedia. Just like if there is a Simple Chinese Wikipedia, I think the Chinese Wikipedia should link to it (but there is no Simple Chinese Wikipedia). --Kaypoh (talk) 09:45, 26 November 2007 (UTC)[reply]
  • Support. Unfortunately, there is not Simple Chinese Wikipedia. Maybe we could request it. bibliomaniac15 00:25, 27 November 2007 (UTC)[reply]

So is this enough support for the creation of a bot that will place SE templates to English articles??-- Penubag  03:41, 29 November 2007 (UTC)[reply]

I hope not; not only am I personally against this, but I have grave concerns about how it will look in a real article. Placing the "SE" link above the infobox and other information will make the page look like crap. We don't need to clutter up of our own articles. EVula // talk // ☯ // 15:50, 29 November 2007 (UTC)[reply]
You don't understand. The template will be placed way below at the bottom at the page, near external links/See also, right above that Wiktionary Link. Only the people who need the link shall see it.-- Penubag  16:41, 29 November 2007 (UTC)[reply]
I'm somewhat opposed to this too. Currently we use templates like the Wiktionary and Commons link templates to direct people to where they can get more information, not similar information in a different format. And I would think that you need a wider consensus than this to put a template on 21,000 articles. Mr.Z-man 18:16, 29 November 2007 (UTC)[reply]
How much wider can my consensus get? In case you want a sum of all the advantages/dis you can just read this: >It will help everyone from highschool (where new concepts are introduced) down (and maybe up too, kids and English learners included >It will help improve the quality and quantity of the Simple English wikipedia >It will get SE out of the in other languages bar and to somewhere where kids can find the link instead of searching through an alphabetical list >and most importantly for fluent english speakers, it is a quick summary for lazy people (like me) who just can't read an entire article on WWII just to find out which battle turned the tables for the Allies (although stated in English, this important battle is introduced much earlier in SE so it helps at times when readers are feeling lazy) Cons> Nothing at all except maybe a little cluster issue which can be resolved (see my next edit below).-- Penubag  03:31, 30 November 2007 (UTC)[reply]
Ah, I was misunderstanding it; however, I still think it'll be cluttered. We currently use that space to direct users to other WMF projects that are of relevance to the article; why would someone scroll all the way down to the bottom of the page, when there's a link on the left within the first two thresholds? It gets cluttered enough with {{commons}}, {{wikispecies}}, and other such templates; drawing a distinction between Wikipedia and Wikispecies is good, as they're separate projects, but it gets considerably less clear once we start adding additional language editions. EVula // talk // ☯ // 18:45, 29 November 2007 (UTC)[reply]
The reason why we should put the template at the bottom of the page rather than the side is because no one knows that SE is over there on the side (let alone, it's not even another language). Only experienced wikipedia users would know of it's existence (by then SE is not needed for them), which is why it is only two thresholds for you. Simple English can be very informative especially for highschoolers who are learning new concepts and for other young persons or foreigners. Addressing the concern that the See also and External Links may become too cluttered..: Usually it's not that cluttered where adding an additional template makes it so unorganized that we can't even help young readers with an SE link. But, I do see your concern. Maybe adding a smaller template will help this issue, similar to this one:
See ARTICLE in the Simple English Wikipedia
. With this template, young readers alike can go to almost any wikipedia article, type in what they want, and scroll down to the bottom of the page to click the link. It sounds stupid at first, but if you really think hard about it, I think that's what a lot of kids will be doing.-- Penubag  02:56, 30 November 2007 (UTC)[reply]
I'm still opposed to this; I've yet to see any evidence that this is helpful other than vague "think of the children"-type hypotheticals. I agree with the overall purpose of the Simple English projects, but only in regards to the greater good of making information more accessible. Creating garish templates to redirect people who may very well not care to be redirect doesn't strike me as a very good idea; the more I think about it, the more I think this would be best served by moving the simple interwiki to the top of lists.
Suggestion: make some temporary versions of a handful of existing Wikipedia articles in your userspace that would illustrate how the template would/could function. Seeing a working example might change minds moreso than imagining it (for example, it could work better than I'm thinking, or it could work worse than you're thinking). EVula // talk // ☯ // 04:09, 6 December 2007 (UTC)[reply]

I think I could support moving it to the top of the interwikis - can we get consensus for this change in particular, since the devs won't do it without a clear consensus?—Random832 14:32, 30 November 2007 (UTC)[reply]

For this change in particular? You mean that little template above? Well, as stated many times above, that little template will get the Simple English Wikipedia out of the In other languages bar from the side, where it clearly doesn't belong, let alone, it won't be found be anyone needing it; and it can promote and help the growth of the SE. Hopefully that convinces the devs ;)-- Penubag  08:58, 2 December 2007 (UTC)[reply]
To move a [[simple:]] link to the top of the list, you simply move it to the top of the list; interwikis are displayed in the order they are given in the article. No dev involvement needed, but you would (most likely) need a bot to make all the changes. EVula // talk // ☯ // 04:09, 6 December 2007 (UTC)[reply]
Okay, moving it to the top of the interwikis and possibly bolding it, but I still don't think it would stand out enough, can I have your (since you're an admin in every project) confirmation for the little template thing above? -- Penubag  04:21, 6 December 2007 (UTC)[reply]

Support for the proposal, but only if there's a visible link for a guideline to simplification on the SE pages. It is more difficult than many realize to simplify things, so without a guide we might get excessive length from over-explaining, dumbed-down to a point of confusion which hurts the goal of being understandable. I'd like to see the SE pages get special treatment, where a list of un-friendly words are cross-referenced with an internal database that editors contribute to. So if anyone writes an article in SE, the unfriendly words become highlighted in a low-distraction color (vey light gray?) and users can double-check that internal database for whatever alternatives might be listed in pararenthesis next to the un-friendly word. -boozerker 01:12, 01 December 2007 (UTC)[reply]

That's a whole new proposal altogether; but, I do agree with you, it would be nice to have-- Penubag  08:58, 2 December 2007 (UTC)[reply]

So? Do I have proper support for a bot now? What's my next step? -- Penubag  07:55, 4 December 2007 (UTC)[reply]

Support moving simple english wikipedia link to the top of the interwikis and even make it more prominent than other links. Arman (Talk) 03:26, 6 December 2007 (UTC)[reply]

Support We need to make Simple Wikipedia easier to find and help it develop. Encyclopedia Britannica has 6 levels of articles, with different levels of difficulty and sophistication. With Simple Wikipedia we can have 2 levels for many articles. With the introductory articles like Introduction to evolution together with Simple Wikipedia we can have some articles with 3. If EB can have 6 levels, can't we have 2 or 3?--Filll (talk) 05:31, 6 December 2007 (UTC)[reply]

Oppose Ugh. This is a lousy idea, and an even worse one if someone tires to implement it with a bot. I can't watchlist both the English and Simple English versions of every article that I keep up with, and if you try to prominently link the simple article to the en article, it just blurs the line for readers. Can't we think of the readers? The vast majority of them who wind up at a POV fork on Simple will think they "read it on Wikipeida". There's no need to encourage this. Simple can get the same treatment as the other language wikipedias, and stand on it's own merits, or lack thereof. ➪HiDrNick! 07:23, 6 December 2007 (UTC)[reply]

I think not. We already have enough clutter in terms of links to other projects.Geni 03:51, 9 December 2007 (UTC)[reply]

Hmmm Some good points Geni, and it could become messy where article splitting, page redirection, and such on regular Wikipedia isn't mirrored on its Simple counterpart. That is a big problem if the two versions are tightly cross-linked. At the same time, the increased readership of Simple means they have healthy population of their own watchlisters, so you don't need much worry there. --Boozerker (talk) 07:47, 9 December 2007 (UTC)[reply]

Oppose Don't get me wrong, I like the Simple English Wikipedia and I've used it on occasion to explain Mechanics of Materials to a 9 year-old... lol. However, Simple English is just another form of English. The Chinese Wikipedia has six types of Chinese, ranging from Simplified Chinese, Traditional Chinese, Taiwan Traditional Chinese, People's Republic of China Simplified Chinese, Hong Kong/Macau Chinese, and Malaysian Chinese. They all appear to be as separate languages when linked properly (however, they have a pull down menu on top next to the "History" tab where they could select again which six versions of Chinese to use. Nevertheless, they are listing all six Chinese forms (max) as different languages, even while in the same article under a different form of Chinese, so I don't see how Simple English and regular Wikipedia needs any more distinction than it already has. - Jameson L. Tai talk ♦ contribs 07:37, 12 December 2007 (UTC)[reply]

Expand to more generalized solution

Support, but think it is high time we stop the highly parochial (and more than a little childish) attitude that "they aren't us, so why should we advertise for them". Admittedly, other projects in their early days had some real rough spots... but then so do our article stubs. It's time to revisit those "consensus decisions", if indeed they weren't the normal case... a swarm of the really involved subborning those who have less time to keep up. (Personally, until and unless we have a"quorum floor", I don't believe we've got a mechanism that reflects the claim of consensus. As a project now maturing and stable, that is perhaps a good next step too, but I digress! Sorry.)

Interwiki's are known to many foreigners, and probably nearly totally unknown to newer editors here. Worse, they don't link to our sister sites, many of which are equally unheralded, but would be of interest to our readership. Hell, I didn't know about Simple English wikipedia, until seeing the above, and I've accounts on most sisters! What harm would there to be having a page wide (noprint class) 'banner' above our article proper. It'd be far less controversial to me than those confidence distroying self-inflicted wounds we base on {{ambox}}, that is about every cleanup template out there. Better yet it'd be more consistent to the current state where one sister (wiktionary's {{wiktionary}}) template is tolerable on a page top, at least defacto, and others are in effect insulted by being relegated to "External Links", with other links. I'm personally convinced that this issue is a big factor behind some sister's almost hostile attitude to any idea which originates here... people don't like their hard work to be dismissed, and if the foundation is funding them, I say they deserve a little prominence and acknowledgement here!.

Have such a banner template link to whichever sisterpage handles the same topic, wikibooks, wiktionary, wikiversity, the commons (may need two entries sometimes, given atlases), wikiquote and other content sites (admittedly, meta and mediawiki will hardly ever be linked, but they are administrative or source repositories, not content sites per se.) whatever... and cease denigrating our sisters as if they were just another external link. THEY AREN'T.

Like any other nav box, it can be thin and inconspicuous, and programmed in this case with named parameters to generate boilerplate if the community desires. Unlike most other nav boxes, I think this one should be a header placement. I'm suggesting something fairly inconspicuous, but standardized along the understated size and height of {{commons-gallery}} which can be seen on a page here. Considering all the waste space we create with "Ugly White Space" (how professional does a screen filled with long Table of Contents and nothing else look!??, giving a small banner border to cross-sister linkages is a minor page formatting issue. Actually, implementation would be pretty trivial, a few parserfunction tests in the applied template, calling some sub-templates modeled on {{commons-gallery}}, which is a table format, gives an array of tables across. The order would be standardized alphabetically, and the link could be the display icon, sans text... that would prevent space overcrowding, and enable links to slightly differently worded titles covering the same materials. Some template savvy editor could knock together something like that in a few hours. The template could take a command arguemnt that tells it how to format itself. Three or four links as icons would fit in the 250 pixels width easily of the current sister links templates, as "commons-gallery" will fit in less as shown. A few more links could wrap to a double row of icons format. Hence on linkname trigger for each sister, one number command, saying how many links are involved to control the formatting. That would appear above any infoboxes etc., but if a page has a lot of links, could left float and appear as one stretched out banner of icons above page intros. // FrankB 17:37, 14 December 2007 (UTC)[reply]

We have enough tagcruft already. Based on your changes to Middle Ages just now, I don't like this idea at all. Johnbod (talk) 18:10, 14 December 2007 (UTC)[reply]
I did not agree at all with what I saw on Middle Ages. Seemed particularly cumbersome and somewhat unnecessarily complicated. Modernist (talk) 20:31, 14 December 2007 (UTC)[reply]
On my monitor at least, your edit displays very badly. A single word ("The") is isolated at upper left, then there's the contents box, the two nav boxes and the image; some scrolling is required to find the rest of the sentence: "Middle Ages form the middle period..." etc. Perhaps an inconspicuous page-wide noprint banner would be fine, but if it's inconspicuous it will be easily overlooked, no? Is there any evidence that users have had trouble finding nav boxes located in External links? Ewulp (talk) 22:41, 14 December 2007 (UTC)[reply]

Put button for "ref" tags in edit window toolbar

The <ref> tag has got to be a thousand times more important to the encyclopedia than something like the <nowiki> tag, and is a feature that should be easily accessible to every new user, if we want to improve referencing in articles. There should be a button for the <ref> tag in the edit window toolbar, alongside the signature button, the image button, etc.--Pharos (talk) 03:54, 29 November 2007 (UTC)[reply]

I was proposing that the citation formatting should be done by DHTML / Javascript. I assumed the toolbar is is implemeted via Javascript - is this assumption correct? Philcha (talk) 16:14, 6 December 2007 (UTC)[reply]
  • Support Really... this has to be done.. atm, referencing is pretty hard to do.. or its hard to find out how to.. so if we pull this off.. we will get more referenced articles. Just one thing... if ud check the Wikipedia talk:WikiProject Illustration, you will see that nothing has been done there in a long time.. i guess ure better off at WP:GL Yzmo talk 21:27, 3 December 2007 (UTC)[reply]
  • Strong Support I had the same idea long ago but was too stupid to think of actually suggesting it. And I see that it is already done! Just curious - how was it implemented? Did it require developer support or was it a simple edit to perhaps a system message? Sbowers3 (talk) 03:56, 5 December 2007 (UTC)[reply]

On Wikipedia talk:Village pump (proposals)#Web-page tool for citation formats? someone pointed out that there's a PHP-driven tool at [2]. The edit form should link to this, preferably in a new window / tab so that the edit box keeps its position (insertion point). Philcha (talk) 16:31, 6 December 2007 (UTC)[reply]

I have added a request for further ideas on icon design to Wikipedia:Graphic Lab/Images to improve#"Ref" button on edit toolbar. Please voice you opinions there. Thank you.--Pharos (talk) 21:32, 13 December 2007 (UTC)[reply]

Proposed new Admin noticeboard

This looks to me anyway to be very possibly an extremely contentious political season in at least the United States. I believe it is certainly possible that several sources will be introduced or highlighted in this season out of proportion to their relevance or accuracy, and that several articles, including those which do not necessarily relate to one or more active politicians, may well be altered for the purposes of benefitting a political agenda. I do note that we have a template for biographies of active politicans articles already, but I doubt that will be able to deal with the entire range of changes which may arise from the politically-motivated changes which might be made in these articles. There is a current Wikipedia:Fringe theories/Noticeboard, but I don't think its' scope is necessarily entirely relevant to the changes I think may happen here. I was wondering whether there might be any advantage to create a new noticeboard, maybe called Wikipedia:Politics and society/Noticeboard or something similar, which might serve as a central location to discuss these matters. John Carter (talk) 16:13, 5 December 2007 (UTC)[reply]

Would you care to list a <shudder> mission statement for this new board? All I can see at the moment are downsides, nothing that would be useful.
  1. Editing of political articles is already heated; would a "run and tell" board add or subtract from that?
  2. When disputes break out, they need to go through discussion, dispute resolution, RfC and finally ArbCom in order to be sorted. What would be achieved by having a further, nebulous, step in this process?
  3. Wikipedia's rules on NPOV and reliable sources are writ in stone. Would a new board intend to vote on their application in specific circumstances?
  4. If not, what would be the purpose of a board that was about heated subject but didn't have a mandate to alter longstanding rules and guidelines and didn't have a place in dispute resolution?
  5. Which backlog would the board solve?
  6. If there is no backlog to be solved, which process is currently substandard and thus would require a specific board to compensate?
  7. Boards that overlap each other cause forest fires, with multiple blazes breaking out on each board that even slightly seems related. How is this board unique?
  8. Why would this board be exclusive/recommended for admins, who are ordinary editors like everyone else but happen to have 3 extra buttons?
Sorry to rain on your parade, but, as I say, I'm only seeing downsides at the moment. ➔ REDVEЯS likes kittens... and you 20:50, 5 December 2007 (UTC)[reply]
Responses:
Mission statement: To ensure NPOV of articles relating to politics, specifically to ensure reliable sources are used for the inclusion of NPOV content which does not violate other wikipedia policies, including WP:Undue weight.
Q1: The presence of the noticeboard would be to bring new, fair, informed input on the article, probably regarding phrasing or the inclusion of certain content. Those parties who tend to watch the noticeboards tend to be more familiar with policy, and on that basis would probably help ensure that the article doesn't violate any policies.
Q2:This question assumes that the dispute is intractable, which is not necessarily true, even in most cases. Bringing in unbiased editors generally will resolve some of the questions which relate specifically to policy matters. On that basis, it might even make later steps redundant. Also, this is not necessarily a "step" in procedure, just a place to request comment in a less formal way. Clearly, it would not "bypass" any other steps.
Q3:Many of these disputes would relate to questions over whether a given source is reliable, and also, possibly, such things as WP:Undue weight. A noticeboard to informed parties would be more likely to help ensure that those policies are applied reasonably, not vote on applying them, as was stated above.
Q4:The same question could be applied to Wikipedia:Fringe theories/Noticeboard. The fact that that board exists seems to indicate that this question is not one that many think likely to arise.
Q5:See answer to Q4 above.
Q6:Again, see Q4 above.
Q7:This seems based on what may well be a substantially faulty premise, that this board would overlap others. Except possibly for the fringe theory noticeboard, I'm not sure that the questions raised here would overlap any other boards. Clearly, it would be a place to place comments about matters which may involve policy, but not necessarily be blatant violations of policy, again, like the existing fringe theories noticeboard.
Q8:As far as I remember, none of the noticeboards are not necessarily recommended for admins, just informed, capable editors. Also, the question ignores the fact that one other thing which tends to be true of admins is a greater familiarity with policies, and, yes, the advantages in argument bearing that title implies. I have already been in situations where regular editors have been belittled by those who seek to add or change content, but treat admins with more respect. As a nonadmin, I note most of my colleagues also tend to speak a bit more carefully around those who will often know policy better than we do. Bringing in informed editors of any stripe easily and quickly can often help resolve issues which are often intractable without such informed outside input.
In short, while I acknowledge those "downsides" can be seen to exist, to me they seem to be "reaches" for objections. John Carter (talk) 22:36, 5 December 2007 (UTC)[reply]
I think creating a Wikipedia:Neutral point of view/Noticeboard, a noticeboard for all alleged violations of WP:NPOV, akin to Wikipedia:Biographies of living persons/Noticeboard, would be more fruitful. AecisBrievenbus 00:46, 6 December 2007 (UTC)[reply]
I'd agree Wikipedia:Neutral point of view/Noticeboard would indeed be better than Wikipedia:Politics and society/Noticeboard. Thanks, Luc "Somethingorother" French (Just so long as we don't wind up with Wikipedia:Assume good faith/Noticeboard or Wikipedia:Ignore all rules/Noticeboard) 09:19, 6 December 2007 (UTC)

Aecis, I appreciate your editing of my "ïnterruption" (below) and I understand the talk about noticeboards, particularly one for all the violations which don't conform to a policy. So can you give me some idea of where a new person might go to get a feel for the culture of Wikipedia stuff? I mean, if a person makes a start, is there some way you have of introducing them to what is going on, how the tools are meant to be used and how one is meant to conform, apart from having their first article deleted or, through their focus on one question, being made to feel like fool?

I think John's idea of "a central location to discuss these matters" is really terrific, if one could do such a thing in this online environment. In the méantime would you put any comments on my page. In return, I'll do the same on yours (as seems usual around here). That way we can be certain no one else will learn a bloody thing.--Simonfj (talk) 05:08, 10 December 2007 (UTC)[reply]

Question 6. I've just been running through the backlog page [[3]] Whoah! I've also been commiserating with an administrator who, while doing their job, has deleted an article signed by Mr. Wales which aims to further the Foundation's aims. [[4]]. So I've got nothing but respect for admins who must interpret contentious policies and articles, and take the flak.

Yu ask "which process is currently substandard". Just go to meta's front page [[5]] and click on the Communications Projects Group. This is where it starts, or doesn't. The problem here (as it appears to me) is that while a wiki is a fabulous tool in putting articles together and building interactive global libraries, it's not the right tool for helping people get orientated or explaing where they've gone wrong, or coming to an agreement on their understanding about an article. Or keeping track of the latest FAQ's thrown up by some remote group coming across an article for the first time.

In short, there are no classrooms to which a newbie might be directed or get orientated after they've found one article or visited one shelf (one directory) of a Wiki(project's) library. So we have (here) what appears to be an endless discussion about NPOV as opposed to a place where different interpretations of its meaning might find an understanding. The same can be said for any article.

All I see are opportunities here for the most influential groupings of interactve global librarians in the online world. But it will require our trustees to see that at some point Wikis cannot be the only tools used if global groups are to share their (specialist) knowledge with their common communities of interest. And it will require Wikipedians to make a thorough (and hopefully reasonably quick) examination of the (latest) communication tools available and then agree on the ones which they want to share.

If we can get this far, I'm sure we will find a sponsor of them --Simonfj (talk) 22:38, 9 December 2007 (UTC)[reply]

The suggestion of a Wikipedia:Politics and society/Noticeboard seems sensible. The problems are occurring as we speak and will likely get worse in 2008. It would be good to have a central place to adjudicate and centralize real world political problems. Is there a cost to doing so? In other words, if no one uses it, who cares? Can it actually do harm? I doubt it. Cheers! Wassupwestcoast (talk) 22:48, 10 December 2007 (UTC)[reply]
I don't see the proposal as being in any way superior to the board already set up for firefights... WP:AN/I, which is watched and checked regularly by those with the time to fight fires on any given day and time. Moreover, as a page consistently checked by our Admins, suggestions by others frequently lead to a consensus way to handle whatever repetitive occurrences are inflicting the project in any particular period... such as the current USA election cycle. Pages which are "assaulted" as hypothesized will be best watched by notifications and renotifications therein, and appropriate consensus will then lead to protects of targeted pages... which can then use {{Editprotected}} mode submissions to further a page in non-controversial ways, or by talk page consensus. In short, I believe we really already have this circumstance covered, and the watchdogs therein know all the tricks to detect a systematic attempt to circumvent our consensus... and if necessary, a few admins on alert can quickly block an IP or range of IP's who are (Ahem) "Misbehaving" with edits, whether just an individual, or an orchestrated effort. // FrankB 18:50, 11 December 2007 (UTC)[reply]

Add a Slideshow template, based on existing functionality in French wikipedia

This has been discussed here recently, but I'm creating a new topic to specifically request addition of two functions to en:MediaWiki:Common.js that would enable Template:Slideshow. You can see other recent relevant discussions at Wikipedia:Village pump (proposals)#How about Not a picture book? and Wikipedia:Village pump (proposals)/Archive 5#Image gallery.

What is it?

Template:Slideshow is a straight translation of fr:Template:Images. It would place a box on a page that displays a sequential selection of images when the user clicks on forward and back buttons. For an example of the French template in use, see fr:Pétra (sections Géologie and Pétra dans les arts, for example). The template recommends all images to be of similar size.

Why is it needed?

Some articles, such as those about artists and series of art works, would benefit greatly from a way to present more images than can be comfortably accommodated by displaying them all at once. English Wikipedia currently has templates such as {{Gallery}} , but these display all images in the selection at once (or thumbnails of all images). In particular, I have wanted to use this facility in articles such as David Roberts (painter) and Boydell Shakespeare Gallery.

What change is required?

The French template relies on two functions (toggleImage and ImageGroup) in fr:MediaWiki:Common.js. I have translated the basic French template (and renamed it as Template:Slideshow). For it to work properly, it needs either those two functions adding to en:MediaWiki:Common.js, or substitute functions identifying or creating.

Arguments in favour

  • Would add a useful and unobtrusive image display for articles that have a legitimate requirement for multiple images in a series.
  • A good example of how Wikipedia can improve presentation of content compared to text encyclopedias.
  • Improves on-screen presentation of multiple for the the bulk of users.
  • Definitely preferable to Template:Gallery in many cases.
  • For users without JavaScript enabled, gracefully falls back to display all images in vertical table.
  • Independently requested several times recently.
  • Gained considerable support in discussions (see links above).
  • Mirrors functionality used successfully on many other reputable sites, such as BBC News

Arguments against

  • Requires more functions in Common.js
  • May encourage inappropriate padding of articles with many images (possibly of dubious merit)
Can be handled by existing or new policy. Template is not infinitely extendable (max: 20 images). User:Rupert Clayton
  • Non-JavaScript users see a vertical table of images that is arguably uglier than Template:Gallery produces
  • Commons already offers the concept of galleries to address this issue.
I feel that Commons galleries serve a different purpose. They're not integrated side-by-side with Wikipedia's encyclopedic content. Many novice users won't make the two clicks required to get to a Commons gallery. Commons galleries generally include all relevant works, not just the selection one would want to present in a Wikipedia article. User:Rupert Clayton
There's a bug report here Bug 5383 that refers to a Commons script that users can add to their monobook.js. The idea sounds good (though I couldn't get it to work, even after a refresh), but it's a different animal from offering inline slideshows on Wikipedia. Rupert Clayton (talk) 19:02, 6 December 2007 (UTC)[reply]

Things to check

Could a user with JavaScript knowledge please scan the functions (toggleImage and ImageGroup) in fr:MediaWiki:Common.js to see if there's anything of concern in the code?

Also can someone advise on whether any existing functions in en:MediaWiki:Common.js offer similar functionality? Rupert Clayton (talk) 20:33, 5 December 2007 (UTC)[reply]

Well that's my request. I'd be grateful for comments. Thanks. Rupert Clayton (talk) 18:25, 5 December 2007 (UTC)[reply]

I think it at least warrants a couple of weeks of testing it live. I'm not 100% enthusiastic about it, because i'm not sure people will be able to control themselves in adding it to every single article, but it does have some interesting advantages. --TheDJ (talk • contribs) 19:30, 5 December 2007 (UTC)[reply]

Additional note... We should first do some thorough testing on various browsers to determine the technical limitations of this technique. If {{Ambox}} has taught me anything, it is that browsers can do weird things with the most simple html at times. --TheDJ (talk • contribs) 19:35, 5 December 2007 (UTC)[reply]
Sounds sensible. As this template is already used by the French Wikipedia, presumably we can simply test relevant French pages in whatever browser combinations we want. Any issue with this approach? Is there a list of browsers we should be trying to support, or other info on compatibility testing? Rupert Clayton (talk) 20:31, 5 December 2007 (UTC)[reply]

Another thing we should consider is the "non-portable"-ness of this. What if people want to move this to another wiki, or worse to print? It has detrimental effects on the quality of the article in that case. Perhaps we should find a way to switch to a matrix of images in that case, with the matrix similar in dimensions as the original included slideshow. A more unobtrusive way of presenting the images at least. Perhaps AzaToth (Twinkle) or Duesentrieb (wikiminiatlas) has some good ideas. --TheDJ (talk • contribs) 21:23, 5 December 2007 (UTC)[reply]

As far as I understand it, if someone wants to include an article from Wikipedia that uses the Slideshow template on another wiki, then it would depend on the configuration of Common.js on that wiki's servers. If the functions are present, they'll get the slideshow. If they're not, they'll get the non-JS presentation. So this issue is another aspect of the failover behaviour. Let's say we have six images 250px wide by 150px high. In the current, French implementation, the failover version shows a table with all six pictures and captions, each at 250px by 150px. Text wraps around this table (in most browsers, not currently IE7, see below), which means the on-screen presentation is still fairly decent, so long as there's a high enough ratio of text to images. Are you suggesting that (in our example case) the failover option would be a single 250px by 150px image with a matrix of thumbnails? If so, that sounds good, but I imagine creating this on the fly wouldn't be easy/possible (particularly without JavaScript). I guess a failover image (possibly a hand-made matrix) could be specified in the template parameters. But that seems like a lot of work to impose. Am I understanding your idea right? Rupert Clayton (talk) 22:52, 5 December 2007 (UTC)[reply]

Here's another idea for failover. I'd appreciate the comments of anyone with more Wikipedia template knowledge than me (err... that's everyone). If JS is not enabled, or the relevant JS functions are not loaded in Common.js, then the first image from the slideshow is displayed in a regular image box at the position the slideshow would have occupied, and the full selection of images is shown in gallery format (horizontal table with multiple rows if needed) at the end of the article. This seems a graceful failover mechanism, but I can imagine it may not be technically possible (especially without JavaScript enabled). Can anyone enlighten me as to whether markup in one portion of a document can reference another portion? Seems like this already happens for reference tags and categories, but I guess those are special cases. Rupert Clayton (talk) 22:52, 5 December 2007 (UTC)[reply]

Browser tests

Tested fr:Pétra in Firefox 2.0.0.11 on Windows XP SP2. With JavaScript enabled appears to work fine. With JavaScript disabled falls back to display all images from the slideshow in a vertical table (as intended). Rupert Clayton (talk) 20:55, 5 December 2007 (UTC)[reply]

Tested fr:Pétra in IE 7.0.5730.11 on Windows XP SP2. With JavaScript enabled there are a couple of glitches: (1) left and right arrow icons do not display, and (2) slideshow box fills entire page width (rather than text wrapping around box). More testing needed to determine cause of each issue here. With JavaScript disabled, IE7 falls back to display all images from the slideshow in a vertical table (as intended). Again, this is within a full-width box (issue 2 above). Rupert Clayton (talk) 21:24, 5 December 2007 (UTC)[reply]

Tested fr:Pétra in Safari 3.0.4 on Mac OS X 10.5 With Javascript enabled works fine. With JavaScript disabled falls back to display all images from the slideshow in a vertical table ( as intended) --TheDJ (talk • contribs) 21:23, 5 December 2007 (UTC)[reply]

Tested fr:Pétra in Opera 9.24 on Windows XP SP2. With JavaScript enabled appears to work fine. With JavaScript disabled falls back to display all images from the slideshow in a vertical table (as intended). Rupert Clayton (talk) 23:18, 5 December 2007 (UTC)[reply]

Discussion

  • The sound of silence is rather daunting as evidenced in the lack of other users posting here on this... suspect there be a language to brower issue involved, as for me the slideshow alledged in the fr:Pétra is nowhere in evidence in three trips, but it's not a language my browser even has as an alternate. Can the esteemed nominator provide a way to load an English script here which will enable us to view the benefits of changing the .css? Alternatively, a direct link to a commons page where it's been put to use, presuming that css page will load the proper code. Thanks! All in all, if this is feasible it would really help in many articles to unclutter the prose, if used judiciously. I give it a hearty "I hope this works!", and kudos to Rupert Clayton for bringing this to the community. // FrankB 04:48, 12 December 2007 (UTC)[reply]
Yeah, I've just started looking in on this page, and I think this is a great idea. Even if users go a little crazy with it (and I expect they will, even though I haven't seen {{gallery}}s all over the place), the benefits seem to outweigh the dangers. I support the motion. – Scartol • Tok 18:37, 12 December 2007 (UTC)[reply]
  • Simplest solution would be to make the whole template noprint class... which as far as I know, means it wouldn't make it to the local browser at all. Someone more familiar with the matter have any insights? // FrankB 18:30, 14 December 2007 (UTC)[reply]
  • It seems to work very well in the articles I've seen in French Wikipedia. It seems useful as a more compact alternative to <gallery> especially for groups of closely related images. - Neparis (talk) 21:26, 15 December 2007 (UTC)[reply]

I would prefer external links to open in a new window/tab. There should be a preference setting for this. Peter J. de Bruin (talk) 23:05, 5 December 2007 (UTC)[reply]

It's typically not a good idea to force links to behave one way or another. You can, however, put your cursor on a link and click the middle (scroll) button. This will open the link in a new tab. —Remember the dot (talk) 05:36, 6 December 2007 (UTC)[reply]
Shift-click will also open in a new window/tab, depending on your browser. A modification that alters the way that pages are presented and linked would probably require a change to the Mediawiki software itself. (You might first ask at Wikipedia:Village pump (technical) if there's a way to modify your personal javascript to do what you would like, however.) I suspect that you may have to file a feature request on Bugzilla. TenOfAllTrades(talk) 14:44, 6 December 2007 (UTC)[reply]
Well, that's one school of thought. The other is that as long as the user is informed in some way that a link opens up in a new window, it's all right. Stevie is the man! Talk • Work 16:43, 7 December 2007 (UTC)[reply]
I can see the use (for some people who like that sort of thing) of having an option to have external links open in a new window. I hate, however, web sites that force my browser to work in a nonstandard way—for example by deciding that all new links ought to open in a new window, whether I want them to or not. That nonstandard behaviour creates clutter and it makes it more difficult to find out where the thing I just clicked on is supposed to open. Simply forcing a change on our readers wouldn't be acceptable, even if we provided a notice that we were implementing such nuisance behaviour. TenOfAllTrades(talk) 16:56, 7 December 2007 (UTC)[reply]
Nothing forces your browser to do anything it wasn't programmed to do; if you don't want your browser to give that power to web pages, install firefox and the "tab browser extensions" extension (click tools -> addons -> get extensions and search). Then you can specifically configure what your browser allows web sites to do. No relevance to the proposal, just FYI. —Jemmytc 23:18, 14 December 2007 (UTC)[reply]
That it's "nonstandard" is also debatable. "_blank" is a valid target in most versions of HTML, the last time I checked. Making external links open in a new window is common, and I've never received complaints from any of my sites where that happens. Stevie is the man! Talk • Work 18:36, 7 December 2007 (UTC)[reply]
Target, as an attribute of a link, was deprecated in HTML 4.01. For the attribute, however, _blank is an acceptable value. GracenotesT § 07:05, 8 December 2007 (UTC)[reply]
Considering that the only web browser in the world that can override an "open in new window" link to open in the current window is Opera, forcing links to open in a new window is bad. --Carnildo (talk) 09:41, 8 December 2007 (UTC)[reply]

I wrote a user script that did this a couple of months ago. Let me find it. GracenotesT § 01:13, 8 December 2007 (UTC)[reply]

Okay, here we go: 

addOnloadHook(function() {
    var alinks = document.getElementsByTagName("a");
    var tablink, sitename;
    for (var i = 0, leng = alinks.length; i < leng; i++) {
        tablink = alinks[i];
        if (tablink.className.indexOf("external") != -1 && tablink.href.indexOf(wgServer) != 0)
            tablink.target = "_blank";
    }
});

To open the link in a new window, replace "_blank" with "_window". To open it in a new tab, replace "_blank" with "_tab" (this only works in Firefox). Leaving the target as "_blank" will result in your browser's default action, and nothing if popups are blocked. GracenotesT § 01:42, 8 December 2007 (UTC)[reply]

Thanks, but still, having it available as an optional setting for everyone would be an improvement. Peter J. de Bruin (talk) 12:49, 8 December 2007 (UTC)\[reply]

Well, we do have a new Gadgets tab (in my preferences) which makes implementing JavaScript user scripts like this a matter of a couple of clicks. (There's a section at WP:VPT about this, at the moment.) So it is possible to offer this to editors as an option. -- John Broughton (♫♫) 14:30, 8 December 2007 (UTC)[reply]
I've suggested it here: MediaWiki talk:Gadgets-definition‎. I'm not sure if there is a centralized place for suggesting scripts, though. GracenotesT § 22:10, 8 December 2007 (UTC)[reply]

I find that when searching through long Wikipedia articles, it is often easiest to use the table of contents to navigate. Therefore, I think that there should be a "back to the top" link directly underneath the "edit" link at every paragraph, because scrolling back to the top is an arduous process for the fast browser. Does anyone else see the benefit in this addition?? —Preceding unsigned comment added by 153.104.101.29 (talk) 20:52, 6 December 2007 (UTC)[reply]

In most browsers, pressing the keyboard's "Home" key will bring you to the top of an article. In addition, the browser's back button can help you jump from a clicked section header back to the table of contents. Hardcoding such a feature into the webpage might be useful for some visitors, although I would personally not get much use out of it. GracenotesT § 18:17, 7 December 2007 (UTC)[reply]
I think Gracenotes' alternatives are viable, especially since a "back to top" link would potentially clutter the page (which is sometimes already cluttered as it is). EVula // talk // ☯ // 19:06, 7 December 2007 (UTC)[reply]
Right clicking the scroll bar and selecting "Top" will do it, too. Corvus cornixtalk 19:32, 7 December 2007 (UTC)[reply]
In what web browser? Neither Opera nor Firefox has that feature. --Carnildo (talk) 09:43, 8 December 2007 (UTC)[reply]
In Internet Explorer. Anyway, I'd think this feature could be useful - navigatibility vs. aestheticness is always a tough one to pick from. I drew something up in my Sandbox - the link doesn't work, but it's what I think it may well look like. To me, this isn't obtrusive. x42bn6 Talk Mess 22:24, 8 December 2007 (UTC)[reply]
I think the suggestion was to have it in more than one place, though; specifically, under each heading (which would get very cluttered very quickly). EVula // talk // ☯ // 23:14, 8 December 2007 (UTC)[reply]
Huh. I never knew that Firefox and Opera didn't have that feature. Well, score one for IE.  :) Corvus cornixtalk 04:14, 9 December 2007 (UTC)[reply]

This is actually a pet peeve of mine. The links clutter up the page a bit, and there are lenty of other easy ways to get to the top: Scroll bar, scroll button, Home, and Back. If this were (hopefully not) implemented, it would have to be a changeable preference. Reywas92Talk 23:40, 8 December 2007 (UTC)[reply]

Well, there would always be the option of turning it off via your monobook file. EVula // talk // ☯ // 23:45, 8 December 2007 (UTC)[reply]

This is already implemented on Wikisource (see for example, wikisource:Gettysburg Address), though there it has to be added manually through a template. I agree Wikipedia would benefit from a similar feature (especially considering the length of some articles), which would however hopefully be implemented as part of the site interface.--Pharos (talk) 06:20, 14 December 2007 (UTC)[reply]

Redirects to sections in articles

Recently, I've been working on a template, User:The Placebo Effect/Sandbox3. The point of this templat is to list what redirects point to a section in an article and what section they point to. The idea is, the bot will run every 2/3/4 weeks to update the template on every talk page. Suggestions? Comments? Concerns? --The Placebo Effect (talk) 06:14, 8 December 2007 (UTC)[reply]

A list of pages linking to a section of the page would be useful too. (Or alternatively, Template:ml (backlinks edit) is used for these links, so that Special:Linksearch can be used to find the pages linking to a particular section. A bot could change links to sections to this form. This method can also be used for redirects.)--Patrick (talk) 11:39, 8 December 2007 (UTC)[reply]
No, no, no. The standard is to put an invisible comment on the same line as heading, indicating what links to that heading (articles, redirects, whatever). Don't put a template on a talk page; when someone edits an article, they don't check the article talk page, and there isn't a snowball's chance that we can train editors to do so - and we shouldn't try. A bot to add invisible comments to section headings would be great. (I don't like the example at Wikipedia:Manual of Style#Invisible comments about not changing a section heading; it should read something like "If you change this section heading, you should also change the link to it at pagename.")
(In fact, User:Anchor Link Bot was supposed to be doing this, but hasn't run since July.) -- John Broughton (♫♫) 14:10, 8 December 2007 (UTC)[reply]
I changed that example.--Patrick (talk) 14:23, 8 December 2007 (UTC)[reply]
As I understand this, Patrick is suggesting that the bot put a template into (say) article A, which has the link to ArticleB#Section C. I'm suggesting that the bot not place a template on the talk page of article B, but rather put an invisible comment on the heading line. So there isn't an disagreement there (we're looking at the two halves of the situation), and both of us agree that a bot would be invaluable for this. -- John Broughton (♫♫) 18:24, 8 December 2007 (UTC)[reply]
Now I'm confused - how does it help to say there is a section link from a particular article? I can just look at the source and see the link. On the other hand, the destination page has no evidence that there is an incoming section link unless a note is made. — Carl (CBM · talk) 22:06, 8 December 2007 (UTC)[reply]
A bot that puts an invisible comment on the heading line would be good. The Template:Ml I mentioned as alternative would not be for providing info itself, but for enabling Special:Linksearch to provide link sources for a given target.--Patrick (talk) 00:43, 9 December 2007 (UTC)[reply]
I have to agree that the template in the sandbox seems ... like something that will be ignored. As a bookkeeping method for a BOT, it may have promise, but if used at all, please locate after interwikis! Page tops are already too busy.
Unexpected use of template {{2}} - see Template:2 for details.OTOH, I may have given you a 'Stealthed Start?' - Template:Redirectstohere(edit talk links history) was generated with just this problem in mind between me and CBDunkerson, though has no "BOT thought" in it's philosophy. The template poses a direct warning to editors that changing the titleline requires fixing other section type links (one hopes they check the usage, anyway, if they aren't familiar with it! <G>)When the template is given "|hide=something" disrupts sections minimally, causing a single newline which is all but unnoticable in most cases... really only evident with a {{main}} or other {{dablink}} template also present in the section head, and those instances can usually cure the hide mode's newline by reversing the order and nesting the }}{{ respective "End templates" on the same line. The key difference is that an editor has the choice of overtly annoucing the destination of the redirect, or hiding it like the commented technique. Being a template, editors editing a section pay attention to it, or so one hopes! I've been hesitant to use it with links, save when checking for likely redirected names in the initial previews of a page, which I later "delinkify" UNLESS the section titleline is a really important titleline (so, maybe a half-dozen of those? About that, iirc). OTHO, adding the appropriate [[ ...and... ]] will provide a backlink to the redirect in the whatlinkshere of the page... sounds like some script comparison of the templates whatlinkshere, the articles, and checking of the templates, would pretty much allow a validate check of any applied use in this manner, assuming a BOT capable of checking all three links pages; OTOH, the main use is at article page tops just above the intro, as it's much simpler to apply than the various RedirectsNN templates, since the only thing it takes as inputs are redirect pages there's not all the headscratching about which one does what phraseology... and those really handle other (mainly disambig linking) needs in the main.Given that, Steal the code by redirect, AWB the current uses and substitute a redirect title, "redirectedto_this_section", which the "hypothetical" BOT can use to test links...
Unexpected use of template {{2}} - see Template:2 for details.If a BOT is used, suggest also that it make sure the redirect pages have proper {{R to section}}} tagging and preferentially, add a Template:I{{cat also|} {{PAGENAME}}|catlist... (of non-maintenance cats of the targeted page)}} in another or the same pass, as is convenient and possible. // FrankB 18:30, 11 December 2007 (UTC)[reply]

A humble request to all the user of Wikepedia...please make active contribution..

I feel sad that despite being one of the 10th most visited site in the world..still the number of people who made contribution is meager ...around 40,000.I would like to suggest that users are ready to donate...but all they need is little more understanding as to how a little contribution from them can make a huge difference...As in my case..it was only during leisure that I accidently clicked on the link that took me to web page and that is how I came to know how a little contribution can make a difference...people are so engrossed in looking for the article ..that they just glance at the message asking to raise funds..moreover the message is not flashy..the color combination is such that it doesn't catch user's attention..

So,I would ask you to please generate more awareness amongst people...just a little realization is all they want..and I bet...people would like to be part of this great cause...and will make our goal..goal of wikipedia that every single human being in this world can freely share their sum of knowledge.

As a suggestion,please change the font color and change it to something that catch user's attention or before allowing user to login...a web page should be displayed ..and it should include a message that would create a great impact on user and will make them realize about how a little contribution by them would play a major role in allowing this portal to be accessible to people who are deprived of it...or after user signout of Wikipedia...a web page must be displayed showing the status of how far are we from our goal and ask user to become active member of this common cause by donating..believe me..it would really allow us to accomplish our goal at fast pace... —Preceding unsigned comment added by 68.89.42.28 (talk) 01:22, 11 December 2007 (UTC)[reply]

No, it's actually a lot different than you think it is: Wikipedia has arond 60,000 registered editors. 5% of those are admins. So we actually are making an active contribution. Want to see how active? Go here. --Gp75motorsports REV LIMITER 03:07, 16 December 2007 (UTC)[reply]

Multi-Lingual Dictionary/Thesaurus

Greetings to all,

I am new to this area of Wikipedia, so forgive me if my suggestion is not new.

In the spirit of knowledge for all, and a belief that universal knowledge can break down the barriers of ignorance that I sometimes see in my many travels...

I would like to see a multi-lingual Dictionary and Thesaurus as part of the Wikipedia experience. I believe this would go a long way in helping people to understand the many cultures around this great world of ours.

Thanks,

Micheal B.

Kansas City —Preceding unsigned comment added by N0TYM2H8 (talk • contribs) 20:11, 11 December 2007 (UTC)[reply]

Hi, you might want to have a look at our sister project, Wiktionary! -- lucasbfr talk 20:44, 11 December 2007 (UTC)[reply]

Thank you! N0TYM2H8 (talk) 09:43, 13 December 2007 (UTC)[reply]

Hey folks,

I am not a programmer nor a frequent contributor to detailed Wikipedia discussions. As a medical student, I frequently use Wikipedia to refresh my memory on the multitudinous terms we have to become acquainted with. It would make my life easier, and I'm sure many other folks, if the search option returned a "suggested spelling" correction for items not found during search, similar to Google's "did you mean ___?". This would help not only with typos, but also because much technical jargon, like in medicine, can have varied spellings... or incorrect spellings for students who are learning and have only heard the verbal expression of a term. I hope y'all will consider this, I think it would greatly improve Wikipedia's function.

Thanks!

<name+location of user pulled to sustain user's privacy> —Preceding unsigned comment added by 67.11.200.238 (talk) 20:25, 11 December 2007 (UTC)[reply]

Hi, and thanks for your message. For alternative spellings, we normally use redirects from all usual spelling to the main article. If you wish, you can help by creating an account, typing an alternative spelling, and creating the redirect yourself! As a side note, I often use Google to search Wikipedia, just add "site:en.wikipedia.org" in your search query and google will only return results from Wikipedia. I hope that helps! -- lucasbfr talk 20:32, 11 December 2007 (UTC)[reply]

Thank you! I'll try that out. —Preceding unsigned comment added by 67.11.200.238 (talk) 20:37, 11 December 2007 (UTC)[reply]

This is already available and turned off for performance reasons. See Wikipedia:Perennial proposals. Dcoetzee 08:23, 12 December 2007 (UTC)[reply]

News content change

Recently, almost all the "In the News" topics are about recent deaths, hurricanes that caused death, death by shooting, crimes, etc. Is there any way that other news could be included? There are a lot of positive things going on in the world, and I think that we should balance the reporting of the negative with the positive. How about science news, or art news? Surely this world has other newsworthy current events that don't include death and dying. The sad stories are of course inevitable and newsworthy too, but let's aim for some balance please. —Preceding unsigned comment added by 63.215.129.228 (talk) 13:56, 12 December 2007 (UTC)[reply]

I agree, however this would be kind of difficult. To be an item in the news it must have an article to link to, because things such as break throughs in medicine are usually not given their own article while articles on wars are usually created overnight you have to expect some bias. -Icewedge (talk) 06:05, 13 December 2007 (UTC)[reply]

random article for various subject areas

I think their should be a random article generator for various subjects. e.g if you wanted a random article about maths you would go to the math's portal and click on the random article link their. Ziphon (talk) 04:50, 13 December 2007 (UTC)[reply]

I support. I also feel there should be a way to pick a random featured article and a random FA/GA article. Perhaps we can have a random article generation page. Subject wise randomization can be done by wikiprojects. Arman (Talk) 08:17, 13 December 2007 (UTC)[reply]
Given the limited number of FAs (I won't speak to GA's), it doesn't seem that difficult to set up a random article page - see this, for example: Portal:Middle-earth/Random-article.
As far as getting readers to it, perhaps a link in the "Today's featured article" section of the Main Page, so the links at the bottom of the page would then read Archive – By email – More featured articles - Random featured article -- John Broughton (♫♫) 19:53, 13 December 2007 (UTC)[reply]

See bugzilla:2170. It is possible to get a random article from a category (e.g. Category:FA-Class articles), but for performance reasons this is disabled on Wikimedia wikis. GracenotesT § 20:31, 13 December 2007 (UTC)[reply]

Important article statistics on mainspace

One of the main criticisms of Wikipedia is that its articles are often not reliable. Whenever Wikipedia or Wikipedia fans try to defend this complaint, they generally stress that the reliability of a Wikipedia article can be checked with a few simple tests. Like:

  • If the article has verifiability / factual accuracy / neutrality tag - it is likely to be unreliable. In such cases it is advisable to consult the discussion page along with the article page.
  • The older the article, the higher the chances for the article to be stable and reliable.
  • An article on which several unique editors have contributed is likely to be more reliable than an article edited by only one or a few editors.
  • Article subject to a very recent change or high frequency of changes in recent time may have lower reliability as other editors have not yet got the chance to validate these changes.

All these sound very simple to experienced Wikipedians, but most new comers are not familiar with the way to check all these.

That’s why I propose the following:

There should be a small but prominent box (with small font) showing the vital information of the article at a visible location of article mainspace. It may be in article header, footer or even right below the Wikipedia logo on left hand side. The box should contain the following information:

  1. Whether the article is an FA or a GA. Omit this line if it is not.
  2. Whether the verifiability / factual accuracy / neutrality / notability of the article is disputed. The "disputed" word may be linked to the talk page. If there are no disputes, this line should be omitted. Also if this is implemented, the "ugly" tags that now appear at the beginning of articles should all be removed.
  3. How old is the article and when it was last edited.
  4. How many unique editors have contributed to the article; and
  5. How many edits it received in last 24 hours. May omit this line if there were no edits in last 24 hours.

Although I have proposed 5 sentences, with the proposed omissions, for most articles the number of sentences will come down to 2-3.

These are the vital information that a reader should know to decide how to use an article or to what extent the article can be relied on. So I think these information belong to the article page. Arman (Talk) 06:28, 13 December 2007 (UTC)[reply]

This is not a bad idea. Actually, it is a good idea. Anecdotally, I know from my experience with casual non-editors who use Wikipedia that they have no idea about checking the 'discussion' or 'history' tabs. They simply read the article. These people would notice an info box of the type proposed - and I suspect that they are by far the most common users of Wikipedia. Cheers! Wassupwestcoast (talk) 13:55, 13 December 2007 (UTC)[reply]
It's definitely better than the huge ugly banners that are there now.
However, I have a suggestion. The current banners added to protected articles are ugly (that's why some administrators replace them with padlocks). Perhaps this could also be mention in the box (and omitted if the page isn't protected).
Furthermore, if consensus is gained, maybe we could get a bot to transform the current banners to this compact box.
What I'm, unsure about is the placement of this box. I don't think a footer is enough of a prominent place, as you pointed out, this is an important thing for users to know. My ideas are the toolbox (along with interwiki links), but I'd prefer it in the header. Puchiko (Talk-email) 14:48, 13 December 2007 (UTC)[reply]
Good idea in concept but I suspect that most readers wouldn't have any idea what to make of those statistics. Do you think it would be feasible to boil down the statistics to a single number: a reliability rating? Sbowers3 (talk) 17:01, 13 December 2007 (UTC)[reply]

Wikipedia does not make disclaimers about the reliability of its articles, and a heuristically based disclaimer may cause more harm/speculation than good. As Sbowers3 said, most readers might not understand (and even make incorrect guesses) about what the statistics mean. The 24 hours line may be a problem, since that cannot be cached – I'd imagine it must be calculated every time a user visits a page. The reason why Wikipedia's servers are efficient is because they cache (hold copies of) pages for the next time someone requests it. he last-modified date can be seen at the bottom of the article, in the white box with the orange border. The rest of the statistics can be cached, it looks like, but the database load of it all might be too much. GracenotesT § 17:55, 13 December 2007 (UTC)[reply]

It sounds like a great idea in concept, but technologically, as Gracenotes points out, it is costly. I think we might be better off abandoning this in favour of using the effort towards implementing FlaggedRevs, which would probably be more effective anyway. :) Nihiltres{t.l} 18:24, 13 December 2007 (UTC)[reply]

At the least it might be an informative thing for our casual readers if we started putting {{ArticleHistory}} on the front side of our articles.--Pharos (talk) 06:38, 14 December 2007 (UTC)[reply]

Simplifying proposal for technical feasibility

Thanks everyone for the feedback. In general there seems to be a consensus that this is a good idea - at least better than the "ugly" tags we have now. As far the article rating suggestion is concerned, we should rather allow the readers to interpret the "facts" given in the box, than giving a conclusive remark on the reliability of the article, which would be too subjective and debatable. So far the strongest objection to this has been on technical limitations. I strongly feel technical limitations tend to be short lived. What seems impractical today may become very simple in few year's time. But still, let's think whether the following suggestion makes it more practical given today's technology: Let's have the box with the first 3 points: the GA-FA status, The quality tags and the first & last edit dates. Then we have a (show more) link which, if clicked, will retrieve the two more processing-capacity intensive points - number of unique editors and number of edits in last 24 hours. May be we could think of a few more points. Does it sound more practical now? Arman (Talk) 08:58, 14 December 2007 (UTC)[reply]

It is worth mentioning that there are academic research projects on-going looking at client / browser side solutions to the article credibility problem. You may wish to check out these external sites: U of California Santa Cruz Wiki Lab' Wiki Trust Coloring, PARC's Wikidashboard and an article in The Chronicle of Higher Education. Cheers! Wassupwestcoast (talk) 17:34, 14 December 2007 (UTC)[reply]

Recalling admins

It has been suggested in the past that admins should voluntarily make themselves open to recall. A slightly more formalized idea is suggested at Wikipedia:Admin Accountability Alliance; comments welcome. >Radiant< 18:34, 13 December 2007 (UTC)[reply]

Better cross-referencing between wikipedia and sister projects

Here is a suggestion; I don't know if it has been brought up before or not. I would like to see more cross-referencing between wikipedia and its sister projects...in case this isn't clear, let me explain. There is often a link for wikiquote or wikipedia commons on an article page, but I would like to see more, similar sites linked. For instance, I am a frequent traveler, and I love wikitravel. It would be helpful, say on a wikipedia page on Egypt, to have an "official" wiki link to the wikitravel Egypt article, and maybe a link to the wikiversity page on learning Arabic. It seems like this would create a more cohesive, integrated wiki experience, rather than having to go to each site independently. Amssports06 (talk) 21:37, 13 December 2007 (UTC)[reply]

This does happen to some degree; articles on words often link to the wiktionary definitions. But we wouldn't link to any other travel agency in an article on Egypt, so why would we link to Wikitravel? -Amarkov moo! 01:49, 14 December 2007 (UTC)[reply]
You may be surprised to learn that Wikitravel, despite the similar name and the somewhat similar method it operates on, is not actually a sister project to Wikipedia. You can learn all about our actual sister projects at Wikimedia Foundation.--Pharos (talk) 05:51, 14 December 2007 (UTC)[reply]
More on this (an active discussion) as a generalized proposal above at #Simple_English_Wikipedia, and #Expand_to_more_generalized_solution. // FrankB 17:46, 14 December 2007 (UTC)[reply]

)

Ok, thanks a lot. I am surprised to learn that Wikitravel is not a Wikipedia sister project! Thanks for your input.

Amssports06 (talk) 23:49, 14 December 2007 (UTC)[reply]

Optional display options panel

This one just struck me. How about an (optional, of course) options panel which has clickable options for such things as "hide links" (which are distracting in overlinked articles), "hide refs" (I've seen objections to distraction from superscripted cite.php ref links), etc. Panel display off/on and panel option population should be configurable in "my preferences", as well as panel placement (top/bottom of article, top/bottom of window, whatever). Clicked options could be saved in cookies or in user namespace, (I'd vote against saving them as cookies) and saving them could itself be an option. I'm not a WP developer, but this is simple stuff to implement for someone with javascript and css skills. -- Boracay Bill (talk) 12:38, 14 December 2007 (UTC)[reply]

Isn't a better solution to overlinking to just remove some wikilinks? And as for footnotes being distracting, are you really saying that a lot of people find the tiny superscipts (which tell you which statements have a cited source and which don't, and therefore give you clues as to credibility) to be irritating? (If so, then wouldn't you want to also turn off the really big, ugly numbered external links?) -- John Broughton (♫♫) 14:13, 14 December 2007 (UTC)[reply]

A Sister-project to allow 'Signed Versions' of Articles

Okay, this is a biggie and would need lots of input and thinking before anything like this could ever happen, but it's been in my head for a long time, and I think sooner or later, SOMETHING like this is going to be essential for us.

Technically this calls for a new wiki-project, but since the goal of that project basically to "he Wikipedia in its goal to build a better encyclopedia", I would really like to get Wikipedians take on it, so I posted it here. —Preceding unsigned comment added by Alecmconroy (talk • contribs) 16:56, 14 December 2007 (UTC)[reply]

A need

The first part of improving something is to recognize a need. We have some problems. Not problems, per se, but needs. Issues that are preventing us from being as good of an encyclopedia as we could. Specifically:

  • Educators and researcher can't trust our articles, because at any given point, our quality can't be assured. While we hope the mean value of our articles averages out to be trustworthy, any particular instance of our article may or may not be trustworthy. This means nobody can cite us as a reliable source, no matter how good an article we have.
  • It's not enough to know about a topic and to be able to write-- if you want to improve Wikipedia, you need a whole third skill of "consensus generation" to get your improvements added to the article. Knowledgeable skilled writers want to spend their time writing, not arguing.
  • Additionally, there's no guarantee that the "best writers" will be the people who are "best as generating consensus". The current system tends to favor "time-rich, ultra-passionate" editors, while disfavoring "time-poor, dispassionate" editors. If you care about a topic immensely and have infinite amounts of time to pour into fighting for a POV, you're probably going to "win" by attrition, as the outside editors who are less passionate get frustrated and aren't willing to devote the same amount of time.
  • Our articles are subject to entropy-- if we got a "perfect" article, it would tend to degrade over time, unless actively "defended" by editors. Time spent being a "defender of the encyclopedia" is time that could be spent improving the encyclopedia.

My wiki-life, two years ago and now

So, let me give examples from my own experience on Wikipedia. As Wikipedia has grown, our focus has shifted from "pouring knowledge into the project" to "stylistic tweaks". A few years ago, my on-wiki time was totally pleasant and highly efficient. It went like this:

  1. Search for something on Wikipedia.
  2. Wikipedia doesn't have the article/fact you're looking for.
  3. Go find the information you're looking for using Google
  4. Add that information to Wikipedia.

Simple. Our "Massively-Multieditor" style works very very well in these instances.

But now, many years later, it's very hard to find information that is completely missing from the project. Instead, at the same time, I still see articles all the time that, although broad and comprehensive, could be improved stylistically-- especially in controversial areas. Here, though, the editing pattern isn't pleasant and efficent, it's frustrating:

  1. Search for information on Wikipedia
  2. Notice that article that has stylistic problems, organizational problems, or balance problems
  3. Do research to figure out how to improve article
  4. Spend 10% of the time improving it
  5. Spend 90% of time debating with other editors to get those improvements actually accepted.
  6. Fight entropy indefinitely, in a never ending battle, as new editors add information that sometimes improves the article, but sometimes degrades it.

I am at the point where, I feel like I could be much more use to the project if I could spend all my time doing rewrites of articles, and less of my time arguing over whether the rewrites are better or not, and then fighting entropy to get those versions accepted. I think there are probably a lot of people like that.

The point being is, when it comes to pouring information in, "Massively Multieditor Collaboration" works very very well. But when it comes to polishing and creating beautiful finished-product articles, "Massively Multieditor" doesn't work as well. Pouring information in is a Bazaar-style task, polishing it to the point of perfection is a Cathedral-style task.

How could we be even better?

So, here's my question: Is there any way we could, through some sister-project, allow forks of articles are instead of being "anyone can edit" are 'signed encyclopedia articles'-- i.e. articles that have one person has editorial control over.

Here's my first tentative thoughts on how something like this would work.

  • Wikipedia itself would stay exactly the same. We NEED a Wikipedia, Wikipedia works incredibly well, we don't want to in any way damage Wikipedia by changing its policies.
  • Wikipedia would still be the "main" version of the article, the default version of the article, the Wikipedia version of the article-- one absolutely anyone can edit, keeping Wikipedia exactly as it is, with no no changes whatsoever to Wikipedia or Wikipedia policy.
  • There is a closely-affiliated "sister project" where anyone can create a 'signed version' of an articl, over which they have final editorial control.
  • Anyone could edit the 'signed articles', groups can collaborate on a 'signed article', but one editor would maintain the final say-so over which edits are accepted. No edit-warring against that editor on the article bearing his signature.
  • Wikipedia readers will have some way of knowing about the existence of 'signed versions of articles', so that they can leave Wikipedia and view the 'signed versions'
  • Editors have some system of "endorsing" the signed versions-- some 'signed versions' will be very popular, whereas signed versions by minority voices will be less popular. When presenting the list of 'signed versions' to readers, these endorsements can be used to rank the signed versions perhaps.
  • The set of articles "an editor has signed or endorsed" can become an mini-encyclopedia unto itself. A credentialed professor, for example, might lend his name or endorsement to a set of articles that he considered to be quality articles-- the professors students could then "trust" those articles and cite them. Etc.
  • People can discuss and debate the merits of signed versions, so that readers can have full access to seeing which 'signed articles' are controversial and which are not.


Pros and Cons

The UPSIDE of such a system is:

  • We get to keep Wikipedia, the "encyclopedia anyone can edit". This is essential, of course.
  • We still have wikipedia, with 100% collaborative articles that no one owns which are required to be NPOV and V and etc.
  • The existence of the 'signed versions' would enrich the main wikipedia articles, because we could copy the best parts from the 'signed versions' into the wikipedia article whenever we want.
  • Since the signed articles have to be free-license, people can can copy anything from the 'other signed articles' into their own signed versions.
  • Like-minded people can collaborate on their own articles, creating a 'signed article' that is still highly-collaborative.
  • People who want to write and only to write have a way to contribute their writings in a way that doesn't require them to spend time edit-warring, fighting, arguing.
  • On Wikipedia, we should see less time spent dealing with POV-pushers, conspiracy theorists, lunatics, etc-- because those people will still have a forum to express their opinions in their own signed articles. They won't feel it's a choice between being "censored" or "being in Wikipedia"-- there will be an easy middle ground they can refer to.
  • The 'signed articles' will be mostly vandalism and entropy-proof. With some minor software changes, "mostly" could become "totally".
  • Writers who like to write can spend more of their time writing. Editors who like to edit and polish can spend more of their time editing and polishing. 'Publishers', who like to find good articles and promote them, can spend time finding the "best signed articles" and endoring them. No more spending 10% of your time improving the project and 90% of the time arguing over it.
  • This would solve our reliability problem-- a 'signed article' which was signed by an expert (or by some peer-review ala FA) would be a reliable source students could cite.

The Downside is:

  • Some signed versions won't comply with NPOV and V. We should expect that many of the 'signed articles' will be very bad-- little more than rambling blogs.
  • If not done carefully, people might tend to confuse this new sister-project with Wikipedia, and get confused about which is which-- which article is the 100% collaborative NPOV, and which article is 'Signed' (and therefore only as good as the person who signed it).
  • Time spent on the sister-project making signed articles will be time taken away from working on the 100% collaborative Wikipedia article. People would have less incentive to work out their differences and reach consensus, since their own 'signed article' could still reach readers even if they didn't have consensus.

Thoughts and discussion

So.. Wow, that's my scheme. I really feel like this, or something like this, will be the next big thing, the meta-wiki. Massively-collaborated and massively-forked, combined with a system to find the "best" of those forks.

One way to accomplish this would be to "fork" the project, to some extent this has already been done. Veropedia and Citizendium could both be regarded as sets of 'signed articles' with an emphasis on Verifiability and Credentialed Expertise. Wikinfo is a set of 'signed article' which experiments with Sympathetic POV instead of NPOV. Conservapedia is a sets of 'signed articles' with a focus on having a Conservative POV. All of these are good things. But instead of someone having to create a whole new project just to make your own 'signed article', I would like Wikimedia to give ALL of us the power to conveniently write our own 'signed articles', without having to bother with servers and software and projects.

One of Wikipedia big guiding principles is "freedom to fork", but at the moment, that freedom is inconvenient to exercise. I think it might be a wonderful wonderful thing if Wikimedia made a sisterproject to host such "article-level" forks, and then provided links from Wikipedia to this sister project.

So... what do you think? am I crazy? is there any truth to this? Am I on to something? Am I the 1000th person to suggest this, but there's a big reason it would never work? --Alecmconroy (talk) 16:50, 14 December 2007 (UTC)[reply]

Yup, you are about the millionth person to suggest such a scheme :-) On a more serious note, there is this experiment FlaggedRevs that will essentially promote two versions of articles on Wikipedia. Cheers! Wassupwestcoast (talk) 17:24, 14 December 2007 (UTC)[reply]
I figured it was too good an idea to come out of someone like me  :). I don't suppose you know where I could find such a discussion, and why it didn't end up happening? --Alecmconroy (talk) 17:31, 14 December 2007 (UTC)[reply]
If you check out Wikipedia:Flagged revisions/Sighted versions you get a bit of history. Similar ideas to yours are perenially debated - another credibility idea is just above us at Wikipedia:Village pump (proposals)#Important article statistics on mainspace. From my previous reading of similar discussions, two separate problems are often conflated: article degradation and article credibility. Your idea may be unique but the problem is often expressed — many solutions have been discussed — and nothing much comes of it. In addition, it is worth mentioning that there are academic research projects on going looking at client / browser side solutions to the article credibility problem. You may wish to check out these external sites: U of California Santa Cruz Wiki Lab' Wiki Trust Coloring, PARC's Wikidashboard and an article in The Chronicle of Higher Education. Cheers! Wassupwestcoast (talk) 17:51, 14 December 2007 (UTC)[reply]
edit conflicted--new post than above
Think WP:PEREN may cover some of this. But I and my frustrations agree with your problem statement fervently... Sometime back I hypothesized a slightly different approach. Imagine seven to fifteen editors who would act as a committee on matured articles to gate changes. Assume one needs an agreement of four (why below) of these for any proposed change using the {{Editprotected}} method, or better yet, a talk subpage where one can submit a "clean copy" of the proposed edit. The talk pages can be "recycled" using the "whose editing method" of {{tt0}}, {{tt1}}... saving resources.
Now, it is a little known fact that two pages of the project can be compared with diff by manually plugging in the proper syntax to the diff url lines... all one need do is specify the proper hashcodes, the unique page identification numbers. Hence your clean version or mine can be easily compared by the "Pages Editorial committee", however ad hoc it is, or how formal (and signed!)! Jimbo was soliciting Ideas last spring on having editors register their expertise with the foundation,... don't know what happened in that discussion, but the problem is of concern to many of us... Wish I had a tenspot for every good admin or editor who's left the project because of such frustrations! I could ease up retirement planning!
I say four, acting as a rump committee, to ensure the change could be implemented quickly. In my scheme, ideally, the initial seed committee would be at least three admins and two volunteer editors who agree to add others they elect to the committee, and some of those choices should be geographical, so that there is ideally 24 hour coverage by at least one committee member. I imagine the committee would work a lot using intercommittee emailing. If a change is relatively trivial, that one alone can on his/her own authority authorize the update. If more substantial, one would wait for four or more to confer and achieve a consensus or at least a majority—one reason my scheme presupposes an odd number on each committee at all times. Template:IIf controversial, or needed backup up beyond their own knowledge of the subject, the larger committee as a body would deliberate and approve, disapprove, or request a rewrite, or implement the change with their own editorial changes... as all editors do in all publishing houses world wide... hence we'd follow suite, and still retain an ability for a speedy response cycle and content protection. We are, when all is said and done, an e-publisher!!!
Lastly, the committee should probably have term limits... two per year kicked off with a mandatory one year wait before being allowed to resit, and secondly, the committee as a whole should be able to vote off and disqualify anyone who is contentious or wacky, the hardcore pov editors... Anyway, that's the closest thing I can scheme that might have some chance of succeeding here. To my mind, some such scheme is the only way we will gain any sort of respectability in acedemia. You should here the comments I get from my wife AND KIDS!!! (in H.S.) about wasting my time here! I'd like to see something, anything better than what we're doing for sure. It is clear to me the current structure can not ensure reliability nor overall quality. Too much effort is being discarded policing trivial changes, as you noted. Entropy always wins. // FrankB 18:21, 14 December 2007 (UTC)[reply]
Some may be interested in this Wikipedia:Village pump (miscellaneous)#Question about my Masters project which refers to this User:Thorblood/ Edit This Paper: Truth, Reliability, Consensus, and Wikipedia. Cheers! Wassupwestcoast (talk) 19:22, 14 December 2007 (UTC)[reply]
Throw in some optional advertisements and this sounds just like what Google just announced. Mr.Z-man 01:28, 15 December 2007 (UTC)[reply]
My 2cents Well, I always believed, and do still, that a part of the Wikipedia way, even if unintended, is challenging the authority and authorship of knowledge. The moment we start signing articles and judging the value of the article on the value of the author/authority we largely defeat the project. "Anyone can edit" is a biggest commitment in the world of knowledge ever. That needs to be not just the "large part", that has to remain the "only part" of the project.
That's a valid concern-- the point of "signed articles" isn't just to allow signatures, it's more to allow multiplicity of articles on the same topic. Right now, Wikipedia only have ONE article per topic-- a Verifiable, NPOV, Anyone-can-edit, NOR one. That's certainly the most important one to have. But what would be wrong with, somewhere in the wikimedia family, hosting OTHER kinds of articles on the same topic. Once that are unabashedly POV, for example-- "editorial" pieces instead of "journalistically neutral" pieces. Or having one articles that are "ultra-verifiable, and verified" at the expense of "anyone can edit".
If there's only going to be one article per topic, then Wikipedia's NPOV,V,NOR,anyone-can-edit is definitely the one to have. But-- why does there have to be only one? What can't there be multitudes, on some sister project? --Alecmconroy (talk) 18:47, 15 December 2007 (UTC)[reply]

Too many redundant stubs

There are approximately 300,000 species of plant and an estimated over 1,000,000 species of animal. It seems that some people want to have an article on every one of them. There are multiple bots whose job is to create these articles from other websites. All of these bot-generated articles are very short stubs at first, and very few make it anywhere beyond that. Take for example genus Aloeides. Of its eleven species articles, not a single one has any edits but its bot creation way back in July. I have seen countless others of these useless stubs while random paging and new article patrolling. I call them useless because they are; not a single word of unique information is in any one of them.

Another example from a main culprit, User:Polbot, is Keizaburō Saeki, one of many so-called renowned Japanese photographers, all generated from a single website list of 328 of them. I find it hard to believe that a one-sentence article is useful. A single list should be made with all of them.

My proposition is simple: An article about something should be created only if it has enough unique material to warrant its own page. If not, then a list is perfectly acceptable. If a stub could easily be merged into a parent article, then it should. In fact, this theory of individual notability could also be attributed to people, places and other topics.

Following the plants/animals example, all species should be included in the genus article until sufficient unique information is found. People and places can have fine lists until more things pertinent to that person/place is found.

Obviously, perhaps the best, most common, and strongest rebuttal is eventualism, that every one of these articles could, as legitimate topics, eventually be a featured article or whatnot. I fully agree with this. A species of butterfly is vital to the ecosystem and a Japanese photographer is important and notable in his own right. But until a topic has eventually been taken one step further and a second sentence has been written, I insist that the individual articles remain merged as one. While these topics may be notable, they rarely have good sources and are much too short for use.

As a model, the German Wikipedia, even if it were about the President, would not allow such a short article. I will admit, however, that we are not the German Wikipedia, and that some of their merging, such as for fictional characters, is a bit too intense.

The first step toward merging these unneeded articles is stopping the bots which automatically write them. Proponents of these bots claim that these immediate stubs are starting points for other users to add to them. However, I see absolutely no reason that, as the articles contain only a few lines anyway, a list is not a perfectly acceptable starting point. Besides, as I said before, this point is nullified as the butterfly species pages above haven't even been touched since July, and I could find many even older than that if I tried. Eventually? Maybe. Having no unique, useful content for the last six months? Definitely not. And no, I did not scour the site for the very shortest pages; there are many more rediculously short articles.

I do hope that you can see the unnecessarities of many redundant stubs. I'm sure that many will oppose this, but I hope I have made my points clear and that many will agree that redundant one-liners are not wanted here. Thank you, Reywas92Talk 00:21, 15 December 2007 (UTC)[reply]

Article Ratings

I think all articles should have the ability to be rated, eg like videos on Youtube, and knols on Google. The reasons for this are twofold:

  1. It lowers the barrier to entry for feedback/editing of articles. Users who - for whatever reason - don't click the edit button, or don't contribute to talk page discussion, are much more likely to offer a rating of the article. This benefits editors of wikipedia because it allows us to gauge the opinion of the silent majority of Wikipedia readers. This in turn makes it easier for editors to quickly see which articles need improvement and which don't on a global basis.
  2. It offers another method to judge possible quality of articles, and by its nature will be more widespread than the current ad hoc grading system. Ratings are not a replacement for this system, but rather act as a complement to it. While in the short run, high popularity (ie high rating) does not equal quality, in the long run great articles (in the eyes of say FA reviewers) will inevitably become highly rated.

The key drawback here is that a vote is only completely relevant for the version of the article it was actually intended for. Thus, votes would decay with subsequent edits, with votes from more recent versions of the article receiving a higher weighting. A possible idea is if the user clicks on 'Rating' they see a graph of the rating over time, reflecting the dynamic nature of the article. Furthermore, users should be restricted to one vote per edit, so as not to bias the rating. Abuse would be detected and not tolerated. Suicup (talk) 03:48, 15 December 2007 (UTC)[reply]

Many (most?) articles are rated, via templates on the talk page. Not sure what additional purpose would be served by such a massive change to the Mediawiki software. -- Visviva (talk) 17:26, 15 December 2007 (UTC)[reply]
Rated by whom? One person? A group? Who decides who can rate? How often are the articles rerated (the rating is only as relevant as the edit it took place at). The key here is that the collective wisdom of the readership should be able to produce a robust (and current) rating of any article in the long run, which is exactly the same logic that says that the collective wisdom of editors should be able to produce a robust article of any subject. Suicup (talk) 18:33, 15 December 2007 (UTC)[reply]
Interesting idea. If implemented, we need at least 2 rating systems. The one for quality should be as it is now, otherwise IPanon could get a few frieinds to promote a poor article to FA status. But user ratings might give us some idea of where to focus our efforts. A user rating system probalby needs to measure several variables, e.g. how important it is to the reader, how informative and how easy to understand. Philcha (talk) 16:18, 16 December 2007 (UTC)[reply]
Sure, I would never suggest that the current rating system be replaced by this one - and an article could never become FA just because it has a 'high' rating. Rather, allowing readers to rate articles offers another qualitative angle for people to judge quality. It is deliberately simple - any extra feedback (ie writing quality, content issues) should be dealt with in the talk page. I am strongly of the opinion that on average, a rating will offer a useful guide to the quality of the article. Suicup (talk) 18:24, 16 December 2007 (UTC)[reply]
But how is a rating of "2 stars" going to help someone know how to improve the article? Unless its accompanied by text, its pretty much a random number. Mr.Z-man 18:59, 16 December 2007 (UTC)[reply]
Well if an article has a rating of two, any reasonable interpretation would be that it must mean the article is 'below average'. After rating an article, if a reader wants to be more specific in their feedback, they can go to the talk page, or obviously just edit the page themselves. All the rating does is allow you to gauge some qualitative assessment of the article (1) before you read it and (2) without having to go to the talk page. When reading wikipedia, you should always take the material with a grain of salt. However, some articles are clearly better than others - all a rating does is tell you how big the grain of salt should be. This is because over the long run, articles which have been deemed 'FA' by wiki's established process will inevitably be given a high rating, and those which are of poor quality will be given a low rating. Suicup (talk) 22:32, 16 December 2007 (UTC)[reply]
I definitely like your idea. It might also be cool to offer ratings by sections? I don't know. But I definitely like the rating system. And your explanation for supporting it, Suicup, is very well put. —Preceding unsigned comment added by VaporOne (talk • contribs) 10:07, 17 December 2007 (UTC)[reply]

Another way to combat potential vote abuse would be to prevent users from rating their own edits. Suicup (talk) 17:41, 17 December 2007 (UTC)[reply]

Comments welcome

Comments would be welcome at Wikipedia:Village pump (policy)#Proposal to reformat ISO dates in footnotes. —Remember the dot (talk) 00:26, 17 December 2007 (UTC)[reply]

Sign and Save

I don't know if this is the right place for this and it has probably been suggested before but it hasn't been introduced so I'll ask about it here... Why can't discussion pages have a button "Sign & Save" on them so that a user doesn't have to type or press the '~ ~ ~ ~'?

Thanks Shniken1 (talk) 04:03, 17 December 2007 (UTC)[reply]

When you press Save, you cursor could be at any position inside editing window (for example, you just corrected a typo). IMHO the best approach (besides switching to a better forum system) is to simply warn users about missing ~~~~ on saving. This is implemented for unregistered and new users for example in ru.wp (with JavaScript). Another approach is to have the bot sign afterwards ∴ AlexSm 06:27, 17 December 2007 (UTC)[reply]
Is there a script on the English Wikipedia that an editor could add to their monobook.js page to warn about a missing signature? -- John Broughton (♫♫) 14:31, 17 December 2007 (UTC)[reply]
Yes; WP:US/S lists two (User:Olliminatore/sign.js and Wikipedia:WikiProject User scripts/Scripts/qSig). --ais523 16:00, 17 December 2007 (UTC)

Mobile Wiki Action

I like to Wiki on my phone, but every time I load a page I have to scroll all the way to the bottom of the page to do a new search or just use the navigation menu. I'm wondering if anyone has already brought up this issue or if anyone is bothered by it at all like I am. I know that Tikiwiki has a mobile version, but I haven't seen anything for Wikipedia other than wapedia, which doesn't let you edit pages. Discussion? --Vapor One (talk) 09:55, 17 December 2007 (UTC)[reply]

Landmark images

In the last week I've been surveying the site's public domain files for images that could be featured picture candidates. What these files actually contain in greater number are historically important images that don't qualify to become featured because the image is too small, or a poor quality scan, or heavily artifacted. These images still have significant research value and some of them could qualify for featured status if better versions become available. It would be good for the site to have some method of distinguishing them from thousands of others that don't have as much value or potential.

So I propose Wikipedia:Landmark images, which would be a rough parallel to Wikipedia:Good articles. Landmark images would be selected for intrinsic uniqueness and encyclopedic significance. DurovaCharge! 18:26, 17 December 2007 (UTC)[reply]

Ugh. Another level of "featured" content??? Good Articles is bad enough as Featured Articles Jr. Why not just try and make an exception to the Featured Picture criteria that states landmark, historical images can become featured as uncompromisingly important, even if they aren't quite up to snuff on the size aspect? Seems much less bureaucratic and mind-numbing. Mahalo. --Ali'i 19:01, 17 December 2007 (UTC)[reply]
The featured image guidelines do make some allowances, but in practice these examples are getting thrown back. Have a look at the picture peer review for the first photograph from space and the Commons featured image proposal for the Reims cathedral shot. The result is material that has real importance and potential remains lost in an undifferentiated pool. After reviewing tens of thousands of Commons and WP images I've decided we could do better. For instance, this 1911 photograph of a Moroccan seaport might pass FPC if the artifacts were cleaned up. It would be a useful thing to have some mainspace location where volunteers can pool energies and improve this material. DurovaCharge! 19:22, 17 December 2007 (UTC)[reply]
Maybe WP:FOTO would be interested in this topic, or perhaps a new WikiProject would like to shepherd a collection. It looks like it would be necessary to recognize which images are Landmarks, and then try to improve them (and WP:FOTO already has a structure for image improvement). -- SEWilco (talk) 19:44, 17 December 2007 (UTC)[reply]
Good link. Their graphics lab looks like it's set up for different purposes. I may host this in user space for starters and see how well this works. I see a gap that needs to be filled, but if other people's first reaction is bureaucracy then a trial run on an unofficial basis might be the best compromise. Thanks for the feedback. DurovaCharge! 19:58, 17 December 2007 (UTC)[reply]

FWIW here's the page User:Durova/Landmark images in early form right now. A few might already be feature-worthy. Others have issues that could be resolved with better captioning, larger replacements, etc. Teamwork is welcome here; contact me in user space. DurovaCharge! 20:33, 17 December 2007 (UTC)[reply]

Block specific segments of text

I have a suggestion which I belive would seriously help out with the duties on Wikipedia (I posted this here because I do not know where else to post it). Basiccly, What I'm suggesting is the following:

(only) Segments of text being Protected

What I'm trying to say is this:

You know on say the main page, you can copy the source code but you cannot edit (it's grey and won't accept any text) well, I think Admins should be able to block specific segments of text, e.g the header of the sandox, or say in an edit war, instead of protecting that page, an admin could protect the information that people are conflicting about so people are free to edit the rest of an article without having to request it on the article's talk page.

So, if admins had the privleges to do this, it could lessen out the duties (e.g restoring the sandbox header) so users can concentrate on other things.

For anyone who is reading this- Please don't steal my idea!

thanks, cf38talk 22:08, 17 December 2007 (UTC)[reply]

This has been proposed many times before; e.g., bugzilla:4375. Cheers. --MZMcBride (talk) 22:29, 17 December 2007 (UTC)[reply]

Main Page Proposal

I think that there should be dates along with the selected news stories on the main page. It's confusing to see "Pervez Musharraf ends state of emergency" at the top of the news section today, 12/17, when it happened on 12/15 . My proposal is that the dates (MM/DD) should replace the bullets in order to lessen the confusion about when things happened. Let me know what you think. Jerse (talk) 00:26, 18 December 2007 (UTC)[reply]

What is the 17th month of the year? Shniken1 (talk) 01:26, 18 December 2007 (UTC)[reply]
Oh my bad, I didn't know you couldn't read. (MM/DD) meaning month first, day last. Jerse (talk) 02:25, 18 December 2007 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=178635323"