Jump to content

Wikipedia:Village pump (proposals)/Archive 98

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

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

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

Talk Block

Someone who continually violate WP:Bite should be blocked from editing talk pages for a period of time. Of course, all the blocks would have to conform to WP:Blocking Policy. People would be blocked to prevent imminent or continuing damage and disruption to Wikipedia, and to deter the continuation of present, disruptive behaviour. Biting new users on their talk page is not necessary for Wikipedia to continue, and thus should be subject to blocking. — RosscoolguyCVU | My Talk 15:05, 13 January 2013 (UTC)

The problem is there is a spectrum of behavior that different editors consider Bitey, which can include proper deletion nominations and warnings. Its vague enough that we probably shouldn't block people for it without at least holding a discussion of the behavior in question at WP:AN/I, and if we are going to hold such a discussion to consider the conduct on a case by case basis, we really don't need a seperate rule on it. Monty845 15:34, 13 January 2013 (UTC)

The Wikipedia Image Gallery needs to be improved as a slide show overlay or something of that sort.. Its really painful to view them each in a separate window. Mohammadulhaque (talk) 16:09, 14 January 2013 (UTC)

Commons has a gadget that allows users (who selected to enable this gadget) to view galleries as slideshow. you can create a proper "proposal" to import this gadget from commons to enwiki. peace - קיפודנחש (aka kipod) (talk) 22:41, 14 January 2013 (UTC)

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–


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 = 384.64569 but User:Rjensen with 65299 edits (almost one fourth of Bgwhite's edits) but a stunning 10.81 edits per page gets = 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. Monty845 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 edits2/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)

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)

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? Monty845 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 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)

Change 'contributions' to 'edits'

Per a request at WP:AN/RFC, this discussion is closed with the consensus of contributors preferring to keep the current word "contribution". -Nathan Johnson (talk) 15:51, 17 January 2013 (UTC)

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)

  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
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.

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)

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)

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 -
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)

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)

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)

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)
Wikimedia Commons has media related to Featured_pictures_on_Wikimedia_Commons.
  • Startbutton for GallerySlideshow in commons
    Startbutton for GallerySlideshow in commons
  • GallerySlideshow mode (images of a Category)
    GallerySlideshow mode (images of a Category)
  • image gallery
    image gallery
  • "Wikimedia Commons has more media related to this, click here"
    "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)

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)

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)

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)

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)

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)

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 [1] 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)

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)

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)

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)

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‎

Are you aware of Wikiversity? This proposal might be within their scope. If not, new projects can be proposed at meta:Proposals for new projects. – Philosopher Let us reason together. 17:49, 23 January 2013 (UTC)

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/Archive 52#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)

Cite errors: language translations

See also: wp:VPM § Error message translations

One unresolved issue with cite error messages is that users with a language set to other than en see the default message in the selected language without the link to the help page. I have a solution for at least the top used languages— see the discussion at Help talk:Cite errors#Broken ref: language support. --— Gadget850 (Ed) talk 13:50, 23 January 2013 (UTC)

Interesting problem, but how would a solution work? Is it even possible to have page content (rather than user interface elements) be made dependent on the user's id and preferences? I was under the impression that, since page content gets computed and cached centrally for all users, making it dependent on who is currently viewing it is pretty much impossible, at least without the use of client-side Javascript. Last time I looked, it wasn't even possible to make a template display the username of the user who views it. Fut.Perf. ☼ 14:44, 23 January 2013 (UTC)
I'm not sure what you mean by "page content" here. This only applies to MediaWiki message pages.
When a user selects language in their preferences, the MediaWiki software then switches all MediaWiki messages to a localized version. For example if you select the default of English (en) add references to a page and forget to add {{reflist}}, then Cite calls the error message at MediaWiki:Cite error refs without references which shows as:
MediaWiki:Cite error refs without references
But, if you select Spanish (es) as your language, then MediaWiki adds /es to all messages, so the error at MediaWiki:Cite error refs without references/es is called:
MediaWiki:Cite error refs without references/es
You can use Special:AllMessages to see system messages. MediaWiki ships with defaults that can be customized. When you look at AllMessages, the defaults without custom are clear; defaults with custom are yellow and the custom message is green. Since the messages are built into MediaWiki, the name will be red linked for default and blue linked for custom. There is a pulldown to select the language.
For our example, see Cite error refs without references. As you browse through the languages, only English has a custom message (and Spanish since I have been testing with it) because we added links to help pages.
A common complaint is that an editor encounters the error and asks how to fix it on the Help Desk. Since I am the prime architect of those help pages, I like to get feedback as to why the help page did not work. The most common cause is the language issue, as the defaults don't have the help page link.
For another example, check out MediaWiki:Newarticletext, which has also been customized.[2]
--— Gadget850 (Ed) talk 15:21, 23 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)
"Edits to pages that were later deleted" might be a simple enough description, but you need to talk to TParis. That tool is "his", not "ours". WhatamIdoing (talk) 01:12, 23 January 2013 (UTC)
Keep in mind that having a substantial deleted edit count is actually usually considered a positive. If someone shows up at (for example) RFA and has a bunch of deleted edits, it probably means they've done a fair amount of accurate speedy-tagging of articles. Andrew Lenahan - Starblind 17:43, 29 January 2013 (UTC)

Ensure state of the art security for us

Hello, Sometimes I have to use your website from Office or Cyber Café or Library. There are many hackers surrounding me who use key logger softwares and other techniques. So I am all-time worried. I hope you will provide OpenID service like “Sign in with Google” AND "Login with Facebook" including others. I use it to login to www.mail.yahoo.com by my Google Account based on “One Google Account : One Yahoo Account” policy. Anyone can login to Yahoo’s website without password just by clicking on “Sign in with Google”. Google uses 2-step verification method which is the state of the art security against key-logger. ALSO ENSURE “FULL ACCOUNT” SUPPORT FOR THOSE WHO WILL USE OPEN ID LOGIN. Wish you good luck. Thanks, Tawhidur Rahman Dear

The founder of Wikipedia has already said he does not want OpenID here. Although we can discuss it again, the consensus will probably be to not implement OpenID. If you have a specific security improvement you would like, feel free to email security@wikimedia.org . I think they could reply well. ~~Ebe123~~ → report 20:12, 28 January 2013 (UTC)
Could you link to Wales' statement on the issue? Rmhermen (talk) 17:27, 29 January 2013 (UTC)
Personally, I'm not aware of such a statement from Wales. The issue is currently tracked at T11604. Kaldari (talk) 21:49, 29 January 2013 (UTC)
I might be mistaken. I just remember from somewhere... ~~Ebe123~~ → report 23:49, 29 January 2013 (UTC)

"America is Great" bias

Good day, all. I just came from the Legalism (Chinese Philosophy) page. As I am currently in a East Asian Thought class, and we just studied that particular time period (400-200 BCE), I was able to quickly spot some... moderate bias.

Sentences I changed:

  • The entire system was set up to make model citizens behave and act how the dynasty wanted them to act against their will.
  • In theory, the Legalists believed that if the punishments were heavy and the law equally applied, neither the powerful nor the weak would be able to escape state control.
  • Guided by Legalist thought, the First Qin Emperor, Qin Shi Huang, would weaken the power of the feudal lords, divide the unified empire into thirty-six administrative provinces, and standardize the writing system.
  • Based on promoting the interests of the state Qin, the law (Chinese: 法; pinyin: fǎ; lit. 'law', ' method', ' way') served as a vehicle to both control the populace and eliminate dissent

If you read carefully, you should be able to spot the bias. While I, personally, do not approve of Legalism, these sentences cast a definite negative bias. The last sentence isn't even necessary, now that I think about it. The real kicker is that there aren't any citations for the whole paragraph. Indeed, the vast majority of the page is without cited reference.

However, the lack of citation isn't my point. That agreeable bias is something we must be on the lookout for. Even if we agree with the ideas behind the bias, maybe even the bias itself, we must eliminate it. Who are we to say what the exact purpose of Legalism was? Who are we to speak for the ancient Chinese people, and what their will was? We can only speak for what was and what was not, and even that we can only do so well.— Preceding unsigned comment added by CirusArvennicus (talk • contribs)

How does "The law served as a vehicle to both control the populace and eliminate dissent" indicate "an America Is Great bias"? That's pretty much the definition of public law, be it 2nd century China, 21st century America, the Hammurabic Code or the Wikimedia Foundation Terms of Use. In modern Western democracies the people (through referenda and election of representatives), rather than the Emperor, decide what the laws will be, but that doesn't mean criminal law has any purpose other than the prevention of activity deemed undesirable by the rulers.
Your complaint about the article being unsourced seems to be based on a misunderstanding. It's missing inline citations, but that's because it's an old article (the bulk of it was written 2003–2006), written when Wikipedia practice was to have a list of sources at the end of the articles rather than the current fact-citation-fact-citation format. The sources used are all listed correctly.
You would be much better off addressing concerns to Talk:Legalism (Chinese philosophy), where those with an interest in the topic are more likely to be found. It's not very clear what, if anything, you're actually proposing here. – iridescent 16:20, 29 January 2013 (UTC)
It should be obvious to anyone that the opinions of a student taking a class in "East Asian Thought" carry more weight in Wikipedia than the preponderance of published material on the matter. Equally obvious is wisdom of discussing the vagaries of a single article (eg "Legalism (Chinese Philosophy)" aka "Legalism (Chinese philosophy)") here in Village Pump.</sarcasm>--→gab 24dot grab← 17:00, 29 January 2013 (UTC)
I would certainly agree that this is the wrong forum. The concern is about a particular article and should be discussed on that article's page. – Philosopher Let us reason together. 18:21, 29 January 2013 (UTC)
The above discussion has been transferred HERE, as it is a more appropriate setting for the discussion.
Thank you. GenQuest "Talk to Me" 22:39, 29 January 2013 (UTC)

Hatnotes to WP pages

I propose eliminating all hatnotes linking to project pages. For example, currently Notability, Source, Sandbox, User (computing), Editing, and so on all include hatnote(s) to project pages. So do almost all abbreviation disambiguation pages – GAC, FP, AFD, RFA, NOR, etc. etc. These should be removed for a few reasons:

  1. Most non-editors will have no need for them, and editors know to use the WP: prefix.
  2. They self-promote, which detracts from the quality of Wikipedia by getting in the way of useful information.
  3. In some cases (such as MediaWiki), they become really long.

  -- Ypnypn (talk) 02:42, 30 January 2013 (UTC)

I question the assumption that all editors, including newbies, know to use the WP: prefix.
Note that such hatnotes should be made using {{Selfref}} so they are clearly marked as such and can be easily removed by mirror sites. If you see any that aren't, please do fix them. Anomie⚔ 02:53, 30 January 2013 (UTC)
Oppose There should be MORE hatnotes. Finding stuff around here is sometimes like finding a needle in a haystack. GenQuest "Talk to Me" 15:32, 30 January 2013 (UTC)
Oppose We do generally try to keep the namespaces separate, but abbreviations are abbreviations and new users aren't likely to know about the Wikipedia: and Help: namespaces. – Philosopher Let us reason together. 19:43, 30 January 2013 (UTC)
On further thought, Support removing non-abbreviation references to the MediaWiki: namespace, where found, since its contents are part of the interface and are unlikely to be of help to new users. – Philosopher Let us reason together. 19:46, 30 January 2013 (UTC)

Languages on sidebar - sequence

Currently if you are on a page that has equivalents in other Wikipedias the sidebar lists them all in sequence. That may have been sensible when we rarely had more than four or five such links, but nowadays when even Britney Spears has about ninety there is a potential for clutter. Wouldn't it be better if it reflected your language proficiencies and listed any you know first? Providing people have completed Babel boxes this should be easy to code. ϢereSpielChequers 00:37, 31 January 2013 (UTC)

I don't think this would be as easy as you think. Having a template on your userpage doesn't tell the wiki software what order a list of links should be; that communication just isn't there, and adding it wouldn't be trivial (I think). I think this is a decent enough idea, but I don't see it as a terribly pressing issue. EVula // talk // ☯ // 00:50, 31 January 2013 (UTC)
Wikidata is about to go live in two weeks; this might in theory make it practical to do dynamic resorting of language links based on a user preference, but I don't know if anyone's actually thought about doing it. Andrew Gray (talk) 14:26, 31 January 2013 (UTC)

Fonts

I like wiki but only one case make me feel uneasy. Why wiki use so ugly font in webpages? do u know? I think it is so poor font that many reader may feel so painfull to read pages. The fonts is so small and not so beautiful. Just replace one better fonts sets for readers. Thank you! — Preceding unsigned comment added by Qduwg (talk • contribs)

Sorry, where exactly have you seen an ugly font? To increase the font size you can use "crtl +". Ruslik_Zero 19:12, 31 January 2013 (UTC)
As far as I am aware, Wikipedia does not use any particular font, but the CSS generic “sans-serif”, whose interpretation is entirely up to the browser. If this happens to be an ugly font for you, fix your browser defaults.—Emil J. 19:48, 31 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? JayJayWhat 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)
    • To be honest, I think if we do have an error message, it should be big and red and obvious - I'd just prefer we fix it silently without needing to shout at anyone ;-) Andrew Gray (talk) 11:01, 23 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)
  • The bot solution doesn't work out well for things like talkpages with ref sections, or sandboxes (which is where I usually encounter it). I like the solution with the reflist tag in its own warning, but it's a bit hacky and I'm worried about the unforseen knock-on effects. Fixing it at source seems possibly safer. Andrew Gray (talk) 11:01, 23 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 T7984 and User:Anomie/ajaxpreview.js. --— Gadget850 (Ed) talk 00:21, 21 January 2013 (UTC)
== References preview <small><small>{{gray|(No references section has been added to the article yet; see the [[Help:Cite errors/...|help page]] for more info)}}</small></small> ==
{{reflist}}
? That wouldn't work straight off (all the cite error messages would need to be modified), but it would solve the problem in the end, by showing the user the references but stating that they are only a "preview" (therefore hopefully making the user do something to make them "more permanent"). — This, that, and the other (talk) 06:44, 25 January 2013 (UTC)
I like this (with the caveats above)! It looks pretty elegant. Andrew Gray (talk) 12:42, 25 January 2013 (UTC)
This is technically feasible, but will still be bewildering in some instances where perfectly valid {{reflist}} exists, but some other error is introduced. And with the current implementation, your message and the reflist will be in strong red. --— Gadget850 (Ed) talk 14:20, 1 February 2013 (UTC)

MathJax

Why does Wikipedia still not use MathJax? ProofWiki uses it with great success. — Timwi (talk) 20:56, 1 February 2013 (UTC)

It’s optional. You can enable it in your preferences (down on the Appearance tab).—Emil J. 21:01, 1 February 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)
    • We can't contact readers directly to get them more involved (because they generally do not have accounts). But we could make it easy for them to find the way in through the interface. The Transhumanist 12:32, 23 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)

In June 2009 then British Prime Minister Gordon Brown announced Tim Berners-Lee would work with the UK Government to help make data more open and accessible on the Web, building on the work of the Power of Information Task Force.[1] Berners-Lee and Professor Nigel Shadbolt are the two key figures behind data.gov.uk, a UK Government project to open up almost all data acquired for official purposes for free re-use. Commenting on the opening up of Ordnance Survey data in April 2010 Berners-Lee said that: "The changes signal a wider cultural change in Government based on an assumption that information should be in the public domain unless there is a good reason not to—not the other way around." He went on to say "Greater openness, accountability and transparency in Government will give people greater choice and make it easier for individuals to get more directly involved in issues that matter to them."[2]

  • Similarly, I believe greater openness and transparency concerning Wikipedia development by making The Signpost more easily accessible to readers will give them "greater choice and make it easier for individuals to get more directly involved in issues that matter to them." The Transhumanist 12:03, 23 January 2013 (UTC)

References

  1. ^ "Tim Berners-Lee". World Wide Web Consortium. 10 June 2009. Retrieved 10 July 2009.
  2. ^ "Ordnance Survey offers free data access". BBC News. 1 April 2010. Retrieved 3 April 2009.
  • Support - per Cirt, Casliber and others. Should have been done long ago. By all means, do this! Jusdafax 07:12, 25 January 2013 (UTC)
  • Support per Cirt et al. Fredlyfish4 (talk) 01:24, 26 January 2013 (UTC)
  • Support this proposal. Wikipedia is not merely a collection of robots, but people with their strengths and weaknesses, interests and beliefs, dislikes and flaws. By putting the Signpost on the main page in some form, we will give the world an appreciation for all that is required to produce this encyclopedia by unveiling to them the community underlying it. Wer900 • talk 20:42, 3 February 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)
        • Not a sledgehammer... a billboard. We want as many readers to see it as possible. So the maximum number are drawn in with a simple click. The Transhumanist 12:53, 23 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)
          • Rather than automatically signing them up for a weekly posting on their talk page, we could send newcomers a modified welcome message that includes the next best thing: The Signpost template...
The Signpost
19 October 2024
  • ...its content changes each week, making it mildly dynamic (eye-catching). But we can't send this to (non-editor) readers, because they generally don't have accounts for us to send it to. How else would we attract the maximum number of readers to edit Wikipedia? The sidebar menu is the most obvious way to reach them all. The Transhumanist 12:53, 23 January 2013 (UTC)
  • Something like this - embedding on talkpages by default - is a pretty good approach; I think this would be a good start towards exposing it.
  • However, I'm still fundamentally unconvinced by the main bar idea. We don't have any indication that an obscurely titled link ("The Signpost" is pretty opaque if you don't know what it is) will catch the attention of many readers; we equally don't have anything but a guess that a significant function will read it and be converted into editing. The sidebar is seen as a wall of text by many new contributors, and I've seen many either hunting aimlessly in it or ignoring it entirely; why cram more information into it unless we have to? Andrew Gray (talk) 09:51, 24 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)
    • It's proposed to be in the interaction sidebar, not on the main page. That sidebar can be easily hidden (assuming its not hidden by default, something I'm unsure about). Many opposes reflect this misunderstanding. It's difficult to know what these people would think if they properly understood the proposal. AgnosticAphid talk 15:42, 25 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)
  • Oppose; this prioritises the editor experience far above that for the readers. Ironholds (talk) 03:29, 24 January 2013 (UTC)
  • Oppose this is of no interest to the genral public and has no place on the front page. Ridernyc (talk) 05:40, 24 January 2013 (UTC)
    • How do you know that? Did you conduct a survey? I was a member of the "general public" when I became interested in editing Wikipedia. Weren't you? The Transhumanist 09:47, 24 January 2013 (UTC)
      • because the members of the general public do not edit Wikipedia, and this publication is primarily for people who edit Wikipedia. It's kind of obvious and self explanatory is you look at from a real world POV. Ridernyc (talk) 10:12, 24 January 2013 (UTC)
    • You misunderstood. It's not proposed to be "on the front page," it's proposed to be in the interaction sidebar, something quite easily hidden. If only people would take the time to understand proposals before rejecting them! AgnosticAphid talk 14:11, 25 January 2013 (UTC)
  • I withdraw the proposal. The Transhumanist 09:52, 24 January 2013 (UTC)

Comments: How can we get more readers involved in the community?

I think this is the wrong question here - if you mean Wikipedia readers, it's too broad; if you mean Signpost readers, it's too narrow. Either way, it's more of an Idea Lab question than a VPR question. – Philosopher Let us reason together. 16:52, 23 January 2013 (UTC)

Portal:Wikipedia newspapers?

The Signpost is, for better or for worse, the community-wide newspaper of Wikipedia. However, there are a variety of "local" papers as well. Would the "Oppose" voters support a "Wikipedia news" link that took readers to a Portal:Wikipedia newspapers, to feature the current editions of the various papers? – Philosopher Let us reason together. 16:56, 23 January 2013 (UTC)

I was idly wondering about this earlier today - some kind of portal for the various newsletters (including the non-enwiki ones), and a streamlined way to sign up for them, would be great. I'm still not convinced about putting it in the main interface, but it would definitely reward better placement in the community portal. Andrew Gray (talk) 17:03, 23 January 2013 (UTC)
Support per Andrew Gray, above. GenQuest "Talk to Me" 05:00, 24 January 2013 (UTC)
Question: There's already Wikipedia:News. How would the portal differ? The Transhumanist 10:10, 24 January 2013 (UTC)
Heh, it wouldn't, so scratch the "create" idea. – Philosopher Let us reason together. 20:32, 29 January 2013 (UTC)
Support adding Wikipedia:News. And if we wanted to save space in the Toolbar, we might consider the overlap between Help:Contents, Wikipedia:About and Wikipedia:Contact us. The "About" page in particular seems a bit "who's that for, and doesn't it duplicate Wikipedia, which most of the curious will look at anyway?" (Incidentally - five hatnotes at Wikipedia:About? Yeah, that's inviting...) Rd232 talk 17:41, 30 January 2013 (UTC)

Question

Would it be possible to add a link to The Signpost from each editor's watchlist page? Not in the watchlist itself but off to the left, maybe in the "interaction" box and only displaying when one's watchlist is displayed. Rivertorch (talk) 11:03, 28 January 2013 (UTC)

It won't really get noticed there, and changing a sitewide interface on one page is not good UI. Why not just watchlist the Signpost by default, so that users who don't want it need to unwatch it? If we want more engagement, we need to make it happen. Rd232 talk 17:44, 30 January 2013 (UTC)

Mechanism for account verification by nominal card payment

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
SNOW close. Sven Manguard Wha? 03:37, 4 February 2013 (UTC)

Proposal:

  1. create a mechanism for account verification by nominal card payment. This would simply be a nominal charge (enough to cover the card processing fee - a few cents), and would record internally that valid card details had been provided for that account. None of the info would be public [nor would there be any kind of matching of card name to username - ecommerce sites don't do this either. It's JUST requirement of valid card details, with validity proven by a successful nominal charge to the card]. Some card details would be retained to prevent use of the same details on multiple accounts (just the card number ought to be enough - at any rate, not enough details to be a security risk for the user).
  2. publicly display (maybe just on userpages) whether an account has been verified in this way. Whether and how much people put weight on this will be up to them; but being verified would be a certain commitment to contributing and a sharply reduced likelihood of being a sock. In some subject areas this might not matter; in others, it could be important.
  3. figure out how (else) to use this. For example, it could replace or supplement the current ID verification system the WMF uses for higher privileges like oversight (currently based on emailing copies of ID documents, AFAIK). In the longer term, it could also be required for other privileges (like adminship). Create the system, and we'll find uses for it, and agree them in the usual consensus way. Rd232 talk 19:19, 31 January 2013 (UTC)
Sounds a good idea. But surely would disenfranchise those without credit, e.g. junior editors? Martinevans123 (talk) 19:24, 31 January 2013 (UTC)
Well the system would also work for debit cards, which are more easily/widely available. But yes, not everyone who might contribute will have access to credit/debit cards, which is why we should be careful about either not making verification essential, or providing alternative means to do so. Rd232 talk 19:45, 31 January 2013 (UTC)
A few thoughts.
  1. Saying "none of the information would be public" and actually making that stick are two separate things. It creates a high-value target for attacks, and destroys Wikipedia's credibility the first time any of it leaks.
  2. It explicitly puts people who are too poor to obtain a credit card, people who are too young to get a credit card, people from many foreign countries (where it may be difficult to obtain a U.S.-compatible card), and people who just don't want a credit card at a disadvantage.
  3. It presumes that there is a reliable one-to-one mapping of credit card numbers to people. Unless a great deal more personal, security-sensitive information is retained and verified for each registered card (name, address, etc., in addition to the card number), this assumption is likely to be grossly wrong. (In the United States, most individuals who have at least one credit card have more than one: the average cardholder had 3.5 unique credit cards.)
This sort of proposal has been around before; I'm not up for deep archive plumbing, but Wikipedia:Village pump (policy)/Archive 46#Preventing sock puppets is one such discussion.
As you say, "Create the system, and we'll find uses for it". That's exactly what I'm afraid of. TenOfAllTrades(talk) 19:53, 31 January 2013 (UTC)
  1. "a high-value target for attacks" - um, Some card details would be retained to prevent use of the same details on multiple accounts (just the card number ought to be enough - at any rate, not enough details to be a security risk for the user). If a hypothetical hack only gets you 16-digit numbers that's not much of a risk; even if in a few cases (given some legwork) they might be linked with other data like names and addresses from other public sources, there will still not be expiry dates and CVV data. Anyway, such details (and much more) are stored by zillions of ecommerce sites; it's an acceptable risk. (And isn't it stored already by the donation system? We're not reinventing the wheel here.)
  2. See my reply above: the system would also work for debit cards, which are more easily/widely available. But yes, not everyone who might contribute will have access to credit/debit cards, which is why we should be careful about either not making verification essential, or providing alternative means to do so.
  3. It makes no such presumption. I have 3 credit cards, so theoretically I can make 3 sock puppets before getting into issues of having to ask friends and family to make accounts for me (and that would hardly be the limit, it I was determined enough). That's still a damned sight more of a restriction than we have now. Rd232 talk 20:03, 31 January 2013 (UTC)
  • Hell no. "Create the system, and we'll find uses for it." I can't imagine a lot of things at Wikipedia scaring me more than an approach like this. -- Toshio Yamaguchi 20:12, 31 January 2013 (UTC)
    • So... you trust the community to work fine with the status quo, but not to pass sensible rules for using this new mechanism? Can you elaborate, maybe? Rd232 talk 21:20, 31 January 2013 (UTC)
      • Sure, I'll try. I don't see a convincing reason in this proposal why we'd actually need this. You say "... but being verified would be a certain commitment to contributing and a sharply reduced likelihood of being a sock". I can't think of any on-Wiki scenarios where it would really matter for me whether an account has been verified or not. In which way would a verified account differ from an unverified one? What could I do with a verified account that I couldn't do with an unverified one? All you say is It COULD replace the current ID verification system of the WMF. Is there a need for such a replacement? Would the Foundation even accept that? If so, where did they state this? I personally would like to see some form of evidence that this is either needed or would be useful. Essentially for me this seems to go against our The free encyclopedia that anyone can edit spirit. It shouldn't matter who an editor is, their contributions should. Judge editors by their contributions to and their behavior on the project, at least that's my view on how an editor should be judged. -- Toshio Yamaguchi 22:17, 31 January 2013 (UTC)
      • And to eloborate on the original statement in my vote: We shouldn't introduce something we have no clear need for. I don't see evidence for the assumption that this would encourage people to make more contributions. I also don't think this is the kind of commitment that is needed for people to become more attached to Wikipedia. -- Toshio Yamaguchi 22:35, 31 January 2013 (UTC)
        • Um ok, but that explanation of "I don't see why we want it" is a long way from I can't imagine a lot of things at Wikipedia scaring me more than an approach like this. so, why do we want it? Precisely because the basic idea of Wikipedia is (as you put it) "It shouldn't matter who an editor is, their contributions should." This mechanism doesn't tell us who a person is, it just makes it lot harder (but not impossible) for editors to disguise themselves across multiple accounts. Having more trust in what's actually visible (because it's much less likely that there's much which is invisible) is a good thing from this perspective. More in a new comment further down. Rd232 talk 23:08, 31 January 2013 (UTC)
          • I can't imagine a lot of things at Wikipedia scaring me more than an approach like this comes from my experience with some cases where some stuff has been ruled out without community consensus and then someone even asks for a consensus for disabling that 'feature' which didn't even have consensus for implementation in the first place. This approach looks similar to me: Through out something and then lets see whether it is useful or not. If something isn't useful, it shouldn't be implemented in the first place. We really should determine the usefulness of a concept before implementing it, not afterwards. I don't see what this commitment to an account you mention would achieve. Also, as far as I know it is still legitimate to have multiple accounts if they are not being used for socking. And I still think this would introduce kind of a class system of users who have a verified account and those who (for whatever reasons) haven't. I don't think that would be a good thing and I personally wouldn't give much weight to whether someone has a verified account or not. Many people might refuse to take the effort of doing this payment just because it is an effort to make. After all, we are (nearly) all volunteers here and do this (mostly) in our spare time, so this effort is creating a natural barrier, how small it may be, and that is not a good thing in my opinion. -- Toshio Yamaguchi 23:50, 31 January 2013 (UTC)
            • Those sorts of problems generally involve the Foundation ignoring the community; there's not very much we can realistically do about that. It's true that multiple accounts can be legitimate, and that it might be a problem that unverified accounts become automatically distrusted (in the way IP edits often are now). Some legitimate multiple-account purposes could be handled by making the accounts linked in the software as publicly labelled secondary accounts, tied to the same card details; the problem would be where the secondary account is intended not to be linked publicly, and whether it's acceptable that these might not be verifiable. These are the sorts of issues I was expecting to discuss, actually. But at this point I guess it's clear that this will not be going anywhere at this time. (Quite possibly it will be like some other ideas which came up repeatedly over years, each time horrifying people in a "the sky will fall on our heads!" kind of way, until suddenly they were accepted, and lo, the sky didn't fall.) Rd232 talk 14:39, 1 February 2013 (UTC)
  • I'll become a Wikipedian who's not a wikipedian before this passes This unintentionally gives the go ahead for users to buy multiple accounts. WP is (for the most part) free. Everybody being able to register accounts for free we put everyone on a playing field. Any payment (even fractions of a penny) creates a entitlement for the account to edit regardless of the community will. The community grants extra privileges and responsiblities to those who have demonstrable trust, not by letting people buy the user right. Hasteur (talk) 20:19, 31 January 2013 (UTC)
    • What? As long as it's made clear what the new mechanism is supposed to achieve (you're making a certain commitment to one account), there's really no need for anyone to think anything else. Nor is that commitment to one account a substitute for any sort of trust and reputation acquired through demonstrated behaviour. Rd232 talk 21:20, 31 January 2013 (UTC)
  • Oppose. I was going to ask what problem this was intended to solve before !voting, but the statement "Create the system, and we'll find uses for it" tells me flat out that whatever problem you are aiming to solve is not worth the trouble this would create. Wikipedia is an encyclopedia, not a financial institution. It has no business asking for, tracking or storing CC/DC numbers for any reason other than donations, and then, only for what purpose is expressly required by law. This is just a bad proposal, made even worse by the number of policies it aims to change in the process. Resolute 20:41, 31 January 2013 (UTC)
    • I'm not sure even you know what on earth it is you're saying. And the number of policies affected by this proposal is currently zero. Try again. Rd232 talk 21:20, 31 January 2013 (UTC)
      • Considering you suggested that we would potentially/eventually require a credit card for adminship (I won't get started on how much I disagree with that idea unless you specifically ask me to), or replacing our existing method of verifying identities with the Foundation, I don't think you should be saying that the number of policies affected by this is zero. The scenarios for use that you've outlined very clearly would require some changes to existing policies. EVula // talk // ☯ // 22:08, 31 January 2013 (UTC)
        • "Considering you suggested that we would" - fail. I said For example, it could. Rd232 talk 22:55, 31 January 2013 (UTC)
          • That is rather the point. You are already touching on WP:SOCK and every policy we have related to accounts. You add WP:ADMIN/WP:RFA as a could, and I doubt you've considered some collateral damage. Resolute 23:55, 31 January 2013 (UTC)
            • Look, there is no way that creating this mechanism in itself changes any policy. The fact that it would make socking harder has no bearing on the socking policy. The fact that it might be used for adminship does not have any bearing on admin policy: admin policy gets affected (sorry to have to spell this out) after a concrete proposal has been made and accepted by the community. No such proposal has been made, and it doesn't seem helpful to do it now. But if it a concern, I can only repeat for the umpteenth time: the mechanism would have to be supplemented with alternatives for people who couldn't access it, or else not be made essential. (Would my proposal be clearer if I made several ones - A) create a mechanism B) create a mechanism AND MAKE IT COMPULSORY?) Rd232 talk 14:29, 1 February 2013 (UTC)
          • Oh, I'm sorry. You hypothesized additional scenarios. You're right, that isn't the same as "suggesting" at all. EVula // talk // ☯ // 00:01, 1 February 2013 (UTC)
  • Strongest Possible Oppose What is being "verified" here? That the name on the credit card matches the name on the account? What does that matter? The name on my credit card isn't "EVula", so what good does that do?
    Let's say Editor X claims to be a professor of history at a small community college. Does providing a credit card to the Foundation prove that Editor X is certified as a professor of history? No, it doesn't; it just proves that they have the same name. Even if it is the same person... so what? The fact that Editor X is a professor doesn't make him any more or less qualified to edit Wikipedia; theoretically, any edits made to historical articles should be well-sourced, and an amateur historian is just as capable of providing good sources as a professional one (the latter might have better resources, but that doesn't mean that they would be used correctly), so Editor X's expertise is irrelevant to the day-in, day-out operations of the project. There's nothing worthwhile to verify. EVula // talk // ☯ // 21:38, 31 January 2013 (UTC)
    • What is being "verified" here? That the name on the credit card matches the name on the account? fail again. No, that is not proposed. Nor is it suggested to publish the names on the credit card. Nor (I'm getting annoyed at reading comprehension fail here) is it suggested that only people with Platinum cards will in future be able to correct Wikipedia spelling mistakes. Rd232 talk 22:55, 31 January 2013 (UTC)
      • You know what I'm annoyed at? Nearly everyone agreeing that this is a bad idea and you acting like we're all idiots and you're the only one that gets it. Being told "fail" twice in a row (plus your reading comprehension quip) has sort of killed any desire to be nice about it. I asked you what exactly would be verified here. You didn't address my comment; you instead opted to make a snarky comment, which is what you've done to most everyone that has commented. EVula // talk // ☯ // 00:01, 1 February 2013 (UTC)
        • The proposal could have been clearer ("verification" an ambiguous word), but "verification" involving matching username to card name is so obviously nuts I'm insulted you assumed that was being proposed. In response to your comment I further clarified what "get valid card details" means. And frankly I'm trying to be as constructive as I can in response to comments which mostly don't understand the concept and show little interest in trying. I'm reminded of why I created the Idea Lab - people round here really do (not always, but far too often) react to new ideas like they're allergic to them. (At least one person here (Toshio) has engaged with an idea he doesn't agree, which is batting above par.) Rd232 talk 14:29, 1 February 2013 (UTC)

The problem

OK, let me try and elaborate the basic problem: the problem is that we have two conflicting aims on Wikipedia:

  1. anyone can edit
  2. transparency of editing, to enable track records of content and discussion contributions to be considered, because it's what you say and not who you are which matters.

The first aim means anyone can edit without an account, and that creating account has zero ID requirements (not even an email). This unfortunately undermines the second aim, by allowing the phenomenon we know rather too well: socking. Socking, unfortunately ends up, in the long term, rather insidiously, undermining the first aim, by creating a systemic distrust of new users (WP:BITE). At least part of the problem with declining editorship is to do with new editors not "surviving" as long as they should. Now we know that Wikipedia depends on a core of significant contributors. The problem is not getting the odd reader to dive in an correct a spelling mistake; it's getting someone from readership to knowing the difference between an infobox and a navbox, and how references work, and how key policies are interpreted, etc etc. This requires people to cross a much more difficult hurdle than just signing up for an account. Now my contention is that being able to create a degree of identity verification (without giving the identity publicly) will

  • (a) make socking much harder, which will in the longer term reduce WP:BITE issues, because the risk of a new verified account being a sock will be much lower
  • (b) make it easier to convert casual editors into more significant contributors, because with a couple of minutes work they can verify their account and thereby give themselves more credibility (lower likelihood of being a sock, more commitment to editing) and so be taken more seriously by others. The very act of verification would also be a source of commitment ("I've made the effort...").

Now, the point of the structure of my proposal was exactly "make the mechanism, and see what happens". Don't force anyone to use it, but put it out there as an option, and see if it is helpful for building trust of people who make the effort to use the option. Make any more sense yet to anyone? We have a fundamental structural trust problem; this is one idea that might help. If you don't like it, what's yours? Rd232 talk 23:26, 31 January 2013 (UTC)

Ok, so after we have wasted developer time on this and absolutely nobody takes advantage of it, what then? I have absolutely no idea what makes you think that adding a barrier to registration will have a positive impact on editor recruitment and retention. At best it will have no impact, and at worst, negative. New users are automatically distrusted because of sockpuppetry? I disagree. Most new users are distrusted because we as a project have become too intolerant of newbie mistakes. And the irony here is that you propose a system that tells a potential new editor that we want some of their personal financial information or else we don't trust them. That is not a good message to be sending. Resolute 00:00, 1 February 2013 (UTC)
adding a barrier to registration - no, that would involve a proposal that you can only create verified accounts, not unverified ones. Where, pray, do you see that? As to wasting developer time - given that this potentially addresses a core problem of Wikipedia, I think the risk is well worth taking. This is not twiddling at the edges, it's blue-sky thinking (urgh to self - but the phrase is appropriate here). So to the concrete question: would this help build trust of new editors who choose to use it? I think you need a clearer argument about why it wouldn't. For instance, newbie mistakes by a verified account are quite likely to be treated (on average) more kindly/helpfully, don't you think? At the end of the day, there is a lot of research about the value of demonstrated commitment to community membership. We currently do not have any form of that apart from contributions - yet contributions can easily get ripped apart negatively (whether it's because of newbie mistakes or socking concerns). This is a new way to demonstrate commitment and build trust. As long as it remains optional, I really don't see how it can be a bad thing. Rd232 talk 11:57, 1 February 2013 (UTC)

discussion was closed with following comment: There are better ways to verify identity, which don't cause problems for editors who may be unable to get credit cards, or may be unable to transact with a US based company. Prodego talk

reopened with questions:
  1. why shut down discussion of a proposal in less than 24 hours? This is not usual on this page - possibly because it's well established that constructive discussion of unfeasible/"bad" ideas can lead to feasible/"good" ones emerging.
  2. what are these "better ways to verify identity"? Can we talk about that, maybe?
  3. it was acknowledged (repeatedly, in fact) that the mechanism would not work for everyone (though pretending that debit cards don't exist unnecessarily narrows the number of people it does work for). As a result, it was clearly stated that we should be careful about either not making verification essential, or providing alternative means to do so. The mechanism would work for large numbers of people, and a large proportion of those who would realistically make substantial contributions, and that it wouldn't work for everyone is not a reason to not create the mechanism: it is a reason to be careful with how it is used.
Rd232 talk 11:48, 1 February 2013 (UTC)

Remark: shutting down this discussion is classic "oh noes, we must protect the community in the here and now by avoiding wasteful discussion". Long-term thinking? How will Wikipedia survive the next ten years, with growing content and declining editorship to maintain it? Oh, we don't have time to worry about that, somebody created an unformatted new article... Rd232 talk 11:57, 1 February 2013 (UTC)

Agreed. Although I oppose this proposal, I think discussion can be useful here. I also don't see what harm is done in letting this discussion run a bit. -- Toshio Yamaguchi 12:23, 1 February 2013 (UTC)

Suggestion

@Rd232 You say one of the goals of this proposal is to make it easier to convert casual editors into more significant contributors. I agree that this is a significant goal, I just disagree with the method for reaching that goal. So lets discuss ways to achieve that goal, as I think this discussion can indeed lead to ideas for improvement.

Some problem I see with acquiring new significant contributors is that:

a) Wikipedia has become a quite complex system whose functions and inner workings aren't really obvious to a newbie or someone visiting the site only occasionally
b) The more experienced you become, the more difficult it becomes to edit, since gradually a higher standard is expected from you
c) There is less and less room for creating new articles on easily accessible topics
d) Many people in real life think only nerds edit Wikipedia, so editing is just uncool for many in the first place
e) (This goes hand in hand with a)) Wikipedia has a lot of rules I guess many people are unwilling to learn

Just some that come to my mind immediately. -- Toshio Yamaguchi 12:53, 1 February 2013 (UTC)

Thank you. Those are indeed some of the problems - but none of them are really fixable in any significant way (and I say that as one of the re/creators of Wikipedia:WikiProject Policy and Guidelines and at one time an enthusiastic improver of Help pages). The only thing we can really substantially do is make it easier for new editors to become substantial contributors; some of that is technical (eg visual editor) and some social: focussing limited support resources on the right people. The problem here is identifying the right people. This is a well-known problem of signalling: in this case, who among new accounts is a new editor (not a returning old one!) who has a degree of commitment to learning the ropes. Those new accounts are gold, and need to be found and given every help from limited resources (including learning, and being allowed to make mistakes without getting cut off at the knees). By creating an automated way of verifying a meaningful signal, we make it easier to identify new editors who should be given a greater chance to turn into significant contributors than the average toe-dipper. In addition, the very act of making the signal will strengthen the signaller's commitment to learning, contributing, and dealing with problems as they inevitably arise.
People in this discussion are unavoidably those who have made this journey to significant contributor without the aid of such signalling; this inevitably creates a structural prejudice. (You see it with much more obvious cases of "it was good enough for me" - doctors who as juniors did 100-hour weeks even though this is clearly dangerous for patients.) I would also stress that if this new mechanism were created, that would (if it gained any traction) create more pressure to find alternatives for those who can't access it for whatever reason. Long-term, a key part of this is that it's an automated way of signalling commitment (once set up, it's just there) - we need to find more ways to use automation to reduce workload generally, because structurally the ratio of work to contributors is falling and will continue to fall. Change scares people, but organisations which don't adapt to changing conditions eventually die. Wikipedia is changing, but if it changes too slowly, it will fall apart. Rd232 talk 14:06, 1 February 2013 (UTC)
See also: "Wikipedia has changed from the encyclopedia that anyone can edit to the encyclopedia that anyone who understands the norms, socializes himself or herself, dodges the impersonal wall of semi-automated rejection, and still wants to voluntarily contribute his or her time and energy can edit." (from User_talk:Jimbo_Wales#Wikipedia_Is_Getting_Worse_As_It_Gets_Better.) Rd232 talk 14:47, 1 February 2013 (UTC)
If you want to talk about a "structural prejudice", how about looking at what happens when you create a separate, privileged class of 'serious' contributors who are worthy of receiving "help from [Wikipedia's] limited resources", and who incidentally will happen to exclude the poor, the young, and many who live outside the United States. If individuals want to be able to signal a desire for growth or assistance as a Wikipedia editor, they should be able to do it for free, without giving up (or risking) their personal information, with as low a bar as possible. Do we need to improve awareness and availability of tools like the Help Desk and the {{helpme}} template? Perhaps. Should we work on providing more mentorship-style opportunities, or apprenticeship-type situations, to aid editors who are trying to learn some of the more complicated ropes on Wikipedia? Could be. Would requiring a credit card before we offer these services be likely to improve their efficacy? I remain highly skeptical.
You call this an "automated" way of signalling commitment. While 'automated' is a pleasant and efficient-sounding word, its use here warrants closer scrutiny. This scheme is 'automated' only in the sense that it offloads all of the heavy lifting to the individual editor involved; instead of being recognized by the community for one's efforts and participation, one remains second-class until one gets the magic credit-card-verified star.
The participation in many online communities follow what is often known as the 1% rule or the 90-9-1 principle. While the exact percentages vary from one community and website to the next, the principle states that roughly 90% of people are 'lurkers' (for us, readers only), 9% are 'casual' participants (who make occasional posts/edits), and just 1% are highly active (lots of activity on a regular basis). I get that you're trying to convert the 9-percents into 1-percents (except when you were going off in weird directions about this somehow being a meaningful solution to sockpuppetry), but putting a formal credit-card-required speedbump across that route isn't likely to help. Worse, by emphasizing to the 9-percenters that they are a separate, distinct, lower class of Wikipedia editor, it makes it harder for us to pull people across the 90-percent to 9-percent divide.
I reiterate my concern, as well, for the bass-ackwards approach being suggested. "Create the system, and we'll find uses for it." Or, "...if this new mechanism were created, that would...create more pressure to find alternatives for those who can't access it...." No, no, no. We aren't going to build a technically-complex, risk-laden, probably-harmful system on the hopeful promise that it's most serious flaws might be fixed in the future, and the hopeful threat that once it place it can experience poorly-controlled scope creep. TenOfAllTrades(talk) 15:28, 1 February 2013 (UTC)
Thank you for a cogent response, I'm glad you appreciate that the conversion of 9%ers into 1%ers is the key dynamic at issue. I don't agree that this mechanism is not an option, though; I think it works as a step in the right direction where it becomes easier for some people to (optionally!) signal their commitment, and if that proves successful, it'll be a big incentive to work out other ways for people to do it. Also, whilst the mechanism excludes a large percentage of people if we look at the world's population, the percentage is a lot lower if we're looking at the sort of people who have the time and ability and regular internet access - i.e. the main target group. I also don't think it's fair to say it's "technically complex" (no more so than problems WMF solves every day) or "risk-laden" (the whole donation system is already there, and no data should be stored that would create a security issue). And it is automated from the point of the existing community, which is the key perspective given the workload issues. The additional workload to people using the mechanism is pretty minimal - people do it every day for ecommerce, it's a few minutes' work, and it only needs doing once.
Alright, so I guess I'm not about to convince you. So what are the alternatives for better turning 9%ers into 1%ers, and pulling in new 9%ers who have a greater likelihood of becoming 1%ers? Rd232 talk 17:02, 1 February 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.

An initiative that doesn't exist

I'd just like to let everyone know, in order to dispel any rumours to the contrary, that Wikipedia:Mediation Cabal 2.0 definitely doesn't exist. Since it doesn't exist, people definitely shouldn't spread the word about its non-existence. Opinions? *smiles sweetly* --Tristessa (talk) 21:17, 3 February 2013 (UTC)

Pardon my frankness, but I think that this idea is really rather dumb. The fake-humor/self-aware-comedy approach you've taken to announcing and explaining it, that's definitely rather dumb, and will serve only to make people not take it seriously. Sven Manguard Wha? 03:31, 4 February 2013 (UTC)

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

Per multiple requests at WP:AN/RFC, this discussion is closed. There is wide consensus that there should be a process for mergers that is similar to WP:RM or WP:AFD. However, as pointed out by the opposes: 1) there is already a process that handles merges at WP:PM 2) the reason for the backlog is the lack of volunteers to do the mergers, 3) merging cannot be simply done by the push of a button or a bot, but requires a volunteer to manually merge the articles 4) similar process have been tried in the past for mergers, but have failed. If the supporters of this proposal intend to go forward with this proposal, they should visit and read the linked processes that have failed in the past and try to address the problems with them before setting up another formal process for merges. -Nathan Johnson (talk) 14:58, 4 May 2013 (UTC)

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.

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)

Survey section 1

  • 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)
  • 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)
  • 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)
  • 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)
  • 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 deckertalk 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)
  • 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)
  • Very Strong Support per proposal. I've thought that myself many times before. Nearly any time I see a merge proposal, it has been around for a long time with no consensus. Occasionally, articles seem to get taken into AFD (without actual intent to delete the articles) just so that consensus can be reached. I would definitely support this! Alphius (talk) 00:27, 23 January 2013 (UTC)
  • Oppose I suspect most people here have never merged two decent-sized articles. If you suggest a merge and nobody comments, then just go ahead and do it! My experience is that lack of boldness is a reason for the delay, not lack of consensus. As many have pointed out, merging is not just a click, and an admin doesn't have time to do it. II | (t - c) 01:13, 23 January 2013 (UTC)
  • Strong support Merges are chaotic right now, and some have been left hanging for years. It should be built like WP:RM, but with a 1-month time limit like an RFC has. -- 76.65.128.43 (talk) 08:39, 25 January 2013 (UTC)
  • Strong Support - I've seen articles tagged as having a merger discussion for over two years and no movement. I've merged one article after a brief discussion myself, but that wasn't a particularly big merger (see Renault 4). Some articles should undeniably be BOLDly merged, others definitely not. Lukeno94 (talk) 15:16, 4 February 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)
    And, to quote the section heading, "Who's gonna do it?" There aren't enough people over at PM to review thousands of (perhaps only slightly) contested merge discussions, so you'll still have a limited subset of participants. Then they'll decide to merge... and nothing will happen exactly like nothing happened with those 150 AFD-endorsed merges I mentioned above. The problem is not at the discussion end. We have thousands of uncontested merges languishing right now. The problem is at the action end. We already know that thousands of pages need to be merged. We do not need more "talking about it". We need more "doing it". WhatamIdoing (talk) 01:01, 23 January 2013 (UTC)
    Help out at Wikipedia:WikiProject Merge. We just have 21 participants signed up there. Currently working on backlog from August 2009. Doing some of these the right way (and fixing things that weren't) can be very time-consuming. I linked another underused bot solution to this project page—see the collapsible box titled Bot-reported errors for manual correction. I worked on one of these. Three articles were merged to create Adidas Sandals, which then was itself merged into Adidas#Sandals. Now I hope some wise guy doesn't come along and suggest that it be split! Wbm1058 (talk) 04:55, 23 January 2013 (UTC)
    1) I think that the process of requesting merges has to be automated and I still think that "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." This is my preferred option because if no one is willing to take on the task of merging then there is little point wasting time discussing the merge. So I would prefer merge proposal, Template proposed merge, holding pen waiting for volunteer(s) willing to carry it out then discussion (say up to three months max -- the proposer can volunteer), volunteer add a template (discuss merge) open for a week. If closed as merge agreed then the volunteers are expected to do the merge within (for example) three months. -- PBS (talk) 12:47, 29 January 2013 (UTC)
    2) But if we are not going to discuss and agree mergers without a clear indication of who is going to do the merger, the if it a merge is agreed, we could have a two stage close "One to close the merge that leave a template saying "merge agreed -- request someone does it and then removes this template parameter |date=Month Year". If after a suitable time period (say three months) it has not been done and so the request is stale, then a bot could remove the template and replace it with one that says "no timely merge done. Merger request closed |date=Month Year. Both these could use hidden categories to inform merge specialists that merges are required and statistics on how many are failing. -- PBS (talk) 12:47, 29 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)
Unfortunately, you can't do mindless, wholesale paste-merges because it screws up interwiki links and similar infrastructure. You need to have a human consider cats (should the source article's name appear in the cats, even though it redirects elsewhere? For many medical conditions and drugs, the answer is yes) and check for interwiki confusion. WhatamIdoing (talk) 01:04, 23 January 2013 (UTC)
I guess my response is, Why not? Whenever there's a merge, its always followed by redirecting the one article to the other. I don't see how mindless copy-pasting would be any different than a proper merge. I feel that copy pasting is not the ideal solution, but in this case I think function trumps form. --NickPenguin(contribs) 17:15, 23 January 2013 (UTC)
I like this line of thinking. My major objection would be that this will in most cases have a major negative effect on the article that the information is being merged into. In my experience the parent article is usually a lot more developed. Swapping a merge for a clean-up doesn't seem like a good trade. Therefor I would prefer it to be done though the talk page and then allow the editors watching that article (who are more likely to have the subject knowledge needed) the opportunity to merge in the new information. AIRcorn (talk) 00:00, 24 January 2013 (UTC)
My practical solution would be to redirect any article with a {{merge to}} tag that has not been challenged at either talk page and that is over ?three? months old to the target page. Then a template can be added to the targets talk page linking to the pre-redirect version and suggesting that there may be information there that could be incorporated into this article. It could possible even cover the function of the {{copied}} template so we don't have to worry about any future license violations when someone does decide to copy information across. It also won't impact the quality of the article or lead to inadvertently introducing redundant information. This should be relatively uncontroversial; if the merge tag is like prod then this is an uncontested merge, otherwise it could be seen as a consensus of one to merge or at worst a WP:Bold merge. The template could be considered a talk page suggestion instead of a banner at the top of the article, so it will not require any further clean-up.
While I understand that in many cases this will simply result in the information never being incorporated my experience with the merge backlog has been that many of these undiscussed merges only warrant a redirect (the information doesn't fit, is already there or there are no supporting references to back it up). It also has the advantage of potentially triggering action from editors who have been watching the page. I have merged articles or removed merge tags only to have someone more knowledgeable on the subject area come along, undo my edit and then sort the issue out themselves. This is an ideal situation in my opinion. It could probably even be automated, leaving the trickier merges to human editors. AIRcorn (talk) 00:00, 24 January 2013 (UTC)
If there isn't an automated listing with many eyes on it, this can easily get to the point where low popularity articles will be redirected by a bad merge suggestion. The redirection at the expiry of an non-participated suggestion should not be automatic, some threshold criteria should be used, if such generic criteria is not met, then it doesn't get redirected, the articles stay separate. And if it is just redirected, a notice should be added like how AFDmerges have {{Afd-merge from}}, at the destination talk page, to indicate that a redirect was emplaced without a merge actually occurring, due to an expired request that was a no contest outcome due to no participation.

Bot-assisted solutions

Good discussion. It was suggested above that I, as operator of RMCD bot could help by writing a bot. I've been lurking on this topic and sleeping on it. In my view the primary issue to be resolved is the large backlog of proposed and—to a lesser extent—approved mergers (see {{Afd-merge to}} and Category:Articles to be merged after an Articles for deletion discussion, and Wikipedia:Merge what?). The goal of any new bot-assisted system would be to assist or enhance the existing WP:Proposed mergers system rather than disrupt it. My first step will be to attempt to revive an existing bot solution. Wikipedia:Proposed mergers/Log has been inactive since mid-2011 because the piece of RFC bot that maintained this automated list of proposed mergers was misbehaving and shut down. I'll see if I can fix the problem and get it running again. Then the next step would be to see if any tweaking of it would be helpful. – Wbm1058 (talk) 19:36, 22 January 2013 (UTC)

I think it'd be better if we just add a new template like the RM talk template, that will flag the bot and tell it which pages are under consideration. Then a new listing for all new merge requests that use the new template could be done. (This would have the added benefit of a template indicating that a merge discussion is open, instead of not knowing whether it was active or not) -- 65.92.180.137 (talk) 04:55, 28 January 2013 (UTC)
I think it important the the bot places templates on the talk page. The reason for this is if the bot places the "merge to" template into article space and it is reverted, then the last thing we need is a bot getting into an edit war over placement of the merge to template. Placement and editing by a bot on the talk pages is far less likely to raise hackles and leaves a permanent record on the talk pages of previous proposed merges.
I think the better model is to follow the placement used in mutli-page moves at WP:RM. A used creates a section on the talk page of of the target with a template. The Bot does the rest including populating the other pages and the central clearing house page. -- PBS (talk) 12:20, 29 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.

Manual of Style proposal for clarification on BC/AD and BCE/CE date styles

FYI
 – Invitation to participate in an RfC on a proposal at another page.

A request for comment about clarifying the Manual of Style's advice on use of BC/AD and BCE/CE dates, to reduce disputes and confusion, has been opened at the MoS talk page. — SMcCandlish  Talk⇒ ɖ⊝כ⊙þ Contrib. 14:26, 5 February 2013 (UTC)

Full-width (and half-width) characters to standard characters

At Wikipedia:Redirects for discussion/Log/2013 January 16#Ｗｅｓｔｅｒｎ Ｓａｈａｒａ, it has been suggested that full-width (and half-width) characters should automatically lead the user to the title in standard width characters without the need to manually create a redirect.

There are two possible ways to do this:

  1. Use fuzzy matching so that it is still possible to have full-width titles if desired (similar to how capitalisation currently works).
  2. Make the software hard translate the full-width form to the standard width form. It would not be possible to have an article with a full-width character in the title, but the {{correct title}} template could be used as with other technical restrictions if needed.

One possible issue I thought of was articles about the character themselves, but the ones I've looked at already redirect to the standard form (e.g. ａ → A). I don't know of any article with full width characters in the title, or full-width titles that redirect to anywhere other than to the standard-width form.

Do people think this is a good idea? Which method should be used? Are there any other issues?

There was a similar proposal in 2008, but that doesn't seem to have gone anywhere. Thryduulf (talk) 00:16, 23 January 2013 (UTC)

Support either proposal, whichever is easier to implement, with one caveat: there are legitimate uses of full-width characters in titles like ＱコちゃんＴＨＥ地球侵略少女. If we do automatic translation, I think it would be better to restrict it to cases where the entire title consists of full-width ASCII-like characters (U+FF00–U+FF5E), not mixed with anything else.—Emil J. 15:01, 23 January 2013 (UTC)
Support, definitely - hard-coding titles really isn't a sustainable way to do this! #2 seems the best to me, but I'm wondering if there's any other pitfalls beyond the one you mention that we'd need to watch out for. Andrew Gray (talk) 15:59, 23 January 2013 (UTC)
Support either with Emil's caveat, though I can't imagine that there will be many actual examples of it on this wiki. – Philosopher Let us reason together. 17:43, 23 January 2013 (UTC)
Support either: while it has just a marginal effect, it's definitely a timesaver. —Theopolisme (talk) 12:18, 24 January 2013 (UTC)
Support all double-byte versions of the standard ASCII characters (the common ones from the first 128) should autoconvert to the regular ASCII characters. That handles the problems brought up last time, since they're all extended sequeneces. -- 76.65.128.43 (talk) 02:11, 25 January 2013 (UTC)
Support, obviously. — This, that, and the other (talk) 04:49, 25 January 2013 (UTC)
Support per my vote at the RFD, tough I don't know which method would be better for this. Also implement this for Soft hyphens, but for Soft hyphens use method two. Emmette Hernandez Coleman (talk) 12:37, 30 January 2013 (UTC)

Implementation

Has a Bugzilla been filed? —Theopolisme (talk) 22:44, 29 January 2013 (UTC)

I was holding off as I wasn't quite sure what to ask for. Automatic conversion of full-width to normal in page names & searches, but do we want it only for enwiki or for mediawiki in general? Andrew Gray (talk) 14:35, 31 January 2013 (UTC)
Why not mediawiki in general, this is technical a problem with mediawiki. As for which method, we clearly have consensus for this idea, lets focus the deduction which which method to use. Emmette Hernandez Coleman (talk) 15:14, 31 January 2013 (UTC)
I'm not certain that we should ask for more than en.wp, other wikis, particularly the CJKV language ones, may wish to do things differently to us. Thryduulf (talk) 10:47, 3 February 2013 (UTC)
AFAIK no language uses full- and halfwidth characters distinctly; if fuzzy matching were implemented, it would not matter which width a wiki used. Gorobay (talk) 02:38, 5 February 2013 (UTC)
So as I understand it, the desire is for hard translation to standard width from titles that contain only ASCII-like full-width characters (U+FF00–U+FF5E) or a mix of them and standard-width characters. For other titles then fuzzy matching should be employed so that search terms containing full-width characters find articles using standard-width characters and vice versa. Is that correct? Thryduulf (talk) 19:06, 5 February 2013 signature added 01:26, 7 February 2013 (UTC)

Stop linking URL text to other URLs in Wikipedia's emails

I've mentioned this before, and figured I'd try again. I got an email today from Wikipedia regarding donations. And, like just about every other email the foundation has sent out, Mozilla Thunderbird has flagged it as a scam.

This is mostly because the email contains linked text that is a URL, but the link goes to a different, and much longer, URL than the one displayed. Example: If you link the text www.ostrich.com to www.donate-to-the-ostrich-foundation.com, mail clients (rightly) think it smells funny. This aspect of it has been a repeating occurrence.

Adding to the problem this time specifically, the presence of the word "donate" in the same email, and the fact that the link actually does lead to a URL with the word "donate" in it (donate.wikimedia.org, in this case), probably contributes points to the scam score. Then we have the displayed link text that is actually a YouTube URL, something a scammer would likely use to try and get you to click a malicious link. Furthermore, they didn't even use the normal YouTube url, but "www.youtu.be" -- which actually does redirect to YouTube, but, yeah, that looks funny too.

Anyway. I'm not sure if Thunderbird is the only mail client seeing it this way, but I'd be surprised if it was. Are you missing out on participation in donation events due to your donation emails being flagged thusly by certain clients? I couldn't say for sure, but just letting you know. Again. Equazcion (talk) 04:44, 2 Feb 2013 (UTC)

Link forwarding like that is a pretty common way for people to track the click-thru on email campaigns; there was also an open-tracking image that got loaded as well, which likely didn't help Thunderbird's assumption that the email was spam. But to a certain extent, any mass email is going to run the risk of being labeled as spam; it's just the nature of the beast, sadly. EVula // talk // ☯ // 05:28, 5 February 2013 (UTC)
First of all, no, most mass emails are not seen as scams -- there is a difference between spam and scam filters, where scam-flagged emails are those believed to be malicious, rather than merely unsolicited. Secondly, this is an easily fixed problem -- If you want to forward people through an intermediate URL, you can do it without making an email look suspicious. These emails are just exceptionally suspicious-looking in the way they do it. A forwarded link doesn't need to use the URL of the final destination as its clickable text. Have donate.wikimedia.com links display simply as donate.wikimedia.com addresses, or use non-URL links instead (eg. "click here to see our video"). Equazcion (talk) 13:44, 6 Feb 2013 (UTC)

Some points about wikipedia homepage language bar and a note about references

In Wikipedia home page: the first point is that there's a little error (unless meant) in the search bar, when we open the language option box (the one next to the search field box) I've noted that that despite languages - (I'm talking about the ones that I can read their characters) - are sorted alphabetically and are written undefined (English, Español, Français, Italiano, עברית,Português...) except "Arabic - عربي" which is written "العربية": literally "The Arabic" instead of "عربي" and thus it should be positioned after "עברית" (Hebrew) in the drop list - noting that both ع",ע" letters don't exist in Greco-Latin derived languages – so we should discuss this problem. Second one is that both Greek "Ελληνικά" and Armenian "Հայերեն" languages are ignored and totally absent from this drop list, despite both of them being among the most cultivated and human culture impacting countries, while you leave them in the (10 000+) field with unheard-of languages, even if they didn't write enough articles until now, just putting them on the drop list will be a moral push for them to create more articles and pages. Third one is that "Bahasa Indonesia" and "Bahasa Melayu" (I don't read or understand any of them) should be written "Indonesia (Bahasa)" and "Melayu (Bahasa)" and kept in their actual place in the list Fourth one "Hrvatski" the "Croatian" (I don't read or understand it) is pronounced – according to mypoorknowledge– "Khrvatski" (Kh = כ or خ) so it should be positioned after "Italiano" In the whole archive we have to note that some references are completely useless; not anyone that create an internet site with few bucks per month became a reference for an international encyclopedia, so to keep wikipedia credibility we'd better get rid of those pointless references.

Just a note that the ע (Ayin) most definitely does exist in Greco-Latin alphabets as Omicron and O, between N/Nu and P/Pi (just as in Hebrew it's between Nun and Peh. In both Hebrew and Greek, the letter Samekh/Xi separates N and O, but the point remains. -- YPNYPN ✡ 03:41, 5 February 2013 (UTC)
The languages are always sorted by ISO 639-1 code. If you disagree with it, the place to argue is Template talk:Main Page interwikis, but you'll have to have a very good argument for changing it. FWIW Greek (Ελληνικά) is right there between Eesti and Espanol on the main list. 84.13.26.181 (talk) 20:04, 6 February 2013 (UTC)

Geo-targeted Editors Participation

A new project idea on Geo-targeted Editors Participation has been proposed. The new project proposal aimes at experimenting with new ways to increase participation of editors on English Wikipedia from underrepresented geographies where the most likely contribution language for editors is English. We look forward your comments, and participation. Thank you. --Haithams (talk) 18:04, 6 February 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 ChatOnline 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
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 like it too. AutomaticStrikeout (T • C) 02:48, 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)
  • Support Audacity's short version. All the others are far too wordy and no one is actually going to read them. Kaldari (talk) 21:37, 29 January 2013 (UTC)
  • Support Audacity's short version per Kaldari. Keep it short and sweet. KillerChihuahua 17:34, 31 January 2013 (UTC)
  • Support Audacity's short version... except I'd have the "improve this article" link point to Help:Editing or something similar. People generally don't read big blocks of texts. The short notice serves its purpose of pointing out what's special about the page at the moment and nudging people to contribute. It makes editing sound fun. A big block of text with multiple links (which people will presume they need to read) gives the impression that editing is tedious. Let's not scare people away with TMI. Jason Quinn (talk) 18:35, 1 February 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 deckertalk 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)
  • 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?

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 deckertalk 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

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)

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)

Test page

A test page for TAFI's presentation on Wikipedia's Main page is located at:

Northamerica1000(talk) 06:32, 25 January 2013 (UTC)

Refined comment above, per new Wikipedia:Main Page/sandbox test area. Northamerica1000(talk) 04:13, 8 February 2013 (UTC)

Category:All unreviewed new articles

The Category:All unreviewed new articles should have a small but dedicated task force to keep it reviewed in a timely way. A break in my effort on this category meant that it balloned in size. A more organized effort is needed, and meanwhile I would welcome some help.--DThomsen8 (talk) 15:44, 3 February 2013 (UTC)

BabbaQ is adding a lot of articles to that category. Why? Ryan Vesey 21:23, 3 February 2013 (UTC)
I was under the impression that the articles was unreviewed and that this "category" could be added by users to these articles. If that was incorrect then I do apologize. But I dont think I have done anything wrong that would make user Ryan Vesey wanting to "investigate" it. Very odd.--BabbaQ (talk) 22:09, 3 February 2013 (UTC)
No, User:BabbaQ, you can add this tag, but most of the tags are from the new articles creation process, but your articles should have talk pages with appropriate templates. My concern here is to get more editors doing the work.--DThomsen8 (talk) 23:12, 3 February 2013 (UTC)
The tag shouldn't be added to articles alone. The only reason articles exist in that category is because they contained at one point {{Userspace draft}}. This was necessary at the time, because articles newly moved from userspace into article space were not patrolled at Special:NewPages. Now, Special:NewPagesFeed does patrol articles that are newly moved into the article space. I suggest that we completely modify {{Userspace draft}} to read the same as {{User sandbox}} when it is in the article space, it no longer serves the purpose it once did. Ryan Vesey 18:44, 7 February 2013 (UTC)

Why not make the watch option in the icons representing Village Pump sections work differently?

When you get to the Village Pump main page you have 5 icons for the 5 sections. Each proposes three options: post, watch and search.

But the way the watch option behaves is not logical: if you are already watching that Village Pump section it is simply redundant. It would be better that it be a toggle watch/unwatch. If you are already watching that section then unwatch should be displayed as an option and the option should be to remove that section from your watchlist. (Incidentally, is this proposal more appropriate for some other Village Pump section?) Signed: Basemetal (write to me here) 21:46, 27 January 2013 (UTC)

SupportI think this will ad functionality and usability to the itnerface, and shouldn't be too har to implement. Retrolord (talk) 10:46, 29 January 2013 (UTC)

Oppose. Waste of developer time with a marginal, insignificant benefit. If you know how to get to the Village Pump, you should be competent enough to manually unwatch a page. —Theopolisme (talk) 22:42, 29 January 2013 (UTC)
Then why have those options in the first place, since in every case "If you know how to do blah you should be competent enough to do blah"? None of those options is crucial. Every time there is another less convenient way to accomplish the same task. Once you start providing options and shortcuts, at least they should work logically and consistently. The benefit may be marginal on this issue and on every such individual small issue but this sort of reaction as yours in every case the interface starts looking more and more incoherent, with the rationale that each time the benefit would be marginal, will result in the end in lots of loose ends and an unpleasant experience overall.
It is not a "waste of developper time" to tie loose ends and to make an interface work in a tighter, more logical way. On the contrary letting such inconsistencies accumulate is what should not be allowed to happen. Your argument reminds me of someone who would consider that putting some used pair of socks into the laundry basket doesn't justify the effort, it's soon enough to pick them up from the floor just when they're about to do their laundry, which may be true for each one pair of used socks individually, but before long their floor will be littered with used socks the picking up of each one of which provided just a "marginal, insignificant benefit". Signed: Basemetal (write to me here) 07:39, 1 February 2013 (UTC)
Two more observations: the goal of my proposal was as much providing a shortcut to unwatching a page as making an option behave in a more logical way. If you do not like watch turning into unwatch, then how about if the watch option disappeared as soon as the page was already watched? Either possibility seems better than the way it currently behaves. Or maybe you actually like the fact that that option behaves in an illogical way?
The second observation is just the type of arguments people often use to oppose or to support proposals. "Waste of developer time". The question was basically "Would you like it better if you had an unwatch option when the page was already watched? Would you agree that it would be a more logical behavior? Or do you actually like the fact that when the page is already being watched the watch option is redundant (i.e. useless)"? That was the real question. Optimal allocation of developer time is a wider issue which is best tackled based on the whole picture of development needs, not for every micro-issue on a case by case basis.
I can't help but find comical arguments used by many (including me probably here and there) who like to micromanage, deeply worry about developer time each in their own corner. My considered opinion is that the most effective strategy in such discussions is focusing narrowly on the issue at hand rather than each participant getting involved in issues that are best tackled in a wider context. Let developers worry about how they organize their time. It's our job to make the proposals and it is their job to see where the priorities lie and which proposal is more important and which less so. Signed: Basemetal (write to me here) 08:17, 1 February 2013 (UTC)
It's our job to make the proposals and it is their job to see where the priorities lie. 'Us' and 'they' are one and the same in my case; it just didn't seem to make sense to me at first glance. Or maybe you actually like the fact that that option behaves in an illogical way? No need to get pushy. I think you definitely have some good points in your tl;dr above, but, frankly, this doesn't seem to be a used sock. The [watch] link is simply a convenience, and developing an entirely new method to add two characters seems to outweight the pluses. One could easily write some javascript to make the change, but a slower page load doesn't seem to be worth it. —Theopolisme (talk) 21:15, 3 February 2013 (UTC)
I do not know how much developer time it should take, but from the look of it, it appears a few lines of code (not more than dozen more) would be sufficient to make the change. As for the benefit proposed by this, I think having more consistency in how things behave would be considerably useful compared to the marginal amount of work required for implementing it, and a the few milliseconds extra that the page takes to load. So I'd Support this proposal. TheOriginalSoni (talk) 11:54, 9 February 2013 (UTC)

Customized Welcomes

Here's an idea for welcoming new users (especially considering the latest report about most new users being greeted with automated warning templates. How about if new users were given customized welcomes, either by a bot or by people reading a bot-prepared list? For example, if someone with a French-sounding username edits an article about a museum, we invite him/her to Wikipedia:WikiProject Museums, Wikipedia:WikiProject France, and suggest some French museums in need of improvement. We could even give an invitation to look at the French Wikipedia. Thoughts? -- YPNYPN ✡ 04:44, 5 February 2013 (UTC)

Basing a welcome on their actual edits, rather than what their username "sounds like", would probably be a better idea... though, for the record, I do think tailoring the welcome templates is a good idea. EVula // talk // ☯ // 05:19, 5 February 2013 (UTC)
I sometimes tailor my welcomes by adding a wikiproject that's relevant to their editing. It is a lot of faff to do that manually but if someone could do that programmatically I'd happily use a welcome that included a line promoting any wikiproject that was relevant according to the articles categories or talkpage templates. That would only work for writers of new articles if like me you are welcoming someone whosse new article you'd just categorised, but it would work for most of that majority of newbies who start by editing existing articles. Otherwise the real point I'd make from that survey is that we aren't welcoming enough good faith newbies. Better in my view to welcome someone for their first good edit than start them with a warning for adding unsourced data. ϢereSpielChequers 15:19, 8 February 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_98&oldid=1192827790"
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy