Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Languages on sidebar

On the left hand side of any Wikipedia page, on the toolbar, there is a section devoted to interwiki links to other language versions of an article. I want to propose a small change to the mediawiki software wording here. At current it is simply named "Languages", which is rather ambiguous and vague name. I think that when somebody less experienced at Wikipedia, usually a reader or newbie, sees that and the links below it, that if they click it they can get the whole of Wikipedia translated into that language. I propose it is changed to something short but similar to "View this page in other languages". This clears up any confusion to what you may consider to be a very minor thing but could be very hard to get their head round for readers. Rcsprinter (talkin' to me?) @ 11:27, 26 October 2012 (UTC)

"In other languages" would probably fit. But your solution does not solve the stated problem. I'm as likely to think I'll see a trasnslation of the EN page if we say "View this page in other languages" ... the operative problem being "this page". The interwiki link allows us to view the treatment of this subject in other languages. "Other language versions" might work. "Articles on other languages" also. But we're swapping brevity for perceived accuracy, which still might not be parsed by the user. --Tagishsimon (talk) 11:53, 26 October 2012 (UTC)

Why not "Other languages"? Tony (talk) 12:14, 26 October 2012 (UTC)

Funny, in my toolbar it shows as "in other languages". Lectonar (talk) —Preceding undated comment added 12:20, 26 October 2012 (UTC)

Are you using any custom code that might be overriding the default? —David Levy 12:59, 26 October 2012 (UTC)

Not that I am aware of; but still, it shows "In other languages", even on this page here. Lectonar (talk) 13:03, 26 October 2012 (UTC)

I guess you have selected "en-GB - British English" as language at Special:Preferences. Then you see MediaWiki:Otherlanguages/en-gb instead of MediaWiki:Otherlanguages. en-gb is not recommended at the English Wikipedia. See Help:Preferences. The page history of MediaWiki:Otherlanguages shows some variation years ago but not since 2007. David Levy used the Simple English Wikipedia as reason for not saying "In other languages".[1] PrimeHunter (talk) 13:38, 26 October 2012 (UTC)

Thank you for that; I guess I must have chosen it when I started may account, some 7 years ago. Never had any problems, though. Cheers. Lectonar (talk) 13:54, 26 October 2012 (UTC)

I just harmonized MediaWiki:Otherlanguages/en-gb and MediaWiki:Otherlanguages/en-ca with MediaWiki:Otherlanguages.

If the British English and Canadian English options are to remain available, we should apply the various customizations (with changes in spelling/wording where appropriate). For the messages in which no English variety issues exist (presumably most), we could use redirects. —David Levy 17:15, 26 October 2012 (UTC)

One of the Wikipedias is written in simple English. —David Levy 12:59, 26 October 2012 (UTC)

Keep "Languages". Apart from linking to this subject in another language, it also links to the whole Wikipedia in that language (with "whole" admittedly being smaller than English). You stay in that language if you follow wikilinks there, use the search box, click the logo, and so on. "Languages" is brief and about as clear or open to misunderstanding as alternatives that are not ridiculously long. PrimeHunter (talk) 12:38, 26 October 2012 (UTC)

Keep "Languages". Agree with PrimeHunter - it is ambiguous, but it's short and it won't take the reader long to find out what is meant once he actually follows the link... --Philosopher ^{Let us reason together.} 19:41, 26 October 2012 (UTC)

We will have a huge language button on top right.

The WMF is developing a huge button that says "English" on the right corner, so readers will find the articles in other languages easily. --NaBUru38 (talk) 20:09, 15 November 2012 (UTC)

Note to keep archiving bot away. Rcsprinter (yak) @ 21:43, 14 November 2013 (UTC)

Why not have it say "On Other Wikipedias"? Then it encompasses, say, Simple English, while avoiding the implication of translations. ∴ ZX95 ^[discuss] 01:00, 8 December 2012 (UTC)

My preference is languages because that is more explanatory than other wp's. Technically simple is a subset of English. Apteva (talk) 02:53, 8 December 2012 (UTC)

The issue was raised, however, that "Languages" is likely to make some people think that the linked articles are translations of the English one; that was why I suggested "On Other Wikipedias", which is much less ambiguous. ∴ ZX95 ^[discuss] 15:29, 11 December 2012 (UTC)

Change 'contributions' to 'edits'

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

'Contribution' is quite a subjective term. By definition, it refers to a role played by a person to produce a result. This means that edits such as vandalism and other disruptive activities are considered 'contributions', which fails to harmonise with the idea of a contribution being for the better to produce an outcome. Therefore the word contributions should be replaced with edits to reflect a more netural and objective term. Thus when using the user template, instead of saying Username (talk | contribs) it will say Username (talk | edits). And the 'User contributions' of an editor's page should be changed to 'User edits'. It's shorter, more neutral, more factual, and more consistent. Till 10:12, 27 November 2012 (UTC)

• Maybe. Your arguments are pretty good but "contributions" has been around so long that I'd need think about whether I want to change it. Will editors feel subtly less appreciated? --Trovatore (talk) 10:30, 27 November 2012 (UTC)
• "Contributions" includes page moves and page uploads too. -- Magioladitis (talk) 10:31, 27 November 2012 (UTC)
  • A page move (not sure what you mean by page upload) is still an edit. When an editor clicks on the 'edit' tab, they are 'editing' the page. They may leave an 'edit' summary, and can mark it as a minor 'edit', before finally saving the 'edits' they have made. Notice how they are not 'contribute', 'contribution summary' or 'minor contribution'. Till 10:48, 27 November 2012 (UTC)
    • File uploads and page protections are recorded under contributions. -- Magioladitis (talk) 16:14, 27 November 2012 (UTC)
      • No they aren't. Page moves, uploads, etc. are under logs. Some appear in edits, but that's because you are making an edit to the page. Statυs (talk) 16:18, 27 November 2012 (UTC)

• Support: When I first started, I found "Contributions" to be a confusing term and wasn't quite sure how it worked. It took a long time to get the hang of it ad work out what it actually showed. Further suggestions are: "Talk" to "Talkpage", "Preferences" to "Settings", and "[Insert Username]" to "[Insert Username]'s Userpage.--Coin945 (talk) 12:52, 27 November 2012 (UTC)

• Oppose. I don't think "edit" would include creating a new image or article in the mind of a newcomer. I also think the newcomer might not think of talk page contributions as edits. Jc3s5h (talk) 15:13, 27 November 2012 (UTC)
  • All those examples are still edits, regardless of thought. I would hardly consider vandalising articles to be a 'contribution' to the project. Till 23:15, 27 November 2012 (UTC)

• Support. I have to agree. I don't think that this will end up going through, as there will be a lot of users who think that "what was should always be", but I'm leaving my support none-the-less. Statυs (talk) 15:18, 27 November 2012 (UTC)
  • I personally think a lot of Wikipedia editors should take a peak at List of fallacies before they weigh in at these sorts of discussions. Major arguments always seem to be things like "flawed tradition is better than improved evolution" or "it may result in bad things despite the many good things it will cause so there's no use trying it at all". It's a shame to see editors sink so low...--Coin945 (talk) 16:38, 27 November 2012 (UTC)
    • Naming fallacies is very rarely a constructive contribution to a discussion. Most of the time it's an attempt to frame one's own contingent beliefs about the world, or normative preferences, as a matter of logic. --Trovatore (talk) 20:38, 27 November 2012 (UTC)
• Support per Status. YellowPegasus (talk • contribs) 16:08, 27 November 2012 (UTC)

• Undecided - I can see the validity of the argument however I don't think all contributions are edits whereas all edits are contributions as they contribute another event to wikipedia (even negative contributions are contributions). Cabe6403 ^{(Talk•Sign)} 16:36, 27 November 2012 (UTC)

• At Commons, "contributions" makes more sense than "edits". And we should use the same words in every project. --NaBUru38 (talk) 19:48, 27 November 2012 (UTC)
  • That would be hard to do, given that most projects are in different languages. Commons is in English, but I note that Wikipedia changed "discussion" to "talk" not that long ago (six months? a year?) and Commons has not followed suit. --Trovatore (talk) 19:59, 27 November 2012 (UTC)
    • And Simple English Wikipedia doesn't use "contributions"; the use "changes". Would it be better to go that way? עוד מישהו Od Mishehu 11:40, 24 December 2012 (UTC)

• Support - As stated by nom, changing the owrd makes a lot more sense and is clear. TheOriginalSoni (talk) 08:00, 28 November 2012 (UTC)
• Comment. Isn't this a software, Mediawiki, issue? when I click history I see a list of Username (talk | contribs)‎, but that is not a template, that is the software. Euphemistically, a page blanking is a "contribution". Apteva (talk) 06:41, 1 December 2012 (UTC)
  • Yes it is something that needs to get fixed software wise. Legoktm (talk) 07:02, 1 December 2012 (UTC)
    • Well, many of the places can be changed by editing the appropriate pages in the MediaWiki namespace. But if you wanted to rename Special:Contributions to Special:Edits (or make the latter redirect to the former), that would require a configuration change. Anomie⚔ 18:00, 2 December 2012 (UTC)
      • We don't need to change the URL - we still, for example, have Special:AbuseFilter, even though we no longer call it the Abuse Filter here. As to the interface, we have 39 interface pages where the word "contributions" is used. עוד מישהו Od Mishehu 11:49, 24 December 2012 (UTC)
• Oppose You can make a negative contribution to something. Also Magioladitis is right, Special:Contributions shows more than just edits. Legoktm (talk) 07:02, 1 December 2012 (UTC)
• Oppose Not every action on Wikipedia is an "edit", per se (that is, a change to an article). Contribution vandalism is still contributing, so I like the current wording better than any other possibility. --Jayron32 00:40, 2 December 2012 (UTC)
  • This isn't about what is "right". This is about what is making it easy for our users to understand. If there was a choice between a correct but obscure term versus a common albeit almost-perfect term (e.g. euphemistic/slang etc.), I would hope - and expect - our wikimunity to choose the latter every time.--Coin945 (talk) 10:19, 3 December 2012 (UTC)
    • So you would propose changing something that is correct, and making it wrong? I'm not sure I see the logic in that. Legoktm (talk) 10:22, 3 December 2012 (UTC)
      • Ummm.... that's not what I said.... :/. If you have a term that describes the thing perfectly, but to the common man it is vague and obscure, then I would always swap it for a word that is common and can be understood easily by all (in this case "edit" as it is used all over the internet and is "the" button that users press to make contributions) even if it doesn't describe the thing perfectly (there are going to be exceptions which fall outside the definition of "edit"). An example off the top of my head would be (if The Netherlands was a much more obscure term than it is), using "Holland" in the case of "The Netherlands" even thoguh it is not exactly the same thing, because it is a much more common term and in people's minds they are the same thing, so it doesn't really matter that in actual fact they aren't. I see this as no different. People see their contributions as "edits" so why not just use the word, regardless of whether they 'actually' are edits or not...?--Coin945 (talk) 10:30, 3 December 2012 (UTC)
• Oppose. I don't understand what the problem to be solved is here. The term "contributions" doesn't stand out to me as being inaccurate (even when the contributions are not productive or are merely technical). I can't see where it's causing any confusion or problems... I don't know whether it would or would not be much work to modify MediaWiki to display "edits" instead of "contributions," but I honestly don't think it would be worth the effort regardless. jæs (talk) 18:14, 3 December 2012 (UTC)
  • Contributions looks stupid especially when it's abbreviated on the user template; 'talk | contribs' could just be 'talk | edits'. Till 02:06, 4 December 2012 (UTC)
    • I really don't understand your subjective argument that it "looks stupid," but I guess that's why it's a subjective argument. I suppose it's a matter of taste. All in all, though, if it ain't broke... jæs (talk) 03:55, 4 December 2012 (UTC)
      • You will admit, however, that it is simply illogical to use the abbreviation 'contribs' when the word 'edits' could be used? Till 06:19, 4 December 2012 (UTC)
        • I don't believe that abbreviations and acronyms are inherently illogical, no. If the community felt strongly about it, I imagine we could simply replace "contribs" with "contributions." But it has been this way for — what, over a decade now? There's been no evidence demonstrating mass confusion or hysteria as a result of the use of "contribs" and "contributions." In any event, as I said earlier, I honestly don't think this is worth the effort. Best of luck with your proposal, nonetheless. jæs (talk) 16:02, 4 December 2012 (UTC)
• Strong support. "Edits" is simpler and clearer, and that's the direction we should always be looking towards in making this project more accessible. As noted above, it also saves having to use the ugly abbreviation "contribs". A quick change for a long-term benefit. — Hex (❝?!❞) 12:34, 4 December 2012 (UTC)
  • Of course, in addition to my further suggestions above, i must confess that after thinking about this proposal for a bit, the term "edits" seems like it may confuse some people. The obvious solution is then to bring back the "My"'s so it will read "My edits". End of story. So what if there is no evidence to suggest this is better or worse. Screw bureaucracy. We have identified a change that we think will be better, and all this talk and talk and talk about possible negative effects or research that must be done etc. has yet again reminded me of why i hate wikipedia so much. Just bloody well make the change already..... :/.--Coin945 (talk) 16:24, 4 December 2012 (UTC)
    • "All this talk and talk and talk about possible negative effects or research that must be done..." There's usually a reasonable amount of discussion of those sorts of things in good user interface, user experience, and human-computer interaction design... jæs (talk) 17:08, 4 December 2012 (UTC)
      • Sorry...? I'm not following. What's your point?--Coin945 (talk) 18:45, 4 December 2012 (UTC)
        • Jæs is saying that typically there is a reasonable amount of discussion and feedback that goes into changes in usability and user interface, which is really what this discussion is about. Since it's unlikely that there will be usability testing done, we have to rely on feedback of other editors, which needs to be given time. Saying "Screw bureaucracy", like you did just above, is essentially saying "screw other editors and their feedback," since it's the community of editors that is going to decide this, not some vague "bureaucracy." First Light (talk) 04:19, 6 December 2012 (UTC)
• Comment. As stated before, even negative contributions are contributions. Also, would adding comments and ideas to a discussion on a talk page really count as edits? Yes it is editing the page, but isn't it more of a contribution to the discussion than an edit? — Preceding unsigned comment added by CharmlessCoin (talk • contribs) 15:06, 4 December 2012 (UTC)
• Oppose per the above. Statυs (talk) 23:07, 4 December 2012 (UTC)
• Strong oppose. Per the comments by users explained above. — Tomíca^(T2ME) 23:09, 4 December 2012 (UTC)
  • You probably didn't even read them, or any of this thread, you just saw a proposal initiated by me and decided to oppose it. Till 02:41, 5 December 2012 (UTC)
• Support. "Contributions" in some sense would be a useful statistic, but its definition and restriction is unclear, prone to misunderstaning. "Edits" is clearer, and seems to be closer to what is actually being counted. ~ J. Johnson (JJ) (talk) 23:59, 4 December 2012 (UTC)
• Oppose. - No need. GabeMc ^{(talk|contribs)} 00:01, 5 December 2012 (UTC)
• Neutral leaning oppose - It wouldn't be the end of the world either way, but I tend to agree with Gabe, I don't really see a need. <sarcasm> Additionally, a change as drastic as eight characters would put me over the edge. Eight characters! Come on, I mean, maybe seven, but I can't deal with eight. </sarcasm> That said, should this change be implemented, I can guarantee you I won't notice it in two months (just like I probably wouldn't have noticed not having the "my" in front of talk, preferences, etc. a few weeks ago...) Go Phightins! 03:36, 5 December 2012 (UTC)
• Oppose Having uploaded a fair number of images, some of them without any digital editing having been done on them, I prefer "contributions" as being more literally accurate. And a new article is more accurately a "contribution" than an "edit." No name will be perfect, but "contributions" works better. First Light (talk) 23:42, 5 December 2012 (UTC)
• Oppose . A solution looking for a problem. If it ain't broke, why change it? Kudpung กุดผึ้ง (talk) 00:25, 6 December 2012 (UTC)
• Oppose per what Kudpung stated above.--Amadscientist (talk) 00:35, 6 December 2012 (UTC)
• Oppose per First Light's well-reasoned arguments about uploaded images and new articles not falling under the "edit" category. Firsfron of Ronchester 01:23, 6 December 2012 (UTC)
• Oppose per above. Also, neither of these contributions could possibly be considered edits, because they made no change to the content of the pages. Graham87 08:54, 6 December 2012 (UTC)
  • You edited the revision history of the page. There is no reason to pedantically restrict "edit" to the meaning of "changed the content of a page". — Hex (❝?!❞) 14:27, 9 December 2012 (UTC)
• Strong support. Why use a biased word like contribution, when we can use a neutral word like edit? Azylber (talk) 08:53, 13 December 2012 (UTC)
• Support - "contributions" sounds like donations or something. "edits" is much more clear. -- FutureTrillionaire (talk) 23:50, 19 December 2012 (UTC)
• Oppose - Contributions is fine. It refers to all actions, whether editorial or not. My !vote here isn't an "edit" per se, any more than typing a comment into IRC is an "edit." People still seem of the mindset that Wikipedia pages are like paper; really, they're part of a database of various articles, file-linking actions and conversations like this one. Personally, I'd replace the "Edit" links on WP to "Modify," since that's really what we're doing: modifying a database. — The Hand That Feeds You:^Bite 08:35, 20 December 2012 (UTC)
• Oppose - There is nothing wrong with Contributions, and as a concept, is it not more positive to encourage people to contribute to Wikipedia, rather than merely edit it? Edwardx (talk) 18:11, 20 December 2012 (UTC)
• Strong oppose, per all above opposes, and, most of all, albeit not an argument, it is semantic (as)in(i)anity. Secondly, because any "edit" is a "contrubution", but not all "contributions" are "edits" (creating new content can not be defined as "editing" in any dictionary I'm aware of). St John Chrysostom ^Δόξα_{τω ^Θεώ} 02:29, 21 December 2012 (UTC)
• Strong support. Obviously there are more ways to contribute than to edit.. but this small technical point obscures the truth from most new editors because (I think) the word "contributions" to most non-wikipedians means "donations". Perhaps there is an even better word for the changes made, but the word "edits" is more understandable to new people than "contributions". No matter what you call it, the regulars will know what we mean. Mlm42 (talk) 10:31, 22 December 2012 (UTC)

In response to Dcoetzee's comment below, the term "edit" is already widely used across the encyclopedia. It doesn't say "contribute to this page", is says "edit this page". The word "edit" is the first piece of jargon new users have to learn.. without clicking on it, they can do nothing! :-) Mlm42 (talk) 10:17, 24 December 2012 (UTC)

• Oppose. We're getting caught up in our own jargon again. In normal parlance, "editing" is the process of refining a draft document to create a final document. "Contributions" is a better common term to describe what users do at Wikipedia, which often includes writing substantial original content. Dcoetzee 23:30, 23 December 2012 (UTC)
• Strong support - This clearly isn't a contribution - contributions are necessarily positive, and this one is clearly negative - both in the purpose of the site (the edit removes useful information), and in content (it's being removed, not added). And Mlm42's probably right - to many non-Wikipedians, "contributions" are donations. Maybe "changes" would be better (note that in Simple English Wikipedia, that's what they're called). עוד מישהו Od Mishehu 11:35, 24 December 2012 (UTC)
• Oppose per Edwarddx. As the proposer of this change noted, contributions are an action "for the better to produce an outcome" – it can't be a bad thing to recognize the efforts of constructive users. Changing "contributions" to "edits" will hardly discourage vandals from continuing to disrupt the encyclopedia. Altamel (talk) 16:27, 26 December 2012 (UTC)
• Oppose as entirely unnecessary and lacking in evidence that it wont be harmful. "Contributions" include things other than page edits, and contributions are not necessarily positive (what gives people this idea? It's not a concept I've ever encountered until this discussion?), they can be positive, negative and neutral. Abbreviations are not harmful and there is no evidence presented that "contribs" or "contributions" has ever caused any difficulty, nor that "edits" would solve any problems that do exist without causing problems of its own. There was a huge amount of work done on the interface as part of the programme that developed Vector which resulted in an interface optimised for new and inexpert users, which would surely have picked up on any issues around the use of "contributions". Thryduulf (talk) 17:02, 26 December 2012 (UTC)
• Oppose. Away from Wikipedia, the word "edit" has not traditionally been used to describe the expansion of a written work. In the real world, fleshing out a bare-bones text (what we call a stub) isn't editing; it's writing. Editing generally involves more removing than adding, and good editing is always a judicious process. Calling acts of vandalism "edits" makes no more sense than calling them "contributions". As someone who was an editor years before Wikipedia was a twinkle in Jimbo's eye, I've sometimes wondered whether we use the word "edit" too freely around here. Rivertorch (talk) 05:59, 29 December 2012 (UTC)
• Oppose. Contributions can be negative, as shown by more than 50,000 hits in Google Scholar, so if it ain't broke don't fix it. Plus, many actions on WP are not best described as edits, as many have said above at length. This would be a step in the wrong direction. --Presearch (talk) 08:00, 2 January 2013 (UTC)
• Start an RfC on this I strongly believe that a wider community input on this Issue will be much more helpful and useful for gathering the required consensus regardless of what the result turns out to be. ~TheGeneralUser (talk) 05:09, 5 January 2013 (UTC)
  • Be bold and do the honors. TBrandley ^{(what's up)} 05:45, 5 January 2013 (UTC)

And waste more of our editors' time? A rough tally of this discussion should demonstrate where it will lead. Kudpung กุดผึ้ง (talk) 06:11, 5 January 2013 (UTC)

Fair enough. TBrandley ^{(what's up)} 06:24, 5 January 2013 (UTC)

• Oppose. Contributions pages show not only edits to Articles, but also opinions on discussion pages, like this one or any AfD, and so on and so forth. So, the term "contributions," the "result" to which we "contribute" simply being a better Wikipedia, is actually the least ambiguous possible term. The Mysterious El Willstro (talk) 07:06, 10 January 2013 (UTC)

But to contribute to this page you had to edit it. AIRcorn (talk) 08:39, 10 January 2013 (UTC)

• Support We can argue till the cows come home over what is the more correct definition, but at the end of the day that is not what is most important. The most important thing is to make this more accessible and understandable to new users. Edits keeps us more in sync with the "edit" buttons on articles and our motto "the free encyclopedia that anyone can edit". Contributions include donations, the time spent looking/verifying information, coding bots and a myriad of other activities that are not recorded in the edit contribution history. As a bonus we will get rid of "contribs", which is not a standard or well known abbreviation. Even taking into account of the opposes I can see no real harm coming out of this change. AIRcorn (talk) 08:39, 10 January 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia "Merge" like WP:RM or WP:AFD

Trying to write in brief: Wikipedia merge should be similar to WP:RM or WP:AFD process. Currently in many articles "Merge" is proposed for months and no consensus is built, in many articles, even discussion is not started in talk page., thuse "merge" tag becomes aimless and unnecessary! --Tito Dutta (talk) 10:54, 26 December 2012 (UTC)

• Strong support for this relatively uncontroversial idea that is simple, well-designed, and will expose to the broader community our articles that need the most attention. Wer900 • talk 20:45, 26 December 2012 (UTC)
• Support I suggest a AfD style. A problem is just that merging can be tedious. I think we could also merge WP:PM to WP:AfD. AfD does a lot of mergers already and PM is inactive. ~~Ebe123~~ → report 21:33, 26 December 2012 (UTC)
  • It sounds like Wikipedia merge already exists at Wikipedia:Proposed mergers, but it does not appear to be inactive - there are about seven active requests, and ten that were handled recently. It could be added to the dashboard, though, to publicize it better. Out of 4 million articles I would guess that there are more than seven merge tags. There are currently 5,867 transclusions. I would not suggest adding these to AfD. Apteva (talk) 04:29, 27 December 2012 (UTC)
    • Not very active compared to here, or AfD. ~~Ebe123~~ → report 23:41, 27 December 2012 (UTC)
• Very strong support I too suggest AfD, which we would then rename as Articles for Discussion, to match the other XfDs. The reason for combining them is that merge is often the result of an AfD close, and the effect of a merge can be and often is, to delete material--sometimes without consensus, by just getting consensus for the merge, but not actually merging any significant amount of content. There's even a nickname for it "smerge". The reason there is a 6,000 item backlog is people tag them, but never do them. We should first clear out the backlog, at the rate of 20 a day added to the AfD load. It would take only 1 year, and then we'd be done with them. Many of those tags have been sitting there longer than that. Alternatively or in addition, we need a way of handling the one not likely to be contested. It would be good not to continue to treat a merge as normal editing, which just requires Boldness, because it can be a drastic change on a little watch article, but to expose them in some manner, like WP:PROD. DGG ( talk ) 05:15, 27 December 2012 (UTC)
  • Previous discussion at WT:Articles for discussion/Proposal 1. Flatscan (talk) 05:05, 7 January 2013 (UTC)
• Just as a reminder that other ideas similar to this fall into WP:PEREN. This is not to discourage this idea (which I think is sufficiently different) but be aware of why some of the other efforts have tried and failed (particularly DGG's concept of Articles for Discussion). --MASEM (t) 05:35, 27 December 2012 (UTC)
  • Failed proposals mentioned by other users: WP:Mergers for discussion (2009) and WP:Articles for merging (2010). Flatscan (talk) 05:05, 7 January 2013 (UTC)
• Strongest Possible Support. Of the various merge discussions I have seen, they typically take a long time to complete, and the quickest mergers tend to be the ones that are the consensus of an AfD discussion. If we set up a page for requested merges in the style of WP:AFD, that would be a terrific upgrade. RedSoxFan2434 (talk) 05:49, 27 December 2012 (UTC)
• Comment - I would support merging this process to WP:RM. I strongly oppose merging it to AfD simply because AfD does not happen on the talk page of the article in question. Merge discussions should happen on an article's talk page, not somewhere out there in Wikipedia space. - jc37 08:48, 27 December 2012 (UTC)

  Merging the proposed merges to RM does not seem good as RM as there is a backlog and PM's problem is also on RM. Also, why shouldn't proposed deletions go on the talk page? It is somewhere in Wikipedia space, and not on the talk page. ~~Ebe123~~ → report 23:41, 27 December 2012 (UTC)

  We don't do AFDs on the article talk page because if the article is deleted, so is the talk page, and we lose a record of the deletion discussion. Mergers and moves do not suffer from this problem. --Jayron32 03:05, 28 December 2012 (UTC)

  That's like saying we choose to do something bureaucratic for the sake of some other bureaucratic choice : )

  We shouldn't be CSD-ing talk pages with substantive content anyway. - jc37 06:45, 28 December 2012 (UTC)

  What does "CSD-ing" mean? Discussing changes to the content of an article is what talk pages are for. There is no limit to how much discussion takes place on a talk page as the page can always be archived. I think that merge requests should always be done on the talk pages of the articles (as happens now). That way the information stays with the article even when the page is moved at some point in the future. -- PBS (talk) 03:21, 5 January 2013 (UTC)

  CSD means speedy deleting - if there is a discussion on a talk page about whether to delete an article, we don't normally delete it. Ego White Tray (talk) 20:47, 5 January 2013 (UTC)

• Comment Once upon a time, I tried to create Mergers for Discussion (MRFD) with exactly this purpose. It failed spectacularly, mostly because it is hard to attract outside interest to a merge when you have no vested interest. At the height of it's two month success, it looked like this. I still believe in the concept, but the specific method had yet to be discovered. --NickPenguin_(contribs) 04:09, 28 December 2012 (UTC)
  • Arguably, participation would be improved if we could get the DelSort to include these types of discussions. --MASEM (t) 04:14, 28 December 2012 (UTC)
• Support, with a particular preference for the idea of integrating this into WP:AFD. In addition to the points raised above, I feel that a broader view, framing and awareness of possible options among discussion participants, both in the case of proposed mergers and proposed deletions, would be a positive. --j⚛e decker^talk 04:27, 28 December 2012 (UTC)
• Strong support, @jc37 we could implement a bot transcluding the discussion on the talk page, that would be rather easy. mabdul 19:58, 29 December 2012 (UTC)
• Support. Right now, merger proposals can stay in limbo for years; when they are contentious they often don't get closed because everyone who knows about them is involved. This would resolve that. I prefer a separate system similar to WP:RM, so that discussions would occur primarily on the article talk page (where knowledgable people will contribute) and are allowed to go on longer than the typical AfD, but the discussions will come to the attention of other observers -- and will eventually be closed by an uninvolved administrator. --Orlady (talk) 17:05, 2 January 2013 (UTC)
• Strong support, mergers take forever, especially if it is for a minor article that nobody looks at... Jucchan (talk) 17:49, 4 January 2013 (UTC)
• Support  Too often, time is wasted at AfD on discussions for which there is no policy-based possibility of deletion.  Hopefully, this forum would lessen that problem.  Unscintillating (talk) 02:29, 5 January 2013 (UTC)
• Comment  I'm puzzled that the discussion to date has not used the word "redirect".  Redirect at AfD has two common meanings, one is to redirect and delete the edit history, the other is to redirect without deletion of the edit history.  A "merge" result brings with it the impracticality of forcing material to move from one article to another.  I suggest that for this "Merge" forum, "Merge" be defined as a redirect without deleting the edit history, and the amount of material to be merged is not determined by the WP:AfMerge closing.  Unscintillating (talk) 02:29, 5 January 2013 (UTC)

  I thought a "Merge" was a merge of the text ending up in a redirect without deleting the edit history. If the edit history is deleted then one has copyright problems, and usually merges can not involve merging the histories of the articles as the result would be spaghetti. Merging histories only works for fixing cut and past moves and similar situations. -- PBS (talk) 03:38, 5 January 2013 (UTC)

• Right, see WP:MAD.  I think this Merge forum should be used for cases where there is no possibility of WP:MAD issues.  Unscintillating (talk) 12:24, 5 January 2013 (UTC)

• Merge means combining two articles into one article and has little to do with page histories. Usually content from article A is moved to article B and article A would then redirect to article B. There would never be a deletion of page history in a merge. BTW, a vote for redirect at AfD almost always means to keep the edit history. Ego White Tray (talk) 20:47, 5 January 2013 (UTC)

• There is a bit of support to revamp this merge proposal so as to combine it with AfD.  Thus it is useful to be clear about what separates the two, and this leads to the current ambiguity in "redirect" at AfD.  Currently, editorial control (i.e., not using admin tools) in this context extends from making a redirect and merging 0% of the material, to making a redirect and merging 100% of the material.  So I think that a straight redirect without merging any material is within the scope of this merge discussion.  Unscintillating (talk) 19:30, 6 January 2013 (UTC)
• What is your basis for saying, "a vote for redirect at AfD almost always means to keep the edit history"?  When I have had to document such, I have only been able to do so by opening up AfDs one-by-one and examining the statement of the closer.  Thanks, Unscintillating (talk) 19:30, 6 January 2013 (UTC)

• Support Some years ago I proposed the automation of requests for RM which up until that time had been a manual process. I propose that a bot is set up to automate the system and an obvious person to request to do this is user:Wbm1058 who has fairly recently taken over the bot that controls RM requests. I also strongly suggest that the requests are moved out of article space onto the talk pages (as is done with RM requests). This was discussed recently with RMs where there were two templates that could be used, one on the talk page and another that could be used in article space. It turned out that advertising in article space attracted few users to discuss moves who did not have the page on their watch list, and this included pages that were listed as potential moves for up to one year (see this debate). -- PBS (talk) 03:03, 5 January 2013 (UTC)
• Comment I have been pondering on this issue for several months (since the Movenotice debate). The major problem that I see is not putting a process like WP:RM in place. The major problem is what to do if the proposal is accepted. One can not expect the closing admin/editor to do the merge. I would therefore suggest that part of the process must involve someone offering to do the merge if the merge proposal is accepted. The obvious person is the person who propose the merge. But if they think that they are unable to undertake it, it would probably be necessary to have a seconder for the proposal who would be willing to do the merge. Without a person willing to do it, there is little point debating if it should be done. The other point is how long should a debate stay open. Although in the long run it would be preferable to bring it down to the seven days used for a RM. Initially, as there is no time limit on debates at the moment I suggest that a month is given (as it is for RfCs). If after say six months it is obvious that a sorter period (such as 7 days would be preferable) then can hen that can be proposed at that time. -- PBS (talk) 03:15, 5 January 2013 (UTC)

  • Regarding the suggestion that the nominator or a second must volunteer to do the merge

The pattern from AfD is that nominators in general are unprepared to be involved in working on the content of the article.  Although this statement is based on personal experience, it can be objectified by comparing AfD nominations with the guideline at WP:BEFORE, including that the analysis of merge or redirect targets is routinely missing from AfD nominations.  As for how this plays out in a merge forum, requiring the existence of someone willing to do the merge seems like a good idea.  But the practical effect may be to encourage work-avoidance nominations to remain at AfD.  Also, the power for the nominator to control the amount of a merge is questionable, as the nominator is unlikely to be a preservationist.  Maybe another solution is a bot that merges everything.  Unscintillating (talk) 13:20, 5 January 2013 (UTC)

• Comment Also if a bot is used then there would only be a need for an editor to place one message on the proposed target's talk page, as the other talk page can be populated by the bot (as is done for multiple page moves at the moment). This would even allow a user to propose multiple page merges with the same template. Wbm1058 may be willing to explain that in more detail if someone would like to know how the RM bot handles multi requests at the moment. -- PBS (talk) 03:29, 5 January 2013 (UTC)
• Comment See Wikipedia:Proposed mergers, Template:Merge/doc and the categories Category:Articles to be merged (between 5,000 and 6,000 articles to be merged assuming both have merge tags) Category:Items to be merged (about 100 but a lot are old and need deleting eg see Wikipedia:Notability (doctors)). -- PBS (talk) 03:59, 5 January 2013 (UTC)

  And Wikipedia:WikiProject Merge -- PBS (talk) 16:32, 11 January 2013 (UTC)

• Support The current method can be greatly improved upon by the discussed fix. 7 days, however, is too short a time frame, to discuss controversial merges, I think. As far as getting the actual merge done, see my comments/possible solution below at "Who's gonna do it. Thanks. GenQuest ^{"Talk to Me"} 23:03, 7 January 2013 (UTC)
• Comment I support it in theory, but am not sure how it is going to work practically. The Merge backlog is immense and in all likelihood is never going to be cleared. If it is done it will most likely have to start independently to the current merge requests. Also a merge is a lot harder to do than deleting an article and in many cases would involve at least some knowledge of the topic. There are also issues with merging poor content into a Good or Featured article and effectively ruining its classification. If this goes ahead I would personally like to see the responsibility for completing a proposed merge that is closed as merge be handled by the person who created the article or an interested Wikiproject. If no one steps up then simply redirect the article (maybe making a note on the target articles talk page) after a set number (two?) weeks. That way the information can still be found if someone interested comes along in the future, but we are not continually building a backlog. AIRcorn (talk) 23:27, 9 January 2013 (UTC)

• Strong oppose Merge is not a mechanical process so differs fundamentally from AfD or RM - you can't do a merge with the stroke of an administrator's pen. Slightly less problematic is the goal of making decision on a merge in a timely manner. To actually complete the merge, you need to find an editor with enough knowledge of the subject to perform the merge. If such an editor is not immediately available, the decision should be deferred because all stakeholders should participate in the merge decision discussion. I'm not clear what the objection is to having merge proposals open for long periods. Presumably both articles contain useful information else they would be edited or deleted. The merge banners give readers indication that the information they're looking for may be in more than one article. -—Kvng 02:18, 12 January 2013 (UTC)
• Support: If it's been at least a month and there isn't a second or third person supporting the merge, it needs to be closed pbp 05:01, 12 January 2013 (UTC)
• Support Sounds like a great idea ·Add§hore· ^{Talk To Me!} 02:18, 19 January 2013 (UTC)

Who's gonna do it

There have been several similar proposals in the past (one attempt, another attempt and while there was never any debate about having a discussion similar to Articles for Deletion or Requested Moves, what really got things hung up was how it gets done if the discussion decides to merge. Renaming and deleting pages are very quick and simple tasks and the effort involved for admins is reviewing the discussions. The consensus in the second attempt linked above was that merging is not a simple task and can not be automated. We would still, then, have a backlog of articles to be merged. That said, with the opposed ideas eliminated, the merge backlog would be much much smaller. Ego White Tray (talk) 20:54, 5 January 2013 (UTC)

I think the answer is either nobody or somebody. I consider the current merge scenario like a someday list. Like, someday, these two article will be merged. Maybe. Unless someone disagrees, then they won't. I think what we need is to create templates that distinguish between a "proposed merge" and a "consensus to merge" or "uncontested merge". That way if a wild editor comes across the second type, they can treat it like a cleanup action rather than a discussion action. --NickPenguin_(contribs) 01:09, 6 January 2013 (UTC)

Any merge should have discussion for 1 week, but let's use the incubator:'s rule that if there is no comment, then that means there is no reason to not merge, so the proposal is closed as a merge. ~~Ebe123~~ → report 15:06, 6 January 2013 (UTC)

I agree with Ego White Tray: the root cause of the backlog is that mergers are not easy to implement. Flatscan (talk) 05:06, 7 January 2013 (UTC)

However, having a structured discussion system would slash the size of the backlog. You would have 7-day discussions, and then those rejected would be removed from the backlog. The backlog currently makes no distinction between good ideas and bad ideas. Ego White Tray (talk) 22:01, 7 January 2013 (UTC)

Merges that are successfully approved by the community like this should be tagged with an "approved merge" template, where it says something like "Community discussion, found here, has determined that these articles should be merged together. Assistance and help completing the merge can be found here." --NickPenguin_(contribs) 01:10, 8 January 2013 (UTC)

The merge discussion should take place on the talk page of the nominated target page. The placement of the template on the "from" talk page can be automated -- much as is done with multi-moves at RM. What I envisage is one template for discussion "Proposed merge". If there is no agreement to merge then the closer close it with a template "merge closed|date=date|reason=reason" If the move is agreed the closer put in place a second template eg "merge pending|date=date". The automated process will post that to the other page. If after a time out of say a three weeks (one weeks discussion + 3 for the merge) if the templates are still on the talk page they are removed by a bot with the comment "merge closed|date=date". -- PBS (talk) 14:19, 8 January 2013 (UTC)

Somebody has to do the merge. I have recently become involved in the merge process as it currently exists, and it is, indeed, cumbersome. I have also taken it upon myself to do some of the non-controversial merges myself, just to get them off the request page. I am a non-involved editor in most of these, and I feel that is a good thing, but, there are subjects that I wouldn't want to touch with a ten-foot pole, and the nominators aren't always willing/able to do the work. Perhaps creating a "Merger" status (much like the "Rollbacker", "Autoreviewer", etc.) would help get a few more people exposed to, and interested in, doing the work. Automating the nomination process would be very helpful, too, as I recently found a merger request tag from 2009 on an article – but the request was never listed at Wikipedia:Proposed mergers, so it has sat for two years with no follow-up whatsoever. GenQuest ^{"Talk to Me"} 22:54, 7 January 2013 (UTC)

It was never intended to have every merge proposal listed on proposed mergers, and it's not the intention now. Instead, it's a noticeboard for users seeking help with the process. Ego White Tray (talk) 02:03, 8 January 2013 (UTC)

1) There is no point going ahead with this process unless it is automated (it will simplify everything and reduce errors in formatting requests).

2) There is no point agreeing a merge if no one is willing to do it. So that ought to be part of the decision making process

3) After the proposed merge has been discussed and agreed, there must be a time limit for the merge to take place, otherwise the pages will start to diverge from those for which the merge was agreed, and having an agreed merge hanging over a page it is likely to dampen editors contribution to either page until the merge is done because their new edits to the page since the mege was agreed could be lost in the merge.

2) There should definitely be a central page to list proposed merges with the request formatted in a way similar to RM, but unlike RM, I would suggest that is done with a translucent page by the month similar to the way it is done on Wikipedia:Copyright problems

--PBS (talk) 14:06, 8 January 2013 (UTC)

• Already exists at Wikipedia:Proposed mergers. Plain old {{mergeto}} is the equivalent of WP:PROD. If nobody objects after a suitable length of time (anything over a week is usually fair game), then you can do the merge yourself. You don't need permission from so,eon else to do this.
  If you want more discussion for some reason, then use Wikipedia:Proposed mergers, the equivalent of AFD. Also, see the FAQ at the top of WT:AFD about why merges aren't supposed to be handled there.
  What you're never going to get is a bunch of people really excited about doing the complex and tedious work of actually doing the merges. That's true for AFDs that close as 'merge', too: there are currently more than 150 of those listed at Category:Articles to be merged after an Articles for deletion discussion, and a brief check shows that some, like Saint Joseph's Catholic Church (Sugar Creek), have been there since 2009. The fact that a couple of volunteers said that a merge is the best outcome for a page does not mean that any of them are willing to do the merging. WhatamIdoing (talk) 22:49, 18 January 2013 (UTC)
• Support We desperately need this, merge discussions can go on for years. Emmette Hernandez Coleman (talk) 22:52, 18 January 2013 (UTC)
• Support. To address WhatamIdoing: If I understand correctly, this proposal simply aims to make WP:PM "policy", and then in turn, much as you said, clarify that {{mergeto}} is like WP:PROD. The change, in a nutshell, is if someone contests the merge {{mergeto}}, rather than create a merge discussion on the talk page/etc. (which typically is viewed by a limited subset of editors, usually who are already involved, yadda yadda), the proposed merged is listed at WP:PM (or something like that). —Theopolisme (talk) 03:08, 19 January 2013 (UTC)

So if Merge is like PROD

Then what happens after the determinate period of time? I read someone suggest that the mergeto page is copy-pasted to the bottom of the mergefrom page with a notice saying "Page X has been merged here, please integrate this information into the main article text." That's the only way I can think the content will actually make it into the article, if it shows up on the page and then becomes a cleanup task. The alternative is we declare that Page X is to merge into Page Y and hope someone will come along and do it. In that scenario, we are back where we started, only having spent more time making things all official-like. --NickPenguin_(contribs) 16:58, 19 January 2013 (UTC)

As a means of flow control of this process, what you're suggesting makes the most sense so far. The only big problem I would see is the potential for too many of these "combined haphazardly" articles would eventually build-up into the same two–three year backup we now have with the noms. GenQuest ^{"Talk to Me"} 18:28, 19 January 2013 (UTC)

I agree to a certain extent. Usually the article getting the merge content has a lot more eyes than the other article, so the content would be integrated more quickly than otherwise. --NickPenguin_(contribs) 18:44, 19 January 2013 (UTC)

Proposal to show article rating on top of each page.

This is a proposal to show the article rating on top of each page. This way users can have directly an idea if the article is trustworthy or not. There are so many articles on wikipedia that are containing false/not neutral/biased information because they are being hijacked/monopolized by people that have an interest in promoting their point of view on the subject. Rating the article is a good way to unmask these improper articles! Thank you! Dzjorrit (talk) 12:08, 29 December 2012 (UTC)

Interesting. We already have a rating system in place, which is shown for just good, featured and stubs. What if the B and C classes are also displayed at the top of the page. TheOriginalSoni (talk) 13:12, 29 December 2012 (UTC)

For registered users, there is the metadata gadget; see the line "Display an assessment of an article's quality as part of the page header for each article. (documentation)" --Izno (talk) 14:43, 29 December 2012 (UTC)

I think he means something like that gadget but for everyone. ~~Ebe123~~ → report 16:20, 29 December 2012 (UTC)

No, showing only the rating results of the system that is now on the bottom of each article, clearly visible on top of the article should be fine enough! It would greatly improve the interaction between Wikipedia and it's users and would make users more aware that they are part of our common knowledge that Wikipedia is trying to represent.Dzjorrit (talk) 16:50, 29 December 2012 (UTC)

Um what rating results? TheOriginalSoni (talk) 16:52, 29 December 2012 (UTC)

WP:Article Feedback Tool. Did you disable it in your preferences, by any chance?—Emil J. 17:07, 29 December 2012 (UTC)

On any article page on the bottom there is a grey box called 'Rate this page' with a link on the right 'View page ratings'. These ratings should be visible on top of the page so the user can see them clearly when the page opens.Dzjorrit (talk) 17:56, 29 December 2012 (UTC)

Oh. That rating. Can anyone just link to some excellent, good, average and poor articles here so that we can gauge whether the ratings actually describe the state of the article? TheOriginalSoni (talk) 18:14, 29 December 2012 (UTC)

I am quite fond of the gadget that Izno mentions, and I would endorse its implementation as an opt-out rather than opt-in. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 10:52, 2 January 2013 (UTC)

I found out that not all articles have ratings enabled for them. Like China and India.

Here are some that I found -

• Albert Einstien GA,2400 votes - 4.1 4.0 4.1 4.1
• Earth FA,1000 votes - 3.5 3.5 3.5 3.6

TheOriginalSoni (talk) 18:22, 29 December 2012 (UTC)

I can give as example the Dorje Shugden page. There are 2 groups that have different opinions about this subject. The New Kadampa sect thinks Shugden is a Dharma protector, and the followers of the Dalai Lama think it is a negative spirit. But the article is clearly controlled by the New Kadampa people. And this also shows clearly in the 'Trustworthy' and 'Objective' index (1.9 and 2.0). The disclaimer of Wikipedia states clearly that it is not guaranteeing the quality of the content. But the very least it should do is showing what the average opinion is of the users about each article.Dzjorrit (talk) 18:53, 29 December 2012 (UTC)

13 ratings is not a valid starting point for ratings. 100 might be; Over 250 will definitely be. Why not single out only those articles with over 250 ratings so we can find out exactly if the quality of the article is represented in its ratings?

TheOriginalSoni (talk) 19:48, 29 December 2012 (UTC)

Since there is no threshold for publishing an article, and there is no way for an user to find out if it is trustworthy, I don't see why there should be a threshold for publishing ratings. Also this will encourage more users to also give ratings. An other idea is to look at the different votes, if they are all almost giving the same ratings then we know an article is either good or bad. But if a lot of users give it a bad rating and a lot of users give it a good rating then we know this article subject is probably highly controversial and there should definitely a warning being displayed on top of the article page warning the user that the contents are likely to be very subjective. Wikipedia is more and more getting a bad name for hosting wrong/controversial information, it is very important that users get proper feedback about the content of each article! Only by properly informing users, Wikipedia can live up to it's reputation as the major source of information on internet.Dzjorrit (talk) 22:27, 29 December 2012 (UTC)

The question is why to use ratings given by "readers" when you can use those given by "editors"? Readers may look at at a one-sided controversial article where they know about only one side, and give high ratings to it, not knowing how bad the article is. Or they may be shocked to find the opposing view given (in well-written controversial articles) and give it low ratings. What would be the primary advantage in having single time readers give those ratings than experienced editors? TheOriginalSoni (talk) 10:01, 30 December 2012 (UTC)

We all know that there is no absolute truth, we all have our own truth and slowly adjust what we think is true by interacting with other peoples opinions. There is no guarantee that the opinion of an editor has more truth then a visitor. The only way to come close to the 'real' truth is by having a democratic system in place. It would be even better if Wikipedia would give space to each point of view about a controversial subject. Now a controversial article is just showing the opinion of the group that has the most 'power' over the article. It is really bad to present a limited point of view (even if it is well written) as the general accepted truth.Dzjorrit (talk) 10:37, 30 December 2012 (UTC)

That is one of the most dubious statements that has ever been labeled "We all know". No, we don't all "know" that there is no absolute truth or that we all have our own truth. Some of us believe in objective reality and the scientific method. And it is demonstrably untrue that Wikipedia articles show the opinion of the group that has the most 'power' over the article. That would be Reddit. We, on the other hand, have WP:V and WP:NPOV. --Guy Macon (talk) 09:35, 2 January 2013 (UTC)

Article Feedback Tool Version 4 "Rate this page"

Measuring Article Quality (AFT4). Wikimania 2012

Dzjorrit, actually this Article Feedback Tool Version 4 "Rate this page" is not useful. It really isn't. There has been a lot of research and analysis: Article feedback/Research, User:Protonk/Article Feedback, wikimania2012 presentation and wikimania2012 video (30 min). Read it or watch the video with the slides for the details.

Now, you may ask yourself: if this tool is useless, why is it on 90% of english Wikipedia articles? That's a good question which was also asked on the mailinglist a year ago. Apparently, AFT4 is a kind of placeholder for AFT5 ("Did you find what you are looking for?"), which is a lot better. Cheers --Atlasowa (talk) 18:56, 31 December 2012 (UTC)

OK, the real issue is this: How do we prevent that an article is only showing the point of view on the subject of the group that has the most 'editing-power' over the article? Wikipedia is in some cases not democratic at all! Many article are not neutral or objective, visitors only are presented with one side of the subject and are not aware that they are not presented with an objective point of view (not everybody reads the wikipedia disclaimer).Dzjorrit (talk) 10:32, 1 January 2013 (UTC)

---

We already have enough distracting junk at the top of articles (fundraising banners, article problem banners, etc.); don't think we need more. Most people probably don't want to parse statistics before they read an article anyway... AnonMoos (talk) 02:51, 3 January 2013 (UTC)

We currently display when an article is really good (FA) and pretty good (GA). Why do we want to advertise when it is not so good yet.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 20:55, 3 January 2013 (UTC)

Oppose In most cases I encountered with the B-C-D-ranking, I have the idea this ranking system was also biased or at least flawed. It is good enough to state the GA and FA statuses and not display any more "distracting junk" at the top of articles. On top of that, the proposal is almost a guarantee for more edit wars and drama, as the hijackers and POV-pushers will fight to the last to prevent exposing their "work". The Banner talk 12:25, 4 January 2013 (UTC)

• Oppose: If you want to see the ratings, there's a little thing you can click in your preferences that changes the title of the article a certain color depending on the rating (sky-blue for FA, olive for C, maroon for stub, etc). I think that's probably all we need pbp 05:10, 12 January 2013 (UTC)

Oppose unlike the GA and FA rating system (that is not perfect) - all other classes are not unformed across all projects/people that rate pages. Thus may not accurately be rated. Moxy (talk) 05:15, 12 January 2013 (UTC)

Guys, he's not talking about B-class or Start-class or that sort of thing. He's talking about the old version of the WP:Article feedback tool. That's the thing with the stars at the bottom of the page, and which gets excellent ratings if the readers like the subject (all the girls reading about this week's favorite teenage heartthrob) and lousy ratings if the readers dislike the subject (creationists reading about evolution or vice versa). It kind of works for neutral subjects (like Cancer, but not Alternative cancer treatments), but whether it provides useful information about the article depends on both the state of the article and the age and biases of the readers who are attracted to that page. For example, Alternative cancer treatments names almost 50 sources, almost all of which are significant peer-reviewed journal articles, scholarly books, or official statements from major drug regulating agencies, but it gets a rating of "Heavily biased" from most of the people who leave ratings, because it doesn't reassure them that whatever quackery or outright fraud they're interested in will surely cure them. WhatamIdoing (talk) 23:03, 18 January 2013 (UTC)

Simple English at top of languages

The primary question for this discussion is- Should the Simple Wiki be put at top of the languages bar? TheOriginalSoni (talk) 20:11, 29 December 2012 (UTC)

The issue was already discussed on the Village Pump and had garnered supports too, but due to an amateur mistake on my (nominator) part, it had to be closed on mainly technical grounds. Relevant discussion related to the issue may be found in the following places-

• The Original discussion in the Pump encompassing a broader range of issues
• RFC and subsequent voting on the above (Later being narrowed down to the above question asked here)
• Discussion related to the closure of the topic above
• AN discussion on re-opening the RFC after closure
• Discussion at Bot requests to deliberate on Technical implementations of the project
• A related thread in the Idea Lab.

Adding an RFC to have wider community opinion- TheOriginalSoni (talk) 20:11, 29 December 2012 (UTC)

Discussion

Feel free to discuss any of the issues already discussed and add your/previous statements here.

• Please see WP:Manual of Style/Layout#Order of sections. Apteva (talk) 07:19, 31 December 2012 (UTC)
• I noticed that simple English is already the top link in the foreign languages on the WP:MAIN page. Does anyone have any insights as to why this decision was made? Might it shed some light on this discussion? AgnosticAphid talk 11:07, 18 January 2013 (UTC)
  • That simply reflects the current ordering at W:, which comes from {{Main Page interwikis}}, which has been that way since simple was added in 2007.[2] Apteva (talk) 02:43, 21 January 2013 (UTC)

• What's going to happen when Wikidata comes along? MER-C 10:08, 21 January 2013 (UTC)

I believe enWiki shall send a note to the developers of WikiData to customize our sorting list. TheOriginalSoni (talk) 05:06, 22 January 2013 (UTC)

Voting

• Support as nominator TheOriginalSoni (talk) 20:11, 29 December 2012 (UTC)
• Oppose'. I'm going to say what I think, and I apologize if it sounds impolite or hurts feelings, but it's what I think. Simple English Wikipedia is mostly a failed experiment. The task that it theoretically sets for itself — explain ideas just as complicated as those of any other Wikipedia, but using simple language — is basically just not possible. There is no justification for giving it priority over genuine natural languages. --Trovatore (talk) 20:30, 29 December 2012 (UTC)

Two things. First - Simple wiki is not as good as it should be mainly because of the coverage it fails to get from users who are actually "searching" for something to edit substantially. I believe this proposal could get it some decent coverage. Second - I dont think its impossible to do what the Simple Wiki tries to do. All it envisgages is Wikipedia, but just without the technical Jargon and the sophistication in languages and sentence construction that is like a signature style of the wiki now. Challenging? Yes. Impossible? I dont think so.

And finally, Simple gives a scope for the readers who do not have the technical mind to understand the current articles, to do so - A place where everything is simple. TheOriginalSoni (talk) 09:52, 30 December 2012 (UTC)

We disagree. My view is that it is, in practice, impossible. Technical "jargon" (used judiciously) is actually the simplest and clearest language for expressing technical concepts. If you ban it, clearly explaining the concepts becomes tedious to the extent of impeding the effort of getting them across at all.

That doesn't mean that people shouldn't try, if they want to. So far they have not succeeded. Given the inherent implausibility of the goal, I do not think that we should distort the interlang listings just to advertise it. --Trovatore (talk) 18:42, 30 December 2012 (UTC)

If both of you are under the impression that Simple doe not use technical terms, then it doesn't sound as though either of you are sufficiently informed to be able to judge the success of the project... (see Macdonald-ross' reply below). Osiris (talk) 00:51, 4 January 2013 (UTC)

• Oppose. I'm afraid I have to agree with Trovatore. Whatever it is that Simple wants to do, it has never succeeded in even clearly defining that goal, let alone making any significant headway towards achieving it. Its programmatic statements about it are largely either vacuous or self-contradictory, and its practice is chaotic. Fut.Perf. ☼ 10:50, 30 December 2012 (UTC)
• Oppose. Unlike the other posters, I don't really have a view on Simple English Wikipedia. Sometimes, it can be quite useful; at other times, it's hopeless as a reference tool. However, it is easier to locate Simple English in the list of interwiki links if it is in the correct alphabetical order. No need to overcomplicate it. — This, that, and the other (talk) 11:25, 30 December 2012 (UTC)

  I believe the point of the proposal is not to make it easier to find, but to make people be aware of its existence at all. Being buried in the middle of the list is easy to overlook, being at the top makes it clear it's different (and it IS different) and calls attention to itself, which is what the proposer wants. Most people don't know it exists, after all (though granted, many people don't realize anything but en exists...) ♫ Melodia Chaconne ♫ (talk) 14:31, 30 December 2012 (UTC)

  Or just change the font color. Others are completely different language, "Simple English" is not!-Tito Dutta (talk) 19:48, 30 December 2012 (UTC)

• No opinion as to whether it should be at the top or not, but I'm not sure it makes sense to be having this discussion now. As I understand it, interwikis are going to start being handled by Wikidata in a few weeks, which will probably take the issue of how to order things away from the English Wikipedia. A while later we'll probably have ULS here and have interwikis selectable through that instead of the current list display, making the point moot. --Yair rand (talk) 19:58, 30 December 2012 (UTC)
  • First I've heard of this. Can you give a pointer to further information? --Trovatore (talk)
    • On which part? There's some info on Wikidata at d:WD:I. Wikidata interwikis are going to be used on Hungarian Wikipedia starting January 14 (announced at d:WD:PC#next steps for the first Wikidata client - the Hungarian Wikipedia), followed by the Hebrew Wikipedia, and then the English Wikipedia, and then all the other Wikipedias. There's some stuff on ULS at mw:ULS. --Yair rand (talk) 21:11, 30 December 2012 (UTC)

In the previous discussion, I was told that we can contact the WikiData developers (or something like that) and place a request so that Simple English comes out at the top for us. TheOriginalSoni (talk) 04:39, 31 December 2012 (UTC)

• Oppose, really the Simple English Wikipedia was even worse an idea than Klingon. Its mostly good for laughs, and quite honestly might be the least useful link in the list. Prodego ^talk 06:50, 31 December 2012 (UTC)
• Oppose - If we want to promote the simple English WP, we'll need more than this - and I don't think that we should promote it in the first place. Ajraddatz (Talk) 05:36, 1 January 2013 (UTC)
• Oppose we do need something more sophisticated here, but it should be user driven not project driven. Ideally we need something that looks at the languages you have set in babel boxes and user preferences and prioritises those links accordingly. So if you speak two other languages and and are looking at an article that has 23 other language versions including one that you speak it should list that one first. ϢereSpielChequers 15:52, 1 January 2013 (UTC)

• A good idea, but most people who read Wikipedia are not users. And even for users, that would probably be implausible for the Wikidata developers. Language links won't be hosted locally much longer. Osiris (talk) 00:51, 4 January 2013 (UTC)

• Support - I only recently got familiar with Simple and that was only after my attitude with En Wikipedia degraded and I sought out other projects to participate in outside this one. Had that not happened I probably would still be oblivious to it. Simple is useful and if its a failed experiment its only because access to it is hidden among a sea of links. The English Wikipedia is the prominent link and always has been since the creation of the project so naturally so its going to get more activity. Moving the link up in the interwiki list doesn't just garner traffic to simple, it lets the readers of the article know, that there may be a simpler version of it that they can start with to gain at least some familiarity with the subject. Its easy for us to discredit the site because we can all clearly read and articulate english, many of us at an advanced level. But try reading a site in another language, maybe using google translator and see how much it makes sense. Kumioko (talk) 17:00, 1 January 2013 (UTC)
• Oppose I'm concerned about the effect this might have on contentious articles - fringe, biographies, etc as it might drive vandals, BLP violators, etc to work on the Simple version. Dougweller (talk) 15:17, 3 January 2013 (UTC)
• Support. It is true to say that reliable articles on science and other technical subjects need non-simple technical terms, and Simple does use them. We approach this problem by 1. agreeing that accuracy is a prime objective in science communication (we have a consensus on this), and 2. by using appropriate editing techniques. A technical term can be linked to a page which explains it, to an entry in Simple wikt (our version of Wiktionary) or by explaining it in a footnote. The fact that some of the negatives appear not to know this is interesting. I think if one looks at some of the pages on molecular biology, or immunology, or astronomy, you can see some fairly good examples. Some topics are relatively undeveloped, because we have no-one with the background to handle a particular subject -- physics for example -- but that is a reflection of the problem that we have too few editors to handle the work that needs doing. On the other hand, English Wikipedia has quite different problems. There are an astonishing number of long, verbose and unreadable articles, where struggles between editors have destroyed any sense of structure. Articles wander this way and that way, everything that anyone can think of is stuffed in... The standard of prose in many articles is truly dreadful. It is very difficult to improve pages on important topics because of the time taken in endless discussions. Much of English wiki is a closed book to the many, many readers whose reading skills in English are average. Simple English is a sensible answer to a real problem. It deserves to be better known, and the proposal is one way to go about it. Macdonald-ross (talk) 22:55, 3 January 2013 (UTC)
• Support. Not doing anything in response to all the article feedback is just not productive. Whether or not you find it useful, not all readers have a sufficient knowledge of English. To readers of this wiki, the link to SEWP is the most valuable link in the list. If they're reading this wiki, chances are good they can understand a bit of English -- if they want to read the topic described in clearer terms, they'll be able to see the link more easily. Nothing wrong with sorting it at the top at all. Osiris (talk) 00:51, 4 January 2013 (UTC)
• Support - as expressed by so clearly by Osiris above. --Peterdownunder (talk) 23:00, 4 January 2013 (UTC)
• Support per above.  Hazard-SJ  ✈  04:27, 6 January 2013 (UTC)
• Support, as per nom.--TVBdxiang (Talk) 06:08, 6 January 2013 (UTC)
• Support - As Osiris says. Yottie (talk) 16:39, 7 January 2013 (UTC)
• Oppose, on the grounds that "Simple English" is ill-conceived. ~ J. Johnson (JJ) (talk) 22:25, 7 January 2013 (UTC)
• Support Osiris does a wonderful job explaining what I couldn't have said any better. MJ94 (talk) 18:50, 9 January 2013 (UTC)
• Support Basically per Osiris. AIRcorn (talk) 09:13, 10 January 2013 (UTC)
• Support I couldn't have said it better than Osiris. -DJSasso (talk) 20:04, 11 January 2013 (UTC)
• Oppose: Simple Wikipedia is a joke. Most of their articles are out-of-date stubs. It's not helpful to most readers, who just have to come back here to find what they're looking for pbp 05:07, 12 January 2013 (UTC)

Purpleback! Nice to see you here. :) Osiris (talk) 14:28, 12 January 2013 (UTC)

• Comment: Should be noted that most of the "Support" votes are active on Simple English Wikipedia, if anyone's interested pbp 19:32, 12 January 2013 (UTC)

• And the fact that you are banned there doesn't play into your opinion at all? -DJSasso (talk) 19:07, 14 January 2013 (UTC)
• A sudden rush of supporters does seem to have occurred here after Macdonald-ross advertised this discussion on simple.wp's village pump. Jafeluv (talk) 13:48, 15 January 2013 (UTC)

• I wouldn't really call it a sudden rush seeing as how they are spread out over a number of days. But yes simple was made aware of the discussion. -DJSasso (talk) 14:09, 15 January 2013 (UTC)

• Oppose - If it ain't broken, don't fix it. This is hardly an issue. --Futuretrillionaire (talk) 16:11, 16 January 2013 (UTC)

In this case, it would not appear that nothing's broken. As I mentioned in the previous discussion, many reader feedback on well known articles repeatedly ask for a simple version of the article, or show that the reader in question failed to find the necessary information from the large (and should I say excessively long) enWiki page. Exposure to the Simple Wiki would help in solving this issue. TheOriginalSoni (talk) 16:35, 16 January 2013 (UTC)

• (edit conflict)Support. Simple English isn't a different language edition, unlike the other entries in the list, so it should be distinguished. I also agree with Madonald-ross and Osiris above - for the record other than a updating my user page there just now, my only connection with the project is a handfull of edits in 2005-6. As for Purplebackpack's comments above, we do not filter the non-English langauge edition links because of good or bad quality, so what justification is there to do so in this case - particularly as it could be a spur to improving their content? Thryduulf (talk) 16:36, 16 January 2013 (UTC)
• Support, agree with Thryduulf. --Nouniquenames 16:46, 16 January 2013 (UTC)
• Support echoing above supporting opinions. Small effort which could help a number of visitors. Kennedy ^(talk) 17:38, 16 January 2013 (UTC)

Note - I would also note a couple things that have been brought up above. Most support voted are from people familiar with Simple and its mission and purpose. Most of the oppose votes have never edited there and thus likely have no understanding of its purpose or mission. Kumioko (talk) 18:15, 16 January 2013 (UTC)

• Conditional support - this should be done within the Mediawiki software, but not by manually editing articles. It it easy enough for the software to sort the displayed links in any order. The order of the interwiki links in the source of the page should not affect the order in the rendered page, and trying to put simple first in the source of the page is a never-ending maintenance headache. — Carl (CBM · talk) 18:34, 16 January 2013 (UTC)

I am not sure I was clear enough, but it was implied that it shall be done within the MediaWiki software. Among the discussions between those who knew the technical aspects, it was proposed to inform the WikiData developers once the proposal was passed. I intended to discuss those technical issues only once there was a clear cut consensus on the original proposal TheOriginalSoni (talk) 18:41, 16 January 2013 (UTC)

It ewas not very clear to me, but I will edit my comment. — Carl (CBM · talk) 18:53, 16 January 2013 (UTC)

• Oppose efforts should be made at making this encyclopedia more accessible, not split off to a redundant project. --Jayron32 18:36, 16 January 2013 (UTC)
• Oppose Jayron32 summed up my thoughts exactly. Legoktm (talk) 19:05, 16 January 2013 (UTC)
• Comment. To most other languages, putting en in one place and simple en in another makes no sense. That can be fixed without contention. If simple englash is a worthless project it can be axxed, but there is clearly a need for a kids encylcopedia as well as an adult one, and I would see simple English more along the lines of that rather than it simply being one geared to those who do not have any three syllable words in their vocabulary.. Apteva (talk) 20:11, 16 January 2013 (UTC)
• Oppose As much as I like the ideology behind it, I don't believe this is totally necessary.

First, no reader is required to gain a full understanding of an article. As I said in the previous discussion, they may simply read the lead and look at the pictures if they do not understand an article. We have a template to indicate that the lead does not summarize the contents well enough; it should be used more often. Other resources exist for those with insufficient knowledge.

Yes, this has the potential of destroying the ability of a Wikipedia reader to get information by looking at the images alone! But why did you say no reader is required to gain a full understanding of an article?···Vanischenu^「m/_Talk」 07:59, 19 January 2013 (UTC)

Second, readers who really and truly wish to gain a full understanding of an article will make a strong effort to do so. This will actually be more beneficial to them than a watered-down Simple English version, which I should note can appear to be condescending at times.Pokajanje|Talk 21:00, 16 January 2013 (UTC)

Just one point that I will like to make here. Not everybody is as proficient in English as our average Wikipedia editor here. There are plenty of places where I personally had to reread paragraphs several times just to understand what it means. It is then illogical to assume that all the articles here will be within the reach of the standards of the average reader. There will be plenty, if not many, who would not be able to gain a full understanding, despite really and truly wishing and trying to get it. And everyone certainly does not have as much time as you might think. TheOriginalSoni (talk) 21:23, 16 January 2013 (UTC)

Third, I fully agree with Trovatore's quote above: "The task that it theoretically sets for itself — explain ideas just as complicated as those of any other Wikipedia, but using simple language — is basically just not possible." It is impossible to achieve a perfect balance between getting information across and making it understandable.

Finally, I think proposal shows Wikipedia's systematic bias. Would this proposal affect the ordering on other-language Wikipedias? If so, that would be very biased, as they likely have no more use for a Simple English article than I. There is no reason not to have Wikipédia Français Simple or other Simple Wikipedias, so why not create them? Because when "Simple English" is between Norwegian Nyorsk and Azerbaijani in its article count, with only 35 featured articles and 59 good articles, it can pretty much be considered a failure.

In summary: Simple English interwiki links at the top would only be partially beneficial, for 94 English articles. Pokajanje|Talk 21:00, 16 January 2013 (UTC)

Are the Norwegian Nyorsk and Azerbaijani wikis also failures? --NickPenguin_(contribs) 21:04, 16 January 2013 (UTC)

Clarification - This proposal is solely going to affect the English Wikipedia, and not any other language Wikipedia. TheOriginalSoni (talk) 21:16, 16 January 2013 (UTC)

• I believe several editors might not realise or may forget this, and so I am going to repeat what has been earlier said in the previous discussions - There are literally dozens (possibly hundreds) of editors and potential editors, especially new ones, who fail to contribute completely to the project because they do not find anything to edit here. Most of the things that they could have edited have already been, and there is precious little for them to try their hands on.

On the other hand, we have the Simple Wiki, which is a failed project in the eyes of several users. In my opinion, this is not because it is inherently a doomed task, or anything of the sort. Its mainly because the Simple wiki does not get the due coverage it gets. I believe that once the Simple Wiki link is put at the top of the Languages, most editors who would otherwise have not been able to contribute here would come and add to the Wiki, as it is still way far from a comprehensive project. Furthermore, many readers who might benefit from a simple explanation and rules for Chess would now find something that actually makes a lot more sense to them. Do these benefits and potential benefits outweigh other concerns? I believe they do. TheOriginalSoni (talk) 21:16, 16 January 2013 (UTC)

I doubt that I am alone in thinking that the reason that Simple English Wikipedia is a failed project isn't for a lack of content or for a lack of editors. In both of those areas it would be hard to call it anything but a success. Rather Simple is a failed project because it does not provide a useful resource for readers. In other words writing simplewiki is inherently a doomed task. Prodego ^talk 21:32, 16 January 2013 (UTC)

We shall agree to disagree on that one. For you, its inherently a doomed task. On the contrary, I see it only because of a lack of awareness among the readers and the editors. These concerns calling the simplewiki a "doomed task" sound surreptitiously similar to similar concerns voiced by opponents of the enWiki itself. And yet, I do not think we have failed here. TheOriginalSoni (talk) 21:40, 16 January 2013 (UTC)

• First of all, let me stress that Simple English Wikipedia is a small community, of perhaps twenty named, and perhaps another 10-15 unnamed contributors. Throughits size, the need to regulate is far less than with a big project that regular English Wikipedia. We have not limited the creation of new articles, and our admin team regularly deletes the nonsense that gets created. While we cannot agree on what the target group really is, the resulting articles are often easier to understand than the regular English counterparts. Yes, we lack editors, and yes, our target group is probably not native English speakers. Now take the example of a learned person, who simply has not learned English completely so far; would it not be helpful for those people to get the link to the "easier-to-understand" version before the others? - Similarly, wouldn't it be a laudible task to help those few editors create decent articles? - Have you ever tried explaining a scientific concept, using scientific language, but at the same time making sure that someone outside that domain of study can grasp it? -Wouldn't that be more thrilling than simply copying the formulas from the textbook you get from the library? - A purpose, perhaps? --Eptalon (talk) 23:31, 16 January 2013 (UTC)
• Oppose as a vote of no confidence in Simple. Sven Manguard Wha? 23:40, 16 January 2013 (UTC)

You know: there are a lot of things about Simple that desperately need fixing. But it makes it a hell of a lot harder when it's got critics pulling it down whenever they get the chance. You don't have to help the project; this isn't a vote of confidence, and you don't have to vote either way. This is about helping the readers locate easier-to-understand information on the topics they're reading. Osiris (talk) 11:01, 20 January 2013 (UTC)

• Comment - I don't have any first-hand experience with Simple, so I can't guess as to its current or future status, or how it should be mmarketed. However, if a decision is made to move Simple to the top of the interwiki list, please change Wikipedia:AutoWikiBrowser/IW so that AWB follows the new rule. Thanks! GoingBatty (talk) 00:47, 17 January 2013 (UTC)
• Support I'm not the biggest fan of Simple English wiki, but it's not a different language so it shouldn't be listed in the middle of the foreign languages. Ryan Vesey 00:55, 17 January 2013 (UTC)
• Support As CBM said above somewhere, as long as the reorder can be done within the mediawiki software rather than bots going and making million of edits. ·Add§hore· ^{Talk To Me!} 04:12, 17 January 2013 (UTC)
• Support Simple English is different from all the other links in two ways: it isn't really another language at all, and all of our readers will be potential readers of Simple (since all of them can speak English). We don't filter the other language links by quality, and I don't see any reason why we should do so here. Hut 8.5 09:39, 17 January 2013 (UTC)
• Support. A link to Simple English version of an article seems qualitatively different to most readers of the english wikipedia than a link to the Afrikaans version of the article: everyone here can read the former; most can't read the latter. If the point of the simple English Wikipedia is to make other Wikipedia articles more accessible to those with limited English skills, which I think is fair, then moving the link to the simple English article out of a mass of foreign languages makes sense to me – it's the most likely link to be useful. It seems poor form to deliberately bury the link to make it unlikely to be used, which seems to be the goal of those opposing the proposal out of a dislike of the simple English Wikipedia. AgnosticAphid talk 10:59, 17 January 2013 (UTC)
• No thanks I don't feel this is appropriate at all. Interwiki links shouldn't be filtered for the dertriment/preferment of a particular project and its certainly very closed to other projects to advance the argument that simple is more useful to our readers than other projects. I would suggest that's actually not true and there are a lot of our users who have more than one language. Spartaz ^Humbug! 15:22, 17 January 2013 (UTC)

  But surely, generally speaking, simple English is more likely to be useful than any other individual language? AgnosticAphid talk 00:56, 18 January 2013 (UTC)

• Support Per Ryan Vesey et al. It's not really another language, it's a supplement to this one. --GRuban (talk) 17:16, 17 January 2013 (UTC)
• Oppose I don't like Simple English WP, and giving it prevalence atop the rest of the pedias is something I can't support. — ΛΧΣ²¹ 23:19, 17 January 2013 (UTC)

  Why should this WP:IDONTLIKEIT view be given any weight by whomever closes this discussion? Thryduulf (talk) 09:16, 18 January 2013 (UTC)

• Oppose If someone is viewing the regular English version of an article, why would they need to see the simple version? HueSatLum 23:32, 17 January 2013 (UTC)

  What if you do not understand the regular article, and need a simpler version? TheOriginalSoni (talk) 08:52, 18 January 2013 (UTC)

  Mathematics articles on WP are frequently far too advanced for me to understand, and I'm an intelligent native speaker of English. Simple English coverage of these topics would be very useful. Thryduulf (talk) 09:16, 18 January 2013 (UTC)

  That's true, and that's probably why the simple version exists in the first place. For me, when I was just a Wikipedia reader, I never paid any attention to the language links on the sidebar. Anyways, it's still there, just not at the top. HueSatLum 23:02, 18 January 2013 (UTC)

• Support This could be the boost that Simple needs to get going. AutomaticStrikeout (T • C) 01:58, 18 January 2013 (UTC)
  • I'm skeptical about the idea that sending more readers over to Simple would give Simple a boost in productive editors. Simple will always fail, by necessity, because it lacks the crucial source of life blood that successful wikis have: being able to recruit your editors from your readership. With normal wikis, if you are a competent reader of the wiki's language then you are a good candidate for becoming a competent editor in it. But with Simple, if you are a reader who needs simplified English to understand things, that does not mean you are going to be a good writer in simplified English. Because writing simple English is not easier than writing normal English; quite the contrary. Taking a reliable source about something (which will obviously be in normal English) and then breaking that information down to a simplified but correct linguistic form without dumbing down or distorting the content is a hugely difficult task; it needs more than the average proficiency of a competent English speaker, not less. Those people who Simple addresses itself to as readers will invariably produce broken English, not Simple English. Fut.Perf. ☼ 09:34, 18 January 2013 (UTC)

Umm.... I believe you are making the mistake of assuming all users and editors who shall start noticing the Simple wiki shall be less than average. Also, I do not think that there are currently no editors in Simple who are more than proficient in English. Not to forget that any average and sub average editors shall not be using complicated words, which would be precisely the motive of the Simple Wiki. Experienced editors can always then copyedit for further clarity. TheOriginalSoni (talk) 10:04, 18 January 2013 (UTC)

Oh, of course there are some good editors over at Simple. But they are people who work there out of sheer idealism, not because they were guided there by their own needs as readers. And as for low-proficiency writers not using complicated words: oh yes, believe me, they do, all the time. Because the complicated words are there in the sources they work from (or copy-paste from), and they lack the linguistic skills to replace them with simpler ones. Fut.Perf. ☼ 10:14, 18 January 2013 (UTC)

I hope you do not imply that only those who "require" a simpler version of articles will notice and go to and contribute to the Simple wiki, should we decide for this proposal. TheOriginalSoni (talk) 11:17, 18 January 2013 (UTC)

• Oppose: There should be no priorities with languages. --NaBUru38 (talk) 16:33, 18 January 2013 (UTC)
• Oppose per NaBUru38. If a reader is not a native speaker of English, then they are going to be a native speaker of another language. If they wish to get the gist of an en-wiki article before reading it properly, why do we believe they wouldn't rather use their home-language Wiki for the purpose, rather than the simple: version? Elevating this particular sister project above others strikes me as arbitrary. It Is Me Here ^{t / c} 20:43, 18 January 2013 (UTC)

Just so you know, my native language is not English. Yet when it comes to understanding and learning things, I use English and not Hindi. For Hindi is not the language where I can understand scientific stuff like Radiation or Earth. Its English. So just in case I do not understand the English page, its only Simple which can help. And there are plenty of those who are worse off than me, who will be more helpless. TheOriginalSoni (talk) 03:33, 19 January 2013 (UTC)

I am certainly not going to dispute your personal experience of the site – but my question is, why do we think that more readers as a whole prefer simple: to de: for native German speakers / ar: for Arabic speakers / etc.? Do we actually have good data on this? It Is Me Here ^{t / c} 16:44, 19 January 2013 (UTC)

Maybe someone with more data might help. Till then, I also point out that there are plenty of native English editors who may not understand the enWiki article well enough. For them, Arabic will not really help. Simple on the other hand, will. Not to forget that since the reader has chosen to read the original article in English, they might want an explanation too in English, and not any other language. Or else they would have gone to that language immediately. TheOriginalSoni (talk) 18:43, 19 January 2013 (UTC)

• Support: How can I oppose if it brings only good? No harm done to those readers who like not to see Simple English, and for those who like to, this is very helpful. Any reader who knows English would be able to understand Simple English. Period. Also, no one forces you to click on the link; if you like you can get there easily, and if you don't like it, then you are not much affected by this as it is not different from having the Arabic and others at the top; so why oppose it for not liking BE, simplewp, or the community?···Vanischenu^「m/_Talk」 07:59, 19 January 2013 (UTC)
• Support - Most useful link to the vast majority of readers, so it makes sense that it should be a the top. There will be cases in which readers won't be able to understand an article on this project, so by having the simple version linked in a prominent position, they can easily try the simple version. Failing that, anyone who doesn't like the Simple English project shouldn't be bothered by the change. CT Cooper · talk 12:54, 19 January 2013 (UTC)
• Support as it aids those who need it most and has minimal to no negative impact on everyone else. Having the link to Simple at the top makes it easier to find for those Simple is aimed at: "people with different needs, such as students, children, adults with learning difficulties and people who are trying to learn English". SilkTork ^{✔Tea time} 14:44, 19 January 2013 (UTC)
• Support as per Osiris -Cameron11598 (Converse) 00:56, 20 January 2013 (UTC)
• Oppose: Simple is super :-/. I think we really ought to stop advertising it all. Per Spartaz, Sven, Fut.Perf, and many of the other opposers. --MZMcBride (talk) 01:39, 21 January 2013 (UTC)
• Support - I have only made a handful of edits on Simple, and I'm not sure if I plan to edit there more; that being said, I support this proposal. Osiris sums up most of my thoughts in the relevant support - to the English Wikipedia readers, Simple is most often the most relevant "language" on that list to people who read English. This change would make Simple more accessible to people who would find it useful, even if some or most of us English Wikipedia don't. I see people opposing because Simple English isn't a language - they're right. It isn't a language by traditional standards. However, it may be one of the best ways for people to understand a topic they'd like to learn more about, coming from the English Wikipedia. A boost to the top for Simple would not only make it more accessible to readers, but it'd make it more visible. I didn't know that much about SEWP early into my wiki career, but I can certainly say the project isn't a waste. With this extra visibility, editors may find a desire to explore and build upon Simple, making it an even better resource for knowledge. Knowledge is for everyone, it's a language we all understand - English isn't. MJ94 (talk) 03:47, 21 January 2013 (UTC)
• Support as the most useful language link to the majority of readers of the English Wikipedia. JASpencer (talk) 23:01, 21 January 2013 (UTC)
• Oppose as per Ajraddatz.  TheArguer  _{SAY HI!} 00:38, 22 January 2013 (UTC)

"Editor of the day" section of main page

• I also suggested this on Jimbo's talk page (here) a few months ago, with only one reply, which was positive. Mark M (talk) 21:58, 31 December 2012 (UTC)

In the interests of encouraging more people to become editors, I would like to suggest showcasing a different editor everyday, on the main page. This would consist of a blurb by the editor, answering a simple question like "what made you start editing wikipedia?" or maybe "What do you do as a Wikipedia editor?" Then there could be a link See the changes made by this user. And maybe Leave this user a message. You could be famous for a day!

I'm imagining some kind of nomination process to become a "featured editor" selected an editor "testimonial", and of course the editor would have to consent, and brace themselves for what surely would be a surge of interest. I think this would be great for giving current editors more recognition for their hard work (the ultimate barnstar!), and it might also encourage / inspire readers to join up, by giving them something to aspire to. Two birds, one stone! :-) Mark M (talk) 21:58, 31 December 2012 (UTC)

• Question What kind of process would be used to select this "featured editor"? Just as a well meant advice: This could also have some negative side effects if handled improperly. I think a LOT of care should be taken when developing this process (which isn't meant to discourage the overall idea). There is a lot of stuff that needs to be considered (does something like the general spirit of WP:NOBIGDEAL apply here as well etc). Perhaps similar processes at other projects (such as this one) should be examined first and look taken at how they work, how abuse of the process is being prevented etc). Just some food for thought .... -- Toshio Yamaguchi 22:29, 31 December 2012 (UTC)

Maybe "featured editor" gives the wrong idea.. I just mean editors whose brief "testimonials" are chosen to appear on the main page. I imagined the process would go: 1) Somebody would write a blurb about what they do, and/or why they think Wikipedia is great. 2) Other editors check the blurb, and check the user's recent edits to ensure they are "good" edits, and ensure the user is in good standing with the community (whatever that means), 3) The blurb / editor is approved (or rejected). I don't know how much demand there would be for such a thing, so it's hard to figure the best process beforehand.. it's just an idea. Mark M (talk) 23:26, 31 December 2012 (UTC)

Okay, thanks for the clarification. I'm not sure what exactly I think of this yet. One more thing to consider: It isn't always easy to determine whether an edit is good or not. There are editors who make a lot of edits that are controversial that are nonetheless made with the best intentions. This might not be of interest to the majority of editors of course, just saying that this could happen. I think the information given should be very basic. I like this "What made you start editing" idea. Oh, and who has the ability to approve or reject a blurb? Can any editor do that? Will there be a consensus / vote based process? -- Toshio Yamaguchi 23:50, 31 December 2012 (UTC)

I was thinking of a process similar to DYK, where there might be some obvious criteria that a testimonial would need to satisfy, as well as obvious criteria for the editor (not currently blocked, etc). Then it would be a consensus decision on whether the blurb is approved for the main page. Obviously there would be quite a lot of work involved here, and there doesn't seem to be much interest anyway, unfortunately. Mark M (talk) 18:14, 3 January 2013 (UTC)

• Interesting. Perhaps it could be tied to this, if it ever gets off the ground, which seems like a similar concept that was suggested by Dennis a week or two ago at WER. Go Phightins! 22:32, 31 December 2012 (UTC)

• No: This isn't a social network, this isn't about you, this isn't about being a drama-queen and attention-whore. Go be famous elsewhere. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 22:34, 31 December 2012 (UTC)
  • I agree with what you said and I haven't fully formed an opinion on this, but couldn't having an editor on the main page remind readers that anyone can edit? I don't know, just a thought. I'm not a big fan of the idea, but I wouldn't rule it out entirely. Go Phightins! 23:09, 31 December 2012 (UTC)

• Fully support Adding the humanity back to Wikipedia is the best thing we can do. We are a community of hard working volunteers - real people with real lives - and not just anonymous pieces of code that magically create content related to your latest school assignment, and who may drop by with long and scary messages full of policy shortcuts. Reminding our readers... heck, even our editors, that there is a real community out there that they are actually a part of.. man, it would be the greatest feeling ever. I know we got a teste of this during the findraiser, and I for one fell in love with it. That's exactly the sort of things we need these days, and the sort of thing that keeps on getting declined every time it is proposed... The time is now.--Coin945 (talk) 15:55, 9 January 2013 (UTC)
• Oppose. Navel gazing at its worst. Editors can get recognition through thank yous, barnstars or other awards on their talkpages. AIRcorn (talk) 09:17, 10 January 2013 (UTC)

• Support After thinking about it a bit more I support this idea with a reminder that care needs to be taken when developing this. -- Toshio Yamaguchi 18:16, 12 January 2013 (UTC)

• Comment - Wikipedia Editor Retention has launched a similar award recently - Editor of the week. All are welcome to comment there too.

• Support I don't think it should be viewed as self-promotion. I prefer to think of this as a good tool for editor recruitment. AutomaticStrikeout (T • C) 02:00, 18 January 2013 (UTC)
• Support Why not. We do need to remember that the encyclopedia is written by real people. This stuff doesn't write itself and the contributions of some do deserve attention.--Amadscientist (talk) 11:18, 18 January 2013 (UTC)
• Oppose In such a measure we would create the battleground for a whole new set of long and ultimately not particularly useful arguments about editor conduct that would complicate everything we currently have in place. The pressure on high edit counts means that the pool of people is bound to draw in a whole heap of controversial editors - I say "controversial" but the actual level of discontent would only have to be minor. There would be an assumption that only the absolute best (whatever that means) editors would qualify, a drive to perfection that would feed back into the disagreements and would be unavoidable. Grandiose (me, talk, contribs) 13:35, 18 January 2013 (UTC)

I tend to agree with most you say. Also I see the risk that this can create kind of a class system of those who have been featured and those who haven't (I am waiting for the first time I see a vote in an RfA like Oppose "He / She did some good article work, but hasn't been a featured editor."). -- Toshio Yamaguchi 13:50, 18 January 2013 (UTC)

• Comment While what I said above is not enough for me yet to withdraw my support for this proposal (acknowledging that we don't have an instream of hundreds of new editors per day), I think perhaps we should use something other than a vote / poll based process. What about a bot that parses through all editors who have been active in, say, the last month and randomly chooses one of them? -- Toshio Yamaguchi 13:59, 18 January 2013 (UTC)

Which would defeat the entire purpose of this section - To recognize good quality work on Wikipedia. TheOriginalSoni (talk) 14:32, 18 January 2013 (UTC)

Which would defesa

Edit count gravity or Edit score (Edit count/contribution assessment)

The aim of starting this topic is attempting to find a way to assess an editor's contribution by his edit count and not to present any specific idea. Consider the formula below as an example and feel free to modify or expand it

In brief, it is generally/widely accepted that edit count does not indicate quality of an editor's work (don't click on these links if you already know it, skip to next paragraph, otherwise for details, Caveat lector and points mentioned in the 4 deletion nomination

The current writer (i.e. I ) has done a study in last few weeks which shows editors with very high number of bot, scripts, Toolserver tools (reflinks, dabsolve) edits have generally low "Average edits per page" (2.0 or less edits per page.)

Proposing "Edit count gravity" (or call it something else like "Edit score").. with the basic idea–

$T\times A \over 1000\!$
Where T=Total number of edits, A=Average edits per page and division by 1000 because we generally count our edits by 1000

Note Editors with very high edit count may score low
Example: User:Bgwhite with 227601 edits with 1.69 average edits per page gets $227601\times 1.69 \over 1000\!$ = 384.64569 but User:Rjensen with 65299 edits (almost one fourth of Bgwhite's edits) but a stunning 10.81 edits per page gets $65299\times 10.81 \over 1000\!$ = 705.88219.
And... it can be made more complicated adding number of blocks, number of pages created, number of deleted pages, files, user rights etc which I have not thought. Okay, that's all. --Tito Dutta (talk) 19:18, 1 January 2013 (UTC)

A nice idea, but further refinement would be needed. Alas, the law of unintended consequences means that there would be a perverse incentive to break up one big edit into lots of smaller steps. I've also been thinking about the challenges of Wikipedia:Editcountitis today: Wikipedia talk:WikiProject Editor Retention#Things that are difficult and easy (1 edit/day) Edwardx (talk) 20:43, 1 January 2013 (UTC)

that there would be a perverse incentive to break up one big edit into lots of smaller steps– True! But, it is (currently) similarly true for increasing edit count or to avoid loosing long edit because of edit conflict.--Tito Dutta (talk) 22:13, 1 January 2013 (UTC)

• I'm not understanding the value this is attempting to judge. How is making 10 edits to one page more valuable to the encyclopedia than making 1 edit to 10 pages? The core flaw of editcountitus is that quality of edits matters more then quantity, yet I fail to see how including average edits per page in the metric better measures quality. Monty₈₄₅ 21:59, 1 January 2013 (UTC)
• I have to also agree with Monty, above. The fact that I can copyedit a huge article, often taking 1/2-1 hour to do so, while doing so in a single edit is a source of pride for me. I consider it nonsense when another editor takes 10 edits to get to the same point, and the article remains in need of a good copyedit. Quality, not quantity, makes a good editor, and the only way to rate that is singularly and subjectively. There can be no canned formula for that. Any formula proposed would, therefore, be useless as a rating tool or parameter. GenQuest ^{"Talk to Me"} 03:53, 11 January 2013 (UTC)
• I agree with Monty; it seems the proposer has inadvertently opened a philosophical debate: Is it better to make many improvements to a few pages, or to make a few improvements to many pages? I think they should both be regarded as equally valuable (I, for one, attempt to balance both editing habits), but the proposed "formula" favors the former. I would recommend adding a factor for number of pages edited to solve this. Ideally, we would also want to have some form of a deduction for identified vandalism or other disruptive editing. RedSoxFan2434 (talk) 22:20, 1 January 2013 (UTC)

Ah, Philosophical debate?! Anyway, 1) we can not assess by "number of characters added per edit.." because "RefLink" etc tools add many characters automatically. 2) we can not assess by "interval between each edit while online" because it is useless, I am still watching a movie and editing Wikipedia. Edit count does not indicate quality of an editor's work and we don't seem to have any indicator too (other than another editor's comment/opinion)! --Tito Dutta (talk) 22:32, 1 January 2013 (UTC)

Sorry in advance if this sounds like throwing cold water on an attempt to create a useful metric, but I don't see what problem this metric is attempting to solve. I grant that raw edit count isn't a measure of quality. However, when you start with that premise, and introduce a new metric, the implication is that you are trying to devise a quality metric. (If not, I misunderstood). Ten edits to one article is different that one edit each to ten articles. However, it does not follow that the first editor's contribution are of higher quality. They may be, they may not be.

I'll also grant that if someone had the skill set, and decided their goal was to improve the quality of articles on Wikipedia, it is more likely that we would see a higher edit count per article than average. But the converse cannot be stated with any confidence—that an editor with a high number of edits per article is contributing more quality than one with a lower measure. It might be slightly true, in the sense that, given two random editors, the one with a higher edit count per article is slightly more likely to deliver more quality, but my guess is that it would be something like 51%/49% or maybe closer, which is virtually indistinguishable from random, and therefore useless.--SPhilbrick(Talk) 14:47, 3 January 2013 (UTC)

I don't think a proposal such as this even needs to solve a problem. It would really just be a statistic that could be used to analyze the contributions of editors with whatever level of importance the reader chooses to attach to such things. As to the suggestion, if you are going to try and argue this as a measure of quality of contributions, I would say that only article space edits and pages should be considered. Resolute 18:23, 3 January 2013 (UTC)

The units of such a figure would be edits²/page (per mil). That's bizarre. LadyofShalott 03:24, 11 January 2013 (UTC)

Oppose - thee is no way to measure the quality of an edit by automatic means. The fact tht a user split his/her edit into sevral smaller ones (thereby raising the edits per page) would be less good than doing it in a single edit; but if you're going to be doing it by paragraph, you're better off doing more (and thereby getting more edits on the page). This also encourages users to do more depth work (causing there to be more articles looked at by fewer users, resulting in less NPOV results) than breadth work. עוד מישהו Od Mishehu 21:22, 16 January 2013 (UTC)

• This reminds me of the long-running effort years back to measure programmer productivity by klocs (thousands of lines of code). One glaring problem is that making some code better, faster, more robust actually makes it smaller, which would be negative klocs. I don't recall that any quantitative measure of programmer productivity has been found; WP editing seems to be of the same clase of problem. ~ J. Johnson (JJ) (talk) 22:29, 16 January 2013 (UTC)

How about some way to see how many people are watching an article

Most experienced editors are watching 100s or 1000s of articles. Often this is to help ensure that pages are not being vandalised, having contentious unsourced content added, or worthwhile sourced content removed.

When adding yet another page to my watchlist, I do sometimes wonder how many others are already watching that page, and whether another watcher is really necessary (my speculation is that vandals and disruptive editors are much less likely to watch pages, so I assume that watchers are doing so primarily for good reasons). Equally, there may be many pages with no watchers at all.

Privacy and other concerns mean that we can't see who is watching an article, but how about some mechanism to see a simple count of how many people are watching an article? Edwardx (talk) 10:21, 3 January 2013 (UTC)

Near the top of the "History" tab there is a line of "external tools". One of these is labelled "Number of watchers", and it does roughly what you are asking for. When a page has fewer than 30 watchers, though, it just says "fewer than 30". I believe this is intended as a security measure. -- John of Reading (talk) 10:31, 3 January 2013 (UTC)

Thanks, I'd forgotten about that. For example, this page has 2357 watchers. Alas, "fewer than 30" is not much help to me. Is there any good reason why we can't go down to, say, "fewer than 5", or is there some real security issue? Edwardx (talk) 11:13, 3 January 2013 (UTC)

The problem with giving an accurate count of how many people are watching an article all the time is that it would be a goldmine for vandals. If you're looking to find somewhere your vandalism won't be noticed all you have to do is pick an unwatched page. Admins do have Special:UnwatchedPages, but it isn't very useful as it only lists the first 1000 pages (which isn't enough to get past Al). Hut 8.5 11:15, 3 January 2013 (UTC)

Perhaps I underestimate them, but I really can't see vandals going to all that trouble. And I would speculate that going from 30 down to 5 would not assist even the most sophisticated vandal. Edwardx (talk) 11:27, 3 January 2013 (UTC)

There are certainly some vandals who would. There is a documented example of a banned user getting hold of a list of unwatched biographies of living people and inserting subtle vandalism into them just to see what would happen (the admin who gave them the list was subsequently desysopped). The fact that a page is watched doesn't mean that someone is monitoring it - it might be watched by a new editor or someone who hasn't edited for months. Consequently telling someone that a page has fewer than five watchers is nearly as bad as telling them it is unwatched. If the page has 30 or fewer watchers then there is a good chance it is watched by someone who knows what they are doing. Hut 8.5 11:51, 3 January 2013 (UTC)

Agreed. There really are two classes of vandals: kids that think inserting dirty words into an encyclopedia is funny, and those that seriously intend to cause harm. The latter group is small, but they are relatively clever and persistent.—Kww(talk) 17:53, 3 January 2013 (UTC)

Secrecy is a two edged sword, which is why in most matters Wikipedia works by openness. Like many of my fellow vigilantes, I am overloaded with over 5,000 watched pages. Last year, cutting that from 6,000 I started by looking at the watcher number but it was always "under 30" so I quit looking and just went by whether others had edited at least four times as many times as I had. Surely this method left some of them unwatched, or rather not effectively watched, but absent one piece of useful information we must decide by using what's available. Jim.henderson (talk) 03:26, 5 January 2013 (UTC)

Not sure if this is for mediawiki or here but is there a reason that Admins do not see the exact number, down to 0 and everyone else sees only down to 30? Apteva (talk) 03:47, 5 January 2013 (UTC)

this feature actually exists for some time (through adding "action=info" to the address line), and recently it became more readily available through adding "page information" link to the toolbox menu.

through the "page info" page, admins, or more precisely, anyone with "unwatchedpages" user right, can see the number of watchers (yes, all the way down to 0). other wikis, typically those with "patrollers" group, give the "unwatchedpages" user right to groups other than admins. if you think it's a good idea, you can create a new proposal to add "unwatchedpages" right to, e.g., "rollbackers" group on enwiki - if this will be done, rollbackers will be able to see how many people watch each page, all the way to 0. peace - קיפודנחש (aka kipod) (talk) 15:01, 5 January 2013 (UTC)

If you ask for your name to be added to this list and you have a TUSC account, you can find out exactly how many users watch a page with less than 30 watchers through the tool discussed above. The given number should be taken with a pinch of salt; it includes inactive users and editors who, for whatever reason, don't thoroughly check their watchlist. Graham87 10:53, 8 January 2013 (UTC)

I've got a TUSC account and been added to that list; what do I do now? --Anthonyhcole (talk) 18:58, 13 January 2013 (UTC)

There was a script that linked to a count of active users rather than all accounts. It seems to have quit working for me, though. WhatamIdoing (talk) 23:25, 18 January 2013 (UTC)

Merge low budget films article

I propose that the low-budget film article be merged into theZ movie and B movie articles, but not the z movie and b movie articles. Could someone please propose this for merger for me, since I am an IP address or else I would do it myself. Thanks! :-) --Able

I don't quite follow. Do you want to propose merging Low-budget film into Z movie and B movie, but keep Z movie and B movie separate? If you go to the talk page (I will watch all three for a while) and add you reasoning I will add the templates. AIRcorn (talk) 09:28, 10 January 2013 (UTC)

I have copied this request/discussion to the Wikipedia:Proposed mergers notice-board. Feel free to archive. GenQuest ^{"Talk to Me"} 04:12, 17 January 2013 (UTC)

color of text for edits

I'd like to offer an idea for you to help with all the vetting and editing issues. This would be a simple color coding of the text that has been vetted, from that which hasn't. You could allow edits to remain both ways (in colors) until the vetting process works out the issues and declares what is "factual" and supported by being in black print. That way contested material is marked as so (by color) with the contested edits, and unconfirmed data is marked as so, too (by its color). and so too with vetted factually certified information. Thanks, Dave

You might look into WikiTrust. WhatamIdoing (talk) 23:27, 18 January 2013 (UTC)

Unanswered questions - TAFI

(Moved from Wikipedia talk:Today's article for improvement.)

The TAFI proposal, which can be found here has been closed in support but cannot be implemented yet as there are still unanswered questions.

At current, it has been decided that:

1. It is obvious that there is support to implement TAFI on the main page.
2. The community has agreed to place the recruitment message below DYK as suggested in this image.
3. The community has agreed to use "Help Wikipedia and join fellow editors in building _______ - today's Article for Improvement"
4. To reduce edit conflicts, the community has agreed to constantly, randomly, display one out of several articles chosen per day.
5. Edit notices geared towards new editors will be placed on TAFI articles.

—cyberpower ^Chat_Online 20:01, 8 January 2013 (UTC)

The following subsections will address the unanswered questions:

The wording of the edit notice

How should the TAFI edit notice(s) be worded and linked?

Live version

Template:TAFI(edit talk links history):

Comments

• From WP:TAFI: "Welcome to Today's article for improvement (TAFI). Each day (or other time period, to be selected) Periodically we identify one or more underdeveloped articles that require improvement, to be linked to the Community Portal for collaborative editing, ideally to improve it to good article or even featured article quality over a short time frame, through widespread collaborative editing." -—Kvng 20:08, 8 January 2013 (UTC)
• Comment – For context, below is how the current edit notice is worded (as of this post). Northamerica1000^(talk) 20:25, 8 January 2013 (UTC)

• It may be functional to reduce the length of the message to make it slightly less verbose. Omitting, or at least modifying the phrase "Together we can expand the world's knowledge" may be in order, because while the intent is clear, technically the "world" doesn't possess knowledge in a literal sense (people do). If to be retained, it should reworded to something such as "Together we can expand the availability of knowledge in the world." Northamerica1000^(talk) 20:41, 8 January 2013

• Suggested revision to above infobox to better target new editors. -—Kvng 22:07, 8 January 2013 (UTC)

This article has been selected as Today's Article for Improvement!
Wikipedia is a free and open source encyclopedia that has been expanded by volunteers to over 4 million articles.
Please consider collaborating with other volunteers to improve this article.
Together we can expand the world's knowledge.
If this is your first contribution to Wikipedia, welcome! You will find editing instructions in the help system.
Click on the Edit tab above to start improving this article. Thank you for helping!

• I stumbled upon the template through WT:MED and made edits before finding this discussion. Template:TAFI now says

  This article has been selected as Today's Article for Improvement!
  Wikipedia is a free and open source encyclopedia that has been expanded by volunteers to over 4 million articles.
  Please consider collaborating with other volunteers to improve this article.
  Together we can expand the world's knowledge.
  
  You can see the cheatsheet and tutorial for some instructions about how to edit and please feel free to start an account and to ask a question at the "Teahouse" by clicking here. You can also see pages on our "five pillars", our FAQ and for general editing. To see discussion about the TAFI WikiProject go here. Thanks!

  Best. Biosthmors (talk) 02:46, 10 January 2013 (UTC)

I like it too. AutomaticStrikeout (T • C) 02:48, 10 January 2013 (UTC)

• Just to give a heads up, we already had an ongoing discussion for an edit notice at Wikipedia:Village_pump_(proposals)#A_set_of_guidelines_to_be_presented_to_each_new_editor. It would be good if that discussion is also looked into here. TheOriginalSoni (talk) 14:19, 10 January 2013 (UTC)

• Lots of links and meandering information in the current version of the template. Feels like reinventing the wheel. Isn't there a simple intro page we can point to or include that lays all this out? Closest I've found so far is WP:WELCOME. -—Kvng 15:42, 10 January 2013 (UTC)
  • Wikipedia:Introduction also looks good. -—Kvng 19:24, 10 January 2013 (UTC)

• Holy crap that template needs to be shortened. I've put the live version above, which seems to have gotten longer since the original post:

I'd suggest something like this instead:

Λυδαcιτγ 09:29, 11 January 2013 (UTC)

• ALT 2

 – It's shortened while still providing editing assistance, encourages account creation and is updated with the project's logo. Northamerica1000^(talk) 12:35, 11 January 2013 (UTC)

I just found out about this project when NickPenguin posted a notice about it on Teahouse talk. I strongly support this project: it's a great idea and very well thought out. However, while this template looks good in general, there is one potentially major issue. Providing a section-edit link to the Teahouse/Questions page (rather than just linking to WP:Teahouse/Questions breaks the Teahouse process, makes more work for Teahouse hosts, and isn't very helpful for new editors:

1. this method doesn't give the user any of the important context. They're sent to an empty edit window and given no instructions (e.g. 'put your the subject field to "don't forget to sign your posts"). Pragmatically, this means that the Teahouse will get (potentially many) more poorly-formatted questions that will need to be manually fixed by hosts. New users also don't have a chance to figure out anything about the page they're posting to before asking their question, and the process for asking is potentially confusing. Say they fill in the edit form and press save: the question they just asked will not even be visible on the next screen! They wind up in the middle of a long discussion page that they have never seen before. Where did their question go?
2. the vast majority of Teahouse questions are posted to the top of the page, feed-style, not the bottom. This is enabled by a JavaScript gadget that provides easy in-line editing. Posting to the top makes it easier for hosts to keep track of new questions, and figure out which ones have been answered. If we suddenly get a lot more questions being posted to the bottom of the page, it makes it more difficult to track.
3. this also breaks my metrics :) I track how many questions are asked on the Teahouse Q&A board, how many answers each question recieves, and how many times the original questioner responds in their question thread. The Teahouse is an editor engagement project, and we're still analyzing the impact of Teahouse participation on new editor retention. Tracking these metrics relies on consistent edit comment strings. More bottom-posting (and more manual monkeying with poorly-formed section titles) makes my metrics less accurate.

So... can we just link to WP:Teahouse or WP:Teahouse/Questions instead? Jmorgan (WMF) (talk) 21:18, 11 January 2013 (UTC)

I removed the "by clicking here". The template has grown far too large though. Ryan Vesey 21:43, 11 January 2013 (UTC)

Thanks, Ryan. How about we just link to TH and to one of our newly-redesigned portal pages, Help or Community? Jmorgan (WMF) (talk) 22:44, 11 January 2013 (UTC)

I've shortened the live version to something inspired by ALT 2. I like the cheatsheet link being the first help link because it is plain nuts and bolds editing. I removed the link to the WikiProject TAFI, which is irrelevant to a newbie, in my opinion. The first link is now edit, as it should be, I think. Biosthmors (talk) 01:48, 12 January 2013 (UTC)

Regarding removal of the TAFI link: editors other than newbies are likely to work on TAFI articles, and the template sans the link orphans the project from where the article was decided upon to be a collaboration. Including the link provides perspective about how TAFI articles are chosen, and may encourage participation there. Northamerica1000^(talk) 18:15, 12 January 2013 (UTC)

• ALT 3

• Here's alt 3: Teahouse link to edit page removed. WP TAFI link retained, because editors other than newbies will likely be editing TAFI articles, and the link serves to provide context to the project and how entries are chosen. Help page and Community portal links added, although this does increase the word count. Northamerica1000^(talk) 18:07, 12 January 2013 (UTC)

I was actually suggesting we add (one of!) the portal links as a substitute for some of the other links. Particularly cheat sheet, tutorial, editing help and FAQ. Rationale being that these portals (particularly the help portal) links to a lot of these resources or similar ones, which offloads the responsibility from the template itself and reduces clutter. Plus, I like the way the help portal is designed :) But now we have all the other links, PLUS BOTH the portal links, so my suggestion has now inadvertently made the template longer, not shorter. I hereby retract my suggestion and excuse myself from the design committee! Jmorgan (WMF) (talk) 21:36, 12 January 2013 (UTC)

• ALT 4

Posted ALT 4. Northamerica1000^(talk) 05:50, 13 January 2013 (UTC)

Arbitrary section break - Edit notice

• I support ALT 4 to be used as the TAFI edit notice at this time (which I composed), but this can easily change if new alts are posted. Northamerica1000^(talk) 05:46, 13 January 2013 (UTC)
• Regarding the edit notice part, I would like to clarify which is the edit notice everyone is talking of? Currently, there is one message that appears on the article page only, that introduces the reader to TAFI. But there is also another type of notice that comes up while you are trying to edit a page (just above the edit screen - I have seen it for the talk pages of several users, like AutomaticStrikeout).

That sort of notice will be a lot better than one on the normal page, as people will be more likely to be trying to find out how to work things around when they actually realise things are harder than they thought [which would be after they hit the edit button, for most users]. TheOriginalSoni (talk) 20:12, 14 January 2013 (UTC)

How many articles are chosen per day

How many articles should be selected per day?

• 1 article displayed randomly from a pool of 7. The oldest article in the pool will be removed and replaced with a new one at least once a week. -—Kvng 19:59, 8 January 2013 (UTC)
• Choose and publish on a weekly basis: Have a minimum of 7 articles present in the queue each week, with 1 randomly displayed. I would prefer for all 7 articles be changed-out weekly. If the same articles are in place for weeks at a time on the Main page, editors will likely become disinterested in utilizing TAFI. Also, it may be unrealistic for articles to have to be chosen every day. Northamerica1000^(talk) 22:21, 8 January 2013 (UTC)
• Every week, we choose 7 or more articles to be randomly displayed on the main page. Like what Northamerica said, it would be to unrealistic and troublesome to nominate a new article every day.--Horai 551 (talk) 09:08, 10 January 2013 (UTC)
• Why not have 7 articles per week on a rolling basis? The 7 would be randomized as to which gets shown at any one given time, but we could roll the oldest one of the list each day at midnight UTC and replace it from the pool. That gives each article equal access, and keeps the list slowly evolving. --Jayron32 17:08, 10 January 2013 (UTC)

• This. —WFC— _{FL wishlist} 19:39, 10 January 2013 (UTC)
• At this time, I'm still for updating on a weekly basis with a minimum of 7 articles, and perhaps a maximum of 10, per the new guidelines at the project that utilize 10 categories from Wikipedia:Peer review/volunteers. Of significant concern is the likelihood that editors and administrators won't be available on a daily basis to perform daily updates for the Main page (which only administrators can edit), although a script could be developed to do so automatically. Additional concerns include daily updating being contingent upon the project continuously receiving a high degree of participation and maintenance; sometimes participation in WikiProjects begins to wane after initial interest, and using a script would still be reliant upon high participation levels. Weekly updates also serve to keep the process simplified. As a side note, if auto-updating is to occur, there would need to be a 7-day delay to provide time for the initial entries to exist. Northamerica1000^(talk) 12:52, 11 January 2013 (UTC)

• A rolling approach sounds good to me. I think we should consider a pool of 14, though, to maximize the odds that the reader will find something that interests him (or her), and to decrease the odds that dozens of people will try to work on the same article at the same time. WhatamIdoing (talk) 23:32, 18 January 2013 (UTC)

How the articles are chosen

How will the articles be chosen?

Moved from a different thread for consistency I propose that the following criteria be used when determining the next TAFI:

• New TAFI should be chosen at least 4 weeks in advance, but no more than 8.
• They should be chosen from articles nominated in the last 30 days.
• Nominated articles should be unoffensive and of a large general interest so as to attract the most amount of editors
• The article with the largest amount of support and the least amount of opposition becomes the next TAFI. Discussion will ensue in the event of a tie or a compromise
• Unsuccessful nominations should not be nominated again for 4 weeks.
• Articles above a C class should not be nominated.
• Nominated articles should have the capacity to be improved up to FA
• Successful and unsuccessful nominations will be archived after 30 days in the appropriate locations.
• A notice should be posted on relevant wikiproject noticeboards when an article goes live as TAFI

Thoughts? --NickPenguin_(contribs) 05:16, 6 January 2013 (UTC)

What does "Nominated articles should have the capacity to be improved up to FA" mean? What's an example of an article that would not meet this criteria? -—Kvng 03:19, 8 January 2013 (UTC)

In truth every article should have the capacity to become an FA, otherwise we don't need that article. What I mean tho is that the subject matter should have sufficient depth to allow for the quality we come to expect from FAs. Medical certificate is something like this; it is a notable subject, but it would likely not be among the best articles Wikipedia has to offer. Journalism, in contrast, seems to fit the bill. What I mean is that the article should lend itself to improvement because it has sufficient potential to be awesome. --NickPenguin_(contribs) 03:37, 8 January 2013 (UTC)

I don't understand how "The article with the largest amount of support and the least amount of opposition becomes the next TAFI" would work. A single article is not always going to have the most supports and the least opposes. First Light (talk) 06:03, 8 January 2013 (UTC)

How about "supports-opposes" --j⚛e decker^talk 06:13, 8 January 2013 (UTC)

That would work, and is probably the simplest solution. First Light (talk) 16:08, 8 January 2013 (UTC)

I really think we need guidelines for TAFI suggestions.Horai 551 (talk) 07:38, 8 January 2013 (UTC)

I note that the criteria above makes no mention of lists, and implicitly suggests that they should be excluded (by only mentioning FA). Overlooking them altogether would be an opportunity missed in my opinion, as certain lists (such as List of food preparation utensils) really do lend themselves to this format. There are several very interesting lists in the link in my sig, some of which are at a low enough state of development to be worth considering. —WFC— _{FL wishlist} 13:58, 8 January 2013 (UTC)

I'm not trying to explicitly exclude lists, I think they can make great TAFIs. Any article that lends itself to improvement should be a good candidate for this project. The suggested criteria should be amended so that it includes all types of mainspace content. --NickPenguin_(contribs) 17:11, 8 January 2013 (UTC)

With that caveat, your suggestions look reasonably good. The fourth point would obviously need to be clarified, but presumably your intention was to keep things brief. —WFC— _{FL wishlist} 18:07, 8 January 2013 (UTC)

I've updated the project's scope to include lists. See the Header page. Northamerica1000^(talk) 20:52, 8 January 2013 (UTC)

Update: the project's main page has been updated with a guideline section. See: /Guidelines, which is transcluded to the project's main page. Northamerica1000^(talk) 17:50, 9 January 2013 (UTC)

• Using current WP:TAFI procedures to select the replacement article for the pool update as described above. -—Kvng 20:01, 8 January 2013 (UTC)
• I agree with the comment directly above by User:Kvng. Articles being chosen by consensus at Nominations is working functionally. Northamerica1000^(talk) 20:21, 8 January 2013 (UTC)

• Comment – Regarding the proposals at the start of this section. The time frame in point 1 seems arbitrary, and creates a large, entirely unnecessary gap of time between acceptance of nominations and publishing; I oppose this. Point 2 isn't necessary, because sometimes discussion may occur for longer than 30 days about a nomination, particularly controversial ones. Point 3 goes against the grain of WP:NOTCENSORED, which is policy, although the latter "general interest" provision makes sense as a suggestion, but not as an absolute, because this can restrict topics and people can discuss matters at TAFI nominations on a case-per-case basis. Point 4 is fine, per being consensus-based. Point 5 may unnecessarily restrict editors from re-nominating after additional discussion has occurred about a topic on the project's talk page, for example. Point 6 is agreeable as far as being a general guideline, but some B-Class articles may be incorrectly assessed, and sometimes they still need significant improvement: it should not be an absolute. Point 7 is fine, but Featured lists should also be included. Point 8's time frame isn't necessary: the page has a tendency to become long, and people can easily find archived entries from the archives box, which is specific per types of nominations and content. Point 9 is all right, but it adds on more duties to the project: while this is a good idea, it shouldn't be made mandatory. Northamerica1000^(talk) 18:17, 9 January 2013 (UTC)

To Point 3, I believe accepted nom should be uncontroversial, as they are going on the Main Page. I don't think the goal of WP:NOTCENSORED is to say we can't choose what to feature. The idea there is just to have editors consider the range of appeal for their nominated subject. About time frames, the time frames are completely arbitrary and probably unnecessary. I pulled them out of a hat with the intent of preventing slow down. The idea behind Point 5 is to prevent constant renomination of unsuccessful articles in order to get your horse in the race. If time based criteria are necessary at all, then we can just add something to the effect of "a reasonable time frame". --NickPenguin_(contribs) 19:06, 9 January 2013 (UTC)

Hello NickPenguin. Regarding point 3 – Consensus being decided at the discussions has been functional so far. For example, the nomination for the Human body article didn't proceed to a scheduled article, due to many opposing based upon clinical nudity in the article (See this link to read the discussion). What is offensive or controversial is subjective, and I think nominations should be decided on a case-per-case basis via discussion, rather than limiting what people can post from the start, which may deter participation. Regarding point 5, I find the addition of something along the lines of "a reasonable time frame" to be acceptable. Northamerica1000^(talk) 19:28, 9 January 2013 (UTC)

• IMO,The articles choosing process be more streamlined and simplistic. We are obviously going to be nominating loads of articles, and it makes no use keeping the same way we have.

I suggest that we simply have a table for each category to be chosen. Each table shall list only the article name, the nom, the nom date, and three votes from other users. All articles with 3 supports go straight to the holding area [from where the articles per week are chosen], while articles with one or more oppose go to the discussion area, where we have a full fledged discussion and voting on opposed articles. TheOriginalSoni (talk) 14:19, 10 January 2013 (UTC)

I like the idea, but I would say that in this scenario, we can't do self supports, the 3 supports have to be from other editors. But ya, that sounds good. --NickPenguin_(contribs) 17:07, 10 January 2013 (UTC)

Some sort of a table format to shorten the page is a great idea and would help to streamline it. Queues based on 3 supports from editors other than the nominator seems quite functional. I agree that nomination itself should not be counted as an !vote. Nice suggestion! Northamerica1000^(talk) 23:49, 10 January 2013 (UTC)

The arts section has been converted into a table format for now. Please give your opinion on the new format on the TAFI talk page. TheOriginalSoni (talk) 15:54, 16 January 2013 (UTC)

Overall, I think that some of the proposed rules (Who cares exactly how soon the decision is made? What's wrong with picking something nominated 31 days ago?) are WP:CREEPy but not really bad as a rule of thumb to get us started.

I like the idea of including lists. Lists (especially lists that aren't in table form) are accessible to most new editors, especially if they are significantly incomplete and on a fairly popular subject (maybe something from Category:Lists of automobiles or Category:Lists of foods or possibly List of cancer types (which would benefit from very brief descriptions, like * "Astrocytoma, a type of brain cancer usually seen in children")). WhatamIdoing (talk) 23:40, 18 January 2013 (UTC)

PC1

Should pending changes level 1 be applied to TAFI articles for the duration of their post on the main page?

• Oppose – Applying pending changes protection to TAFI entries on the Main page as a default may discourage editor participation, and a significant aspect of publishing them there is to encourage participation. (See: Village pump discussions.) Furthermore, other articles on the Main page don't have pending changes protection on them by virtue of them being present on the main page. Northamerica1000^(talk) 19:48, 8 January 2013 (UTC)
• Oppose we don't generally apply protection until a problem is demonstrated. -—Kvng 19:57, 8 January 2013 (UTC)
• Oppose - Why should we advertise an article with the intention of directing new users to edit it, and then erect barriers to prevent them from doing so? The reviewer backlog would be unmanageably huge as well. ∴ ZX95 ^[discuss] 21:03, 8 January 2013 (UTC)
• Oppose Pending changes is "Intended for infrequently-edited articles" (from the lede of WP:PC), and it highly problematic for frequently-edited articles. While there are other reasons for me to oppose, I feel this objection is sufficient and easily understood. --j⚛e decker^talk 23:32, 9 January 2013 (UTC)
• Oppose This would largely defeat the purpose of putting it on the main page. AutomaticStrikeout (T • C) 02:36, 10 January 2013 (UTC)
• Oppose keeping it as open and accessible as possible to attract new editors is the key. Hopefully there'll be enough editors around to revert vandalism ASAP. Casliber (talk · contribs) 23:38, 10 January 2013 (UTC)
• Oppose as that would be working at cross-purposes for the intent of the TAFI implementation. GenQuest ^{"Talk to Me"} 23:54, 17 January 2013 (UTC)

How to implement the random article feature

moved into this RfC for consistency

Following the closure of this discussion it seems there was consensus to run multiple TAFIs at the same time, and randomly show one of them to a visitor. How and who will implement such a feature? Additionally this raises the question about the number of article categories, and the number of articles that would run concurrently. My initial thought is we should select one article from each of the main categories found at the top of the Main Page:

• The Arts
• People and Biography
• Geography and Places
• History and Events
• Mathematics and Science
• Society and Culture
• Technology and Applied Sciences

7 categories would mean that if the one week improvement time-frame is kept, a new article needs to be determined every day. --NickPenguin_(contribs) 02:14, 7 January 2013 (UTC)

The random article feature was proposed to solve the anticipated problem of edit conflicts. I'm not convinced this will actually be a problem. I propose we proceed with current TAFI and solve problems as they actually appear. Looks like we must heed the fear of edit conflicts. -—Kvng 03:22, 8 January 2013 (UTC)

It probably would be easy to construct something on top of {{Random subpage}} or the like, if desired. --j⚛e decker^talk 06:11, 8 January 2013 (UTC)

What about simply selecting all 7 articles as a group at the start of the week or something? -- Toshio Yamaguchi 13:08, 8 January 2013 (UTC)

Note: the discussion here was actually closed in favor of having a single article appear on the main page at a time, chosen randomly from some pool of suitable articles. NickPenguin's suggestion above was also considered in that discussion, but it didn't make it. No need to reinvent the wheel here, guys! Cheers, ∴ ZX95 ^[discuss] 14:56, 8 January 2013 (UTC)

There was no previous discussion of how big the random group chose from should be. Anywhere from 2 to 7 seems like a reasonable number. TAFI is currently selected at the rate of once per week. Do we have the wherewithal to increase this to once per day? If not we can select the first N articles and then every week we can add a new one to the group and remove an old. -—Kvng 15:12, 8 January 2013 (UTC)

Ah, whoops. When I wrote that I had not read the OP very carefully; I was thrown off by the phrasing "... run multiple TAFIs at the same time ...", which, in combination with the list of categories, brought to mind a failed proposal to have many TAFIs displayed together on the Main Page. I have stricken my comment for the record :) Cheers, ∴ ZX95 ^[discuss] 15:17, 8 January 2013 (UTC)

I threw the 7 categories out there as a suggestion. I still think the new article posted every week is a good time frame, but I was saying that 7 articles selected a week turns into 365 a year, or an average rate of one a day. I kind of like the idea touched on by Kvng, we have a floating group number, and as articles are approved, we add them and remove the oldest items from the nominated group. --NickPenguin_(contribs) 17:06, 8 January 2013 (UTC)

Is one a day doable. TAFI is currently doing one a week. I don't think there's a hurry to rotate articles out. Giving editors a prompted opportunity to improve an article more than once over several weeks does not seem to me to be a problem. -—Kvng 20:04, 8 January 2013 (UTC)

Regarding frequency, having a pool of 7 articles (one per each of the main topics at the top of the Main page), to be randomly displayed in the TAFI section on the Main page would be functional at this time. Entries could be chosen on a weekly basis here at TAFI. However, if participation drops, as often occurs at WikiProjects over time, this may have to be modified. If this is to go into effect, editors would need to be notified on this project's main page about the need for diversity in topic nominations, so that each main topical area is covered. In the event that less than 7 nominations are approved weekly, singular rotation as stated above would be functional (newest added, oldest removed). Lastly, an idea is to possibly include a purge option on the TAFI section of the Main page, to read as "View another selection." Northamerica1000^(talk) 21:16, 8 January 2013 (UTC)

Regarding the implementation of random generation, utilizing wikicode similar to that used by Wikipedia's portals to view new selections could be a possibility. The following code: <div style="text-align:center; margin:0.25em auto 0.75em">{{purge|'''View another selection''' (purge)}}</div>, creates the following link below. Duplicate listings occur from time-to-time, whereby the same article is sometimes listed despite random generation, but it would likely work. Northamerica1000^(talk) 21:48, 8 January 2013 (UTC)

• Update: I've created some test pages in Portal namespace to demonstrate how this can be implemented, at: Portal:Today's article for improvement. Check out how the purge function provides randomization. It appears that the Random portal component will not function in Main namespace to provide randomization, and something likely needs to be developed that will function in it.

The relevant subpages are: Portal:Today's article for improvement/box-header and Portal:Today's article for improvement/Main page queue. Northamerica1000^(talk) 21:45, 14 January 2013 (UTC)

Progress - Random generation

• Update: The Random component appears to be transferable and functional in various namespaces other than the portal one. Please see the new Template:TAFI Main page. To create randomization this utilizes Template:Random component main namespace, which was created by simply copying the wikicode from Random portal component. The Template:TAFI Main page randomly reads directly from one of 10 subpages:

• Template:TAFI Main page/Main page queue/1
• Template:TAFI Main page/Main page queue/2
• Template:TAFI Main page/Main page queue/3
• Template:TAFI Main page/Main page queue/4
• Template:TAFI Main page/Main page queue/5
• Template:TAFI Main page/Main page queue/6
• Template:TAFI Main page/Main page queue/7
• Template:TAFI Main page/Main page queue/8
• Template:TAFI Main page/Main page queue/9
• Template:TAFI Main page/Main page queue/10

It appears that a similar system is possible to be implemented for the Main page area. It's a turnkey process. The "max=" section on the template's edit page: {{Random component main namespace|max=7|header=|subpage=Main page queue}} is updated per the number of weekly articles, and the subpages are updated accordingly per week. In the event of more than 10, the max can be adjusted and new subpages created accordingly. Northamerica1000^(talk) 23:46, 14 January 2013 (UTC)

• A note to everyone: Once the template is transcluded on to the mainpage, it will be cascade protected.

Should we be welcoming the new users who edit there? If so, how?

I think having some people there to patrol the TAFI article will be good. How about someone like the Welcoming Comittee or the Teahouse keeping an eye out for all the new editors coming in, so that we can give them good guidance? TheOriginalSoni (talk) 14:19, 10 January 2013 (UTC)

I posted requests for input over at the Welcomeing Comittee and Teahouse talk pages. --NickPenguin_(contribs) 17:04, 10 January 2013 (UTC)

Presumably TAFI members will be visiting TAFI articles and will see edits from newcomers. We can update guidelines to remind editors that welcoming newcommers is part of the program. We can also recruit members of the welcoming committee to join the TAFI project. -—Kvng 19:23, 10 January 2013 (UTC)

These are all great ideas, and I support the notion of welcoming as part of the project's scope. Northamerica1000^(talk) 23:56, 10 January 2013 (UTC)

To do list

We have already approved having a to-do list. How should we be displaying it? And who adds to the list? I think the best thing to do is to have a few experienced editors go through every article thats to go up to TAFI, and list all the potentials problems. These will be the to-do list that will be displayed to give a sense of direction to the new editors. TheOriginalSoni (talk) 14:19, 10 January 2013 (UTC)

Sounds like a good plan to me. So we establish the 7 articles for the week, then to-do lists are generated for each article on the talk page, and then everything should be ready when it goes live. --NickPenguin_(contribs) 04:10, 11 January 2013 (UTC)

One line description

Now that I see the proposed template to be placed at the main page, I feel it looks a bit empty. I also find myself trying to remember what exactly that article would be about (as in most cases I would remember "A girl who dresses and acts like a boy" but not the word "Tomboy").

Voting

1. TheOriginalSoni (talk) 22:03, 14 January 2013 (UTC)

I agree, I think we should have a one line overview of the subject. For example, suppose we nominated Their Greatest Hits (1971-1975) to go on the main page. Who's greatest hits? What's a "greatest hit"? In most cases we should include the first line from the article, or provide some context like in DYK content. --NickPenguin_(contribs) 04:16, 16 January 2013 (UTC)

Where and how to place it?

In one of the discussions above, editors were in agreement to place TAFI below the DYK entries on the Main page (see this discussion). Regarding implementation, see the above Progress - Random generation for some ideas, and also check out this demo page: Template:TAFI Main page. Northamerica1000^(talk) 00:30, 15 January 2013 (UTC)

By where and how, I implied where in the TAFI section - Should the description line be in a separate line, the same line or maybe before naming the article. TheOriginalSoni (talk) 14:39, 16 January 2013 (UTC)

Flagging up link advertising

It seems that there are a number of articles on Wikipedia which violate WP:SPAM by including phrases such as "for further information visit www.examplewebsite.com". While I'll admit this isn't a particularly large-scale problem in the scheme of things, I was wondering if there's a way that some sort of extension or bot could flag up these up with the advert template or something similar, and make it easier for editors to address this. -- Half past formerly SUFCboy 00:01, 14 January 2013 (UTC)

Good spot, just search for the phrase and remove or if appropriate external link them. ϢereSpielChequers 07:16, 17 January 2013 (UTC)

Link at the top for creating article drafts

I propose to add a link to the top of all pages (where talk, preferences, watchlist etc. are) when you are logged in. This link would be

http://en.wikipedia.org/w/index.php?title=User:This_User/{{{1}}}&action=edit

There should be a possibility to easily specify the parameter {{{1}}} which is the name of the page to be created. Also, User:This_user should be the name of the account under which a user is logged in (I think this could be accomplished using a magic word). The rationale for this change is that this would make the creation of user subpages for userspace drafts easier, especially for newbies (well, it's not actually that difficult right now, but from the perspective of a newbie, this might be different).

It might also be useful to provide a link to [3] at the top, which I currently achieve by having

$( document ).ready( function() {
 mw.util.addPortletLink(
   'p-personal',
   mw.util.wikiGetlink( 'Special:PrefixIndex/User:' ) + mw.config.get( 'wgUserName' ),
   'Subpages',
   'pt-mysubpages',
   'Show your subpages',
   null,
   '#pt-preferences'
 );
});)

in my common.js.

The overall goal is to encourage more use of subpages and make this easier for newer users. I think this should be activated for all users (as otherwise most newbies wouldn't be aware of it) and an option to opt-out be provided for users who want to disable this (either as a script or in user preferences).

Regarding the technical details of the implementation, I am not sure where the link would have to be specified and how it could be achieved that a user can easily specify the name of the subpage to be created (maybe a more Media-Wiki-Tech savvy user knows the answer to this). -- Toshio Yamaguchi 15:53, 14 January 2013 (UTC)

two different subjects here. let's take them one by one, starting with the last (link to personal subpages): IMO, it's more useful to have a "subpages" link on *any* page, not just for "my subpages". this way, when one want to see one's own subpages, one clicks on the username, and then on "subpagess". imho, the proper place for this link is in the toolbox, so what you want is something like:

mw.util.addPortletLink('p-tb', mw.util.wikiGetlink('Special:PrefixIndex/' + wgPageName), 'Subpages');

as to a new link for new draft creation: we already have a "Sandbox" link at the top. what we do in hewiki, is adding to the "Sandbox" link an "Editintro", which contains, by using an "InputBox" tag, a very easy way for the user to select a name and begin edit of a new personal subpage. after all, what you describe is basically a "sandbox" with a different name, so the "sandbox" link makes sense. while doing so, we also changed the wording: instead of calling it "Sandbox", which is very common use in software development, but which some users found offensive ("i am not a little child, so don't send me to play in a sandbox"), we called it "Draft", which many people found more appealing.

peace - קיפודנחש (aka kipod) (talk) 16:42, 14 January 2013 (UTC)

• I would recommend against making it super easy to create millions of scattered content forks and page sandboxes. Apteva (talk) 20:59, 14 January 2013 (UTC)
• Agreed, with Apteva above. The idea looks fine at first glance, but... There is a non-negligible risk that we'll end up with users creating well intentioned forks, work on them a couple of days, and then paste on the original article, deleting all contributions made in between. - Nabla (talk) 21:24, 14 January 2013 (UTC)

every time we introduce a tool, we run the risk of it being used inappropriately/abused. with confidence very close to certainty, i can say that removing the "edit" link at the top of the page will reduce vandalism. still, this is not good enough reason to actually remove those little "edit" links. making it easier for users to create sandboxes/draft pages will bring with it problems of its own, like the ones you guys pointed to. however, as long as enwiki sports the "Sandbox" link at the top of the page by default for every registered user, it makes sense to help those users to also create a named "sandbox". peace - קיפודנחש (aka kipod) (talk) 22:37, 14 January 2013 (UTC)

• Agree generally w/ Apteva and Nabla. If users want to make a draft, what's wrong with Special:MyPage/Sandbox? Similarly, I don't know that we want to encourage the unnecessary creation of a gazillion userspace drafts - many articles can be created in mainspace just fine. For those that don't, changing the speedy deletion rules to prefer userification in certain cases would be a more productive change. – Philosopher ^{Let us reason together.} 14:09, 21 January 2013 (UTC)
• Or Special:MyPage/Draft, but you get my point. – Philosopher ^{Let us reason together.} 14:10, 21 January 2013 (UTC)

Proposal to import Wiki Commons "slideshow" button in Wikipedia Pages Image Gallery

Following Wikipedia Gallery needs improvement,

I propose to import Wiki Commons "slideshow" button in the Image Gallery in the Wikipedia pages. I have found through informal survey that users find it difficult to browse through the images in any image gallery in the Wikipedia pages. They say that they have to open the pages corresponding to each of the images in another window/tab which is really painful.

Also in the wiki Commons slideshow overlay the font size is a bit abnormally large. Mohammadulhaque (talk) 17:59, 15 January 2013 (UTC)

So, it's a gadget? And you would need to activate it by setting account preferences? The Transhumanist 05:19, 16 January 2013 (UTC)

I think it should come by default , may be at one of the top corners in every image gallery.Mohammadulhaque (talk) 18:50, 16 January 2013 (UTC)

Here is a link to this GallerySlideshow gadget: commons:Help:Slideshow, and a direct link to try out: http://commons.wikimedia.org/wiki/Category:Featured_pictures_on_Wikimedia_Commons?gsAutoPlay=1&gsDelay=10000&gsDir=desc&gsAutoStart=1&withJS=MediaWiki:Gadget-GallerySlideshow.js&withCSS=MediaWiki:Gadget-GallerySlideshow.css

I'm a bit wary about putting this Slideshow button in image galleries inside Wikipedia articles, when we don't yet offer the direct button to commons categories at the end of an image gallery (instead of end of the article page). Why not start with that? Or both options (commons /slideshow) in one field at the end of the gallery? --Atlasowa (talk) 15:13, 18 January 2013 (UTC)

• 
  Startbutton for GallerySlideshow in commons
• 
  GallerySlideshow mode (images of a Category)
• 
  image gallery
• 
  "Wikimedia Commons has more media related to this, click here"

Oppose because I actually think that galleries should be deprecated and users pointed to commons, any images in wikipedia articles should be relevant and next to text they relate to and not grouped together. MilborneOne (talk) 23:50, 18 January 2013 (UTC)

Proposal to include a hover box showing basic info on (blue) links

Hi! I have an idea I believe would greatly improve the efficiency of Wikipedia surfing. It includes an element already used by Facebook; a hover box or mouseover if you will.

Imagine reading an article, stumbling across a word you don't know the meaning of. Given that it links to another article, wouldn't it be convenient just hovering the pointer over the given link to learn more about it in a pop-up window, instead of having to open a new tab/page every time? The way I imagine it is using a script that includes only the first paragraph of the article (usually containing a summary on the subject) in a pop-up window. I have no knowledge of programming myself, but i assume this would be possible?

Here's a picture of how it might look: http://www.imagebam.com/image/25c61f232202862

The guy who sent me here had these thoughts on the matter:

"Personally, I feel that it might well impinge on server load, if every time the mouse moved over a blue link, it called up more data. Some articles are awash with blue links."

Couldn't this issue be solved simply by implementing a (e.g) 0.5 second delay before it starts loading? Something like this seems to bee the case on other sites using mouseovers. Or would it impinge too much on server load anyway, just by lots of people using this function on purpose, more than actually clicking the link? Any thoughts on this?

English isn't my native language, so please bear with me and thanks for reading! Kind regards. — Preceding unsigned comment added by Moondog616 (talk • contribs) 04:53, 15 January 2013 (UTC)

If you have an account, this exists: Wikipedia:Tools/Navigation popups. It is mostly focused towards editors, but it is useful when browsing. It wouldn't be too hard to customize it and run in as a browser script if you wanted. Prodego ^talk 04:55, 15 January 2013 (UTC)

(edit conflict)Logged-in users can use Wikipedia:Tools/Navigation popups for this purpose, but I realize that most readers aren't logged in. Besides this isn't perfect anyways. My only concern is whether the the foundation views this as a high priority.--Jasper Deng (talk) 04:57, 15 January 2013 (UTC)

Ah, thanks a lot! I basically made this request being tired of reading about chemistry, having to open a million new tabs. At least my problem is solved, but I still think most users would benefit from it. Anyway, Wikipedia is one of the best things that have happened to the internet, and you can't expect everything from a non-profit organization. Cheers! — Preceding unsigned comment added by Moondog616 (talk • contribs) 05:06, 15 January 2013 (UTC)

As its a .js tool already, supposing the community supported it, would it be possible to enable it by default just by editing the right media wiki page, and not require foundation effort? Monty₈₄₅ 05:20, 15 January 2013 (UTC)

It could be done at MediaWiki:Common.js, but I don't know if it's "clean" enough for that use in terms of design.--Jasper Deng (talk) 05:26, 15 January 2013 (UTC)

I thought we enabled this recently by default for everyone? Nyttend (talk) 07:40, 15 January 2013 (UTC)

what was enabled by default is something (somewhat) similar, but not identical: it's the Cite tooltip gadget. this is not the same as internal link tooltip. קיפודנחש (aka kipod) (talk) 19:32, 15 January 2013 (UTC)

Whenever I hover the pointer over a link, it just displays the full title of the article. E.g. "symbol" might show as "Chemical symbol", etc. -OP {{subst:xsign2|07:59, 15 January 2013‎ Moondog616}}

Yeah, it isn't 100% - that's usually because it doesn't render templates like this one.--Jasper Deng (talk) 08:01, 15 January 2013 (UTC)

I'm not sure if I fully understand, but I wasn't talking about chemistry in general. Take for example a sentence containing the word "horses". Hovering over this, the pop-up will say "Horse", the title of the page it links to. Not any additional info, as I thought Nyttend were talking about. The same is the case for most links I've tried. -OP — Preceding unsigned comment added by Moondog616 (talk • contribs) 08:42, 15 January 2013 (UTC)

Sometimes, if a template is the first item encountered on a page, pop-ups may fail to render it.--Jasper Deng (talk) 09:00, 15 January 2013 (UTC)

IMO, it would be a mistake to enable navpopups by default. don't get me wrong - i use this gadget and love it, but it's way too complicated, it has way too many features, and its code is way too unruly to be enabled by default. this suggestion is more in the line of what you get from the miniatlas _{(i.e., the thing that opens from the little globe icon in the coordinates - see Boston for example)}, when you hover over a legend while holding Ctrl: the first sentence from the article, with no fancy links like "action" menu with 11 items in it, and "popup" menu, and all kinds of stats that are all very interesting to editors, but nearly useless to readers (do you really need to know when was the last time this article modified, or how many categories it belongs to?). so the idea is intriguing, but navpopups is absolutely not the answer, even if it does provide the requested functionality - because it provides too much else, is too heavy (codewise: 250KB and ~7700 lines is too much), and is not stable enough to be enabled by default. peace - קיפודנחש (aka kipod) (talk) 19:32, 15 January 2013 (UTC)

Proposal: Add The Signpost to the main menu

This is a proposal to place the words The Signpost on the main menu, in the "Interaction" section right under "Community portal". The words would be linked to Wikipedia:Wikipedia Signpost, Wikipedia's newsletter and community news department. As a publication title, it would be italicized.

Rationale: The Community Bulletin Board (CBB) used to be the central place for posting announcements. It was located near the top of the Community Portal, but when that page was redesigned, the CBB was removed and its functions were transferred to the Signpost's WikiProject News sidebar. The main link to the Signpost used to be in the CBB, near the top of the Community Portal. But now it is near the bottom of that page. Even though the Signpost is the community's central communication instrument, it's main page gets only about 10,000 visits per month. By comparison, the Community Portal gets around 300,000 visits per month. Placing a link to the Signpost on the main menu would make it accessible from every page of Wikipedia. This would give everyone easy access to the Signpost, while increasing the community's awareness of it. This would in turn increase awareness of current events and participation in them. Since the Signpost is the WP community's main communication instrument, it would really help to centralize it by including it on the main menu. The Transhumanist 18:54, 15 January 2013 (UTC)

Support

• Support – as nom. This will help the Signpost get the word out. The Transhumanist 18:54, 15 January 2013 (UTC)
• Support, this is an excellent idea. It might also have the added effect of getting readers more involved. KillerChihuahua 19:31, 15 January 2013 (UTC)
• Support. I've thought this was a good idea for a while, but with the recent changes to the community portal, it's especially relevant. Your mileage may vary, but for me, reading the Signpost when I started was, more than anything else, the thing that made me understand and feel part of a community.--ragesoss (talk) 19:43, 15 January 2013 (UTC)
• Support More visibility of current WP events is a good thing. Some folks still get caught by surprise when new policies or features are rolled out, and the Signpost is a good place to keep up on those things. — The Hand That Feeds You:^Bite 21:04, 15 January 2013 (UTC)
• Support, wonderful idea, will help to foster positive collaboration and constructive quality improvement in many varied capacities throughout. — Cirt (talk) 22:05, 15 January 2013 (UTC)
• Support; I echo the rationales of those above, especially ragesoss. — Preceding unsigned comment added by Theopolisme (talk • contribs) 22:37, January 15, 2013 (UTC)
• Support I think the central idea here is to turn readers into editors. All of us had a reason to click that first edit link. Without looking too deeply, you don't see the wiki's central nervous system, and it is easy to be completely unaware about the editor community. Having the Signpost on the main page would show this is an ongoing collaboration. --NickPenguin_(contribs) 04:26, 16 January 2013 (UTC)
• Support Although I feel the page that is linked to should probably have some description of what the sign post is at the top rather than dumping the reader straight into the signpost itself. ·Add§hore· ^{Talk To Me!} 04:14, 17 January 2013 (UTC)
• Support. I don't think that adding the signpost would cause an increase in clutter, because, if I understand correctly, this proposal would add the signpost under the interaction sub-menu, which everyone can easily decide for theselves whether or not to show the contents of. AgnosticAphid talk 11:09, 17 January 2013 (UTC)
• Support - Newcomers have no idea this publication even exists. The publication's content helps to build understanding and participation in the project. Carrite (talk) 20:41, 17 January 2013 (UTC)
• Support I think I like the idea of somehow promoting that this place is a community, which seems to have faded in recent years. Casliber (talk · contribs) 09:36, 19 January 2013 (UTC)
• Support, not to promote the Signpost or to endorse it or anything, but because it shows we have a community and invites people to join us.– Philosopher ^{Let us reason together.} 13:58, 21 January 2013 (UTC)

Oppose

• Oppose - we should be very careful about adding any new material to the interface; each incremental addition seems like a good idea, but the inevitable result is increased clutter and a more unfriendly interface. While I like the Signpost very much, I don't think this is the most appropriate place for it - why not link more prominently from the Community Portal, instead? Andrew Gray (talk) 19:44, 15 January 2013 (UTC)
  • The Community Portal (CP) was redesigned to support active editing by channeling editors to specific pages where their help is needed. News does not fit that theme directly (it would require extra clicks to get to problem pages), and so it was moved to the bottom of the page. The changes to the CP haven't changed traffic to The Signpost much if at all. The underlying question is: Should we increase The Signpost's readership, and if so, how? A link on the main menu is about as convenient as you can get. The Transhumanist 21:26, 15 January 2013 (UTC)
    • It's convenient and easy, but it's not free. This approach would increase readership at the cost of marginally diminishing the usability of our user interface, which is a disproportionate cost. (See similar objections in the past to linking to the Teahouse from the sidebar, or to adding new links to the "user bar" at the top.) This is a sledgehammer of a solution, and we should try to think of a better one. For example, why not look at linking to the Signpost from the standard welcome templates? The main interface isn't the only thing available to work with. Andrew Gray (talk) 10:23, 16 January 2013 (UTC)
      • ...actually, this prompts an interesting thought. In the spirit of the meta:Editor engagement experiments, we could try randomly subscribing half of all new user accounts to the Signpost, with corresponding weekly notifications, and see if that causes an increase in activity... Andrew Gray (talk) 11:51, 16 January 2013 (UTC)
        • Randomly adding people to a subscription is a Really Bad Idea™. People get testy when you mess with their watchlist.
        • That aside, I really don't understand your argument that adding the Signpost to the sidebar "clutters the interface." — The Hand That Feeds You:^Bite 15:51, 16 January 2013 (UTC)
• Oppose I read The Signpost religiously, and pore over every article of every issue. However, it is primarily an internal newsletter, of interest mostly to editors of Wikipedia and as such giving it a more prominent place on the main page represents a level of "navel gazing" that I don't think we should participate in. The link in the community portal is sufficient, posting it on the main page is a little too much "airing one's dirty laundry". --Jayron32 19:59, 15 January 2013 (UTC)
  • Good point, but it's everybody's encyclopedia. There is no "us" or "them". Dirty laundry = problems. The more readers who know about their encyclopedia's problems, the more who will be inspired to get involved and help. There's an edit button on every page of Wikipedia. The Signpost may help readers decide to click some of those edit buttons. Transparency = good = more reader feedback. The Transhumanist 21:09, 15 January 2013 (UTC)
    • Yes of course there is an us and them, if the Signpost were to be promoted to the general public then every article would have to be dejargonified, and internal news such as welcoming new admins would need to be dropped in favour of more stuff that is of interest to a different set of readers. ϢereSpielChequers 07:13, 17 January 2013 (UTC)
• Oppose 90+% of people coming to Wikipedia do so to get their information and move on. They don't need further, basically insider, information and/or links to wade through. I believe it would be off-putting to many. It is like hanging another magnet on your refrigerator: the first few additions seem like a good idea, but then, one day, you can't see the door anymore. GenQuest ^{"Talk to Me"} 22:51, 15 January 2013 (UTC)
• Oppose per Jayron32. Unless this is tied to a broader initiative to make the Signpost more of a general-interest newsletter than a Wikipedia-specific one, I don't see that it would be of much interest to casual non-editor readers. And clutter is also a factor. For those who do want it, it's not exactly hard to find. Andrew Lenahan - Starblind 03:32, 16 January 2013 (UTC)
• Oppose As much as I want to support the Signpost, and as much as I think that some of the members try hard to do a good job, when it comes to a straight up or down vote of confidence, I'm going to vote no confidence. It doesn't happen often, but when the Signpost loses its way, it throws journalist integrity and neutrality out the window, and I don't think that it's a good idea to put that on the front page. Sven Manguard Wha? 04:09, 16 January 2013 (UTC)
• No. The Wikipedia Signpost is written for the community; our readership is not our community. A newspaper has no place in a serious, neutral encyclopedia. As has already been said, we need to clearly justify the addition of new links to the Sidebar. And, most critically of all, readers who stumble onto the link are likely to be confused. Sven also makes a good point that we shouldn't be airing our dirty laundry so visibly. This proposal, while well-intentioned, is worse than wrong. AGK [•] 16:17, 16 January 2013 (UTC)
• Greater publicity for the Signpost is a good idea, but it needs to be appropriate publicity. A link on the birthday committee greetings or a Signpost discussion at Wikimania would be good ways to publicise the \signpost to potential readers. But the mainpage is mainly read by the general public, and publicising the singpost there would either turn it into a very different publication or turn the mainpage into something less interesting to our readers. ϢereSpielChequers 07:10, 17 January 2013 (UTC)
  • I could be missing something here with either your comment or the proposal, but I don't think this proposal would add anything to WP:MAIN, per se, it's about adding a link to the interaction sidebar, something that appears on every page but is easily hidden. AgnosticAphid talk 11:15, 17 January 2013 (UTC)
• Oppose the Signpost represents neither official Wikipedia views, nor community consensus. It has, effectively, the same status as an essay. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:39, 17 January 2013 (UTC)
• Oppose I have contributed to the Signpost in the past, and with a few exceptions, I think it's a Good Thing. But it is a few meta-levels beyond what should be on the frontpage. It just doesn't necessarily have relevance to the general Wikipedia reader until they've become hooked on hitting that 'edit' button. —Tom Morris (talk) 01:00, 22 January 2013 (UTC)

Proposed New Rating Scale: Approachability

I've just been editing an article that enjoys a very high "well-written" rating even though its introduction was constructed almost entirely from the most arcane scientific Latin with only the occasional English verb or article to hold it together. What's worse, the introduction dwelled on minutia, such as its having "lobopodia limbs that are poorly articulated," while failing to mention that it can live 10 years without food or water and 10 days in the vacuum of outer space.

This is an animal of wide interest, yet the introduction was slamming the door to all but experts already well steeped in post-grad zoology. Then, because these experts were the only ones likely to ever reach the bottom of the article, they were the only ones voting, and they were voting that the article was "well written," thereby obscuring a real problem.

We need a separate and distinct rating scale to indicate whether people who hold no advanced expertise in the field in question will at least be able to launch themselves into a given article. I don't propose we turn Wikipedia into The World Book. Anything but. I only suggest that we provide encouragement for people to write—or edit—introductions that are readable by a wide range of people, rather than a limited set of specialists. Many people, having read, understood, and become intrigued by a lucid introduction, will be willing to climb a mountain of verbiage that follows.

The reason I suggest using the term, "approachable," is because of its limited promise: Just because a lay person or younger student can "approach" a subject doesn't mean that he or she will be able to "master" it. Wikipedia is, after all, a watering hole for all of us, including experts, and experts may have taken decades to master the field about which they are writing. Articles should include dense, scientific information, much of which will remain inaccessible unless lay people are willing to invest significant time and energy. As long as the introductory material is accessible, overall complexity should never detract from a high "Approachable" rating and will, of course, continue to add to an article's "Complete" rating. Nor should it be a goal that each and every article be "approachable": Tens of thousands of articles are truly in the realm of experts, and there's no reason to make them approachable.

Tardigrades, on the other hand, are not the exclusive province of zoologists, and I found them worthy of rescue. It's bad enough that scientists are constantly starving, freezing, and subjecting these little superheroes to the vacuum of outer space. The poor little water bears at least deserved an introduction written in English, and Wikipedia should be encouraging exactly that kind of activity,

-tog — Preceding unsigned comment added by Toghome (talk • contribs) 23:27, 15 January 2013 (UTC)

The WP:Article feedback tool rating system you're talking about is going away. It is being replaced by WP:AFT5. WhatamIdoing (talk) 00:47, 19 January 2013 (UTC)

Proposal to deprecate Wikipedia:Collaborations and replace it with something else

The good news is that Wikipedia:Collaborations is trending upwards, and is getting 1200-1300 page views a month, up from 800-900. The bad news is the page is largely unused, and has been almost completely unchanged since 2007.

There are a handful of active wikiproject collaboration pages listed (a couple very active), however they are in the minority, and the average active lifespan of most collaboration pages is only a month or two.

I realize that the goal is to get editors to work together, but the current structure is doing very little in that regard. I vote we kill it with fire and build something else in it's place. --NickPenguin_(contribs) 05:18, 16 January 2013 (UTC)

• Question – build what? The Transhumanist 05:21, 16 January 2013 (UTC)
• Question – What would (whatever we would create) intend to achieve that WP:TAFI could not? -- Toshio Yamaguchi 08:56, 16 January 2013 (UTC)

That's the main idea. The Collaborations page relies on many projects suggesting one article on one subject, while TAFI is proposing to suggest several articles across many subjects. As a single project, TAFI has the larger potential for impact on readership, and a greater chance to promote collaboration. I would propose that the Collaborations page be disassembled and recreated to promote primarily TAFI, and then secondarily the other active collaboration projects.

I think other areas could also be used to promote collaboration on this page, such as Delisted GAs, pending articles at GA reassessment and FA review, articles with the {FailedGA} tag, and Former FAs. The goal of the new page would be to select and promote collaborations, rather than describe that collaborations exist. --NickPenguin_(contribs) 18:47, 16 January 2013 (UTC)

Like. I like the idea. TheOriginalSoni (talk) 18:51, 16 January 2013 (UTC)

• Seeing that there are no major objections to this idea, I will begin adjusting the page. --NickPenguin_(contribs) 20:55, 19 January 2013 (UTC)

Proposal to delete more than 1,000 empty A-class categories

I have launched a proposal to delete more than 1,000 empty A-class categories. Instead of tagging all these pages one by one, I'm notifying people through notes like this one to get a wide participation. Discussion can be found at Wikipedia:Categories for discussion/Log/2013 January 16#Empty A-class categories. Fram (talk) 13:15, 16 January 2013 (UTC)

Wikidata

See Wikipedia:Wikidata interwiki RFC. --Rschen7754 09:37, 17 January 2013 (UTC)

Article feedback RFC now being drafted

Hi. Wikipedia:Requests for comment/Article feedback is now being drafted. Any and all users are encouraged to add a view or polish up the page. The RFC is scheduled to begin on Monday, January 21. --MZMcBride (talk) 17:41, 17 January 2013 (UTC)

Citation handling errors

Hi all,

Before I file a bug request for this, I thought I'd suggest it here.

At the moment, if you add <ref>...</ref> tags to an article which does not have a corresponding <references/> tag, you get an ugly red warning at the bottom of the page. It occurs to me that we could make this fail more gracefully if we adapt the system so that:

• a) the footnotes are displayed wherever the <references/> tag is (as currently happens); but
• b) if no <references/> tag is present, it defaults to displaying them as the last visual element, before any categories, rather than not displaying at all.

Thoughts? This is one of the most glaringly counterintuitive bits of the system that I've encountered when showing people how to edit, and I feel that while references in the wrong place aren't great, they'd certainly be better than the current system! Andrew Gray (talk) 19:27, 17 January 2013 (UTC)

• Oppose If someone doesn't know how to do it, it should be explained to them. While this might make things easier at first glance, it will make the understanding of how footnotes actually work even more difficult to comprehend in my opinion. -- Toshio Yamaguchi 20:32, 17 January 2013 (UTC)
• Comment Wouldn't it be better if a warning sign could show up saying you the reflist or close the ref tag or whatever be better than the ugly red warning? JayJay^{What did I do?} 00:54, 18 January 2013 (UTC)
• I think the idea is a good one if technically it is reasonably feasible. We have a default Table of Contents unless we say otherwise so why shouldn't we have a default reflist? We would have to deal with reference groups somehow. Thincat (talk) 14:24, 18 January 2013 (UTC)
• Comment There was a pretty important case a while back where an otherwise productive new editor left the project due to those tags. Some comments by me and a short discussion can be seen at User talk:Steven (WMF)/Archive 3#Since you appear to know how to do the meta testing.... I am completely 100% in support of any solution that can be thought up of for this issue. Ryan Vesey 18:31, 18 January 2013 (UTC)
• Comment If the red warning because of issues with the ref tags is seen as too annoying it should be changed. I have to admit I see no reason why this must look the way it does. A less colorful message should be sufficient. There are more serious issues than a page lacking a {{Reflist}} template. -- Toshio Yamaguchi 11:36, 19 January 2013 (UTC)
• Comment I am going to self-declare as an expert on cite error messages. The messages are generated by the Cite software extension and are wrapped in <strong class="error">...</strong>, causing the bold red message. The text of each message is contained in a MediaWiki message page such as MediaWiki:Cite error refs without references.

Admins can edit the message pages. We use the {{broken ref}} template on each page to display it and control where it displays- we don't show messages on talk pages. It also places pages where the error is displayed into a maintenance category Category:Pages with citation errors. This category is patrolled and articles are repaired fairly quickly. There are also some bots that do repairs.

Each message shows a link to a help page, such as Help:Cite errors/Cite error refs without references.

So, what can we do?

• We can update {{broken ref}} so it closes the span, thus the messages will not be in strong red. Pro: the message is not in strong bold; con: the message is likely to be overlooked.
• We can add {{reflist}} to MediaWiki:Cite error refs without references so it is generated if an editor forgets to add it. Pro: the reflist always shows; con: the error message is shown for other reasons, such as missing a closing </ref>, thus the reflist would show up in odd places for non-obvious reasons.

--— Gadget850 (Ed) ^talk 12:56, 19 January 2013 (UTC)

• Comment. Yes, that big, red warning is overly alarming, and ought to be toned down. As a possibly related aspect: when editing a section that does not have a <references/> tag or {{reflist}}, I have to add a temporary tag to preview the notes, then remove it. I think the best solution for that would be a "Preview w/ refs" option. But I wonder how what is being proposed here might bear on this case of editing a section. ~ J. Johnson (JJ) (talk) 23:50, 20 January 2013 (UTC)

Preview is a separate issue. See Template:Bug and User:Anomie/ajaxpreview.js. --— Gadget850 (Ed) ^talk 00:21, 21 January 2013 (UTC)

Resolving systemic bias with "Wikimedia Scholarships" for developing-country editors

The Wikimedia Foundation is profiting immensely and has a large amount of net assets already, which could be put to better use rather than merely sitting in a bank. Sure, some of this money would likely be used for future capital expenses such as more servers and better Internet connectivity, but at the present time much of the tremendous proceeds from donation are being unused. In fact, Wikipedia for function for 14 months and ten days in its current state (no more than the current rate of capital expenses) in the complete absence of further donations. The ten million dollars in gains to net assets made by the WMF could be used for the purpose of creating a "Wikimedia Scholarship" for particularly distinguished editors from emerging economies.

While Meta may seem the place to propose such an action, I am discussing it here as a large group of potential editors attracted by this program would come from former colonies of the British Empire, where English is often an official language. It is because this program will have a particularly large impact (and likely the largest impact) on this project that the discussion should be conducted here.

This project is aimed primarily at the poorest in these countries, rather than members of the urban middle classes. One hundred editors from emerging countries (as determined by oversighters, based on their contributions to the encyclopedia, will be entitled to receive $75,000 in order to make improvements to the life of their community, with a preference for making information technology more accessible to the rural poor but which can be used to improve the community in any way it so chooses.

The benefits from such a technology should be enormous. Combined with the concurrent shift to improving mobile access to Wikimedia sites, this program should enable a large number of contributors in emerging countries to contribute to the encyclopedia and give a different perspective and new information that the white, Western, male-dominated encyclopedia we have now would not see. People of diverse ethnicities and religions would join our encyclopedia, thus improving our coverage of topics related to those subjects and making our encyclopedia more neutral. Overall, Wikipedia would gain a new lease of life after years of declining editorship and low rates of article creation. Wer900 • talk 02:24, 18 January 2013 (UTC)

I'm not commenting on the proposal, but I don't think the name makes much sense. A scholarship typically pays for education; you're describing a grant. Ntsimp (talk) 18:24, 18 January 2013 (UTC)

...and note that the WMF grants program was recently launched, and indeed is being advertised on sitenotices at the moment. Andrew Gray (talk) 16:56, 20 January 2013 (UTC)

And how many of us would continue to work for nothing if we did that? Britmax (talk) 17:15, 20 January 2013 (UTC)

I reject the idea that having a reasonably-sized capital reserve is something the Foundation need to change. It gets people's knickers in a twist (because "OMG they don't need money, they've got all this money in the bank!"), but it's actually sound fiscal planning. Grants are a good thing. They already exist. If you want one, or you can think of an idea for one, go get one from the Foundation or from a Chapter. —Tom Morris (talk) 01:04, 22 January 2013 (UTC)

• • In the UK the Charity Commission, the government regulator, recommends that all charities maintain reserves equivalent to 12 months running expenses, a position that WMF has I think only reached after the latest fundraiser. Many older charities and colleges in the US have endowments that would last them far longer. No doubt WMF could still afford some money in this direction, but I won't comment on the proposal here, just don't lets have more moaning about money sitting in a bank etc. When you have 100+ employees you have to act responsibly. Johnbod (talk) 04:51, 22 January 2013 (UTC)

Proposal to have a multi-language wikipedia with automated machine translation

I would like to propose that a new wikipedia be established for articles intended to be machine-translated into multiple languages (a "multi-language wikipedia").

The general idea is that when an article is added to the multi-language wikipedia, it is automatically machine-translated from its source language into various target languages (English, French, German, Hebrew, Arabic, Swahili, etc), and the translated article is put into the various target language wikipedias (as many as possible).

The problem I am trying to solve is this: when I do a new article for the English wikipedia, that's very nice for English speakers, but not much use for non-English speakers. If I want to make that information available to speakers of other languages, I have to translate it, one language at a time. There are 285 wikipedia languages! I want to write it once and have it available for everybody at once.

The wiki source for such an article would have some constraints.

• The content of the articles would have to be restricted to the kind of simple text that reads well when machine translated. So editors would have to restrict themselves to short simple sentences.
• It would have to identify the source language that it is to be translated from (that is, the wiki source could be written in French or German or whatever, but it would have to identify itself so that the machine translator knows what to translate it from).
• It may be necessary to specify that some parts of the text are not to be translated, but instead remain in their original language (according to the needs of the article).

Machine translation is at a stage where probably the majority of wikipedia articles would not be suitable for automatic machine translation. But a large minority are. And if all of those articles were available to all languages, instead of just one, the reach of the wikipedias would be greatly increased, which would be a wonderful thing.

The kind of articles that I think would be suitable for the multi-language wikipedia are things like tables and lists. For example: List of sovereign states, Homo, List of Chinese monarchs, etc.

I'll note in passing that this is an example of a solution to a problem you get all the time in software engineering. A well-designed system will have a single place which is the definitive source of some knowledge, and you propagate it from that single source to everywhere that needs it. You shouldn't have to repeat yourself.

Ben morphett (talk) 23:26, 18 January 2013 (UTC)

A quick google search found meta:Wikipedia Machine Translation Project, which, although inactive, might be worth a look. —Theopolisme (talk) 03:11, 19 January 2013 (UTC)

Thanks for this lead. That was very helpful. I'll follow up on this. Ben morphett (talk) 21:19, 20 January 2013 (UTC)

By all means, no. The problem you are trying to solve does not exist. "The problem I am trying to solve is this: when I do a new article for the English wikipedia, that's very nice for English speakers, but not much use for non-English speakers." - wrong. The ones who do not know English can use Google Translate without Wikimedia Foundation or us lifting a finger.

And the "solution" would create more problems. One of the worst is that someone will want to update the articles automatically as well. And that will not go well...

The solution is simple: care about things that you can actually do (and do well). Leave everything else to someone else (God, Wikipedia's Community etc.). That's also the moral given in Matthew 6:34 ("Be not therefore solicitous for to morrow; for the morrow will be solicitous for itself. Sufficient for the day is the evil thereof.") or My Little Pony: Friendship is Magic episode "It's About Time"... --Martynas Patasius (talk) 10:20, 19 January 2013 (UTC)

Yes, I'm a big fan of Google Translate, and I use it from time to time. It solves some of this problem, but not all. It doesn't provide me with any lead about the things I don't that I don't know. For example, there may be a useful Hebrew article that is just what I want, which Google could translate for me, but it will probably never show up in my search results if there is no English article for it. And for non-English speakers, their corresponding problem will exclude them from most wikipedia information. (That said, I can see the huge attraction of passing the problem to Google - it means that we need take no action.) Ben morphett (talk) 21:19, 20 January 2013 (UTC)

Certainly the various languages do not have equal articles. de:Verdrillung and es:Presupuesto are bigger and better than their English counterparts, for example. However, machine translation is dreadful for most prose and we are better off leaving it to outsiders. As for data as often found in tables, Wikidata is a far more likely multilanguage bet. Jim.henderson (talk) 10:50, 19 January 2013 (UTC)

Indeed. The same is true for Pierre de Fermat and fr:Pierre de Fermat. The contrast there is so large that I wonder if I should take on as a project to translate the rest of it for English speakers (some time, if I ever have a spare few days!).

Thank you for the pointer to Wikidata. That was another very valuable lead. Ben morphett (talk) 21:19, 20 January 2013 (UTC)

I agree with Jim.henderson - machine translation is currently not of sufficient accuracy (if it ever can be), and will frequently result in misinformation, which is surely worse than no information. PaleCloudedWhite (talk) 11:14, 19 January 2013 (UTC)

I do take the point about the inadequacies of machine translation, but if the entire text to be translated is simple noun phrases, there has got to be a point at which the translations are at least correct (if not beautiful), and as such, good enough. Hasn't there? Ben morphett (talk) 21:19, 20 January 2013 (UTC)

There's another tack one can take on this. Fix the easily confused words that will appear to native speakers as almost cosmetic errors but which will throw a translation program, - I've been working on this for some while. But the next step would be to talk to the translation software engineers and ask if they'd like to collaborate re the words that their software finds ambiguous. I bet that Google could produce lists of sentences in Wikipedia articles that don't make sense to its translators, and if that were done we'd potentially have some big lists of things that probably need fixing anyway. ϢereSpielChequers 21:44, 20 January 2013 (UTC)

This step of the AfD process is very confusing

In step 2 of WP:AFDHOWTO it says Add a deletion sorting template to the nomination, if appropriate. The wikilink in this advice points to Wikipedia:WikiProject Deletion sorting/Compact, without giving any further guidance. This is very confusing, as I had no idea what to do on that page (and I would call myself a relatively experienced editor by now). The advice at step 2 of AFDHOWTWO says I should add a deletion sorting template, but I don't see any templates at Wikipedia:WikiProject Deletion sorting/Compact. I propose to make this clearer somehow. -- Toshio Yamaguchi 10:40, 19 January 2013 (UTC)

In practice, nominators almost never add deletion sorting tags to their own nominations. I have boldly removed that line from AFDHOWTO... — This, that, and the other (talk) 10:51, 21 January 2013 (UTC)

Thank you. -- Toshio Yamaguchi 12:01, 21 January 2013 (UTC)

Remove deleted edit count from everywhere

Everytime I ask someone (online friend etc) to see my edit count page (though I do it very rarely), I have to explain that "deleted count" does not mean someone deleted those edits because they were not helpful. Simply, those pages don't exist now. Seeing the deleted count is increasing is a pain.
Please remove it from TParis's count tool, other count tool etc. OR mention clearly everywhere where "deleted edit count" is given that "deleted edit count" does not necessarily mean "unhelpful contribution" OR rename it as "Past edits", "Not in record edits" or something so. --Tito Dutta (talk) 13:13, 19 January 2013 (UTC)

I don't this it should be removed completely, but maybe have a question mark next to it which when clicked explains what the deleted edit count is. ·Add§hore· ^{Talk To Me!} 16:33, 19 January 2013 (UTC)

They are edits that have been deleted and then counted, so "deleted edit count" makes perfect sense to me. I would also note that I think I appreciate seeing it on the tool. As for ambiguity, a short note in hover-over or clickable text would make some sense, but consider that even if we changed it to "positive contributions which were deleted" (which we wouldn't, ofc), you'd still have to explain that to your friends. – Philosopher ^{Let us reason together.} 13:53, 21 January 2013 (UTC)

Bot proposal for dates in reference section

I would like to draw fellow editors' attention to a newly-opened bot proposal for correction of format drift of dates within citation templates at Wikipedia:Bots/Requests for approval/MOSNUM bot 2. -- Ohconfucius ^{ping / poke} 14:02, 20 January 2013 (UTC)

ABBA vandal

Hi. My issue is concerning user 89.98.37.96, who has edited a clfew abba related articles so far, falsifying information, and heaviky poving it towards Agnethac(the blonde one). Layer editors to tone of the pages havent reverted the edits creatibg a bi of a mess. As i am not in a position to go through all the mess and fix up the damae, i request that someone here gives it a peak. I KNOW IS PROB NOT THE RIGHT FORUM BUT I COULDNT THINK OF WHERE ELSE TO GO AT THIS TIME. IN ADDITION TO THIS, I THINK TGE USER MUST BE EXPLAINED THE RUKES AND IF THIS PURSISTS HE MAY NEED TO BE BLOCKED. Thankyou for reading this :). (btw i only realised now that a lot of my comment was in capslock. Sorry abiut that. Its so hard to edit wikioedia when on ones phone.....)--Coin945 (talk) 20:00, 20 January 2013 (UTC)

I posted this to the correct forum, here. GenQuest ^{"Talk to Me"} 19:46, 21 January 2013 (UTC)

Request for comment on Article feedback opened

Hi all,

The request for comment on article feedback has opened. All editor are invited to comment, endorse other users's views, and/or add their own view.

Thanks, Legoktm (talk) 01:06, 21 January 2013 (UTC)

There can be some Wiki-index-pages of URLs of on-line-scientific-papers

Dear Sirs, Just as Wikipedia has recently started Wikivoyage; so exactly,it is important that there is a page like: Wiki-index of on-line-scientific-papers, because: You know that editors of peer-reviewed-journals are not always free from weaknesses like greed. If an article submitted to a journal is of an average significance, then the editor sends it for peer-review; and publishes it in the journal. But if the submitted article is highly significant, then the editor rejects it without sending it for review, saying that it is too speculative, or it is out of scope of the journal...etc. And after some time one finds the same content has got published by some other author written in different words. So, Wikipedia can contribute to faster progress of science by publishing only the URL-links of papers placed by the scientists at their own web-site. Such links can be classified into different subjects, topics like it is done by the journals. Publishing of only the URL will not consume much space, but it will lead to faster progress of science, encourage true researchers; and nullify selfish, greedy motives of those un-deserving occupiers of editor's posts. There are sites like arXiv, but one requires another person as endorser. Wikipedia has recently started Wikivoyage. Similarly, there can be Wiki-index of URLs of on-line-scientific-papers. This is what i, being a pensioner, can contribute to Wikipedia. — Preceding unsigned comment added by 123.201.22.184 (talk) 12:05, 21 January 2013‎

Notification of bot request regarding NFCC#10c violations

I made a bot request concerning violations of NFCC Policy 10c which can be found at Wikipedia:Bot requests#Bot to detect NFCC#10c violations. Notification placed here as a courtesy for information of the community. -- Toshio Yamaguchi 16:42, 22 January 2013 (UTC)