Jump to content

Wikipedia:Village pump (proposals)/Archive 113

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, 215

Make article titles case-preserving, not case-sensitive

Currently, the title of a Wikipedia article is case-sensitive except for the first character. This means allows articles like Gentleman's Agreement and gentleman's agreement to exist side by side. (If there is more than one place where a letter after the first might be capitalized, there can be more than two similarly titled articles.)

I submit that:

  • Instances where this is actually useful are quite rare.
  • Most computer searches, including Google's, treat words and phrases case-insensitively, so that's what most people will find obvious.
  • Library catalogs likewise access titles case-insensitively (indeed, the ones I'm familiar with don't even preserve the case of the original title).
  • The idea that in Wikipedia the first character is treated differently is additional level of non-obviousness, but does not cause any major problems.

On the other hand:

  • Disambiguation of similar article titles by suffixes like "(film)" or "(aviation)" or "(politician)" is common on Wikipedia and easily understood, and could easily be applied to cases like the example by renaming to "Gentleman's Agreement (film)" or "gentleman's agreement (concept)".
  • Indeed, in a number of cases the lower-case article is a disambiguation page that might as well have been named using the standard suffix "(disambiguation)".
  • In cases where such similarly titled articles exist, there is generally a hatnote pointing from each to the other. If the reader who opened gentleman's agreement wanted Gentleman's Agreement, their experience by following the hatnote will be no different if it points to "Gentleman's Agreement (film)".

I therefore propose that article titles should become case-preserving but no longer case-sensitive. Obviously this transition can't be done in a single step, but I propose the following sequence of steps to achieve it (note: I've edited this from my original posting, where I did not quite get it right).

  1. By "canonical name" I mean the lower-case form of an article title. Change the software that interprets URLs and implements the search blank so that if there is no hit on an article name as given, then the canonical name is tried.
  2. By "special redirect" I mean a redirect from the canonical name of an article to its actual name, e.g. from "william lyon mackenzie king" to William Lyon Mackenzie King. Change the article-creation software so that (1) when an article is created or retitled, if its title is not already in canonical form and there is no existing article with the canonical form of the title, then a corresponding special redirect is also automatically created; and (2) no further articles with the same canonical name as an existing article can be created, except for special redirects. Simultaneously change the editing software so that if an article is already a special redirect, it cannot be edited.
  3. Using a one-time bot, find all cases where the article title contains a capital letter and the canonical name is not already used for an article, and create a special redirect. If there are multiple articles whose canonical name would be the same, but no existing article whose name is the canonical one, the bot should create only one special redirect, making an arbitrary but sensible choice as to which one it redirects to: perhaps to the largest of the existing articles, or the one with the longest version history, or the one with the fewest capital letters in the title.
  4. Start a project where people would identify articles whose titles differ only in case, and retitle at least one of each such pair (or group), adding or cleaning up hatnotes as necessary. Redirects to other capitalizations of the same name, except for special redirects, can be deleted during this process. Once the process is complete as well as the above technical changes, the desired effect has been achieved.
  5. When this is complete, the final optional step is to clean up the article database to eliminate the special redirects. To do this, the database would be changed to make the canonical name the primary key for accessing each article, with the actual (case-preserving) title stored as an additional data item.

In writing all this, I primarily have English in mind, but of course the same would apply to titles in other languages that have the concept of case—and I guess to Wikipedias in all languages.

That's all I have to say. I don't plan to get involved in any way with the project I'm proposing, and if the Powers That Be think the whole idea is a non-starter, that's their prerogative. But I think it's a clear win, and I think the sequence I've set out should avoid situations where "you can't do that". Given that case-sensitive titling has always been kind of unexpected, I was actually a bit surprised that I didn't find it on the "perennial proposals" page; but I didn't, so I'm proposing it now.

--50.100.189.160 (talk) 06:09, 20 July 2014 (UTC)

  • Support! In principle, I think this is a fantastic idea. Imagine all the redirect-cruft from variant capitalizations that could be swept away forever!
⋮
I do have a quibble or two with the proposed implementation. For example: for the same reason that the "eBay" article is technically at "EBay", the "canonical" version of an article title should be the "display" title rendered entirely in lowercase, except for the first character, which, if a letter, should be in uppercase. This would not only accommodate the existing technical requirements of the MediaWiki software, but would also have the additional benefit that the vast majority of articles' "canonical" and "display" titles would be identical, in which case no "special redirect" would be necessary. Also, it would be worth considering that if a URL containing the name of an article incorrectly capitalized were followed, then MediaWiki would respond with an HTTP redirect, using either status code 301 (Moved permanently) or 303 (See other), to the URL with the article name capitalized correctly (i.e., matching the article's "display" title)—rather than accepting the misspelled URL and presenting the article page with a "(redirected from …… )" hatnote.
⋮
One hurdle to overcome will be the fact that usernames are case-sensitive, and it would not be feasible to make the "User:" and "User talk:" namespaces case-insensitive—at least, not to the left of the first "/" character. I also anticipate some grumbling about the special role of ALL-CAPS titles as shortcuts to things in namespaces such as "Help:" and "Wikipedia:". I'm not sure how much of a "collision" problem there would be if these namespaces were rendered case-insensitive, but my guess is that the number of WP:SHORTCUTS that share a spelling with a non-shortcut page to which they don't redirect (or both don't redirect to the same target) is very, very small.
⋮
In sum, while the implementation would be non-trivial from a technical standpoint, much of it could be automated, and my intuitive impression is that this change would be warmly welcomed by our readers and editors. — Jaydiem (talk) 22:14, 21 July 2014 (UTC)
  • Just to amplify what I said earlier about "redirect-cruft": A quick look at Category:Redirects from other capitalisations finds that it contains a mind-boggling 397,446 redirects, of which I'll bet at least 99% are completely pointless. And that number doesn't include what must be many more such redirects that exist but aren't linked to the category. We are talking about something on the order of half a million redirects that could be completely done away with by adopting case-insensitivity. It's a beautiful thing! — Jaydiem (talk) 07:19, 22 July 2014 (UTC)
  • Support These seems like it could solve several conflicts as well. I believe one of the reasons why sentence case article names makes sense is because when articles are linked in sentences it goes to the case linked. If we made them all equivalent it could mean that we could use title case for article names without requiring redirects or pipes in the links. This would allow some of the recent capitalization style differences of opinions to be less important. I think in addition to folding letters, certain symbols should be folded together as well. For example treat "-", "/", "–", and "—" as interchangeable when resolving the page. This means that the correct hyphen, or dash can be used in a title but that it could be found with the standard hyphen-minus character. It could also solve the upper vs lower case first character issue. I'm not sure we need to use 301 or 303 codes. I might suggest making the canonical URL always be the lowercase forum ( etc. ), and just store the preferred capitalization along with the article either internally as a separate data field, or similar to how article names are handled inline for lowercase letters. In which case all interwiki links should always then go to the canonical forum. PaleAqua (talk) 03:20, 22 July 2014 (UTC)
  • Oppose. Instances where disambiguation can be provided entirely via capitalization are not rare - they generally occur when a common noun is appropriated by an organization or creative work as its name. No need to add extra bulk (which also makes wikilinks to those articles more annoying to create as they must be piped). -- King of ♥ ♦ ♣ ♠ 03:49, 26 July 2014 (UTC)
  • Support Also makes it easier to create 1:1 relationships with articles in different languages and clarify differences for non-native speakers. 184.77.68.158 (talk) 04:51, 30 July 2014 (UTC)
  • Oppose per King of Hearts; situations in which capitalisation differences are significant are extremely frequent, and this proposal (if I understand rightly) would get rid of all of them. Nyttend (talk) 18:36, 5 August 2014 (UTC)
  • Support The use of capitalization alone is a rather ambiguous form of disambiguation. Other disambiguation conventions, including hat notes and parenthetical suffixes are clearer. The case-sensitive search function has been a minor irritation since I started editing Wikipedia. It would be far better if it behaved like every other computerized search engine and index I've used, which would be the result of article titles becoming case-insensitive. G. C. Hood (talk) 05:03, 6 August 2014 (UTC)

Reporting on Suicide

I propose that Wikipedia follow http://reportingonsuicide.org/Recommendations2012.pdf. I saw a couple of articles using successful/unsuccessful when referring to suicide. I don't see any downside to following the guidelines and much upside. 184.77.68.158 (talk) 21:08, 29 July 2014 (UTC)

  • Support Seems like something that would make sense to be considered in the WP:MOS, etc. PaleAqua (talk) 21:50, 29 July 2014 (UTC)
  • It's not a guideline, but there's a user essay on articles covering suicides. I think you'll find that some of their suggestions work well with (or as served already by) our content guidelines and practices, but that link could surely be added to the essay (at least) to frame it as a public health issue. Protonk (talk) 21:54, 29 July 2014 (UTC)
  • Clarification Including the considerations such as it being a public health issue certainly sounds like something to include in the essay. I was more focusing on using the term "success" with suicide, which does seem like a Manual of Style issue. Is there a project that might undertake integrating the recommendations as appropriate? 184.77.68.158 (talk) 23:19, 29 July 2014 (UTC)
    Maybe WP:Wikiproject Biography would be a good place to suggest that. As an aside, they recommend how to sidestep "succeed", but how are you supposed to sidestep "failed"/"was unsuccessful" without being unclear about the outcome? "Such and such attempted suicide but survived"? Seems like a weird way to put that. (This sort of discussion can probably go into WT:MOS, of course, but I'm just curious as to what the recommendation is actually supposed to be) 0x0077BE [talk/contrib] 01:38, 30 July 2014 (UTC)
    I changed the one I saw to "did not die." The alternative might be to describe the actual result like "was hospitalized." There apparently is a WP:WPSUICIDE. I don't know how active it is. 184.77.68.158 (talk) 02:52, 30 July 2014 (UTC)
    "To attempt" suicide seems adequate. In typical usage, the verb implies, but does not explicitly state that the task attempted has not been completed. It seems that the subject's survival would be clear in biographical articles. In other contexts, one might distinguish an "attempt at suicide" from a "suicide". G. C. Hood (talk) 05:35, 6 August 2014 (UTC)
  • (edit conflict)I can think of no reason not to include this in the MOS. It probably needs some work on altering from a newspaper emphasis, eg headline guidelines should probably instead be about section headings, and the stuff about quoting first responders or noting trends are certainly not applicable. But a lot of it, like not including pictures of the suicide location, seem like good MOS material. I'd suggest starting up WP:Manual of Style/Deaths as a proposed member of Category:Wikipedia Manual of Style (content), and run an RfC on getting this to guideline status. VanIsaacWScont 23:24, 29 July 2014 (UTC)
  • You might be able to add something like this to a relevant section in WP:WTW or WP:MEDMOS. WhatamIdoing (talk) 04:39, 31 July 2014 (UTC)
  • Maybe While I support that it would be a great idea to add this to WP:MOS, it would need to be done in such a way that it wouldn't compromise the meaning of the article. For example, if there was an article on Hitler, it would be somewhat difficult to avoid the topic of his suicide. Yes, I absolutely agree that wikipedia should be sensitive to this topic, but it should not compromise the integrity of the topic in question. But it would be a good idea to introduce some sort of policy on the mater, so that when these situations arise, there will be a shift to a better method of presenting these sort of situations. Jab843 (talk) 02:47, 5 August 2014 (UTC)
  • Partial support. The first, third, and last points on the "Do this" list seem reasonable, and agreed terminology would be appropriate for the MOS; however, Wikipedia isn't a broadcaster, and shouldn't be making public health interventions suggested in the second, fourth, or fifth points of the "Do this" list. I oppose omitting factual information, such as the contents of a suicide note or comments from first responders, when that information has been published in reliable sources. I'll also clarify that ideas and opinions of suicide are culturally bound, and that the recommendations consider suicide as a public health problem to be discussed. I caution against the legalized assumption that suicide is a sign of mental illness. In many cultures, and many circumstances, suicide has been accepted as the result of a rational decision. To insist or imply otherwise would be an example of both WP:RECENTISM and a culturally-specific WP:WORLDVIEW. G. C. Hood (talk) 05:35, 6 August 2014 (UTC)

Allow "suppressredirect" and "move-subpages" within userspace

I would like to request that autoconfirmed users be granted the suppressredirect and move-subpages permissions for moving pages entirely within the subpage hierarchy of their own User: and User talk: pages.

I am aware of WP:Perennial proposals#Grant non-admins admin functions within their user space, but the main objections highlighted there appear to relate to the potential for vandalism committed through nefarious page deletion. This proposal does not have that problem, because (a) it does not grant the ability to delete any pages, and (b) its scope is limited to moves that both originate and terminate within the user's own userspace. This change would significantly benefit those who do a lot of page development in their userspace, and I can't think of any collateral damage that it would cause.

Respectfully submitted, — Jaydiem (talk) 16:00, 24 July 2014 (UTC)

  • Support if it wouldn't require much dev time to implement. Doesn't seem very prone to abuse, trying to imagine how this could be used nefariously, this is the best I can do: Move page you want to hide to userspace, then move it with suppressed redirect to another userspace name, then create a new page where you first moved it, so that the automatic redirect from mainspace would lead to a normal looking page, with no indication of what happened in the page history. The record of the 2nd move would still be fully visible to anyone who bothered to look at the logs for the page, though the log wouldn't be displayed by default once the new page was created. Also, it would be very obvious what happened to anyone with the original page watchlisted. All in all, I think the convenience factor outweighs the rather minimal risks. Monty845 16:30, 24 July 2014 (UTC)
  • Unless there are dev issues, no reason not to do this. Writ Keeper ⚇♔ 16:32, 24 July 2014 (UTC)
  • Support if not too much work for the devs. Also, I presume that these rights would also be enabled in the User talk: space? I.e. to move talk pages of moved articles, to clean up talk page archives etc? BethNaught (talk) 16:09, 25 July 2014 (UTC)
  • Yes, absolutely, the intention here is for the same rules to apply in the "User:" and "User talk:" namespaces. I'm adding this to the proposal statement for clarity, thanks. — Jaydiem (talk) 17:13, 25 July 2014 (UTC)
  • The only problem I see is when these pages are essentially draft articles--it is still permitted to use these, instead of the Draft namespace. DGG ( talk ) 00:40, 26 July 2014 (UTC)
  • Support Sensible proposal. -- King of ♥ ♦ ♣ ♠ 03:44, 26 July 2014 (UTC)
  • Support with concerns Seems mostly reasonable. However, and trying to avoid beans here, I can see a possible way that this can be used to trick pages into being deleted under a speedy criteria, that might bypass causal checking and could be tedious to undo. Though I'm not so sure that a would be vandal would have the patience required to do it. PaleAqua (talk) 06:57, 26 July 2014 (UTC)
  • Support if there is some restriction in place to move pages in article space to user space. --Fauzan✆ talk✉ mail 02:38, 27 July 2014 (UTC)
  • Support suppressredirect, oppose move-subpages - I would expect that the number of subpages would be small enough to not require a mass-move; and this lends itself to server overloading by bad-intentioned users. suppressredirect, on the other hand, causes almost no problems. עוד מישהו Od Mishehu 20:00, 27 July 2014 (UTC)
  • Support in principle, but I doubt this is ever going to be implemented in the MediaWiki software. — This, that and the other (talk) 10:40, 31 July 2014 (UTC)
  • Support as long as the suppressredirect only works when you've moving a page that's already in userspace; if we move Cheese to User:Jaydiem/Cheese (to make an absurd example), Cheese shouldn't be suppressible, but once you re-move it to User:Jaydiem/Paprika, the cheese title should be suppressible. I don't expect that this would easily be abusable as Od Mishehu fears, unless it's done by someone who's abusing an unapproved bot to create tons of userspace pages, and that's so unlikely that it would be unhelpful to lose such a feature just for that reason. Nyttend (talk) 18:46, 5 August 2014 (UTC)
    Your example is actually a possible abuse scenario: moving Cheese to User:Jaydiem/Cheese with redirect and then on to User:Jaydiem/Paprika without redirect will leave Cheese as a broken redirect. That said, figuring out what happened and repairing the damage is not too much more difficult and usually doesn't require more rights than if a vandal just blanks Cheese. — HHHIPPO 07:00, 6 August 2014 (UTC)

Next steps

Tracked in Phabricator
Task T71162

Assuming it's agreed that there's a consensus to support this proposal, what would be involved in its implementation? Would modifications to the MediaWiki software be required, or are existing configuration options for granularity and context-sensitivity of user permissions sufficient? — Jaydiem (talk) 06:54, 1 August 2014 (UTC)

Filed a request at Bugzilla --Mdann52talk to me! 07:56, 6 August 2014 (UTC)

Deprecation of Wikipedia:Requests for comment/Request board

A proposal to discontinue use of the RfC request board is being discussed at Wikipedia talk:Requests for comment. G. C. Hood (talk) 08:28, 6 August 2014 (UTC)

Proposal: limit the extent of automatic archive options to prevent the use of automatic archival in censorship.

Within the broad range of subjects in Wikipedia there are those that are some that are more controversial and some that are less controversial; some that have contents that have higher levels of complexity or which could be approached from a variety of different angles and some that have little complexity and which have one clear way in which they would be best explained.

Wikipedia is also an environment in which numbers of articles are increasing and in which the number of editors is not keeping pace.

At the present time automatic archival bots work in a way that they can comply with requests to archive topics have been untouched for a specified length of time with a potential that the period of time may be very short (I'm not sure if there is ever any lower limit). They begin to work in talk page situations in which a certain number of sections have been added and, again, the number of sections can be very low.

We are left in a situation in which people can just chose not to reply to and an issue knowing that the bot will act as a censor that places materials in dead topic vaults that are inconducive to further development. Can bot potentials be limited and/or can information links that are displayed, when a bot is used, connect to sources of information on settings that should be used in various situations?

The good information in Wikipedia:Talk page guidelines includes a section on: When_to_condense_pages which says: It is recommended to archive or refactor a page either when it exceeds 75 KB, or has more than 10 main sections. In the case of controversial or complex topics I think that archial should not begin until 8-10 sections have been added and that subjects should not be archived unless they have been added to in the last 90 days. — Preceding unsigned comment added by Gregkaye (talk • contribs) 04:21, 6 August 2014 (UTC)

  • Archiving would seem to be an unlikely censorship technique. If implemented as per WP:Archive, the archived material is both unchanged and searchable. The functionality of archiving bots is certainly something that could be discussed, or experimented with, but I don't see a need for new or changed policy at this time. G. C. Hood (talk) 05:43, 6 August 2014 (UTC)
  • I have seen people claim that archiving talk pages is "censorship", but invariably such claims were illfounded. First, a dictionary needs to be checked to discover the meaning of "censorship" (it's got nothing to do with a stale discussion or archiving). Second, if a proposed edit does not have consensus, it is not made in the article, and repeating the proposal or resisting the archival of the discussion are not helpful. Johnuniq (talk) 05:56, 6 August 2014 (UTC)
  • Can you cite where and to what extent the claims are illfounded. I am not saying that topics are removed from access from Wikipedia but that they are removed both from active debate and from active talk page locations in which people are more likely to read content. Would a word other than "censorship" be better used? In the way the current system works a potential reward is provided to forms of Stonewalling type activity even with a potential involvement of Conspiracy of silence. The result of inaction can be a more rapid sidelining of a raised issue. No person need be directly involved in exclusion. A bot does the work automatically. Gregkaye (talk) 09:45, 6 August 2014 (UTC)
  • It's not important for this discussion, but "censorship" has a specific meaning (per standard dictionaries), and that meaning is unrelated to the issue described here. In general, a proposal needs to be backed with examples of where it would be helpful because rules are not made unless there is good reason. Are there any examples where this would be helpful? Johnuniq (talk) 10:43, 6 August 2014 (UTC)

Link from an old revision to its point in page history

Current introduction to an old revision
This is an old revision of this page, as edited by DePiep (talk | contribs) at 23:01, 8 March 2013 (respell check: stressed syllable in capitals. using AWB). It may differ significantly from the current revision.
Suggest appending this
View page history starting at this revision backward.
Reason
Eliminate the need to browse history in pages, whether the edit activity is high or low. Navigation controls only makes jumping to whole months possible, but this way one will arrive at the desired point in history immediately.
Notes
The page name is an example. Iceblock (talk) 20:37, 5 August 2014 (UTC)
Let me get this straight — you only ask that we add a history-from-this-point link to the top of an old revision of a page? If that's what you mean, I have to say that this should have been proposed years ago; it's a great idea, and I'm surprised that I've never heard of this before. It would save me tons of work, and I'm sure the same is true for many other people as well, and all without causing any substantial difficulty. Nyttend (talk) 01:50, 6 August 2014 (UTC)
Yes, that's what I ask for. Iceblock (talk) 16:27, 6 August 2014 (UTC)

Mission(s)?

I suggest to create a panel with missions for new comers to learn more about what is wikipedia, how to edit... Any one wants to work with me about this?--Gabrielchihonglee (talk) 02:34, 6 August 2014 (UTC)

Does Wikipedia:Welcoming committee not meet your needs? --Jayron32 02:49, 6 August 2014 (UTC)
@Jayron32:As we know, http://baike.baidu.com/ is one of the China famous copier from Wikipedia, they copies Wikipedia's content to their wiki but still, they have tons of active users and newcomers. I watched them for some time. I found that one of their skills is to use missions to make user learn and edit. You may create an account and see http://baike.baidu.com/uc/task .--Gabrielchihonglee (talk) 03:29, 6 August 2014 (UTC)
What definition are you using for mission? Ntsimp (talk) 04:02, 6 August 2014 (UTC)
See an example from baidu http://www.clipular.com/c/6193820676915200.png?k=EjL20fIIlW88tBd2LI4wwIfdW5Y use google translate to translate it.--Gabrielchihonglee (talk) 05:29, 6 August 2014 (UTC)
Translation by Google but which will affect the code :( http://www.clipular.com/c/5846458435633152.png?k=UZuVNryzYCncmsScD0LzEy-IrMo --Gabrielchihonglee (talk) 05:31, 6 August 2014 (UTC)

Any supports?--Gabrielchihonglee (talk) 13:19, 6 August 2014 (UTC)

Requests for comment on meta --Gabrielchihonglee (talk) 03:10, 7 August 2014 (UTC)

Words to watch - automatic tools

An important manual of style, Wikipedia:Manual of Style/Words to watch, explains what are the words or expressions a editor must use with caution. Many users, especially new users aren't aware to manual of style or don't read it - so it is important to integrate software tools with editing interface so when user use such expression they should be aware to possible problems.

In Wikimania hackathon we wrote a tool for it: It shows Clippy when an editor writes one of the "words to watch" (in VisualEditor):

Screenshot

We would like to ask the community to extend the list of words to watch: Wikipedia:Manual of Style/Words to watch/Config so our tool (and other similar tools) can integrate manuals of styles in the editing interface itself. Eran (talk) 09:27, 7 August 2014 (UTC)

I think that User:Dank might be able to provide some useful feedback. WhatamIdoing (talk) 22:14, 7 August 2014 (UTC)
Can we do a regex or lua search, or can we only search for strings? - Dank (push to talk) 22:29, 7 August 2014 (UTC)
Wait... Clippy? Nooooooo.... Herostratus (talk) 22:31, 7 August 2014 (UTC)
It can be merlin instead of clippy ;)
Yes it supports regex too not only simple string search. This can be tested by editing Special:MyPage/common.js and adding:
$.getScript('//wiki.riteme.site/w/index.php?title=User:%D7%A2%D7%A8%D7%9F/WeaselWords.js&action=raw&ctype=text/javascript');
Eran (talk) 23:49, 7 August 2014 (UTC)

Combine welcome with invitation to Adventure

New users may get welcomed by a human, often with a template listing guidance articles; but it is now about equally likely that User:HostBot will invite them to play the WP:Adventure game; some receive both messages. Both offer some induction to Wikipedia in their different ways. The two will appeal to different cross-sections of editors. Why not make it standard practice to offer both together?

A small study indicates that human welcomers are not very good at distinguishing "good" from "bad" editors, but that the selection of who gets the Adventure invite doesn't discriminate at all. It could do little harm, then, for the two messages to be combined. A template could be designed to say, in essence: "Welcome! Here are links to wodges of text you can read, or if you prefer here's a link to an interactive game-style activity". Then new editors could decide for themselves which approach would suit them better at the start. The combined template could be sent equally by a human welcomer or by HostBot: best though if the bot could be programmed to only post the template where the talk page was blank, to avoid duplicated welcomes and also avoid inviting already warned vandals.

Benefits

  • More new editors given a list of guidance to read.
  • More new editors offered participation in the Adventure.
  • New editors get the chance to choose between these two contrasting ways to start learning about WP.

Drawbacks

  • Can Adventure cope with extra traffic, including from some whom the HostBot programmers may not have chosen to invite?
  • A welcome from HostBot doesn't offer a human point of contact (though WP:Teahouse invites do offer this).
  • Development work to design a series of "Welcome/Adventure" templates.
  • Need to inform anyone who does welcoming.


: Noyster (talk), 11:22, 7 August 2014 (UTC)

Discussion

  • Support - good idea!!! I am all for it!!!....point I like to make just for a debate see what other think.... Wikipedia:Contributing to Wikipedia is the best place to start in my opinion (The parent article if you will). It leads to all other intro pages, thus editors can decide which way they wish to learn. Very hard to get people to keep clicking to other pages to learn the way some may prefer. A static page where editors can chose the topic to review (like "Images" or "Citing sources")...I think is best. All that said the idea above and adding "The Adventure" to {{Welcome}} and its many variations Wikipedia:Welcome templates can only help editors in the long run. --Moxy (talk) 13:18, 7 August 2014 (UTC)
  • Biased support: I've wanted to do this for a while and would be happy to help implement it. We've received excellent feedback from editors who have used The Wikipedia Adventure and I'd love to expose more new editors to it. Cheers, Ocaasi t | c 11:00, 8 August 2014 (UTC)

Add a Contributions tab

Add a [Contributions] tab between the [User page] and [Talk] tabs. --82.136.210.153 (talk) 12:07, 6 August 2014 (UTC)

Do you mean at the top left of the page? I don't think that would be helpful, both because we've got the Special:Contributions link in the toolbox when on a userpage (down below, at left), and because it would change the horizontal space requirements for all the other tabs. Nyttend (talk) 12:41, 6 August 2014 (UTC)
Such weird reasoning, Nyttend. It would not be helpful because there's already a link to it somewhere else? And it wouldn't be helpful because it would change space requirements? I don't understand how you cannot see that's weird reasoning. Anyways, it would be helpful because it would improve usability: the Contributions will be easier to find (at the very least for non-veterans) and are better accessible from more locations. Editors' contributions are the core of Wikipedia. Editors introduce themselves (User page), you can talk with them (Talk page), and they contribute to Wikipedia (Contributions). --82.136.210.153 (talk) 17:33, 6 August 2014 (UTC)
What Nyttend means to ask you is this: Is getting a very prominent, duplicate user "Contributions" tab important enough to you to have the page "History" tab hidden for many users? Re-size your browser window to make it narrow, and wait a second or two. You'll see the history tab disappear (also "New section", for pages that have that tab) when the screen gets too narrow to display them all. Adding a "Contributions" tab will make that happen more often (because it takes up more space). WhatamIdoing (talk) 22:18, 7 August 2014 (UTC)
Again, just technical stuff. The first question to answer is: would it be helpful to have it up there. I think: yes. What should happen on smaller screens? The easiest solution: don't show this extra tab on smaller screens. Many other solutions exist, where things are either not shown or moved to either other locations or into (sub)menus. Anyways, never mind. If I'm the only person who thinks having a Contributions tab up there would be useful, discussing this further is pointless. ;) --82.136.210.153 (talk) 23:17, 8 August 2014 (UTC)

Create a BOT to alphabetize and organize categories automatically

As someone who has been doing this manually for years, I hereby dutifully beg of anyone who is technically proficient and knows how to create and run a bot that will:

  1. Automatically sort all Categories on each article and category page alphabetically;
  2. Create a uniform system for where to place categories on each article and category page that commence with numbers, such as years of birth/death, centuries, and any category that starts with a number/numeral.

Please see the centralized discussion at Wikipedia:Bot requests/Archive 61#Create a BOT to alphabetize and organize categories automatically. Thank you, IZAK (talk) 09:12, 4 August 2014 (UTC)

Discussion re-opened at VPP

Please see Wikipedia:Village pump (policy)/Archive 114#Create a BOT to alphabetize and organize categories automatically. Thank you, IZAK (talk) 22:49, 5 August 2014 (UTC)

Tech help required to improve categories

Please see Wikipedia:Village pump (policy)#CatVisor and User:Paradoctor/CatVisor#Planned features if you are willing and able to assist this innovative WP project move along it would be greatly appreciated. Thank you, IZAK (talk) 23:33, 12 August 2014 (UTC)

Watchlist: date and reason

I have found that I have a problem remembering the reason that I placed some articles that I put on my watchlist. Therefore I would like to be able to record in my watchlist, the date I put an article there and the reason that I put it there. Jodosma (talk) 19:35, 9 August 2014 (UTC)

You could accomplish this by copying your raw watchlist to a userspace document and annotating it there. --erachima talk 19:48, 9 August 2014 (UTC)
And then you would use the "related changes" link in the tools to track the changes, or leave a link to it on your main userpage ([[Special:RecentChangesLinked/''full name of subpage'']]. עוד מישהו Od Mishehu 05:06, 13 August 2014 (UTC)

Wikipedia Adventure

Not sure where to post this. Could someone think up a way of stopping the invitation bot from inviting users who are indefinitely blocked from taking part in the Adventure? It seems to me a bit pointless, and also a bit of an insult too, as they can't take part. If and when they are unblocked, the bot could then invite them to participate. Peridon (talk) 13:54, 13 August 2014 (UTC)

Any bot that does it. I think it's HostBot. What happens is that a user offends a few times, then gets indeffed, then gets invited to the Adventure. They've usually been welcomed, and warned in varying degrees before the invite lands on the mat. But, without a fairy godmother, they can't go to the ball. Peridon (talk) 14:34, 13 August 2014 (UTC)
  • In the case of HostBot, I know that J-mo is aware of the issue and was working on it at one time. Not sure if that has fallen off his todo list or not, but I've pinged him here a couple times (and you are welcome to leave a TB on his talk page). — {{U|Technical 13}} (e • t • c) 15:00, 13 August 2014 (UTC)
Yo! So, I am aware that this has occurred, and it's generally a case of replication lag with the logging table (which HostBot checks for blocks before inviting). I also parse the page text pre-invite for key words (like "block") before sending invites. But it's an imperfect system and a few will inevitably slip through the cracks. However, I'm not sure that this is a particularly pressing issue, because:
  • A) as far as I know, it's very rare. HostBot has been inviting 100+ editors to the Teahouse every day for over two years now. The process for checking for blocked/banned users before inviting is the same for TH invites as TWA invites. Errors like this are generally pointed out on my talkpage. I don't get them often--maybe once every 4-5 months or so.
  • B) HostBot hasn't sent any TWA invites out for almost three months (for unrelated reasons). The last time TWA invites were sent was May 19th. So, I'm guessing you were looking through stale, blocked userpages for other reasons, and happened upon an instance of this? Or, was it a more recent invite, from a human editor?
That said, I'm always looking to refine the process. Any real life examples you can link me to are appreciated and will help me hunt bugs. Cheers, - J-Mo Talk to Me Email Me 18:31, 14 August 2014 (UTC)

Patrol edits that remove more than 500 characters

Proposal: if an editor who's not a reviewer or admin removes more than 500 characters, mark such edits and patrol them. Even patrolling edits by such users if more than 1000 characters were removed would be a most welcome change. Things like this should not go unnoticed for more than three months. The section wasn't blanked there (so it wasn't tagged) and a bot made an edit approx. 2:04 hours later which meant the vandalistic edit was no longer the latest revision. --82.136.210.153 (talk) 12:19, 6 August 2014 (UTC)

Large edits are already marked; go to the page history and you'll see that 1,249 is given in big bold text, both when it was removed and when you restored it. Are you thinking of something more extensive? Nyttend (talk) 12:28, 6 August 2014 (UTC)
Yes. Not large edits in general, only large removals. And not with just bold text, but Tag them, and then patrol those edits. Are, for example, edits tagged "section blanking" being patrolled? --82.136.210.153 (talk) 12:37, 6 August 2014 (UTC)
I imagine such a patrol would become backlogged almost instantly and never be fully looked through. I don't think we need another such process. Sam Walton (talk) 13:21, 6 August 2014 (UTC)
I think the idea has merit. While I do not have the technical skills to do the check, it shouldn't be hard to figure out how many edits fall into this category. I would even consider making the threshold 1000 characters by anyone who is not yet confirmed or autoconfirmed. If there are thousands in a week and most are false positives, yes it will become useless, but my guess is there won't be that many. My bigger concern is the possible incidence of false positives, where a new user accidentally removes something, then fixes it immediately. If that is common, then false positives may dominate the list.--S Philbrick(Talk) 14:10, 11 August 2014 (UTC)


Really I see no reason to be more vigilant about large removals than large additions. Actually, the latter may need more attention, because someone dumping a large quantity of borderline nonsense into an article is less likely to be summarily reverted by any passerby than a testing-style deletion of a random chunk of text.
This does bring up another point. The problem with the current numbers that show up in the watchlist is that they show you only the net change in the number of bytes. So if someone, say, replaces a good paragraph by a nonsense paragraph of equal length, the change shows up as 0, and people may pass it by assuming that it's a punctuation change or something. What I would like to see is the magnitude of the diffs, both positive and negative. In other words, if the diff adds 123 characters and subtracts 122, then we would see (+123)(-122) in the watchlist line, instead of (+1). --Trovatore (talk) 14:24, 11 August 2014 (UTC)

Yes, the addition of more text is more of a problem than removal. 99% of the "large addition edits" I see on my watchlist from either IP editors or usernames I don't recognise are copyvio issues. Lugnuts Dick Laurent is dead 12:56, 14 August 2014 (UTC)
Especially if the additions are grammatically correct and coherently written. WhatamIdoing (talk) 21:42, 14 August 2014 (UTC)
  Our general usage is so poor that correctness and coherence are a sign of copyvio? That's not good. Reminds me of a line from John Donne's The Perfume about "a good smell".
  I think Trovatore has a good point re net change. ~ J. Johnson (JJ) (talk) 22:43, 14 August 2014 (UTC)
I am sad to say it, but, yes, "correctness + coherence + new user" is a strong (but not absolute, of course) predictor of a copyvio involving an online source. WhatamIdoing (talk) 23:25, 14 August 2014 (UTC)

Satpal Maharaj/ Devine Light Mission

Details mentioned regarding Devine Light Mission should not be the part of Satpal Maharaj.

In any of the record in Govt. of Indian Department , This organization was not headed by Satpal Maharaj.

Satpal Mahraj is founder of Manav Utthan Sewa Samiti - A Non-profitable organization registered as per Society Registration act of India, 1961.

Manav Utthan Sewa Samiti's registration no is S/7341/1974

Devine Light Mission was headed by Prem Rawat.

Mentioning of Devine light Mission under this article is again to vandalize the image of a person.

This should be on the article or project talk page, not here. (Signing so as perhaps this can be archived.) — Arthur Rubin (talk) 01:16, 15 August 2014 (UTC)

Show article quality to readers?

What do people think of showing article quality measurements besides GA and FA to readers on the main article page? It's useful information for readers, as it gives them a rough estimate of how "good" the article actually is. For example, I know I would be more likely to read a B-class article than a start-class article when browsing, or I'd be more likely to trust an A-class article for accuracy than even a GA-class article. StringTheory11 (t • c) 05:41, 9 August 2014 (UTC)

The last discussion on A-class on this board is at WP:Village_pump_(proposals)/Archive_110#Restrict_A_class_usage. That has a variety of viewpoints to get us started. The thing that struck me was: no one talked with the people who work in A-class. We could ask them if you like. - Dank (push to talk) 09:52, 9 August 2014 (UTC)
I never understood why A-class articles don't get a topicon; I suppose a possible reason is that readers can surmise that FA>GA, but not necessarily that A>GA, which seems to me to be a valid but weird system. As for lower ratings, it just creates loads of work updating it, not to mention that often ratings are out of date, or some projects have (for whatever reason, whether specialised criteria or more regular reviews) different ratings.
Another issue is that some articles are A-class quality but will never get a formal review; this puts Hurricane and MILHIST articles at an unfair advantage. I don't support displaying A-class unless these issues can be worked out. BethNaught (talk) 10:21, 9 August 2014 (UTC)
If you are talking about adding the icons of B, C, Start class to the articles just like we have done for GA, FA, then I agree with this proposal. OccultZone (Talk • Contributions • Log) 12:09, 9 August 2014 (UTC)
In my experience, these quality tags are so randomly and carelessly assigned that they are typically all but useless. I've repeatedly had "start" class tags slammed on articles of my own that were perfectly sourced, perfectly correct and perfectly relevant, albeit relatively short, by drive-by taggers who had evidently hardly even read the article. I'd be strongly opposed to giving these tags higher visibility than they have now, unless we also introduce some measure of accountability for the taggers and an expectation that quality tags should regularly come with an explicit and testable assessment of the relevant criteria somewhere. Fut.Perf. ☼ 12:38, 9 August 2014 (UTC)
I have to agree with Future Perfect, most assessments are not worth the electrons they are printed with. In large part this is because the majority of assessments are performed by "reviewers" operating at a rate of 4 to 8 articles/minute in 50 to 200 article bursts. At these rate of speed, it is not reasonable to assume the reviewer has even loaded the article being assessed, let alone that the articles being assessed were read. --Allen3 talk 12:49, 9 August 2014 (UTC)
Also agree - most reviewers seem to judge only on the length of the article and whether it has refs etc. There is rarely any concept that some subjects only need (or, especially in history, can ever have) short articles. Johnbod (talk) 14:16, 13 August 2014 (UTC)
  • Stub-class is noted on the page already. Start-class through B-class are essentially unstandardized and aren't helpful to display. A-class could certainly be displayed, but it's such a niche rating (product of a process used almost exclusively by a set of WikiProjects I could count on one hand) that there has never been sufficient motivation to do so. --erachima talk 12:44, 9 August 2014 (UTC)
I think this is a good idea, but only if the classes are more standardized. Specifically, for each class rating, I'd like to see at least an explanatory edit summary, stating why the article's class was changed. This could take the form of explaining issues the reviewer had with the article, for example. For controversial situations I'd like to see a quality scale assessment on the talk page, going by the criteria for each class. But for that we'd need to set down clear criteria saying what C-class is, what Start-class is, etc. Currently I don't see any list of criteria below B-class.
I also think that A-class is a bit weird honestly. There is this requirement of having a review, but that is only practical for the largest WikiProjects. And even so, you may not get a review, because you don't get the sticker of prestige. And who aims for A-class as a goal in itself, instead of as a stop on the gruelling road to FA?
I am intrigued by the B+-class label. WP Maths, WP Stats, and WP Elements use it (there may be more). But I find the part of it on WP:1.0/A stating "Possible good article nominee" very weird. It defines a class in terms of another class and kind of reduces B+ to just "ready for GA". Does it usually get independent usage?
I kind of see the point of fine distinctions like we have now, but without clear criteria they aren't going to be useful. I submit that there's really only five really important levels at the moment: Stub/Start/B/GA/FA. The first two are a mess or very short. B is the first level where you have a coherent piece that really adequately describes the topic – I don't see the point of C when the point where an article is substantial is very subjective, and the rest is similar to Start.
A has clearly defined criteria, but is rarely used. I get the impression it's not found to be useful, and its position between GA and FA is perhaps counterintuitive. Perhaps A might be useful if you have distinctions between "FA in content level" and "FA in style level" (I used to think those were A and GA), but while doing the latter alone is easy (come on, look at some obscure FAs which didn't get good peer review from TCO's infamous study), doing the former alone kind of does the latter for you because otherwise your content is incomprehensible. (OK, barring citation format, punctuation, etc. which most readers as opposed to researchers do not honestly care about.)
As for B, there is little social reward for this one, even though work to get Stub/Start to B is valuable to our readers. It's not a sticker that people like to post on their userpages, maybe because there isn't a review (although there should be IMHO). WP:Four Award has DYK/GA/FA: I don't get why new article and DYK are counted separately, because they will generally follow together because of the time limit. And en.wiki's DYK is kind of odd: it's more of an editorial service than a reader's one. The hooks are not always interesting (examples can be provided upon request: thanks to R8R Gtrs by the way for pointing this out!), and it's hard to make it so for some articles: so to make every article have that chance, you sometimes have to sacrifice hook interestingness. But it's on the main page! Surely readers are important too? And it's for this reason that I've tried to make my few hooks interesting, to make readers want to click the link because they are genuinely curious.
But DYK is kind of outside the class scheme. Maybe it would serve very well as a low-class review status, to be the step before B. But I don't see this happening all the time.
This was supposed to be a one-paragraph short post. I don't know what happened: the tale must have grown in the telling. I do hope I tied all the loose ends together, though. Also note that I'm primarily a WP Elements member, which may colour my views because it works on vital articles (level 4) for the most part. Perhaps an interesting case study is WP:Chemicals with a simplified A/B/Start/Stub scheme. It says "Although the Wikiproject does acknowledge the Wikipedia status of Featured Article (FA) and Good Article (GA), these are generic qualifications only, with no specific attention for chemical completeness, and as such are not listed in our Classes." This leads me to wonder if each project should really implement more specific criteria, to supplement or replace the general ones. Double sharp (talk) 21:35, 9 August 2014 (UTC)
I definitely agree with you that C-class is really hard to nail down. In my mind a short blurb is a stub (though the assessment systems says a really bad longer article can be so classified), Start is basically a work in progress (either incomplete or poorly referenced), and then B is a basically complete article that hasn't undergone a peer review process. That leaves C as basically a better start class article. Monty845 22:47, 9 August 2014 (UTC)
The benefit of A-class, for those projects that use it, is that it notes the article is up to the standards of the associated wikiproject. Whether that should actually be how things work or not, I have no idea, but it's the functional meaning. I suspect the idea behind 'B+' is similar: it marks the article as reviewed by editors who are involved in the subject. (Whereas GA-class requires external review.) Thanks to the at times months-long waits articles have on GAN, and then the additional delays once reviews start due to e.g. copyediting stuff, I can see the appeal of a preliminary review and associated grading. --erachima talk 23:14, 9 August 2014 (UTC)
@Erachima: I can definitely see the appeal of that, but it seems as though for all but the largest WikiProjects there is no such review process and grading. WP Elements used to have them for A and B, but after a while they became inactive. That seems to be the problem. For the average WikiProject, I submit that you really only need A/B/Start/Stub, with FA and GA as external general ratings. Maybe even a detailed review isn't necessary for all WikiProjects: just an edit summary explaining the rerating (although the detailed review should definitely be posted if it gets requested). That's what I did when I rerated the WP:ELEM articles a few days ago.
Also, if the ratings differ from project to project, does showing them as topicons really help the reader (as opposed to the editor) gauge its quality? GA and FA are general ratings, so those do help the reader, but I question if showing the rest as topicons would help if they are specific to one WikiProject or another. And what if an article is under multiple WikiProjects and is rated differently by them? (Some time ago chlorine received A, B, and C ratings all at once!) Double sharp (talk) 08:34, 10 August 2014 (UTC)
B-class requires the article to meet six criteria. If an article only meets four or five of those, but is close, it's C-class. For example, if an article is very thorough and informative, but has large unreferenced sections or a confusing layout, it would be C-class. A B-class article could probably get through GAN but may need a peer review first. A C-class article would probably fail GAN right away. A start-class article is nowhere near the B-class criteria. —Designate (talk) 13:15, 10 August 2014 (UTC)
I agree with you here: that's what C and Start generally mean right now. But I submit that defining them only in relation to what B-class criteria they fail isn't a very good a definition. They should have criteria of their own. And from a reader's point of view, C and Start are after all both kind of unsatisfactory (Start is "most readers will need more", C is "Useful to a casual reader" only), especially for more technical topics when C wouldn't be very good at helping people understand the content!
Also, I think that if the layout is confusing, then an average reader wouldn't find it "very thorough and informative", simply because the info is hard to find. Double sharp (talk) 19:50, 10 August 2014 (UTC)
It's possible and acceptable for a WikiProject to write their own standards. Most don't bother. Even when they're supposedly working from the same standard, we find wide variation—and that's before you consider the problem of outdated assessments. User:Nettrom and User:EpochFail just screened WP:MED's stubs for me, and their list suggests that about one in 12 are improperly assessed. Just imagine what the numbers will be for a smaller and less organized project. WhatamIdoing (talk) 23:51, 10 August 2014 (UTC)
Agreed. We can fix that by doing similar screenings for all projects. (Although you are right that it'll be problematic for smaller and less organized projects.) Double sharp (talk) 12:17, 12 August 2014 (UTC)

Also thinking a little about B-class. On the one hand, it has clear criteria and gives the reader good (but not great) content. And getting a lower-class article to B does a great service to the reader, especially since many important articles are not of this quality (e.g. gold is C-class, mostly because it is kind of a mess.) But this is not rewarded. TCO wrote here "Still a little worried at the low social rewards for B and probably the lower stability of B class articles to [degradation]. I would like to see the top 1000 Vital at GA+ and also all the elements because of the benefits of review."

Given this, I think that we should have B-class review available for WikiProjects large enough to cope with it, just like A-class review, and that ideally those classes get topicons as well. B+, I don't know. It is not a standard class, and many large WikiProjects have shown that they don't need it. Nevertheless three WikiProjects (IIRC, Mathematics, Statistics, Elements) have implemented it (Elements as late as 2011). If it gets reviewed as well, I think it could also work.

But there would need to be a caveat for the reader for A, B+, and B stating the existence of different standards among different WikiProjects. Double sharp (talk) 12:33, 12 August 2014 (UTC)

Pretty much the only reason I don't use B+ myself is that it breaks the tables like the one at Wikipedia:WikiProject Astronomy/Article ratings. If support for the class was implemented in these tables, I would probably start using it, since I see it as a class that basically says: "this article is at the point where a GAN alone could address the problems necessary to bring it to GA". StringTheory11 (t • c) 18:44, 12 August 2014 (UTC)

I don't think there is value to our users in hat-noting B-class articles, because the B-class assessment covers so little that is not obvious to the casual reader. Consider the B-class criteria for a moment, which essentially read

  1. Page offers some basic attempt at sourcing.
  2. Page does not have glaring omissions.
  3. Page is not a disorganized infodump.
  4. Page is not grammatically incomprehensible.
  5. Page has appropriate organizational templates.
  6. Page is not a mass of jargon.

Now, of these criteria, how many convey "hidden information" of some sort to our readers? Generally only the first, though in some technical subjects the second may also require a bit of expertise to judge. The remaining criteria are simply a checklist of ways an article may very obviously suck. As a result, telling a reader that they are reading a B-class page communicates almost nothing to them that will not be immediately apparent on reading the article itself.
Where B-class is useful is almost wholly on the metadata side, where it can tell editors interested in a broad subject which articles are and are not at a level of basic presentability.
As to the "social reward" aspect of giving reader-visible announcements, I believe this is a red herring. There are two main routes to B, in my observation. The first is when a page rockets straight from non-existent or stub to B, and most of our writers who can crank out pages like that are perfectly capable of self-assessing when a page is B-grade. Many don't necessarily even bother with having it checked for B before putting it in the GAN queue, and I'm not considering that a flaw. In this context, you'd basically just be giving the writers an extra no-prize for having a draft of the article they're trying to write finished.
The other is when a page has grown organically via the traditional method of everyone who read the page for the last 8 years chipping in a couple sentences, which tends to create pages that have all the necessary factual content for B-grade but are a disorganized mess. In these cases, the reward aspect should already be satisfied: intrinsically speaking, the editor gets to enjoy knowing that it's by their efforts that the page is now essentially readable, and extrinsically, their work was acknowledged by another editor.
In conclusion, publicly visible announcements of article quality are useful to readers only to the extent that they convey hidden information about the page's quality. This is true for the FA process and true for the GA process. It is also in most cases true for A-class, though I suspect that for political and practical reasons a rebranding of A (EA? HA?) with a clearer and more unified associated process may be necessary before it attains community consensus as a recognized category. B/C/Start, however, lack this trait and should therefore be considered purely metadata. --erachima talk 15:08, 13 August 2014 (UTC)

Just a reminder to everyone — while of course this isn't relevant for unloggedin readers, you can get the article quality to appear for you on the top of the article by toggling a gadget. It's the gadget beginning with "Display an assessment"; see User:Pyrospirit/metadata for details. Nyttend (talk) 03:41, 15 August 2014 (UTC)

RFC on SPI Clerk selection

Could use some opinions here [[1]] Hell in a Bucket (talk) 06:42, 17 August 2014 (UTC)

Set index articles or disambiguation for placenames

Two systems are currently used for the disambiguation of placenames. Russian placename disambiguation follows the rules for Set index articles, the rest of the world uses disambuation pages with template:geodis. Since both systems have a history in their respective geographic locations, I suggest to keep the status quo for the time being. A guideline may also be useful. Inwind (talk) 19:37, 21 August 2014 (UTC)

Not sure what it is exactly you are proposing? Any set of entities of the same type by the same name can be compiled as a disambiguation page (unless the WP:DABRL guideline is in the way, but that's a whole other can of worms). A set index approach is only used when inclusion of additional metadata and references (otherwise prohibited by WP:MOSDAB) is deemed to add value and where there is a WikiProject willing to handle set index-specific maintenance. These conditions are met for ships, mountains, anthroponymic lists, chemical elements, and yes, Russian placenames, among other things. Any other WikiProject can come on board or jump overboard at any time; there really isn't anything in the guidelines to either encourage or discourage that, nor should there be, IMO.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); August 21, 2014; 19:57 (UTC)

Jahanian is a small village located on the Narowal Zafarwal road at 18 kms from narowal and 7kms from zafarwal Near the town of dhamthal just 1 km from dhamthal. The total population is approximately 5000 and majority of the locality is Mayo Rajputs. There are also some other casts like araiyen, mian, maliks,insaris. 98 percent of the population is muslims and 2 percent Christians are there. The major source of income is farming and local government jobs

Additional information will be provided soon

Regards

Muhammad Ramzan Jani — Preceding unsigned comment added by Xravian (talk • contribs) 20:12, 19 August 2014 (UTC)

Replied on user's talk page: Noyster (talk), 11:23, 22 August 2014 (UTC)

Superprotect

This is not exactly a proposal, or rather, it is an already implemented proposal by the Foundation. Superprotect restricts editing to WMF staff. It was created, apparently, with the sole purpose of preventing the German Wikipedia editing community from disabling Media Viewer. Anyone opposed to this action can sign an open letter to the Wikimedia Foundation. SpinningSpark 19:48, 22 August 2014 (UTC)

Template:ExcessiveCitations

I was reading this revision of Opinion polling for the Scottish independence referendum, 2014, and I noticed that the ‘School, college and university surveys’ section contained 31 citations for one sentence in a way that was at odds with Wikipedia:Citation overkill. I did not want to spend the time going through the many citations in that section to see which ones were necessary for that particular statement and which ones weren't, so I thought I would flag the section with a template saying that the section contained an excessive number of citations and that disreputable or unnecessary references should be removed. To my surprise, however, there was no such template, so I decided to make one. I did so, added it to the article, and then added it to Wikipedia:Template messages/Cleanup/Verifiability and sources. A user, however, found some aspects of it ‘highly questionable’, and so removed it from the template messages page. He also asked whether there was a consensus behind it, and since there was none, I decided to attempt to establish one. What do you guys think of Template:ExcessiveCitations? We have message templates for virtually every other problem with references or citations (e.g. none, unreliable, more needed, not properly formatted, broken, not used properly), so why not include this one? Esszet (talk) 22:42, 12 August 2014 (UTC)

I dunno. Seems legit to me. I might use it, but I'm more likely to just cull the unnecessary or unreliable citations. In pop culture articles, they're usually very obvious. Discogs, IMDB, Rotten Tomatoes, and AllRovi seem to be the worst offenders. It's a simple matter to move them to the external links, where they belong. For offline sources, this template would be useful. NinjaRobotPirate (talk) 00:46, 14 August 2014 (UTC)
Sounds like a good idea as I suspect many editors have never heard of WP:CITEKILL. That said, I think it should be an inline template only–putting a big box at the top of the page saying "This article may contain an excessive number of citations" is potentially dangerous (e.g. the claim "But it said at the top of the article that I had to remove the citations ...") Instead, we should take a rifle (as opposed to a shotgun) approach with the flag at the end of the "offending" sentence/paragraph. By using a dated category, those so inclined can go through the backlog as and when. I created a similar template, which doesn't get used much(!) but it does the same thing - see {{Chinese script needed-inline}}.  Philg88 ♦talk 16:12, 20 August 2014 (UTC)

Hey, we already have a template for that:

Or maybe you just want moar templates? --Atlasowa (talk) 16:39, 20 August 2014 (UTC)

That page obviously needs this template added:
SpinningSpark 13:30, 23 August 2014 (UTC)
Granted I may be working in some fairly specialized areas of the project, but I'm hard-pressed to imagine a single instance where I thought citation overkill was even remotely a problem. DonIago (talk) 16:57, 20 August 2014 (UTC)
I've seen instances of this. Usually, though, the problem isn't solely the number of citations. The problem was having a dozen biased primary sources rather than a couple of good sources. WhatamIdoing (talk) 17:05, 20 August 2014 (UTC)
It's definitely a problem. It's bad enough in an academic paper: when you cite more than one thing at once, it's not easy to tell what came from where. However, in such a context, you're typically instructed to be engaging in original research, interpreting what's said. In a context like Wikipedia, where we must say only what's in a source, there's almost never a good reason to cite more than one source for a specific sentence, and the exceptions are situations where we're discussing the sources themselves, e.g. "Alice and Bob say X"<ref>Alice's book</ref><ref>Bob's article</ref>. Whenever we're simply talking about the subject, a single source will pretty much always be sufficient, so in pretty much every situation of this sort, we can simply chop all the other sources, although of course we might have to examine the process of adding the sources in case there really is original research. That's why I'll cut additional sources; if one WP:RS for a statement says everything (especially online, so I can check it), I'll chop everything else, since there's already sufficient sourcing. That being said I don't think another template would help. Just use {{cleanup}} with a parameter saying something like "excessive citations for specific statements". Nyttend (talk) 02:23, 21 August 2014 (UTC)
I've frequently found use for multiple sources on a sentence simply for prosifying reasons. For a simple example, when source A says "X is true of T" and source B says "Y is true of T", so the article says "X and Y are true of T" in one sentence instead of two. Anomie⚔ 13:08, 21 August 2014 (UTC)
  • I wouldn't deny that there is such a thing as citation overkill, but placing a template on an article encouraging editors to remove citations is bad, bad, bad. Some analysis of why there are too many citations is required. Frequently, multiple cites to the same fact is indicative that edit warring has been going on and someone is trying to prove a point by weight of citations. The real solution here is to resolve the dispute and reach a consensus. Removing the citations does not solve the problem. Even more commonly, there are multiple citations because some WP:SYNTH is going on, for example, "most/many scientists think..." followed by numerous scientists taking that position. Actually, what is needed here is not removal of citations, but rather {{citation needed}} for the synthesis that most scientists believe that. When that citation is provided then the old ones become redundant. Alternatively, the whole passage needs to go along with its citations.
I also have some objections to the specific wording of the template. Calling for disreputable sources to be removed is wrong. No, the disreputable source remains the source of the passage. The correct actions are either to tag it with {{unreliable source inline}}, {{dubious}}, or something similar, or else to remove the passage altogether. I also don't think much of the call to merge references, by which I think is meant citation bundling. This does not fix the overkill problem, it just moves it further down to the references section.
More generally, a call to delete references without explicitily identifying the problem items, and why they are a problem, is liable to result in the wrong things getting deleted. In short, this was a good faith idea, but ultimately counter-productive. SpinningSpark 13:13, 23 August 2014 (UTC)

WikiProject Rehab

Hey everyone. I'm look for a team of editors to help me get Wikiproject REHAB up and running again. I feel that we should give vandals a chance to turn over a new leaf if they agree to cooperate with the lessons. I need friendly, helpful, yet strict editors. Please help me help others. Thanks, Mirror Freak 17:52, 23 August 2014 (UTC)

I'm up for it. Feedback ☎ 22:00, 25 August 2014 (UTC)

Watchlists and transclusions

I have a suggestion for a bot. The issue it is meant to address is as follows. I have transcluded the lead of an article B into another article A using Wikipedia:Transclusion#Partial_transclusion. But changes to the lead of B do not show up as changes in the watchlist for article A. There seems to be no way to get around this, to alert people of the changes, short of keeping B in the watchlist as well.

I have an idea for reflecting transclusions. Each time the lead changes on article B, a bot adds a whitespace in the odd iteration, (or removes the whitespace in an even iteration) in article A with the edit summary mentioning the diff. Assuming there are not too many transclusions, and that the transcluded section is not changed too many times, this should not be too much of a problem. Any suggestions on whether this is a good idea? If so, I would be interested in writing such a bot myself, though I don't have any experience in such things. Kingsindian (talk) 07:46, 26 August 2014 (UTC)

Remove the "Please donate now" banner

The banner is so annoying! I know that logged-in users can disable it using Special:preferences, but what about IP users? It is obvious that most people will just ignore it. If someone wants to donate to Wikipedia, they can still use the "Donate to Wikipedia" which appears at the sidebar.S/s/a/z-1/2 (talk) 03:02, 22 August 2014 (UTC)

I'm sure if you agreed to personally bankroll the entire necessary endowment to keep Wikipedia running, and were to do so with no strings attached, Wikipedia may not have to run the banner anymore. However, Wikipedia does still have bills to pay, and unless and until you'd like to pay all those bills, it seems unlikely that they are going to stop running the banner asking for people to pitch in and help. --Jayron32 03:45, 22 August 2014 (UTC)
What do you mean?S/s/a/z-1/2 (talk) 05:06, 22 August 2014 (UTC)
I mean, it costs money to pay electricity bills, rent, and pay employees to do necessary work for you. I'm unclear on what part of the world you live in where you would be unfamiliar with the concept of needing to spend money on utilities, rent, and equipment. You seem to object to Wikipedia asking for donations to pay those bills. I was suggesting that the fastest way to solve the problem was for you to agree to foot the bill yourself. --Jayron32 03:01, 23 August 2014 (UTC)
I said "If someone wants to donate to Wikipedia, they can still use the "Donate to Wikipedia" which appears at the sidebar.".S/s/a/z-1/2 (talk) 06:51, 23 August 2014 (UTC)
Yes, but it's also easy to miss. The banner catches people's attention, which you've proven. The fact that you are annoyed by it only proves that it is doing exactly what it is supposed to be, which is getting noticed. --Jayron32 19:56, 23 August 2014 (UTC)
I haven't spoken with anyone in fundraising for a while, but the last thing I heard was that IPs can click the button to suppress the banner for (I think) 30 days. It might still be cookie based. It shouldn't be appearing every day on every page, even for IPs (unless they're testing that particular setting at the moment). If you're seeing this all the time, please reply, and I'll go figure out who's handing fundraising tech bugs at the moment. Whatamidoing (WMF) (talk) 21:21, 22 August 2014 (UTC)
I see it every few days.S/s/a/z-1/2 (talk) 00:42, 23 August 2014 (UTC)
Do you use the same computer all the time, or are you seeing it on different computers? Whatamidoing (WMF) (talk) 00:55, 24 August 2014 (UTC)
This is a good question, as we often see people who switch computers or have a dynamic IP may see the banner more frequently than they should. It's also possible you live in one of the countries in which we have recently run a campaign, such as South Africa or Malaysia, during which banners show much more frequently. Regardless of the reason, I'm sorry to hear you have found the banners obtrusive, S/s/a/z-1/2! There are several options available to you to hide the fundraising banners in the future. If you click the X in the top right-hand corner of the banner, it will hide for two weeks. If you return to the 'Thank You' page, it may give the cookie a chance to reinsert: https://wikimediafoundation.org/wiki/Thank_You/en. We never show banners to logged-in users at this point, so logging in is the best and easiest way to avoid them. Thanks for the feedback! --CCogdill (WMF) (talk) 22:17, 26 August 2014 (UTC)

Bot to keep up to date lists of active and inactive members of WikiProjects

Members list of WikiProjects tend to grow steadily and are crippled with inactive members. The consequence is that when you add your name in the list, you don't really feel like you are getting involved in anything significant, because it means next to nothing to be in the list.

It is not a very rewarding job to clean these lists by hand but that's how it's done in many WikiProjects. Some tools such as Dispenser's useractivity.py can help but they are not very convenient when it comes to performing the edit itself: lines containing inactive users are simply commented out, which is not suitable if your members list is actually a table, or if you want to store inactive members in another list.

I propose to write a bot to do this task. Actually, most of the code is written. It can update the participants list of your WikiProject (but will not unless you request it for your own WikiProject). The update consists in moving inactive participants listed in the "active list" to the "inactive list" of your WikiProject. You can define what an "inactive participant" is. It supports both lists and tables.

For instance, it can mark participants as inactive when:

  • their last contribution to the English Wikipedia is older than some threshold (typically one year)
  • their last contribution to a page (or its talk page) falling in the scope of your WikiProject is too old
  • their last edit to a page inside the WikiProject itself is too old (discussions about the project itself, the portal, and so on)

You choose what is relevant for your project. It can also sort the two lists of members (active and inactive) by user name if it is told so. And it can move inactive users who are actually active again to the list of active users.

Would you find it useful? I can also propose this code as an external tool, but I think it would be simpler for everyone to run it as a bot. Your feature requests are welcome. If there is a consensus here, I will post a request for bot approval. − Pintoch (talk) 11:57, 17 August 2014 (UTC)

This would be very useful I think. These lists are now mostly cemeteries of former editors (or user names). Johnbod (talk) 12:02, 17 August 2014 (UTC)
  • I think if you supported a config script, like they have for archiving bots, and had the bot limit itself to the section in which the script is found, that would make it a lot more user-friendly. I also think it would be good to check for users that are blocked, in addition to simply inactive. VanIsaacWScont 19:48, 17 August 2014 (UTC)
Checking for blocked users might not be such a good idea as it looked at first. A significant number of blocks are for just hours or days, some of the longer ones are reversed and some are succesfully appealed. We'd have flurries of bot activity changing lists to and fro, and anyone looking to the lists for helpful editors might not realise that an editor listed as blocked could soon be back in action. Short-term blocks might come to be resented more if they were seen as damaging participation in projects. Maybe simply looking for inactivity would be enough. NebY (talk) 20:04, 17 August 2014 (UTC)
It's a good idea to use templates, I will do that. Concerning blocked users, it shouldn't be hard to implement, but I quite agree with NebY. Anyway, I don't think the bot has to do frequent changes to the lists. For most projects it should be fine if their members list is a few weeks old. Pintoch (talk) 20:16, 17 August 2014 (UTC)
I'd be happy to see this done. However, the participant lists involve a wide variety of locations and formats, so it's unlikely that whatever you create will work for all of them.
I'd start with the simplest case: no edits at all for at least one year. WhatamIdoing (talk) 15:16, 18 August 2014 (UTC)
Thanks for your support! The most difficult part is to handle the different formats of lists or tables indeed. Clearly, some formats won't be handled, but I believe for some projects it might be worth changing a bit their habits to get something automated. But I will not force them to do so, of course. Pintoch (talk) 16:00, 18 August 2014 (UTC)
I think the usefulness of such a bot would be reduced if the criteria for marking members as "inactive" were not consistent between projects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:15, 23 August 2014 (UTC)
Support I strongly support the creation of such a bot. There are a number of tasks I do which involve going to a Wikiproject I'm not familiar with (example, fielding an OTRS info request) Sometimes I post to the talk page, but I would prefer to make a request to an active member. That is often a tedious task. Restricting myself to a list of active members would be very helpful.
However, I do have a different view regarding the notion that the criteria need to be consistent. I'll illustrate with Wikipedia:WikiProject Basketball/Women's basketball (I do realize, with only 9 members, the bot is a bit of overkill). I would find it useful to know if any of the members become inactive, and I like the second option. I imagine that the list of participants would be changed to active participants, and the bot would move inactive down to a section, which could easily state "Inactive means the editor has not edited a basketball article in six months). If some other Wikiproject prefers a different criteria, they could state it at the top of the list of inactive members.--S Philbrick(Talk) 15:23, 23 August 2014 (UTC)
  • I could support this idea, but it needs to be done with some sensitivity. Members marked as inactive should not have their membership of the Wikiproject removed, for instance, they should remain in Wikiproject categories (but possibly a sub-category). The bot should automatically put them back in the active member list just as quickly once they start editing again. It should be on an opt-in basis, not foisted on Wikiprojects without discussion. SpinningSpark 14:52, 26 August 2014 (UTC)
  • The useractivity tool became an information table as it wasn't conveyed well in lists nor should ephemeral info be constantly saved. I spent some time restoring functionlity, it still badly hurt from labs migration (like Bug 68876). Additions I'd like to see in the future is their sub-specialty, best method of communication (e.g. IRC or wiki), and a user invitation system. — Dispenser 14:03, 27 August 2014 (UTC)

Government parameter in Template:Infobox country and Template:Infobox former country

Further information: Template talk:Infobox country § Edit request 27 August 2014

Moved the discussion. — Preceding unsigned comment added by Trust Is All You Need (talk • contribs) 20:04, 27 August 2014 (UTC)

RfC: Should Persondata template be removed from articles?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
At this time, there is no consensus to remove persondata, due to the uses of it for various tools. However, there does seem to be a consensus for revisiting this in the future, when most or all of it has been migrated to WikiData. --Mdann52talk to me! 08:17, 1 September 2014 (UTC)


Background (Persondata)

The question keeps arising on Wikipedia talk:Persondata and other forums on whether we should drop persondata now that Wikidata provides the same or similar information. I usually state eventually that is the goal, but I haven't heard anything else about it. I decided this time to be more proactive about it.

From Wikipedia:Persondata, "Persondata is a special set of metadata that can and should be added to biographical articles only. It consists of standardized data fields with basic information about the person (name, short description, birth and death days, and places of birth and death) that, unlike conventional Wikipedia content, can be extracted automatically and processed by cataloging tools and then used for a variety of purposes, such as providing advanced search capabilities, statistical analysis, automated categorization, and birthday lists."

At this time, I'm not aware of anyone using the data. DBpedia does gather the information and offers it for download. However, I'm not aware that they use it. Wikidata did have two bots running, which copied |SHORT DESCRIPTION= from persondata and put it into Wikidata. One bot worked only on dewiki. SamoaBot did work on enwiki. SamoaBot's operator stated that he doesn't "...recall having run that task in these months. However, tons of data have already been imported, and now it is up to the English Wikipedia community to decide whether they still want those data within articles." I did ask Wikidata about persondata.

{{Persondata}} does have many drawbacks. Some of which are:

  1. It is hidden, therefore it is often out of sync with the article text or infobox, with no current mechanism to keep it in sync.
  2. If an infobox is present, persondata becomes redundant.
  3. It is currently not being used by anybody (to my knowledge).
  4. |NAME= and |ALTERNATIVE NAME= parameters have no standard format. Format should be surname, firstname, but this isn't always followed. When a person as a stage/pen name, there is not standard on which parameter parameter gets what name.

Positives:

  1. If the article doesn't have an infobox, persondata can become a source of info.
  2. |SHORT DESCRIPTION= is of use to Wikidata.
  3. From Periglio's talk page, "Wikipedia has an easy accessible database of over 1 million people. It is data available for serious research projects. Why delete it?"

Question: Should the {{persondata}} template be removed from all articles and no longer be used?

Proposed by Bgwhite 21:21, 20 July 2014 (UTC)

Discussion (Persondata)

  • Have a comment?
  • Before implementing this change all the gadgets and tools that create or use this template must also be changed. Otherwise we will get them being created when others are trying to get rid of them. A comparable situation where the cite gadget creates "deprecated" cite template parameters that bot(s) go around undoing. So this should be done as a proper release, where wikidata, gadgets and tools are all synchronised with the policy implementation to stop wasted effort. Graeme Bartlett (talk) 22:08, 20 July 2014 (UTC)
    Graeme Bartlett, Wikidata is currently not ingesting anything from Persondata. I'm aware of two tools that create Persondata, Persondata-o-matic and AWB. An AWB developer is aware of this proposal. Persondata-o-matic currently doesn't work. There are some scripts/gadgets that do allow for easy viewing persondata. Bgwhite (talk) 22:17, 20 July 2014 (UTC)
    So I think that Wikidata should ingest this. It will be harder to harvest from history as it may not be possible to tell the "correct" version. AFC reviewer tool currently adds persondata. Graeme Bartlett (talk) 06:02, 21 July 2014 (UTC)
  • My main concern is Category:Biography articles without infoboxes. This means we have 20,000+ that may have Persondata and not an infobox. -- Magioladitis (talk) 08:40, 21 July 2014 (UTC)
    Maybe it would be a good idea to add infoboxes to most of these pages so that we reserve the information in the article and in a visible place? -- Magioladitis (talk) 16:40, 23 July 2014 (UTC)
    @Magioladitis: do you mean automatically create infoboxes and transfer Persondata to them? One consideration in that case then, is articles where there isn't enough information to justify an infobox (Although I'd like to see almost every page with an infobox anyway, I think the general consensus is that infoboxes without enough info are an eyesore). For example, if only |NAME= is available, the infobox is unnecessary as you can (usually) get that info from the article title. Perhaps these sorts of persondata can be deleted early on.—Msmarmalade (talk) 02:34, 24 July 2014 (UTC)
    @Msmarmalade: we can select some rules (size of page, at least 3 fields are filled, etc.) and create infoboxes using a bot only for these cases. Still much better than now. -- Magioladitis (talk) 05:02, 24 July 2014 (UTC)
  • How reliable is Persondata anyway? in this edit a malformed article title was used to create a malformed NAME, and DATE OF BIRTH was copied from the completely unsourced infobox (it's not present in the body of the article). Where does that leave Persondata - or Wikidata if it scrapes up "information" using the same rules? PamD 10:40, 21 July 2014 (UTC)
  • Questions - Perhaps it's just me, but there seems to be a failure of communications at work here. Even now, many WP editors remain in the dark about what Wikidata is doing, and how it will affect WP articles. In this example, for instance, would the supplantation of persondata by corresponding wikidata yield better WP articles? Will it, for instance, automatically populate WP infoboxes? What would the differences look like? How would they be made compliant with BLP, V, and other WP policies? Would WP editors still be able to correct errors, without having to learn their way around Wikidata? Are there some examples in place to show how these things will operate? LeadSongDog come howl! 20:40, 21 July 2014 (UTC)
    @LeadSongDog:. Some data in the infoboxes could be fetched from Wikidata, but that does not seeem to be the matter at hand here. {{Persondata}} is not meant to be used to populate infoboxes. -Superzoulou
    Thanks, but that really doesn't clear much up. The content of {{Persondata}}, {{Infobox person}}, etc should reasonably be automagically verifiable against the categories the article is put into. References supporting the assertions that cause those categories to be applied must be maintained if we are to avoid finding Koffi Annan in Category:Bollywood stars or something equally absurd. Will/does wikidata support checks to see that the categories are supported in the article, with references? Does it have a mechanism to support variances in sourcing policies between the different WP languages, or at least to attribute the sourcing to the WP language and article where the assertion originates? Vandalism isn't going to be disappearing anytime soon, after all. LeadSongDog come howl! 21:53, 21 July 2014 (UTC)
    I do not really understand what you are talking about. This proposal is not about deleting {{Infobox person}} and afaik, there is no consistency check between persondata and categories. Actually, I do not see how a bot could use Persondata in their current form to know that Koffi Annan should not be categorized as a Bollywood star.
    Many bots have added from which Wikipedia the data originated in the source part of the statement. One has added the actual reference that was used in the article (but this is more difficult so less widely implemented at the moment). --07:16, 22 July 2014 (UTC)
  •  Comment: There actually appears to be actually two issues:
    1. should we work toward removing Persondata now ?
    2. should we delete data from Persondata wtihout checkign with have their data in Wikidata first ?~
I am certainly in favour of 1), not of 2): if data in persondata match those in Wikidata, they can be deleted. It is a bit pointless that when we want to correct some data, we need to do it in two pages instead of one. But when there are gaps in Wikidata/mismatch with persondata, it should be checked before deleting anything. --Superzoulou (talk) 07:16, 22 July 2014 (UTC)
  • In that case, perhaps we should have a {{persondata moved to Wikdiata}} which can be applied (by humans or bots) once the data is verified as being in Wikidata. It should prevent further addition of Persondata, and enable us to check progress statistics. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:27, 22 July 2014 (UTC)
    Once the data is in Wikidata, I think we can simply delete it, so we would rather need {{Persondata inconsistent with Wikidata}}. At the same time, we should obviously stop creating new persondata here. That means, among other things, updating scripts like User talk:Dr pda/persondata.js by user:Dr pda so that they add the data to Wikidata instead of Wikipedia. -Superzoulou (talk) 13:23, 22 July 2014 (UTC)
    The major source of new Persondata templates, in my experience, is the Articles for Creation process, where reviewers are encouraged by the script to fill out a template. This should be fixed before any attempt at removing Persondata is made. APerson (talk!) 02:34, 2 August 2014 (UTC)
  • The one question that no one is answering is how Wikidata is being maintained? Another example I have just come across is Ed Vokes. Someone updated his birth and death dates on Wikipedia two months ago (16 May 2014). Although the editor updated Persondata but Wikidata still shows the old information. Periglio (talk) 17:21, 26 July 2014 (UTC)
    Have to agree with above comment to which there has been no answer as yet. There are numerous wiki's interfacing into wikidata and there need to be some means of ensuring that they are all kept in step for this to be useful information. Having had experience of the out of date information on wikidata for simple things such as Commons links, there need to be some rigorous system available before we can rely on wikidata information. Keith D (talk) 12:37, 30 July 2014 (UTC)
  • Has this RfC actually achieved anything? The anti-persondata lobby argument argument seems to be based on fact that they don't use it, so lets delete it. As someone who has invested time in playing with the birth and death data, I'm worried that Wikidata will actually be maintained. Although not normally visible, from my experience PersonData normally gets updated when someone changes a date. At the moment, there is nothing in place to update Wikidata.
I would like to use WikiData but I need to convince myself that Wikidata is just as reliable as Persondata. I am working on a Wikidata extract and in the next few days will be generating some meaningful statistics comparing Persondata and Wikidata to see if there is a problem. All I ask is for Persondata to carry on, business as usual, until we have some actual facts in front of us. Periglio (talk) 13:11, 3 August 2014 (UTC)
This RFC hasn't achieved anything because we are going to be removing something beneficial for something that has significantly more problems and the fact that AWB and users are actively updating, maintaining and working on a monumental task while a more "meta" problem is still being worked through. If users don't use or need it, they don't have to, but I see no need to remove it when an equal or better alternative does not exist. ChrisGualtieri (talk) 04:44, 4 August 2014 (UTC)
Update: I have done an analysis (link here) on over 4000 records comparing Persondata and Wikidata. My first conclusion is that both databases have the same level of coverage, which is around 95% of the total population of notable people. My other conclusion is that Wikidata appears to have the edge on accuracy. The bulk of corrections I am making appear to be updating Persondata to match changes in the Wikipedia article. In short, I am switching my personal project to Wikidata and no longer extracting from Persondata. However, I still remain opposed to the removal of Persondata until SHORT DESCRIPTION is moved across to Wikidata. Periglio (talk) 19:40, 4 August 2014 (UTC)
  •  Comment: separately maintaining {{Persondata}} is an anachronism with Wikidata existing. *If* the template is to be retained, then it should be auto-filled from WD. That said there is valid comment that there are many statements in existing person data that is not replicated to WD. So until the point that the data is transferred/merged, then we should be retaining the anachronism. Can we look to auto-fill the current template, and then find uses where we have data, but WD is bereft of that and migrate? — billinghurst sDrewth 01:32, 23 August 2014 (UTC)

Support (Persondata removal)

  1. Support, unless anyone shows a temporary need to retain the data while it is copied to Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:55, 20 July 2014 (UTC)
  2. Support as redundant, --Gerda Arendt (talk) 22:07, 20 July 2014 (UTC)
  3. Support as redundant. I've never added it to an article, never understood why. Sometimes have to fix work of others who insert inconsistent data. Montanabw(talk) 02:48, 21 July 2014 (UTC)
  4. Support per others. --AmaryllisGardener talk 03:27, 21 July 2014 (UTC)
  5. Support as long as it is implemented cleanly, (see discussion above) and the information therein is not lost. This sort of data should appear in Wikidata instead, and is not really "encyclopedic" in itself. But it could be a tool to populate indexes, categories, or add to author records - more the thing for Wikidata. Graeme Bartlett (talk) 06:05, 21 July 2014 (UTC)
  6. Support methodical transfer and removal as per others. Perhaps afterwards, focus should move to cleaning up infoboxes, and standardizing the dates, data, etc within them.—Msmarmalade (talk) 07:47, 21 July 2014 (UTC)
    Expanding on that. The examples of people using Persondata that i've read in this ongoing discussion, seem to be personal. It doesn't seem to be used by the main body of Wikipedia users so I think it's not really appropriate to put in the article, albeit hidden. It would be more appropriate to outsource the data, or embed it in the actual article, rather than adding an extra step for editors to complete and maintain, for negligible useage.—Msmarmalade (talk) 07:04, 4 August 2014 (UTC)
  7. Support as redundant. The use to which this data is potentially put is dubious, and the fact that it isn't sync'd seems to make the whole thing pointless. I'd like to see the automated insertion by AWB switched off immediately, and its complete reversal (into 'systematically remove' mode and not just neutral) if the RfC goes through. -- Ohc ¡digame! 09:10, 21 July 2014 (UTC)
  8. Qualified support remove data that are identical on to those on Wikidata so that we do not need to maintain them at two places. Check and then remove the other ones. --Superzoulou (talk) 10:11, 21 July 2014 (UTC) + Superzoulou (talk) 11:01, 22 July 2014 (UTC)
  9. Support Finally the time has come. You always had the highlights and details in infobox, there was no need of persondata like others may have thought as well. OccultZone (Talk • Contributions • Log) 10:44, 21 July 2014 (UTC)
  10. Support as redundant, and an annoyance to maintain. These can also be a pain to fix when disambiguating links because the link is there, but invisible. bd2412 T 13:33, 21 July 2014 (UTC)
  11. Support I like the idea of using a tool designed to keep track of this sort of data to keep track of this sort of data. Zell Faze (talk) 14:04, 21 July 2014 (UTC)
  12. Support, though make sure that the data we are removing already exists in Wikidata first. Cbrown1023 talk 17:45, 21 July 2014 (UTC)
  13. Support eventual removal - as and when we are confident it's been migrated to Wikidata. Removal on a case-by-case basis when migrated would be reasonable, and then deprecating the system. Andrew Gray (talk) 19:53, 21 July 2014 (UTC)
    Andrew Gray, Wikidata will not import anything but |SHORT DESCRIPTION=. A bot has already imported this data and will run again before Persondata's removal. Bgwhite (talk) 19:59, 21 July 2014 (UTC)
  14. Support The only reason I include persondata in my new stubs is because they otherwise got inserted with incorrect or incomplete data. I have never used the persondata and I believe it is redundant now with Wikidata - maybe someone could run some numbers on the accuracy of persondata vs Wikidata for 100 random biographies? depending on the results we could just rip them all out. Alternatively, we could agree to no longer insert persondata and manually delete whenever we check Wikidata and see the data exists on Wikidata. Jane (talk) 09:10, 22 July 2014 (UTC)
    Comment: I first create a stub on English Wikipedia, then I create the Wikidata item (if it doesn't already exist). When I create a new Wikidata item it imports the persondata so I don't need to type it over. I would not want to see persondata disappear before my workflow changes (i.e. first make improve WD item, then create stub from that). Now WD lets me import the stub, but so far I can't import the WD item to WP. Jane (talk) 13:04, 26 July 2014 (UTC)
  15. Support as redundant, Since I don't use WikiData I find PersonalData to be absolutely useless anyway. –Davey2010 • (talk) 18:58, 25 July 2014 (UTC)
  16. Support separating plumbing and porcelain. Metadata should be distinct from the text which generates an article as much as possible. It doesn't need to be torn down root and branch but we should not be adding responsibilities to persondata and we should be transitioning to Wikidata over time. Protonk (talk) 18:31, 29 July 2014 (UTC)
  17. Support when all appropriate persondata has been slurped by Wikidata. Until then, we should leave it to carry on its quiet existence at the bottom of our edit screens. — This, that and the other (talk) 10:51, 30 July 2014 (UTC)
  18. Support, after migration is over. The argument about persondata being easier to use is not really convincing, it is rather an argument for simplification of Wikidata APIs, but even now WD looks much better. Max Semenik (talk) 22:33, 30 July 2014 (UTC)
  19. Support per the various arguments already stated with the qualification that a decent amount of time for data migration be granted, again, per the previous comments above. Safiel (talk) 16:17, 31 July 2014 (UTC)
  20. Support - if data such as this is required, it can be maintained at wikidata. PhilKnight (talk) 13:45, 1 August 2014 (UTC)
  21. Support – with the creation of a bot to run through articles, removing Persondata from those where it matches the Infobox and tagging those with diffs for manual processing. Those without Infoboxes should be given one except when only the name is present in the Persondata and it matches the article title. I'm assuming there is nothing inherently harder about scraping from Infobox vs. Persondata for use in Wikidata, etc. Not having to worry about checking the Persondata for agreement with the article all the time will be a nice little improvement to the editing experience. —[AlanM1(talk)]— 21:11, 1 August 2014 (UTC)
  22. Support removal, but not urgently. I've never much liked having "content" that readers of the encyclopedia cannot easily see. --Tryptofish (talk) 20:01, 3 August 2014 (UTC)
  23. Support removal. It does not form part of the encyclopaedia, since it isn't visible to readers. Yes it may help with the Wikidata project further down the line but, frankly, that's that project's problem. Our project is building an encyclopaedia and PersonData does not, and never has, contributed to that. WaggersTALK 13:43, 4 August 2014 (UTC)
  24. Support removal, but delay for a limited time to allow import of short descriptions--if that process isn't complete yet. (A bot doing the removals could also do the imports where necessary, and log conflicts. This shouldn't take a good deal of time, as there has already been a bot pass to record short descriptions. PS: Nice analysis, above, Periglio!--j⚛e deckertalk 01:22, 5 August 2014 (UTC)
  25. Support after cross-check and incorporation into Wikidata. Persondata is now obsolete and redundant. Renata (talk) 00:17, 7 August 2014 (UTC)
  26. Support this appears to be redundant and therefore unnecessary. Fraulein451 (talk) 16:05, 11 August 2014 (UTC)
  27. Support. An excellent and laudable project that is now superseded by Wikidata. Ironholds (talk) 10:43, 17 August 2014 (UTC)
  28. Support I find persondata to be very rarely accurate and have often thought it should be nuked even before we had wikidata. Now that we have wikidata to take care of things and I feel would likely be much more accurate then we should deprecate persondata. -DJSasso (talk) 13:02, 20 August 2014 (UTC)
  29. Support. It always was just more edit window clutter anyway. SpinningSpark 19:39, 22 August 2014 (UTC)
  30. Support. Persondata is a very rarely used feature whose purpose is now replaced by Wikidata. The reliability of Wikidata is as good if not better than persondata (as per Periglio's research) so the reason for its existence is now obsolete. Many of the oppose comments have supporting arguments that are perplexing or based on misunderstandings. The non-reader facing aspect of persondata has always made persondata something of an anomaly and I'll be glad to see it go. The tools that use persondata are few and should be easy enough to modify or block. It would be good if somebody were to run a project to import persondata missing from Wikidata and/or to repair inconsistencies between them but even if that's not done during a pre-removal period, I think removing persondata is a positive step forward. Usually change requires more pain that this will entail so this is a rather easy decision. Jason Quinn (talk) 11:51, 23 August 2014 (UTC)
  31. Support. When I first game here, back in 2009 (2010 was my year when I decided to remove Persondata). When I did it to numerous of articles on the English site, someone told me that it is used to collect dumps from other sites. However, I took a look at other language Wikis such as Russian, Ukrainian, etc, and found out that only {{Defaultsort}} is used! When I first saw Wikidata only couple of moths ago, when it was administered to remove interwikis I was amazed that such a small thing can do something as big as that! My main question however is how and when we will implement it, when we don't even have a template for it, or it will be another invisible tool? Either way, I never liked Persondata because it just adds 240 kb to a server which is already suffering few delays (depending on where you live).--Mishae (talk) 02:47, 1 September 2014 (UTC)

Oppose (Persondata removal)

  1. Oppose: First of all, the claim that Persondata are currently not being used by anybody is wrong. Tools that evaluate Persondata exist and are being used. Secondly, Wikidata cannot be taken seriously at this stage as its data (beyond the interwiki links) are simply not reliable. As elaborated in this discussion, Wikidata looks like a Wikipedia from 2003 without any references. A Wikipedia article, however, combines both, literature and references that backup the data given in the Persondata template. At the current state of affairs, the Wikipedia articles and their Persondata records should be considered as a source, not as a target for Wikidata. --AFBorchert (talk) 08:32, 21 July 2014 (UTC)
    And another observation: I just took a first look at one of the dumps of wikidata. They are as ugly as hell as they are embedding JSON within XML. To extract person data from Wikipedia dumps is pretty simple (and frequently done). This fun will be all gone when you have to turn to Wikidata dumps. --AFBorchert (talk) 08:43, 21 July 2014 (UTC)
    AFBorchert:
    Wikidata does not contain enough references, but English Persondata do not contain any, so I do not really understand what your point is. The real question would be which is more reliable between birth/death place/date in Wikidata and in English Persondata. I see no argument one way or the other.
    German Persondata appear to be more used than the English ones, but the discussion for removing them should be done in Wikipedia in German. Does any German tool use English Persondata ? --Superzoulou (talk) 09:56, 21 July 2014 (UTC)
    @Superzoulou: Persondata are embedded in articles that (hopefully) provide references to backup this data. Hence, you have both, data and references in one place very close to each other. If the article is updated in this regard, the persondata can be easily adapted in one edit. At Wikidata we have mostly a heap of data without any references. This does not help us and is surely no replacement for the current Persondata. I refered to the German discussions as de-wp as this was debated there half a year ago. I think it is always worthwile to look into other similar projects and their discussions. And indeed the Persondata were introduced at de-wp and later imported to en-wp. It is surely a predecessor to Wikidata and at some time it may be envisioned to deprecate it but currently I would see it as a great tool that helps in the transition to Wikidata which is not yet sufficiently mature to replace it in my opinion. --AFBorchert (talk) 11:54, 21 July 2014 (UTC)
    @AFBorchert: English Persondata are mostly meant for bots that are not smart enough to read the rest of the article, and for them references elsewhere in the page are not really useful. It is true that people who maintain the template can check the consistency between Persondata and the rest of the article, but I wonder how many people do it by hands. Bots can also check the consistency of the data between Wikidata and Wikipedia. --Superzoulou (talk) 13:17, 21 July 2014 (UTC)
    @Superzoulou: I do it “by hand” at en-wp as well as de-wp. And indeed the consistency check between Wikidata and Wikipedia is an important advantage that would get lost if we would give up Persondata too early. With very few exceptions, I do not edit data records corresponding to Persondata at Wikidata as it is no fun for me to click through all the Javascript-based forms. Wikitext can be edited far more conveniently (and if necessary even by an editor of my choice like Vim), I do not want to waste my time with clicking through a myriad of forms. --AFBorchert (talk) 13:28, 21 July 2014 (UTC)
    @AFBorchert: Consistency of Wikidata can also be checked against infoboxes, and even against the article's lead (Wikidata items about people are marked as such so which avoids the occasional topic mismatch between the infobox and the article proper). --Superzoulou (talk) 14:44, 21 July 2014 (UTC)
    @Superzoulou: Many biographic articles do not have infoboxes but Persondata (example). --AFBorchert (talk) 20:05, 21 July 2014 (UTC)
    @AFBorchert: I know, and I would suggest that we should start the removal with pages with infoboxes. But the data can also be parsed from the article's lead (admittedly, only as an occasional bot task, not like permanent check thourgh templates). Superzoulou
    @AFBorchert: concerning the ugly dumps, the new JSON version will hopefully make things easier [2]. --Superzoulou (talk) 15:28, 23 July 2014 (UTC)
    @AFBorchert: Agree with removal persondata from those that have infoboxes.--Mishae (talk) 03:00, 1 September 2014 (UTC)
  2. Oppose (from wikiproject templates): until wikidata is brought online, persondata needs to stay in order to populate wikidata with the largest source we have of data on article subjects. I know that AWB automatically copies information from infoboxes to persondata, so there is obviously significant overlap on those two, and I am absolutely convinced that persondata's usefulness will soon expire. But we need to keep this on enwiki, up until a bot goes through and copies the persondata entries to wikidata (just like they did with interwiki links), and no later; nobody else has nearly the comprehensive coverage of biographies that would facilitate that transfer. VanIsaacWScont 09:28, 21 July 2014 (UTC)
    @Vanisaac: In what way is Wikidata not "online"? Are we confident that Persondata is reliable (accurate and up-to-date) enough to be copied to Wikidata? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:58, 22 July 2014 (UTC)
    It's not online in the same way that Obamacare is not online: Yeah, there's a lot of the substantive stuff that's there now, and the different features are getting implemented roughly when they are supposed to, but there's still more to come as time progresses, and it's going to take some effort by people to get to the level of coverage that the system was designed to have. VanIsaacWScont 10:04, 22 July 2014 (UTC)
    @Vanisaac: So you object to deprecating persondata in favour of Wikidata, even though Wikidata does everything that persondata does, and much more besides, because Wikdiata will do even yet more in the future? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 22 July 2014 (UTC)
    Please go back and actually read what I wrote. I object to removing persondata before it's been copied over to wikidata, since enwiki's persondata is likely to be one of the most robust and comprehensive sources for wikidata. That's what "we need to keep this... until a bot goes through and copies the persondata to wikidata" means. Since that has not yet happened, I oppose deprecating persondata at this time. There might also be an argument for keeping it supported after that time, if the transfer bot remains in operation, so that it can be used as a backdoor wikidata upload. But without any details about the wikidata transfer bot, that's merely speculation. VanIsaacWScont 13:03, 22 July 2014 (UTC)
    Yes, I understood that from your original comment, but in the light of it, and of your more recent comments, I cannot make sense of your "until wikidata is brought online" clause. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:23, 22 July 2014 (UTC)
  3. Oppose — this seems slightly premature, and the linked discussion from Wikidata seems to indicate that they would not like to see Persondata nuked just yet. Titoxd(?!? - cool stuff) 18:26, 21 July 2014 (UTC)
    • How about nuking it as soon as Wikidata has it under control? bd2412 T 19:09, 21 July 2014 (UTC)
      • That wouldn't be too problematic, but it's a horse before the cart problem. (Wait a second...) Titoxd(?!? - cool stuff) 20:05, 21 July 2014 (UTC)
        • Titoxd, Wikidata is not importing any data except for |SHORT DESCRIPTION=. This has already been imported via a bot approved in May 2013. In the linked discussion, the Wikidata people were fine or don't care, only two non-wikidata people objected. One of whom uses the data for their personal amusement.
  4. Oppose. The proposer has not provided any English-language documentation demonstrating that Wikidata is, or soon will be, a fit successor to Persondata. Adding to my opposition, I have become active at wikidata to try to get this matter addressed, and I find a low level of activity and only a few editors over there seem to be interested in improving quality. I believe wikidata lacks a critical mass of editors to create reliable information and should be ignored until they prove their ability to provide reasonably reliable information. The only area they seem to be doing an adequate job in is interlanguage Wikipedia links.Jc3s5h (talk) 19:47, 21 July 2014 (UTC), Remark extended 1709, 11 August 2014 (UT)
    • Jc3s5h, Nobody currently uses the data contained in Persondata. How can there be a successor to something nobody uses? People do use Wikidata and DBpedia. Bgwhite (talk) 20:26, 21 July 2014 (UTC)
      • The proposal uses Wikidata as partial justification for the removal, but there is no link to any documentation about the part of Wikidata that would cover people. As for nobody using Persondata, there seems to be some disagreement about that. Jc3s5h (talk) 20:51, 21 July 2014 (UTC)
    • @Jc3s5h: Wikidata entries for people include a |label= property, which is the equivalent of |SHORTDESCRIPTION=, but also multilingual. They also have |Also known as=, |date of birth=, |date of death=, |place of birth= and |place of death=. Not to mention dozens and dozens of other properties, not available in Persondata, such as |gender= and |VIAF identifier=. See, for example d:Q17279725. Each property can be programatically displayed in Wikipedia templates such as infoboxes, succession boxes, etc. - unlike Persondata. In short, Wikidata does everything that persondata does, and much more besides. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 22 July 2014 (UTC)
  5. Oppose. I am just using Persondata to populate some missing birth/death dates in Wikidata; there are hundreds of thousands of statements that can be used on Wikidata. And if Wikidata were fully "populated", there is no reason to run bots to sync; the template can automatically show Wikidata information if no local data is set, and even add the page to a maintenance category if both is the case, so the information can be merged on Wikidata, and the local data can be removed. Once that is done everywhere, we can think about removing Persondata. Not before. --Magnus Manske (talk) 22:44, 21 July 2014 (UTC)
    1. @Magnus Manske: I fear a misunderstanding; Persondata is not displayed in this wiki. When do you anticipate finishing your bot run? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:42, 22 July 2014 (UTC)
      1. I am aware that it is not displayed here. I have only just started with the bot; there are many cases (e.g. "fuzzy" dates) that I am not sure how to handle yet. IMO it would be beyond strange to destroy data in the Persondata template unless we can be sure it has been properly synchronized with Wikidata. --Magnus Manske (talk) 09:13, 22 July 2014 (UTC)
        1. @Magnus Manske: Thanks for the prompt response; I was referring to your "the template can automatically show Wikidata information" comment. Are you confident that the persondata you are importing is accurate and up-to-date? Do you check it against visible values in the infobox, or lede? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 22 July 2014 (UTC)
          1. @Pigsonthewing: Probably the wrong place to discuss my bot's internals, but I also use the Infobox, and the German Personendaten template; I import the highest precision value into Wikidata, with "source". --Magnus Manske (talk) 12:18, 22 July 2014 (UTC)
  6. Oppose People do use persondata. I am using the data extracted from Persondata on my own website to generate facts eg "Who is 50 years old today". Although my use may be regarded as trivial,it shows that Persondata is available for serious research - births and deaths of over a million notable people. A lot of people are stating that Persondata is not used, but on what evidence? Extraction tools exist, who knows what people do with the article they download?
    My second reason for opposing is that based on my own experience, Wikidata does not provide a reliable alternative for birth and death dates. Admittedly, there appears to be an editor who updates Wikidata death dates as soon as they happen, but new articles and fixes to old articles do not get onto Wikidata. Someone editing an article would not necessarily think that they need to fix Wikidata as well.
    Finally, again from my experience, Persondata is pretty accurate. I expanded my own software to validate the extract, comparing dates against categories for example. There were only two or three thousand entries, from 1.1 million articles, where persondata had vandalised or out of date data and I am currently fixing those! Periglio (talk) 23:38, 21 July 2014 (UTC)
    @Periglio: Why are the results of a "Who is 50 years old today" query on Wikidata not acceptable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:39, 22 July 2014 (UTC)
    @Pigsonthewing:Because I would miss Joe Gulla who is 50 tomorrow (at time of writing in my time zone). My point is that no one has explained how Wikidata gets updated when an average editor adds a date to an article. I remain opposed until I know Wikidata is not just a snapshot at the time the original bot ran. Periglio (talk) 21:12, 22 July 2014 (UTC)
    @Periglio:. At the moment, I do not think this sort of update is done systematically. But again, is it done for Persondata ? If so, it should be possible to update the system so that it updates Wikidata instead. --Superzoulou (talk) 09:46, 28 July 2014 (UTC)
    @Superzoulou: Persondata is updated manually, but will normally be seen by editors updating the article. The editor is not necessarily aware of Wikidata so I can see a situation where Wikidata will be out of sync with Wikipedia. This is a general problem for Wikidata. There will be more people actively maintaining accuracy on Wikipedia, and there does not appear to be anything in place to keep Wikidata in sync. Periglio (talk) 15:48, 28 July 2014 (UTC)
    @Periglio: Persondata are not very visible either: you need to either edit the very last section, or the whole page and scroll all the way down to the end of the page. I doubt many users do it. With the Visual Editor, it might be even worse. Do we have any data about how many people update Persondata ? Without really looking for it, I just found an article (Otto Zdansky) with Persondata out of synch with the article's body. For the (few ?) experienced contributors, who update Persondata, I think we could advertise more Wikidata instead. --Superzoulou (talk) 20:46, 28 July 2014 (UTC)
  7. Oppose for now - This proposal seems a bit premature. Once Magnus and others are finished utilizing Persondata, then we should remove it, not before. Kaldari (talk) 21:20, 30 July 2014 (UTC)
  8. Oppose - Wikidata is not able to adequately run the data and use it in a meaningful way or respond as flexibly as Enwiki users have made it - Wikidata is not equal or better than our current system and is a very technical part of the projects that seems unable to keep pace or integrate efficiently to make Persondata truly obsolete or needlessly redundant, yet. ChrisGualtieri (talk) 04:46, 4 August 2014 (UTC)
  9. Oppose - I do not see a legitimate reason for the removal of Persondata. It is assuredly helpful for those who are collecting large amounts of data, and allows a way to index the individuals. Currently wikidata is not ready to be the single source of this information and I think we should revisit this at a later time. Jab843 (talk) 02:50, 5 August 2014 (UTC)
  10. Oppose - Persondata is a useful component for editors who wish to add data which would not always be presented in an article (especially if there is no box) including variations in the name (or spelling thereof), additional names (stage names, pen names), exact date of birth and death (rather than just the year), exact geographical locations (including any useful details of village, municipality, region, country) in addition to those specified in the article. I have no idea how I can add such information to Wikidata when writing a new biography -- or indeed how to access and update Wikidata in order to update incorrect data in existing biographies.--Ipigott (talk) 06:12, 5 August 2014 (UTC)
  11. Oppose because of Magnus' project, if nothing else; we mustn't delete persondata as redundant when it still has substantial amounts of unique information. Moreover, Ipigott makes a great point; this is useful for people who are familiar with Wikipedia but not with Wikidata. Perhaps we could deprecate its addition to articles, saying "If you want to add this type of metadata, please create a Wikidata entry", but not remove it from pages that already have it. Nyttend (talk) 18:39, 5 August 2014 (UTC)
  12. Oppose because WikiData is totally unsourced. Most death date has not any references. Christian75 (talk) 18:34, 7 August 2014 (UTC)
    This is true, but part of bigger problem. Although Wikidata largely references Wikipedia for birth and death dates, I am finding that Wikipedia rarely has a date of birth reference. I have raised the issue at the biography project Wikipedia_talk:WikiProject_Biography#Birth_date_citations although not many comments have been made. Periglio (talk) 20:23, 7 August 2014 (UTC)
  13. Oppose Premature. Alberto Fernández Fernández (talk) 19:01, 7 August 2014 (UTC)
  14. Oppose There are a number of en.Wikipedia-only programs which read Persondata fields, but do not read Wikidata. They probably could be rewritten to read Wikidata, but others above say it's not well-formatted. — Arthur Rubin (talk) 01:26, 15 August 2014 (UTC)
  15. Oppose This should not happen unless and until Wikidata is shown, and accepted to be, reliable and maintained with appropriate controls to ensure that it stays accurate. S a g a C i t y (talk) 07:16, 17 August 2014 (UTC)
  16. Oppose, not convinced that there is a problem with keeping it around for a while longer until more people are accustomed to working with Wikidata. —Kusma (t·c) 07:35, 17 August 2014 (UTC)
  17. Oppose: Premature, even WikiData doesn't want this to happen (yet), nominator's claims are false, and most of the "support" !votes either are predicated on such false assumptions or basically amount to WP:IDONTLIKEIT or WP:IDONTKNOWIT, some quite explicitly ("Since I don't use WikiData I find PersonalData to be absolutely useless anyway", which also misconstrues the difference between WikiData and this metadata). Basically a lot of people who don't actually know what's going on are saying "get rid of something I don't understand!" How about, no. At least not yet. When WikiData has sourcing standards (at least for material they get from Wikipedia) that are reliable enough for Wikipedia, then maybe we can move this metadata over there.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  01:57, 19 August 2014 (UTC)
  18. Oppose As premature. Until Wikidata provides a stable, referenced and suitable alternative, persondata should stay where it is.  Philg88 ♦talk 08:18, 20 August 2014 (UTC)
  19. While IU think it can use some more standardization, I think it's useful to have on the page. (And by the way, it is also a good marker for biographical articles - I used it to allow me to exclude all biographical articles in stub searches a few times.) עוד מישהו Od Mishehu 12:51, 20 August 2014 (UTC)
  20. Oppose for the reasons given by AFBorchert, Magnus Manske and SMcCandlish. --Atlasowa (talk) 19:53, 22 August 2014 (UTC)
  21. Oppose On top of being premature, this seems completely unnecessary. I don't see why we shouldn't wait until WikiData is far more established first. Remove it in a couple of years. We don't need to do this right now. The only thing this will do is stress out the people who actually use it. Feedback ☎ 22:08, 25 August 2014 (UTC)
  22. Oppose - Not only is this premature and unnecessary, it is original research that reached a false conclusion. To state "It is currently not being used by anybody" is a complete misnomer and the parenthetical does not qualify a thing. I use the information myself. Yes it is hidden but I have found that when it is "out of sync with the article", it is, at times, a vandals handiwork that didn't get reverted. The mechanism to keep it in sync is called collaborative editing, and while it is somewhat redundant when an infobox is present, it is not superfluous because of its usefulness to expose the residue of a vandals hoax. The parameters do have a standard format as can be seen at Template:Persondata/doc#TemplateData, and the documentation can be improved by any editor who sees a deficient instruction.—John Cline (talk) 21:44, 26 August 2014 (UTC)
  23. Oppose at the present time. • Astynax talk 18:14, 27 August 2014 (UTC)
  24. Oppose at the present time per Magnus Manske. Apparently, Persondata is currently useful to extract data for Wikidata which isn't present there as yet, so removing Persondata now would seem premature and would mean a loss of useful metadata. Gestumblindi (talk) 23:14, 29 August 2014 (UTC)

Wikidata person import faulty

Whatever process for importing personal data into Wikidata from Wikipedia appears to be faulty. For example, Francis Bacon says he was born born January 22, 1561, which obviously must be a Julian calendar date, since the Gregorian calendar wasn't created until 1583. But the Wikidata item (Q37388) says his birth date is January 22, 1561, and claims the date was imported from Wikipedia. So who or what is doing this importing and do they have any clue about how calendars work? Jc3s5h (talk) 20:25, 7 August 2014‎ (UTC)

I will just add that Francis Bacon is not just a one off incident. My analysis has found the same happening with the Russian calendar and a few where the bot picked up a inaccurate date that was not the date being reference. Another example Lekain where Wikidata has two dates, which may be Gregorian related. There is a lot of tidying up that needs to be done. Periglio (talk) 20:14, 7 August 2014 (UTC)
Where did you report this issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 17 August 2014 (UTC)
Firstly, I note that our article does not mark the date as Julian. I see that you have already raised the issue at wikidata:Wikidata:Administrators' noticeboard#KLBot2 creating incorrect birth dates, but for the benefit of others, the Wikidata edit in question was made by User:KLBot2 on 14 June 2013. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 17 August 2014 (UTC)
The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.

RfC: Should the hidden navbar be removed from the base Stub and WikiProject banner templates?

Closing per long-standing request at WP:ANRFC. Other than WP:PERF, there's not a whole lot of official guidance here for decisions like this one. While it's suggested that removing the template might improve performance for some editors based on how widely it is used, it's not clear whether this impact would be noticeable. (It might be helpful to try this out on something like testwiki to get some actual data.) Some editors may find these extra links for fixing purposes as well. All that said, there was no consensus on what to do with the CSS-hidden navbar from the specified templates, meaning they should be kept until a more definitive consensus has been formed. I, JethroBT drop me a line 20:16, 19 November 2014 (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.

Should the CSS-hidden navbar be removed from the base Stub (1.8 million pages) and WikiProject banner (5.5 million pages) templates? -- Netoholic @ 19:16, 30 July 2014 (UTC) (re-signing to keep from being archived early -- Netoholic @ 01:46, 15 August 2014 (UTC))

Survey

  • Remove - This {{navbar}} template call was added to the WikiProject banner back in 2008, but then immediately hidden by CSS (display:none) in {{WPBannerMeta/core}}. The same thing exists in the Stub base template {{Asbox}}. There is a CSS trick which editors can add to their custom CSS files, but this trick hasn't been publicized and is in use by only a handful of already experienced users. Even though it is hidden by CSS, it still adds a few hundred characters to every stubbed or bannered talk page download (and pages with multiple banners add it multiple times). The navbar template transclusion itself is called every time a page is saved (which for talk pages can be alot). Now, normally, we don't worry about performance, but in the template design space we do have to weigh the costs vs benefits, and since these templates are so widely used, I think every small efficiency we can do deserves consideration. The people that know about this hidden trick or would use it, are also experienced enough to get by without it on the rare occasions they need to edit a particular stub or WikiProject template. -- Netoholic @ 19:16, 30 July 2014 (UTC)
  • Keep and add the code to view the links to MediaWiki:Group-templateeditor.css. I'm basing this on the discussions about this I found (Template talk:Asbox/Archive 2#Navbar & Template talk:Asbox/Archive 4#Why the navbar ?) which were sufficient enough to convince me it is a good idea to have the links. I'd be happy to brief over other discussions if you care to link them. Also, I'm not sure if you've notified the people involved in the previous discussions (if you even found all of the discussions, which I'm sure I haven't and don't expect you have), a quick group ping (MSGJ—Xeno—Amalthea—TheDJ—Happy-melon—Topbanana—Grutness—WOSlinker) should do it. — {{U|Technical 13}} (e • t • c) 14:36, 1 August 2014 (UTC)
  • Neutral. A few facts I can throw at this discussion; firstly the hidden navbar edit links are used by 8 Wikipedians. Per WP:PERF, we should be prioritising pretty much everything over efficiency; there is some discussion here about the impact of this feature - despite the implementation being truly and absolutely awful, it's trivial in the bigger picture of Wikimedia ops. On balance, if there's a better way to do it, we should. If not, we keep it as is. - TB (talk) 09:48, 2 August 2014 (UTC)
  • Remove. It was never really necessary to have this on stub templates in the first place. As Netoholic points out, if you're editing stub templates, chances are you've got enough nous here to know how to do that without having to resort to the embedded links. Similarly, if you're editing a wikiproject's banner, chances are you know what you're doing. I've added the necessary coding in monobook to be able to use them myself, but I can't remember the last time I've actually edited a template this way - it's only the barest fraction quicker than simply editing direct from the template's page. Having the links there, if anything, encourages people to edit the templates - and while editing article pages should be encourages, making changes to heavily-used templates is beyond the scope of "be bold", since it can have far-reaching consequences. So no real benefit, and potential for trouble = ditch it. Grutness...wha? 11:34, 2 August 2014 (UTC)
  • Comment - I don't know enough about this template and its uses to opine about it specifically, but I would like to make a general comment. WP:PERF tells regular editors not to worry about performance because it's beyond their ability to do much about it, since their permissions have been deliberately limited to prevent project-wide impact. While it's true that the "IT professionals" or others with special permissions may be needed to make changes such as the one being discussed, they rely on us to decided which features are important. More and more readers are viewing Wikipedia pages on mobile devices, and I've been reading a lot of comments from editors about page load times on these devices. If a template is being called a gazillion times and is rarely used, I think that efficiency should be considered as well as utility. —Anne Delong (talk) 10:31, 7 August 2014 (UTC)
  • Keep When stub templates and WikiProject banners break page layout, or put pages in incorrect categories, which they sometimes do when somebody (either with good or bad intentions) has been playing with the markup, these links make it much quicker to go straight in and fix. @Topbanana: - I only just noticed this (I came looking for this thread, and searched for my own name to see if I'd already commented), please note that this attempt to ping failed because you didn't sign it at the same time. Accordingly, I'm pinging MSGJ, Borgarde, Quest for Truth again, with my signature. --Redrose64 (talk) 15:13, 1 September 2014 (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.

Commons admins with viewdelete

Some time back, there was a proposal to give Commons admins the right to view deleted content across all WMF wikis; I can't find it, or I'd link it. It gained broad support, but WMF vetoed it on technical grounds, as (if I remember rightly) it wasn't possible to get the software to grant rights to a user on one wiki just because the same user had been granted a different set of rights on another wiki. As far as I remember, WMF wasn't objecting to the idea; I got the impression that it would have been accepted had it been possible to implement.

With this in mind, I wonder what people would think about a request to developers for a new userright that admins here could grant: the right would be called "Commons admin", with just the ability to view deleted revisions of files (both the log entries from the history page, and the actual contents of text revisions and uploads), i.e. vaguely comparable to WP:Researcher in that viewing is the only additional ability, but more viewing ability than Researcher in filespace and no viewing ability in all other namespaces. Upon creation of this userright, we would grant it to any Commons admin who requested it, but under no circumstances would it be granted to anyone else, and (aside from gross abuse) the only reason for removing it would be that the user was no longer a Commons admin. As the biggest WMF project, we're probably the biggest source of images that get transwikied to Commons, so if creating this userright is practical, we'd be able to resolve a big portion of the difficulty that prompted the proposal. I understand that we currently don't have any admin-grantable userrights that involve deletion, basically because admin-type rights are typically granted only after a substantial community discussion, but this is different: we'd simply be allowing our admins to implement what our software would do if it were possible, and anyway people don't become admins at Commons without a substantial community discussion. Nyttend (talk) 14:58, 14 August 2014 (UTC)

  • As long as Foundation Legal is ok with it. (there are legal reasons why view deleted needs to be restricted to a limit number of people, but past discussions haven't given much guidance on how limited, a handful of commons admins who request it should probably be fine) I don't see any reason not to do it. That said, I've very rarely come across requests for that sort of info, do commons admins need it often? Monty845 16:00, 14 August 2014 (UTC)
  • I would personally not have any objections, on the other hand, I am a Commons admin, and I needed this right only a couple of times in my life. Those who transfer a lot of files or those who are superactive on FFD may need the right more often.--Ymblanter (talk) 16:53, 14 August 2014 (UTC)
    • Monty, I suspect that this wouldn't be a Legal concern, since Commons admins already have viewdeleted over there; my proposal, if successful, wouldn't expand the number of trusted users WMF-wide. Both of you address the "how many people" issue, so I've left an announcement at Commons:COM:AN — hopefully we'll hear from more Commons admins. Nyttend (talk) 19:23, 14 August 2014 (UTC)
  • Sounds like a good idea. Having done almost 170000 deletions and 1400 undeletions on Commons, there've been plenty of times when I could have used this to determine whether to restore/delete/DR an image, but instead had to wait for an en.wiki admin to check a file and reply back with the needed info (except for the 6 months when I was an en.wiki admin myself of course). There aren't many admins regularly involved in deletions/undeletions/DR/CSD at Commons, so the right would only likely be given to a small number of Commons admins. INeverCry 20:08, 14 August 2014 (UTC)
  • User:Jalexander knows a lot about what's possible with user rights as well as what's likely to wash with the legal team, so let's see if he's got any suggestions. Nyttend, how many years ago was "some time back"? Whatamidoing (WMF) (talk) 22:34, 14 August 2014 (UTC)
  • If I knew, I'd tell you; I'm sorry. I don't think I participated in the discussion; if I did participate, I've thoroughly forgotten. If I remember rightly, I first became aware of it upon reading that the technical staff had declared it impossible. Nyttend (talk) 22:37, 14 August 2014 (UTC)
Just a guess, but I wouldn't be entirely surprised if the technical problems were no longer so difficult. Whatamidoing (WMF) (talk) 02:17, 15 August 2014 (UTC)
Thanks, INeverCry, for finding that! Having seen that date, I was able to find Wikipedia:Wikipedia Signpost/2008-06-26/Global groups. I've checked every Signpost through the end of September without finding further coverage, so I'm guessing that they didn't cover what happened at the end of the poll. Nyttend (talk) 04:00, 15 August 2014 (UTC)
  • Support - English Wikipedia is just one part of the Wikimedia project; to the degree that we can help other parts of the project, we should. This proposal would cause little harm to us (presumably, any user capable of becoming a Commons admin should be trusted to merely view our deleted media and its descriptions), and significant benifit to the Commons, an other part of the project. עוד מישהו Od Mishehu 03:50, 15 August 2014 (UTC)
  • Seems reasonable. I am sure they don't let just anyone be a commons admin. Chillum 04:28, 15 August 2014 (UTC)
Well, they let me be an admin there...but, then again, they let me be an admin here for a while too... INeverCry 07:00, 15 August 2014 (UTC)
  • No opposition from my side, but how is a local group any different from a global group, from a technical point of view? Note that there is also some information at m:Global deleted image review. --Stefan2 (talk) 17:25, 17 August 2014 (UTC)
  • The commonadmin name is too confusing, as they won't be common nor an en-admin; could be fine, under "imagehistory" right, or the like. Those who want it and will use it should apply individually, like "reveiwer" right. Alanscottwalker (talk) 18:03, 17 August 2014 (UTC)
    I said "Commons admin", so your comments aren't quite accurate, although it was a vague suggestion and I expected someone to propose a different name. Perhaps "imagehistory" as you suggest, or perhaps something like "fileviewer"? Nyttend (talk) 13:47, 20 August 2014 (UTC)
  • Comment. This is a redundant proposal. This idea was proposed 6 years ago and was even approved in an RFC. Then a bug report was filed, which unfortunately has not been fixed yet. There are some related bugs that need to fixed before this feature can be implemented. Ruslik_Zero 19:42, 17 August 2014 (UTC)
  • Please re-read the proposal. I'm proposing a technical workaround for manual implementation of the 2008 proposal, since it can't be implemented automatically. I'm suggesting the creation of just a local userrights group, which shouldn't be too hard; during discussions related to Wikipedia:Requests for comment/Template editor user right (I can't find the precise spot), someone observed that creating the TE userright wouldn't be that difficult for the developers. Should all aspects of my proposal be implemented, we admins will be able to grant it just as easily as we grant rollback, although of course relevant policy will place much greater restrictions on who gets it; requests from "hat collectors" will automatically be declined. Nyttend (talk) 13:47, 20 August 2014 (UTC)
  • Umm, how does that work around the technical problems exactly? We'd still need to create a "viewdeletedfile" to add to the enwp group, and at that point we might as well just put it in a global group. Legoktm (talk) 17:37, 21 August 2014 (UTC)
  • As I understand it, in 2008, the idea was as follows. Legoktm is an ordinary Commons user and Wikipedian without admin rights, so he can't see anything that's been deleted on any projects. He passes the Commons equivalent to RFA, and with a single click of the button by a Commons bureaucrat, he's able to view all deleted revisions in the file namespace of all WMF projects; here at en:wp, he can't delete or undelete anything, and he can't view deleted content in mainspace or portalspace, but he can view deleted revisions of files. Such an idea was rejected by WMF, and if I understand rightly, the idea was simply that it couldn't be done — the ru.wikibooks and ang.wikisource servers have no way to understand changes to your userrights on Commons. My proposal is basically a manual workaround, since a human can look at your Commons rights log and make relevant modifications to your rights on other wikis. I know absolutely nothing about global rights, so I can't make any solid comments. Are you basically suggesting that this be a steward-grantable thing, with the provision that when a steward hits a button on Meta, you immediately can view all deleted revisions in the file namespace of all WMF projects? If that's what you mean, I would say that it was even better than my proposal, but again I have no idea whether things work that way. Nyttend (talk) 02:01, 23 August 2014 (UTC)
  • Support either a local user right "viewdeletedfile" or similar, to be given to commons admins at their request. Or some other magic that allows them to view deleted files here. —Kusma (t·c) 13:34, 21 August 2014 (UTC)
  • Quid pro quo, if we do this, Commons should be willing to grant the same right to en admins at Commons on request. We sometimes need to investigate the disappearance of an image from a Wikipedia article, and that is made ten times more difficult if it was deleted on Commons. SpinningSpark 14:57, 23 August 2014 (UTC)
  • Granting the ability to view deleted files on a case by case basis to commons admins (or an editor here who just wants to work on file stuff, I guess) is a good idea. I'd prefer if we could set it up such that there's some input for the community, but I don't want to create another mini RfA process. Protonk (talk) 15:20, 27 August 2014 (UTC)

Break - possible existing solution

Would the reasearcher right already do the job? It allows you to view deleted pages and their histories? Should we just clone this right, and rename it something like "commonadmin"? --Mdann52talk to me! 15:54, 27 August 2014 (UTC)

As I noted above, researcher is different: it covers all namespaces, but it provides far less information about deleted pages than admins are able to get. In particular, a researcher cannot see the contents of deleted revisions, and the Meta proposal that I'm trying to implement concluded that Commons admins should be able to see everything that local admins can see — the only difference is that the Commons admins wouldn't be able to undelete files. Nyttend (talk) 03:52, 2 September 2014 (UTC)

Request to keep old badge for GA articles

Now that Wikidata handles FA and GA badges and Dexbot is removing the templates, the badge appearing next to interwiki links on en.wikipedia is now a silver star (see the badge next to the German and Japanese links at Oxygen for an example). I propose that we request that it remain the green plus symbol (File:Monobook-bullet-ga.png). The request can be made at Meta:Wikidata/Development/Badges#Requests for different icons. 130.88.141.34 (talk) 09:27, 2 September 2014 (UTC)

It seems we could easier just put the correct image in MediaWiki:Common.css. Along those lines, I see the new badges aren't showing up at all in Monobook because for some reason MediaWiki:Monobook.css is already overriding the bullet images. Anomie⚔ 11:55, 2 September 2014 (UTC)
Anomie there is a known bug. I informed the wikidata guys in the IRC channel. -- Magioladitis (talk) 11:58, 2 September 2014 (UTC)
Anomie https://bugzilla.wikimedia.org/show_bug.cgi?id=70280 -- Magioladitis (talk) 12:03, 2 September 2014 (UTC)

I hope it was not a mistake I approved this task. Please inform me quickly so we can act if there is any problem. -- Magioladitis (talk) 12:01, 2 September 2014 (UTC)

OTRS members

Following a misunderstanding on my part about an editor modifying an {{OTRS permission}} template on a file page, I propose that a new user group be created for OTRS members similar to the one on Commons so that such editors can be clearly identified. Personally I've grown used to hovering my mouse pointer over an editor's name and seeing a pop-up box that contains basic details including the user groups that editor is a member of. In this instance I saw only the word "rollbacker" and forgetting to check the actual userpage, I asked a question at the OTRS noticeboard about whether the license for a particular file was correct because it had been added by someone I thought wasn't an OTRS member. I'm sure I'm not alone in having this bad habit of using pop-ups rather than clicking on a page and checking it more thoroughly, but it occurs to me that we should have a separate user group for these editors because they are a trusted group and they have access to classified information. If it avoids another embarrassing episode on my part, I think it will be worthwhile to have this group. Green Giant (talk) 14:26, 30 August 2014 (UTC)

I was actually drafting a proposal at the same time. The full draft is at this page, but a summary is as follows: Create an "otrs-userright" on enwiki as well, that applies "autoreview" (same as what reviewers have to mark edits to pages under PC as reviewed. Then, create an edit summary to pick up any addition of {{permissionOTRS}} or {{ConfirmationOTRS}} by users not in the groups (like this one). This would both help with the issue that Green Giant mentioned, and reduce the number of false taggings that happen. --Mdann52talk to me! 18:15, 30 August 2014 (UTC)
In that case I defer to Mdann52's superior knowledge and am willing to wait for the RfC to be published. Green Giant (talk) 21:59, 30 August 2014 (UTC)
I agree that we need to open an RFC for this. Whenever it is read. Cheers, TLSuda (talk) 01:57, 31 August 2014 (UTC)

If anybody wishes to participate in this discussion, it is now located at Wikipedia:Volunteer Response Team/Userright RfC. Green Giant (talk) 11:52, 3 September 2014 (UTC)

Alerts list

Have a prominent button at the top of each article that says, "We can alert you when this page changes." If you're signed in and have email enabled, clicking the button adds the article to your alert list, and you'll get an email when the article changes. If you don't have an account, clicking the button takes you to a sign up page and then, once the sign up is complete, you're presented with "Would you like us to email you when [article name] changes?" If you select yes, the article is added to your alerts list and you're presented with "Done." Instead of "We can alert you when this page changes," articles on your alerts list will have a button saying, "Remove from alerts." --Anthonyhcole (talk · contribs · email) 13:14, 3 September 2014 (UTC)

Excuse my ignorance - what's an alert list? Is it similar to your watchlist? — Martin (MSGJ · talk) 13:46, 3 September 2014 (UTC)
As I read it, this is already possible using the watchlist. Preferences has an option for email notifications of changes to watched pages. SiBr4 (talk) 14:00, 3 September 2014 (UTC)
Yep, Martin. A list of articles you want to be notified about when they're edited. AiBr4, I'm aware of that. (I explained the process to a new editor a couple of days ago.) I'm looking for something a lot more obvious and somewhat simpler, for readers who don't know our arcane ways. And I'm suggesting a separate list from the watchlist because I've got lots of articles on my watchlist, but there are only a couple that I would want to be notified by email about. Using the present setup, I think you get emailed every time anything on your watchlist changes. --Anthonyhcole (talk · contribs · email) 16:45, 3 September 2014 (UTC)

A-class icon

Might I suggest that all A-class articles got their own icon in the right upper corner like FA-class articles get. Today it is hard to tell if an article is A-class or not. I think that it should be more visible that an article was A-class. --BabbaQ (talk) 18:04, 3 September 2014 (UTC)

A similar proposal was made less than a month ago and is now at Wikipedia:Village pump (proposals)/Archive 113#Show article quality to readers?. SiBr4 (talk) 18:36, 3 September 2014 (UTC)
@BabbaQ: Go to Preferences → Gadgets and enable "Display an assessment of an article's quality in its page header (documentation)". You won't get an icon, but the page title will turn this colour. --Redrose64 (talk) 18:44, 3 September 2014 (UTC)

Adding non-economical ranks to the table at the top of country articles

I'm perhaps a bit of idealist, but find it odd that only economical ranks (GDP, Gini) or ranks based mostly on economic performance (HDI) are shown at the {{Infobox country}} table. I suggest adding information about state of democracy, state of freedom of speech and level of corruption the the table, right below the GDP, HDI and Gini ranks. These give a much wider view to the society than just economical.

Especially prosperous East Asian countries seem to be like Western countries based on the table and the introduction part in the article, but they have significantly lower political freedoms than their Western counterparts and are often more corrupt. The table in the article Singapore according to my proposion would look like this: [3] Giving the three ranks of Democracy Index, Press Freedom Index and Corruption Perceptions Index would help understanding the Singaporean exceptionalism, where the 3rd highest GDP and the 5th best rank in the Corruption Index is combined with an authoritarian regime, the Press Freedom being lower than in Russia. /á(!) 00:48, 1 September 2014 (UTC)

The problem is that those other indexes are incredibly subjective. Even when it comes to a concept such as freedom, different people can consider the same factor as adding to, or detracting from freedom. Is a society that protects your religious beliefs from criticism more free as a result, or less free because to do so infringes on the freedom of someone who would criticize your beliefs? Do we measure freedom as negative rights against government, do we include positive rights, what about "rights" that restrict what other individuals or associations can do? Monty845 14:35, 1 September 2014 (UTC)
I agree that general most free countries indexes are quite subjective, but these three indexes are subjective only to some level. In the Press Freedom and Corrption indexes information is gathered from many sources – from 13 sources in the Corruption Index –, and in the Democracy Index, the criteria are openly shown at their website, and the criteria are measuring solely level of democracy, not things like religious freedom. If the elections are not plagued by fraud and oppression of voters and the opposition is not harrassed, then the country is more democratic.
If you compare the Democracy Indexes made by Economist Intelligence Unit and World Audit, they look very similar. EIU ranks Singapore as #81 and World Audit as #71. EIU ranks Norway, Sweden, Iceland, Denmark and New Zeeland as the most democratic countries, while World Audit ranks Sweden, Denmark, Finland, Norway and New Zeeland as most democratic countries. There are similar small differences between GDP ranks. IMF ranks Qatar, Luxembourg and Singapore as the wealthiest countries, the top 3 of World Bank rank is Qatar, Luxembourg and Kuwait, and CIA ranks Qatar, Liechtenstein and Monaco as the top 3.
On the other hand, if you look at the page List of countries by income equality, the amount money the richest 20% gets compared to how much money the poorest 20% gets gives a different list than the list of countries with lowest Gini. The 20/20 ratio gives Japan, Czech Republic and Finland as the countries with least income equality, while Denmark, Sweden and Norway have the lowest Gini coefficients. The Gini index is a subjective presentation of income equality level – just as right as the 20/20 ratio –, and yet is it shown in every article. /á(!) 21:46, 1 September 2014 (UTC)
I support adding the Democracy Index, but not the other two. Press freedom is a very specific issue, whereas perception isn't reliable data. --NaBUru38 (talk) 19:46, 2 September 2014 (UTC)
This would be already quite good, because the Democracy Index reveals the remarkable difference between Qatar and Luxembourg, or between Brunei and Norway, respectively, and there is a significant correlation between freedom of speech and level of democracy. (The Press Freedom Index was proposed as a proxy of freedom of speech.) /á(!) 22:44, 3 September 2014 (UTC)

New user status level/new protection level

Is there any way that a semblance of common sense could be applied to the current designations of user status, and, relatedly, to how article protection is done?

Currently we have "autoconfirmed users". To be "autoconfirmed" on English Wikipedia you have to have been registered for 4 days and made at least 10 edits [4]. Ten freakin' edits. How long does it take you to make ten edits? I can make ten edits in under five seconds (I am 100% certain that most users can beat that time easily). I really really hope that this is some archaic throwback to the early days of Wikipedia, like 2002, when very few people edited the encyclopedia, and did so rarely, so back then this low threshold made some sense. Otherwise it's just some supreme nonsense. We are not in 2002 anymore and this requirement is completely superfluous.

So here's proposal #1, the Minimal proposal: Drop the "10 edits" requirement from what it takes to be autoconfirmed. This is just common sense which shouldn't even have to be explained and doing so will have no real effect on editors what so ever. It's just recognizing that... it's not 2002 anymore.

But obviously, having an edit requirement is actually a good thing, which is why this now-ridiculous threshold of 10 edits was put in there in the first place. It's just that now, the threshold should be much higher. And in fact, other language Wikipedias do set a much higher level (usually these are the ones with some kind of flagged revisions). So how about getting realistic and setting the auto-confirmed standard at at least 300 hundred edits. Even that is ridiculously low. If it takes me less than 5 seconds to make 10 edits, it will take me less than two minutes to make 300 edits. Any person who wishes to cause trouble around these parts has only to exert minimal effort to meet that (proposed, higher) standard. Really, the threshold should be at 1000 or more edits. But I understand there's institutional inertia here and all that, so... baby steps.

Second, under the generous assumption that it's recognized that the current system of "autoconfirmed users" is just plain idiotic, we need to revisit article protection. Right now we have either semi-protection or full-protection. These are about the two worst options that could be implemented.

Under semi-protection, disruptive users just have to wait four days, go to effort of making ten edits, and then they're free to go. Of course, somewhat smarter disruptive users, will start an account, make ten edits and then just let it sit there for a year or two, then utilize them again when the real edit warring/disruptive activity needs to be done. Anyone who's been involved in content writing or even content supervision knows very well that this is a very common phenomenon (throw away sleeper accounts) across the encyclopedia. Hence, semi-protection doesn't do crap. It's really "nothing".

At the other extreme we have full-protection. Here, only admins are allowed to edit articles, and any proposed changes by non-admins need to be floated on the talk page first. Under ideal circumstances this would work IF: 1) admins who full-protect pages actually bothered to keep track of these pages and, again relateldy, 2) the admin corps was skilled in content-related edits. We can AGF the first part, but it's clear as day that most admins do not become admins because they are familiar with content editing. There's actually nothing wrong with that. Different people have different skills, some people are good at writing content and others are good at administrative work. The problem is that "full protection" forces the people who are mainly good at administrative work to engage in the content work which they are completely not suited for. So mostly... they don't do it.

The end result of this - the combination of the fact that troll-ish new accounts can easily bypass the joke that is "semi-protection" and the frustration with being unable to edit a page which is "fully-protected" by non-admin but established users is that serious editors are leaving Wikipedia. More and more, which is something we're all aware of.

What we need is an intermediate level of protection and a new level of status, which is higher than the presently silly "autoconfirmed" user one, but not "admin".

So here is proposal #2: establish a status which requires 1 year on Wikipedia, 1000 edits and a minimum threshold of these in article space. Establish a protection level which allows these users but not the "I made 10 edits four days ago, now I get to vandalize Wikipedia articles all I want" ones edit.

 Volunteer Marek  00:47, 31 August 2014 (UTC)

  • I think what you are talking about is fundamentally a "vested contributor" status. While I don't really have a fully fleshed out opinion on this proposal, the one unintended consequence I think this may overlook is that, right now, full protection is actually quite rare an occurrence, and tends to get withdrawn very quickly, largely because it is so onerous for admins to maintain. The low bar to autoconfirmed status means that by default, en.wikipedia is about as strikingly close to the ideal of "the encyclopedia anyone can edit" as can be done feasibly. I think that any conversation about implementing a new "highly protected" status would need to address the possibility of disturbing that equilibrium that so effectively encourages open editing on en.wikipedia in practice as well as in theory. VanIsaacWScont 02:07, 31 August 2014 (UTC)
Thanks for the input. A couple of points.
First, overall, given that Wikipedia has more than 4.5 million articles I'm sure that full protection is indeed rare. However, if we limit the scope to critical, or highly viewed, or controversial articles - or some combination of these - the situation is different. On these, it's frequent enough to be a hindrance or at least an annoyance.
Second, you're also right in that full protection tends to get withdrawn very quickly. But that's a symptom of its dysfunctionality rather than a perk. Basically what happens is that an important article suffers disruption, it gets fully protected, serious editors then cannot edit the article and get extremely annoyed so then they bug and harangue the admin who fully protected it, so then after some back and forth (and some potential and unnecessary drama, even AN/I discussions) it gets lifted. The fact that full protection is "quickly withdrawn" is evidence of the fact that it sucks and that it doesn't work. Not a testament to its viability.
And you're also right about the third issue - the lowbar to autoconfirmed status does mean that pretty much "anyone can edit". Ok, having admitted that, we can go two ways. One: if it doesn't mean anything why even bother with it? Why even have "autoconfirmed status"? If we really want "everyone to edit" why bother with the hypocrisy of this label and why even semi-protect articles? (A more honest approach would be to simply ban unregistered IPs from editing certain articles). Two: despite the high falutin' rhetoric, we actually DON'T want "anyone" to edit the encyclopedia. We ban people all the time. We waste tremendous amounts of time reverting vandalism. And disruptive edits. And sock puppets of banned users. And sock puppets of vandals. And sock puppets of banned vandals. Etc. We obviously WANT a certain threshold of edit quality to exist and if somebody cannot meet that they're not part of that "anyone" that can edit. That "ideal" that you mention is a "founding myth" which was actually never true in the first place (even back in 2002 they blocked people). It's time we grow up and admit to ourselves that certain standards are necessary (we even have essays, like WP:COMPETENCE or WP:NOTHERE) which pretty much say it).
Finally, and this is in some ways fundamental, the problem is that this is NOT an "equilibrium". An "equilibrium" implies a state of stasis, a constant, a situation which can be expected to persist for the foreseeable future. This isn't it. We're loosing editors, and what's worse, we're loosing *quality* editors. And a lot of that has to do with the issues outlined above. I'd elaborate on this point but we'd be getting off topic. What we have now is an *outcome*, not an *equilibrium*. A bad outcome too, and more importantly an unsustainable one.
 Volunteer Marek  03:42, 31 August 2014 (UTC)
@Volunteer Marek: would something like pending changes level 2 work, if the bar to the userright was raised to reflect the new level required by such edits? Alternatively, we could create something like TemplateEditor, and use it on protected pages more (like it seems to be on a few pages now). --Mdann52talk to me! 07:04, 31 August 2014 (UTC)
@Mdann52: That would definitely be a step in the right direction, although if it were up to me I'd move that green box one more square to the right (I'm not clear on why Reviewers wouldn't be allowed to edit - presumably because this Template Editors would be a newly created category?). Those charts actually make my point very nicely - there's semi protection and then there's full protection, and then there is this huuuuggggeee area in the middle. Right now we have a "it really has no effect" policy and we have a "it has a devastating effect policy". Common sense should tell you that we need a bit more... nuance. Very very rough kind of nuance. Volunteer Marek  07:56, 31 August 2014 (UTC)
template editor is a reletively new right, that was created for this very reason (a lot of non-admins were better at editing templates than admins). If you can get support for introducing, lets say a "protected editor" user right (to allow fulfilling edit requests and making uncontraversial changes on full-protected pages), then it should be fulfulled with little complaint on the dev side of things. --Mdann52talk to me! 08:45, 31 August 2014 (UTC)
Though I don't feel like supporting the main proposal, I think spinning out the edit full protected right from the admin package is something worth looking into. Obviously such users would have to act as admins in that situation, i.e. not make controversial changes or any significant ones without talk page consensus; also, a policy about granting the right would be needed, say, answering x semi-protected edit requests correctly, demonstrating respect for consensus. Perhaps make this a separate proposal, Mdann52? BethNaught (talk) 10:39, 31 August 2014 (UTC)
@BethNaught: I'm currently working on another similar proposal (#OTRS members above), but will get round to this once that one is RfC'd and in progress. --Mdann52talk to me! 17:49, 31 August 2014 (UTC)
  • A valuable proposal. This could lead to a desirable simplification of the user rights system: we could create a general "trusted editor" status, amalgamating:
  • rollbacker
  • reviewer (i.e. can approve or reject pending changes)
  • autoreviewer (i.e. own new pages not patrolled)
  • can edit semi-protected pages
  • more controversially - can delete pages.
The pending-changes system would then be abolished as identical in effect with semi-protection.
Approval for the trusted-editor right would be by (1) a certain number of edits, (2) a certain time since account opened, (3) in-depth examination of editor's record by an admin (two admins?); and the right could be withdrawn by any admin with reasons given to the editor: Noyster (talk), 10:00, 31 August 2014 (UTC)
@Noyster: are you proposing we get rid of the reviewer/rollback usergroups, or have another one that incorperates the rest of them? FYI, the request to delete pages will not be added to the group by the foundation dev's, because the ability to see deleted content requires a RfA-like process, so I feel that there is little chance of the last point being implimented sucsessfully... --Mdann52talk to me! 17:49, 31 August 2014 (UTC)
I actually really like this proposal in concert with a "high protection" level; it both simplifies the current cadre of advanced user rights (reviewer? rollbacker? autoreviewed?) and provides a means of relaxing the overkill of many long-term fully protected pages. As to your concern about viewing deleted material, Mdann, I guess the fundamental question here is whether there is a reason why the ability to delete pages needs to be bundled with the ability to view deleted content. If these were, in fact, decoupled from each other, what would be the obstacles, both technical and practical? As far as I can see, the biggest hassle would be the creation of Criteria for Speedy Undeletion to complement the current WP:CSD, perhaps as a subsection of that policy, for cases when material is accidentally deleted by someone who is unable to undelete (undeletion is fundamentally an ability to view deleted content). It would also introduce a small deletionist bias in the system, so it would need a pretty extensive review process. I certainly think it's an idea worth exploring in more depth. VanIsaacWScont 21:28, 31 August 2014 (UTC)
@Vanisaac: I believe (I may be wrong) that they are bundled together on the MediaWiki side of things. I'll look into it. --Mdann52talk to me! 06:02, 1 September 2014 (UTC)

Regarding the trusted-editor right, a similar user right was proposed in April 2013 and did not gain consensus. SiBr4 (talk) 20:26, 31 August 2014 (UTC)

More generally, see also Wikipedia:Perennial proposals#Hierarchical structures. The community has historically been wary of adding more levels of protection to articles and to giving people some parts of the core admin toolkit without the rest. Anomie⚔ 11:46, 1 September 2014 (UTC)
  • Marek, you can make ten edits, I can make ten edits, everyone here can make ten edits, in maybe a minute. A newcomer who is barely grasping wikimarkup can't. More importantly, no, there's no indication that new vandals are anything to do with why people are leaving Wikipedia. Long-term contributors actually have a remarkably high retention rate - it's the newcomers who are struggling - and blocks for vandalism or disruptive behaviour have been going down continuously, in absolute terms, since 2009. Ironholds (talk) 15:21, 1 September 2014 (UTC)

The 10 edits are nothing, but the 4 days are significant. I was an admin prior to semi-protection and auto-confirmed. It sucked.

Those 4 days make a huge difference. Yes it is easy to wait 4 days but it takes 10 seconds to block someone. Since semi-protection and autoconfirm came in it has gone from very difficult to very easy to stay on top of socks.

Even if the person makes 20 sleeper accounts it is still easy to revert/block/ignore in minutes and they still need 4 days to make more.

I think the threshold needs to be kept low in order to encourage new users. Even a brief delay is enough for most socks to get bored and move on while giving admins a lopsided advantage over them. Chillum 15:31, 1 September 2014 (UTC)

  • Oppose any changes mostly per Chillum, but also because we shouldn't make fundamental changes to how Wikipedia operates and it's philosophy merely because of vandals. The low threshold allows good faith editors easy access to all of Wikipedia with a minimal effort, and balances that with enough of a restriction to avoid the throw-away accounts Chillum notes. While certainly annoying, these persistently socking vandal is less of a problem, in terms of volume of people, than are the newbies who want to contribute in good faith. We should be doing everything we can for the second group. The first will always be with us, and isn't worth alienating the newbies to institute such a drastic change. --Jayron32 02:38, 3 September 2014 (UTC)
  • Comment: The 1000 edit criteria is a crude way to compensate for the fact that it's possible to deliberately spam worthless edits. For a good editor who spends time on good edits, 1000 is a pretty substantial bar to pass. What's really needed (if something like this is done) is some criteria that isn't as trivially easily gamed as simple edit count. Alsee (talk) 21:25, 3 September 2014 (UTC)
    • Reply comment: Every single admin knows the tell-tale signs of a vandal account eating through their first ten edits, as do most non-admin vandalism patrollers. Without delving into WP:BEANS-type stuff here, it's really obvious when we see this, and not hard to identify. The 1000-edit count doesn't help us stop bad-faith accounts (of which account for a tiny fraction of all new accounts created at Wikipedia anyways), as much as it does to discourage new users from becoming full contributors. A balance needs to be struck, and 1000 edits is WAY too much in terms of harming new user participation, against the small benefit of stopping a few vandals. Even if it stopped a lot of vandals, we do fine enough doing that using traditional means (AIV, etc.) Contrary to popular belief, we're not being overwhelmed, the system keeps up and squashes most vandals within minutes, and those of us that have been here for many years aren't even annoyed by them anymore. This is using a shotgun to do a flyswatters job, and has too much collateral damage to be useful. --Jayron32 23:44, 3 September 2014 (UTC)

Silent looping autoplay video

Animated GIF really sucks. Everyone knows it. It has limited colour depth and inefficient encoding, meaning large file sizes. Surely it can't be the future of a media-rich internet?

What do you think of the idea of allowing silent autoplay looping WebM/Theora video, as a replacement for animated GIF? An example use case would be File:Lunar libration with phase Oct 2007 450px.gif which is currently on Moon.

Implementation details: some special parameter on the File: link would activate the feature, maybe [[File:Foo.ogv | autoloop]]. If a sound stream is present in the file, it would automatically be stripped in server-side transcoding. -- Tim Starling (talk) 08:33, 26 August 2014 (UTC)

I like the stripping of the audio channel. I wonder about browser (and mobile device) compatibility, how many people would see "broken plugin" or something like that? Anomie⚔ 10:18, 26 August 2014 (UTC)
Judging by commons:Commons:Media help, IE and Safari (iOS and OSX) users would be in trouble, but everyone else would be fine. -- Tim Starling (talk) 16:37, 26 August 2014 (UTC)
people who voluntarily use IE have personal issues beyond the scope of Wikipedia to fix... --Jayron32 19:21, 26 August 2014 (UTC)
Maybe we could transcode from WebM/Theora to GIF as a fallback for IE, iOS etc. -- Tim Starling (talk) 20:42, 26 August 2014 (UTC)

If nobody cares (excepting people on my team) then I don't think I will do it or push for it. Plenty of other things to work on. -- Tim Starling (talk) 00:16, 1 September 2014 (UTC)

I find the looping videos very annoying. We need a way to set the default to "not playing" so that people need to click the image to turn it on. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:39, 1 September 2014 (UTC)
You're saying that all animated GIFs should be treated in this way? -- Tim Starling (talk) 01:35, 1 September 2014 (UTC)
All animated GIFs on a page can be stopped by pressing a key (although Firefox now needs SuperStop for that). After admiring a looping autoplay video, how could it (or all of them) be stopped? Johnuniq (talk) 02:23, 1 September 2014 (UTC)
What a number of us are requesting is a parameter that requires GIFs to be clicked before they play. So that editors of an article can decide if the want it to play continuously or only play when clicked on.Doc James (talk · contribs · email) (if I write on your page reply on mine) 11:59, 1 September 2014 (UTC)
If we did that, and also implemented feature parity between animated GIF and looping video, we would also need a non-autoplay loop parameter for videos, right? Say, "clickloop" and "autoloop", and the default would be autoloop for animated GIFs and single play for videos. You say "a number of us", do you know where this was discussed? -- Tim Starling (talk) 22:47, 1 September 2014 (UTC)
Yes discuss is here Talk:Multiple_sclerosis#Animation Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:28, 2 September 2014 (UTC)

Auto play is extremely annoying, let's avoid it please. --NaBUru38 (talk) 19:26, 2 September 2014 (UTC)

Yes, it soaks up bandwidth, pages take much longer to load, and while they're loading you can't scroll down. All you can do is try the "back" button and hope that the video player hasn't hijacked it so that you can't get off the page until the adverts have played through. --Redrose64 (talk) 22:16, 2 September 2014 (UTC)
Adverts? What? It sounds like you're complaining about something that is not likely to be what we'd ever have here. Anomie⚔ 23:27, 2 September 2014 (UTC)

Since nobody really seems to want this, and given the current problems with delivering video to IE and Safari, I think I'll just leave it for now. I guess animated GIF will be good enough for the next few years. -- Tim Starling (talk) 00:20, 5 September 2014 (UTC)

Extra button to view history

Dear all,

I would like to propose adding an extra button to the top of the page when viewing a history. For example this request page. On the top there are 3 links: "Older revision, Latest revision, Newer revision". However, if you want to know what happened to a request on that page, using the older/newer revision buttons is too slow, moving 1 step at a time, when 100 edits might be in between the request and the answer. You can go to the history section and start going back, but this means searching, and on larger pages it takes some time. I suggest adding an extra button that immediately sends you to the "history section" of that edit, so you are directly at the right spot in the history tab, and can see the 50 edits directly around the edit.

This same request was made to wikimedia-tech on Bugzilla 7 years ago, see [5]. They stated "This would probably not be very hard to implement", however up to date nothing has been done. I am not a Bugzilla user or developer, yet I think this change is usefull and I think we should have it. It gives no disadvantages. I think the only way to get this change is to get some attention for it. I have posted a request on meta ( that can be edited by all, unlike bugzilla) and suggest that people reply there to state their opinion on the change. Thank you very much,

Sincerely, Taketa (talk) 10:15, 2 September 2014 (UTC)

Sounds like a good idea. Doc James (talk · contribs · email) (if I write on your page reply on mine) 10:23, 5 September 2014 (UTC)

Watchlist: date and reason

Moved from Wikipedia:Village pump (idea lab)/Archive 14 § Watchlist: date and reason
Tracked in Phabricator
Task T6354

I first placed this at the Idea lab but I think this is a better place.

When I add a page to my watchlist I would like to be able to put a comment which would appear next to each item on my Edit watchlist page. This would be used to remind me when and why I put it there. Often when I look at this list I find that I have forgotten the reason it's there if it's been a while since I looked at it especially if I didn't make an edit at the time. I could put this info in my sandbox or on another subpage but this would be a much more convenient method. Jodosma (talk) 08:57, 2 September 2014 (UTC)

Proposed changes to sourcing requirements for the lead sections of medical articles

FYI
 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Medicine-related articles#References in the lead.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:33, 7 September 2014 (UTC)

Comparing versions

When I compare versions of articles (in the History mode), after marking the two versions to be compared, I have to scroll to the top or bottom of the list of changes. Sometimes this is a very long ways. Can't we put the "do it" button sliding along the left of the column so it is directly accessible? Kdammers (talk) 00:30, 7 September 2014 (UTC)

@Kdammers: If the history is very long (up to 5000 revisions may be listed simultaneously), and you're comparing two revisions a long way apart (I once compared two revisions about seven years apart in time, about 200 revs in distance), you may still need to scroll some distance to get to that spot in the sidebar. But there is an alternative: hover the mouse over the Compare selected revisions button and you should see a tooltip like  See the differences between the two selected revisions of this page [...]  That last part, which I've shown as "[...]", is the access key sequence that moves focus to the button for your OS/browser combination; you then need to press either the Enter key or the space bar to action the button. For example, I see "[Alt+Shift+v]", because I use Firefox under Windows. So, select the two revisions that you wish to compare, and go for Alt+⇧ Shift+V or equivalent, then ↵ Enter. --Redrose64 (talk) 09:44, 7 September 2014 (UTC)

Option to not break watchlist by day

It would be nice to have the watchlist NOT broken by day. When I log in in the morning, I want to see all changes for the last X hours. Not all changes since midnight, and then changes up to midnight somewhere else. Thoughts? Gaijin42 (talk) 14:38, 4 September 2014 (UTC)

  • Support I would also like to see this. I tend to check multiple days worths of edits at a time on the articles on my watch list. The break down by days just adds a bunch of extra clicks I have to do to find all the changes since I last looked at the article. In particular the behavior of the preference "Expand watchlist to show all changes, not just the most recent" is less than ideal when a page has changes covering multiple days. I really would like a single click from my watch list to the diff of a page between the last time I checked it out to the current version. The changes since last visit link however is restricted to the current day. PaleAqua (talk) 00:24, 5 September 2014 (UTC)
@Gaijin42 and PaleAqua: I can see several days at once, so I'm trying to work out the problem here. What are your settings at Preferences → Recent changes for:
  • Group changes by page in recent changes and watchlist
  • Show Wikidata edits by default in recent changes
and at Preferences → Watchlist for:
  • Days to show in watchlist:
  • Maximum number of changes to show in watchlist:
  • Expand watchlist to show all changes, not just the most recent
  • Hide minor edits from the watchlist
  • Hide bot edits from the watchlist
  • Hide my edits from the watchlist
  • Hide edits by anonymous users from the watchlist
  • Hide edits by logged in users from the watchlist
  • Show Wikidata edits in your watchlist
Not all of these will have a direct bearing on the matter: but I want to see how your setup differs from mine. --Redrose64 (talk) 08:46, 5 September 2014 (UTC)
I'm in the same situation as Gaijin42 and PaleAqua: I can see several days in my watchlist but they're grouped by day. The "n changes" link for a busy article that appears in yesterday's group and today's group too only shows that day's changes. The entry in today's group doesn't have a "changes since last visit" link for an article that's changed not just today but also yesterday since I last visited it. It would be great if you have a combination that works better. My settings are:
at Preferences → Recent changes for:
Y Group changes by page in recent changes and watchlist (de-activate for the "Show Wikidata" option below to work)
- Show Wikidata edits by default in recent changes and watchlist (does not work yet with enhanced changes)
and at Preferences → Watchlist for:
3 Days to show in watchlist:
999 Maximum number of changes to show in expanded watchlist: (I suppose I had a reason - I wonder what it was)
Y Expand watchlist to show all changes, not just the most recent
- Hide minor edits from the watchlist
- Hide bot edits from the watchlist
- Hide my edits from the watchlist
- Hide edits by anonymous users from the watchlist
- Hide edits by logged in users from the watchlist
Y Show Wikidata edits in your watchlist NebY (talk) 11:44, 5 September 2014 (UTC)
My preferences are very similar to NebY's. 10 Days, 1000 changes, Checked yes for expand, hide my edits, show wiki data, group changes. ( all else off ) PaleAqua (talk) 12:34, 5 September 2014 (UTC)
  • Support. @Redrose64: I think the relevant settings are "Group changes by page in recent changes and watchlist" and "Expand watchlist to show all changes, not just the most recent". With those two activated, the watchlist basically contains, for each page, the part of that page's history within the given day. However, when there are unvisited changes from several days (which could be as trivial as last night before and after midnight), the history snippet for each page is not in one place, but there is one snippet for each day. In principle there are two possible solutions to this: a) get rid of the grouping by day entirely; b) keep the section headings, but show all changes to a certain page in a single expandable list positioned at the day and time of the last change. In both cases the disadvantage would be that we need to indicate not only the time, but also the date for each individual change. But I think that's a price worth paying for having all changes to a page in a single list, so this would be nice to have at least as an option (that is, user preference).
Regarding a single click from my watch list to the diff of a page between the last time I checked it out to the current version, that is not exactly the same: with or without grouping by day, such a link is available if and only if the last visited change to a page is within the chosen time span of the watchlist. In this case the "cur" link of the last visited change has the described (and very useful) function. It would be nice if such a direct link would be available even if the last visited change is not within the selected time span. For example, the link "xx since last visit" could refer to "all unvisited changes", rather than "all unvisited changes within the time span of the watch list" or currently "all unvisited changes on that day". — HHHIPPO 22:01, 7 September 2014 (UTC)

A bot trial to generate a very limited sample set has begun, please see Wikipedia:Bots/Requests for approval/EranBot. This trial is to determine what the output type of operations will be to create a reference sample. However, additional discussion as to if the task should be performed at all, and if so under what conditions, may need additional discussion. Please see the bot request and feel free to add any questions for the operator, ערן. — xaosflux Talk 15:51, 22 August 2014 (UTC)

This is one of the initial tests of WP:TURNITIN (proposed), an Internet-based plagiarism-detection service run by iParadigms. The brief overview is that the bot will take edit content, submit it to the third party for scoring, and post a report here. Current examples are here User:EranBot/Copyright. Technically the trials are operating without any issues, however community consensus for this task is unclear, comments at the bot request, or here, are appreciated. — xaosflux Talk 11:00, 26 August 2014 (UTC)
The bot is only running on medical articles as the community supports it use their. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:08, 26 August 2014 (UTC)

Here we have consensus for this bot [6] from WP:MED. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:59, 27 August 2014 (UTC)

  • I've always thought Turnitin violates the copyrights of everyone whose work is added to its database. If Turnitin hashes, or whatever the technical method they use to add it to their database, that portion of the database should be made available under a compatible creative commons license. AFAIK, no one has every succeeded against them, but that doesn't change the fact they are taking our work, making profit off it, and not resharing or attributing. Monty845 23:00, 30 August 2014 (UTC)
  • This is a good example of fair use. They're taking large amounts of content, but that's because they need to: while they're on the "expression" side of the idea-expression divide, they're only concerned with the expression, and the whole process depends on the precise text itself. Look at the fair-use test: (1) Purpose and character — they're definitely not competing with copyright holders, and it's quite obviously transformative. The fact that it's used to detect infringement will probably play into this as well. (2) Nature of the copyrighted work — not particularly relevant, aside from the fact that they're only working with stuff that's already been published. (3) Amount and substantiality — they take lots, but in this case, it's definitely true that "the secondary user only copies as much as is necessary for his or her intended use". (4) Effect upon work's value — nobody's going to use Turnitin as a substitute for a copyrighted work, and as it's used to find infringements, it's quite clearly having a positive effect upon a work's value. Final note This is analogous to Google itself, which downloads massive amounts of content to permit searches, but the ability of search engines to do this was ensured by Kelly v. Arriba Soft Corporation. Nyttend (talk) 14:55, 1 September 2014 (UTC)
  • Suggestion: Should this be approved (which I support), I suggest that rather than going directly from medical articles to all articles, we take an intermediate step of applying it to engineering articles then movie and music articles. There exists a possibility that the types of plagiarism and non-plagiarism that occur in our medical articles are non-typical enough that it would be useful to gather data from some other areas of Wikipedia. --Guy Macon (talk) 22:38, 7 September 2014 (UTC)
Will need to see if we have the bandwidth before we expand. Additionally need a community willing to follow-up before we will begin developing possible concerns in the topic area. Doc James (talk · contribs · email) (if I write on your page reply on mine) 10:28, 8 September 2014 (UTC)

Proposal to disable "Allow saving code with errors"

Please see WT:Lua#Proposal to disable "Allow saving code with errors". Jackmcbarn (talk) 21:15, 8 September 2014 (UTC)

Screenshot with the small proposed change to the page circled in magenta to make it easier to find.

An example of what this could look like is on the article on heart failure. If there is support for this proposal the word "authors" and link to the list of authors would go within the line of code that creates "From Wikipedia, the free encyclopedia".

When a person clicks on the word author it takes you to X! tool here [7]. Preferably the heading "top editors" would be changed to "authors" and that section would be moved up to below "general statistics". I am not sure what punctuation should be used and am open to suggestions / variations.Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:15, 23 August 2014 (UTC)

Discussion (Adding author link)

There is a common misunderstanding regarding who writes Wikipedia. All we state now in the byline is that the text is "From Wikipedia". Adding the word authors and having this word link to a list of authors would increase transparency to our readership.

Another potential benefit is that making it clear that Wikipedia is written by people, people likely very much like the person reading the article in question. It may thus increase people's willingness to edit and this could be easily studied.

Yes I do realize that one can find this information other ways. One can click on the "history" tab. Than click on "revision history statistics" but that does not clearly lead people to whom the authors of the text are. The word history does not lead me to think of authors or editors. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:15, 23 August 2014 (UTC)

In the history page, we can customize everything on the page legend, it is stored in MediaWiki:Histlegend, changing the external link anchors is quickly done if that will help? — xaosflux Talk 23:25, 23 August 2014 (UTC)
The place one expects to see the authors listed; however, is in the byline. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:27, 23 August 2014 (UTC)
I don't really have a strong opinion on if this should be adopted, but if it is I'd suggest it's placement either be a page tab (perhaps incorporating Special:Cite), or else incorporated in to the tag line area From Wikipedia, the free encyclopedia. Having it floating up in the area you have it now seems out of place, especially when used in other display layouts such as mobile view. — xaosflux Talk 23:55, 23 August 2014 (UTC)

So by "would go within the line of code that creates "From Wikipedia, the free encyclopedia" i mean as you suggest "incorporated in to the tag line area From Wikipedia, the free encyclopedia". The example you see on heart failure is just a mockup of how it could look and only works for desktop and with vector. It was not a suggestion on how it would be programmed. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:14, 24 August 2014 (UTC)

I think it would look better there, perhaps along the lines of:
From Wikipedia, the free encylopedia (contributors)
Using PAGENAMEE, and making the external tools more prevalent on the top of the Cite tool? — xaosflux Talk 01:13, 24 August 2014 (UTC)
N.B. that is the MediaWiki:Tagline page. — xaosflux Talk 01:14, 24 August 2014 (UTC)
Yes I like the "contributors" in brackets. I still think going to the list of authors is best. We could than add the Special:Cite to that page. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:25, 24 August 2014 (UTC)
Changing the tagline is highly visible, to may even need an RFC to run for a bit; if that is where you want this to end up, you should start a section over in MediaWiki_talk:Tagline and link in from locations interested parties will visit (like here). Note, there are translations of that page in to many languages. — xaosflux Talk 01:38, 24 August 2014 (UTC)
Yes agree a RfC will likely be needed was just going to allow some initial discussion first. Only discussing this for English Wikipedia at this point in time. Have added a link here from meta. I guess we could consider broadening the discussion to all languages of Wikipedia thought. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:42, 24 August 2014 (UTC)
Oh no, I mean on enwiki we have additional versions of that page based on user language preferences, no big deal,just will need translators for each. — xaosflux Talk 01:52, 24 August 2014 (UTC)
Strongly opposed. It's a pathway to egotrippers and gloryhounds, a feature just begging to be gamed to increase their "rankings" on prominent or notorious articles. ("I'm the lead author on penis enlargement!") --Orange Mike | Talk 22:40, 25 August 2014 (UTC)
People who wish can do this already. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:17, 26 August 2014 (UTC)
  • Oppose because the history tab exists. --Jayron32 22:41, 25 August 2014 (UTC)
  • Strongly support because a) to the casual reader, there is no intuitive way to see who is responsible for the content and b) whether we like it or not, many people, especially those with knowledge of topics sorely lacking in Wikipedia, need to have some kind of credit. This is simply more in line with what is done in many of the publications we rely on.Thelmadatter (talk) 00:38, 26 August 2014 (UTC)
  • I dropped a few notes at mailarchive:wikimedia-l/2014-August/074133.html. --MZMcBride (talk) 01:54, 26 August 2014 (UTC)
    • If Willy on Wheels drops by and adds the word "scrotum" to a random article (assume it is not appropriate to the article), does he get counted as an "author" in this scenario? bd2412 T 04:16, 26 August 2014 (UTC)
      • If Wikipedia were to consistently hide (revdel or whatever the term is) vandalistic edits, would that have the side effect of ensuring the people who made them weren't listed as "authors"? -sche (talk) 04:26, 26 August 2014 (UTC)
  • Oppose. Not because of the history tab - I'm actually a really big fan of increasing the prominence of the fact that did you know you can edit and this was made by people just like you because however much we assume we're good at that, we actually do a surprisingly poor job. But the current implementation seems likely to interfere with readership - we're directing people to a potentially-unstable labs tool that forces them to navigate away from Wikipedia and all of its links to other knowledge and other content. We are a project dedicated to knowledge and the interconnectedness of all things, and this setup sends users to a dead end. I'd be really supportive of, say, an experiment to gauge the impact of including a link that pointed at...I don't know. A quick summary of how WP is written by random joes and can be edited by you, too. But it would have to be an actual experiment. This looks likely to do unexpected things to readership that we can't currently track, and produce (potential) positive results we have no way of measuring. Generally-speaking I'd like UI changes to be both measurable and measured. Ironholds (talk) 06:41, 26 August 2014 (UTC)
We could put the list of authors / contributors within a Wikipedia page and thus not send someone to Wikimedia labs.
The whole point is Wikipedia is NOT written by random joes and this is a misconception that is spread not only by the media but many others. Our core community of medical editors is about half health care providers and 85% have at least a Bachelor. Doc James (talk · contribs · email) (if I write on your page reply on mine) 07:15, 26 August 2014 (UTC)
Okay. What advantage do we get from solving this, then? It seems to actively contradict the potential advantage you raise around editor engagement; I strongly doubt 85% of potential editors have bachelors, or that 50% are nurses or doctors. Ironholds (talk) 14:48, 26 August 2014 (UTC)
These are not the stats for potential editors. These are the states for the current core editors of Wikipedia's medical content. Do not understand you comment about "contradicting the potential advantage". Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:07, 28 August 2014 (UTC)
  • Oppose per Orange Mike and the fact that we have a history tab... not to mention that I am not at all sure about where this would really link. Off wiki to some form of statistical data seems out of the ordinary to me.--Mark Miller (talk) 06:57, 26 August 2014 (UTC)
  • Comment Remember that most "authors" will not be identified by their real names as on a book cover or journal article, but only by usernames that are variously silly, enigmatic or unreadable and mean nothing except to Wikipedia regulars: Noyster (talk), 08:04, 26 August 2014 (UTC)
A number of the core members of WP:MED use their real names. Doc James (talk · contribs · email) (if I write on your page reply on mine) 08:15, 26 August 2014 (UTC)
  • -1. Wiki by definition means attributing my text as Wikipedia. Quoting Wiki:
"While a wiki is a type of content management system, it differs from a blog or most other such systems in that the content is created without any defined owner or leader, and wikis have little implicit structure, allowing structure to emerge according to the needs of the users."
WP:REUSE does allow to attribute by linking to the article. --Gryllida (talk) 12:30, 26 August 2014 (UTC)
  • -1. Oppose listing top editors only; WP:REUSE requires (as an alternative to linking to the article) listing them all with a "Any list of authors may be filtered to exclude very small or irrelevant contributions." comment; this, I understand, implies listing around 99% of the contributors. Every small contribution should count. --Gryllida (talk) 12:30, 26 August 2014 (UTC)
  • -1. Additionally, people would try to get onto the 'top editors' lists, count the amount of articles they 'co-authored'; this all has negative implications (see Karma). Every small contribution should count. --Gryllida (talk) 12:30, 26 August 2014 (UTC)
  • On a related note, if you'd like to raise awareness, just make the edit button bigger and put a reasonably well-visible "anyone can edit" line into the interface. Use the space wisely. That'd suffice. --Gryllida (talk) 12:30, 26 August 2014 (UTC)
  • If you go into it, please allow people to opt out. I'd not like to be, personally, subject to being listed in such author bylines selectively (i.e. only at those where I got into a top editors list). --Gryllida (talk) 12:33, 26 August 2014 (UTC)
    • We already have ways of determining who has edited an article. Opting out is not currently an option. We are NOT listing any authors by name in the by-line, we are only providing a link called authors or contributors. You can see it on the page heart failure Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:52, 26 August 2014 (UTC)
  • Support This would be an excellent way of encouraging content contributions. Note that staff such as EpochFail are working on ways of improving attribution for our content and there is external research too; for example, see this paper, which states

    The Wikipedia Reuse Policy requires people reusing Wikipedia material to either provide a link to the original article and revision history, or to cite the most prominent authors of the content. Furthermore, in the Wikipedia community it is felt that proper content attribution is an important way to acknowledge and reward contributors, and to foster participation and contributions from communities where authorship has been traditionally recognized and rewarded, such as the academic community.

If these ideas are brought together then our contributors will get the credit that is their due and that the licencing requires. The history page is currently quite inadequate for this as its purpose is to show the detailed history of changes and so the authorship of our articles is obscured by this mass of fine detail. Andrew (talk) 12:38, 26 August 2014 (UTC)
Er. Well, people are working on research around editor engagement and attribution, but the paper you've cited doesn't seem to support that at all. Moreover you're not actually citing a part of the paper subject to experimental conditions, you're citing a background section, which is best understood as the author's impression of how Wikipedia works - and surely we're the people who get to decide how much that reflects reality? Paper citations aren't useful for that point. And just to clarify, if the history page didn't do what licensing required we'd have a far bigger problem. Ironholds (talk) 14:50, 26 August 2014 (UTC)
  • We do have significant attribution problems. For example, I was recently working on yacht delivery. There's a challenge to the copyright status of our text in that article but it's not clear whether the other site got it from us or vice versa. Or there's all those thousands of books produced by VDM Publishing. Ostensibly these were written by the prolific authors Frederic P. Miller, Agnes F. Vandome, &c. but the content is actually taken from Wikipedia and was written by our contributors. Why is "Frederic P. Miller" getting all the credit for our work? When our contributors get little acknowledgement and then see someone else taking the credit for their work, it's not surprising that they decline to do more. Andrew (talk) 15:57, 26 August 2014 (UTC)
  • Except first, this proposal wouldn't solve for the example you bring up, and second, none of the work on editor or edit decline has suggested a problem around lack of motivation in existing contributors. In fact, our strength is that the survival rate of existing contributors is incredibly high: it's attracting newcomers we fall down on. Ironholds (talk) 16:00, 26 August 2014 (UTC)
Yup and we plan to look at if this increases the attracting and retainment of newcomers.Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:08, 28 August 2014 (UTC)
Would be happy with that too. Doc James (talk · contribs · email) (if I write on your page reply on mine) 13:50, 26 August 2014 (UTC)
Well, viewing some of the additional comments below, I think I should expand on what I mean by list of contributors. It would include the owners of the image files, as well as the writers. Now, perhaps this does not all need to be done at once but that is what I would like to see. Alanscottwalker (talk) 14:45, 26 August 2014 (UTC)
Yup if this idea received support should be easy to do. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:04, 26 August 2014 (UTC)
  • Support not authors, but contributors for transparency sake (and likely to improve licensing compliant reuse). Identifying the removers of text is fine as they do contribute to the appearance of the article; in another category altogether, identifying vandals is fine, as they should be identified. It should be expanded to image contributors but the perfect should not be the enemy of the good (transparency). Alanscottwalker (talk) 11:18, 31 August 2014 (UTC)
  • Support – Wikipedia is loosing productive editors at an alarming rate. Anything that can help motivate participation is a good idea and giving credit where credit is due is an effective way of accomplishing this. While there are other ways of determining contribution, this is the most direct way I have seen. Boghog (talk) 14:06, 26 August 2014 (UTC)
  • Support as "contributors" - Makes what is already available in two clicks (Page information -> Contributors) available in one click instead, and makes that link more visible. As this information is already available and all this proposal is doing is making the access to it easier, I don't understand the arguments that this will somehow be dangerous or encourage glory-hounds, at least not any more than what the normal page presentation already does. Would be very happy to see this deployed in a trial run on selected WP:MED articles, for example, and see what the feedback is, or see whether the contributor profile of those articles changes (RCT anyone)? Zad68 14:33, 26 August 2014 (UTC)
  • Concerned Wouldn't this give credit not only to contributors of lasting content but also to contributors of large-scale copyright violations, essays, rants and protracted edit-wars? How would, for example, Audit Commission (United Kingdom) appear? X!'s tool shows one editor has made 41% of the edits and 70% of the text additions by bytes, but doesn't show they have all been reverted. NebY (talk) 15:15, 26 August 2014 (UTC)
  • We could right now without to much difficult remove the two edits involved in a revert from the numbers. Please keep in mind that if everything on Wikipedia had to be perfect before it goes lives we would obviously not have Wikipedia.
  • By the way the tool lists contributors by both number of edits and by bytes contributed. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:06, 26 August 2014 (UTC)
  • Would such edits be removed automatically, and would this include cases such as my example above of Audit Commission (United Kingdom)? If so, would this be done using an existing solution or is it something that should be feasible but has not yet been accomplished? We've been shown a research paper from 2013 but no progress report.
  • By the way, as you'll see from the way I presented the example, I do realise the tool lists contributors in two ways. I do also realise that we can't wait for perfect solutions, but I was startled that a supporter of the proposal would still describe the existing count as "obviously unsatisfactory". I hope you don't think it obstructive to consider potential problems and discuss overcoming them. NebY (talk) 14:42, 27 August 2014 (UTC)
Yes thanks. While it is not perfect this it is simply a single word in the byline. I would imagine it would result in improvements in our analysis of who has edited an article.Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:24, 28 August 2014 (UTC)
  • Support - clarification on this and a link to the authors would benefit the reader. QuackGuru (talk) 03:16, 27 August 2014 (UTC)
  • Support Small unobtrusive link that provides "byline" type info. I think this would be useful to those checking to see which editors are most involved in developing an article. Also useful for general attribution. I think this is consistent with what is found in reliable sources. - - MrBill3 (talk) 06:02, 27 August 2014 (UTC)
  • Support. It adds to transparency. Most casual readers wouldn't know where to find the main authors of an article. --Anthonyhcole (talk · contribs · email) 09:28, 27 August 2014 (UTC)
  • Support - While far from perfect, I'd actually like to see this added or enacted as an option on the left column, perhaps in the tools section. Gathering details of the page's history from the "view history" section seems a bit silly for attribution and while this tool is not perfect it still represents an improvement. ChrisGualtieri (talk) 12:59, 27 August 2014 (UTC)
  • Oppose. We have 'history' and other tools for those who need to know this info—the average reader does not. There is no benefit to the average reader knowing who contributed to an article using a pseudonym. And, by-lines are for newspapers. Edit counts are worthless as an edit can introduce incorrect information, be poorly written, vandalism, or just plain bad. The encyclopedia is a community project, not individually driven, and the focus should remain as a collective work, not a personal one. GenQuest "Talk to Me" 13:23, 27 August 2014 (UTC)
  • Support This might be fun! Also, open source projects often list contributors in a similar manner. It's harder to do when contributions aren't subject to some central authority for acceptance, but it's not without precedent. Protonk (talk) 15:06, 27 August 2014 (UTC)
  • Oppose per GenQuest. (1) It may be that many contributors to medical articles use their real names as usernames, but the proposal appears to apply to articles on any topic. (2) I can't imagine an automated tool that could reliably make the qualitative judgement on the value of every edit in an article's history: Noyster (talk), 15:48, 27 August 2014 (UTC)
We could just introduce this on medical articles if this is a concern for the wider community. Our authors are as you mention more transparent and our lack of transparency is criticism I have to deal with when I speak about Wikipedia and medicine. Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:27, 28 August 2014 (UTC)
Then yes, that sounds like you're trying to generalise specific criticism you have heard voiced (around the primacy of attribution in a medical context, so patients/readers can understand who is providing information) to the project as a whole. How much was this proposal driven by those (very subject-specific) concerns? Ironholds (talk) 07:21, 28 August 2014 (UTC)
I believe that this is an important move for medical articles. I have no strong feelings regarding the rest of Wikipedia (but lean towards it being a good idea). We could apply it only to medical articles and then present something in 6 or 12 months on the effects it had (we do have fairly good data on editor numbers and could study the effects on a random selection of articles versus a group of controls). Doc James (talk · contribs · email) (if I write on your page reply on mine) 07:47, 28 August 2014 (UTC)
  • Support per Zad 68's point. Also, a fairly new change to the mobile version is that it now displays the name of the most recent editor. I think that should occur on the desktop site as well. Increasing transparency of Wikipedia's authorship is key to its legitimacy. --Holdek (talk) 17:23, 27 August 2014 (UTC)
  • Oppose authority from names was tried on Google's Knol and it failed, people who really want to know it will open the edit history anyway for clues or visit the talkpage where the editor names are well visible. Mion (talk) 18:14, 27 August 2014 (UTC)
This is not about authority from names. This is about transparency to our readership. Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:13, 28 August 2014 (UTC)
Right, because pseudonymous nicknames and arcane IP addresses are transparent. --Jayron32 13:43, 28 August 2014 (UTC)
Not all of use use IP addresses and nicknames. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:04, 28 August 2014 (UTC)
Mark Twain is a pseudonym.Thelmadatter (talk) 15:29, 29 August 2014 (UTC)
Excellent point. We are not unique in allowing their use. Doc James (talk · contribs · email) (if I write on your page reply on mine) 19:54, 29 August 2014 (UTC)
Samuel Langhorne Clemens wrote original content. We do not. GenQuest "Talk to Me" 12:47, 1 September 2014 (UTC)
Ah, we very much do write original content. That is how we are able to put it under a CC BY SA copyright. We are not simply a collection of plagiarized content.Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:51, 1 September 2014 (UTC)
No. Authors are original content providers, of ideas, stories, theories, whatever. Such original research, or content which goes beyond sourcing, would be quickly removed here. As Wikipedia volunteers, we only summarize (or edit) into our own words what has been already been written in primary or secondary sources about any given subject. That is why we are referred to as editors, and NOT authors. GenQuest "Talk to Me" 19:19, 2 September 2014 (UTC)
We don't do "original research" but wikipedia editors write gobs of original content just as any encyclopedia editor does. Protonk (talk) 13:59, 4 September 2014 (UTC)
  • Comment - If I were a major contributor to an article that I researched, wrote and continued to refine by hand and then suddenly an editor with automated functions "moves" up to a "by line" level...I would be more than a little concerned and annoyed. That would discourage further input and contributions from editors not using tools to edit.--Mark Miller (talk) 20:55, 27 August 2014 (UTC)
Please note the suggest is NOT to add anyone user name to the "by line". It never has been. The suggestion is just to add a link to "contributors". See example at the top. The data is given both by bytes contributed and number of edits. Thus if you contributed most of the text you would still be linked higher. There is NO moving up to a byline level. Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:13, 28 August 2014 (UTC)
I can not support ANYTHING which used number of edits as a measure of excellence, per my comments above. And number of bytes is no better as a measurement, per the same criteria. For instance, some of us actually improve the encyclopedia by removing many, many bytes of badly written prose, comments, narratives, editorializing....etc.; the list is almost endless. Both proposed parameters are pretty much meaningless in the encyclopedia, and wholly not tenable as a measure of article improvement for the reasons I stated. And I have to ask, just what is gained by allowing the average reader, here for information only, to have an instant link to (for example) the list of the last five "contributors" (or prolific serial vandals who have targeted the article)? If Wikipedia were trying to be a primary informational source, I would understand and support this; however, Wikipedia is a tertiary information source—we report what others have written—we just do it in our own words. Authorship is meaningless here (except for those that would revel in their article / edit / byte counts). Given the stated purpose of Wikipedia, this proposal makes no sense. GenQuest "Talk to Me" 14:45, 28 August 2014 (UTC)
They may not be perfect but they are far from meaningless. These are not measures of excellence but measures of contributions. Many of our articles are far from excellent and still have contributors / authors. It also gives the time line for contributions.
Yes agree that improvement often involves removing large amounts of poorly written text. When article are brought to GA / FA the major contributors are usually listed among the first few editors (at least for all medical articles I have looked at).
Are authors / editors / contributors meaningless? After having dealt with a fair bit of COI I would say that is not the case. The people who write the content are exceedingly important. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:03, 28 August 2014 (UTC)
Strong Support (of the "wtf didn't we do this year's ago?" type). It is just so sensible! Over the years I've been involved with WP you wouldn't believe how often readers / press don't understand where the content comes from or what the history tab signifies. There has been a continuous problem with proper attribution of our content for so long and this is a simple and neat way to do something about that. (btw, on my browser, the text on the test page overlaps with other text) --AlisonW (talk) 23:24, 29 August 2014 (UTC)

Strong support I delete a lot of text, and I am not entitled to copyright for that, so I won't rank highly for number of bytes (nor edit count) Yet I am delighted that those who do contribute prose and images will get clear credit from this. A 'Contributors' link has plenty of meaning and value to anyone who reads the written word (as does the analogous 'credits' when we enjoy TV, movies and podcasts), and even more meaning to those who actually contribute. It will never be perfect. If we copy and paste a sentence from another Wikipedia article, or from another free source with a compatible license, that won't be automatically attributed. Neither will text from the 1911 Encyclopaedia Britannica. (For those reasons, I think the current proposal of 'Contributors' is far better than the original 'Authors'.) Yet despite some small weaknesses, which I are largely fixable later, this is a fantastic idea that is far more digestible than the remote possibility that a reader follows 'More/View history' and realizes that tells them not only what was written, but by whom. Is this really the first time in our history that this has been proposed? By the way, the edit count tools have been around for 6 or 7 years, so I don't consider them to be experimental or unstable. Hroðulf (or Hrothulf) (Talk) 16:20, 30 August 2014 (UTC)

Comment. My opinion is that this type of link should stay on-wiki, perhaps to the Special:Cite tool if it will be implemented. — xaosflux Talk 14:49, 1 September 2014 (UTC)

  • Note: Wandering editors have seen this in wider production and were confused, just answered at WP:VPT. — xaosflux Talk 14:38, 1 September 2014 (UTC)
  • Oppose (FYI, I'm the wandering editor), because that's why we have the history page. If you don't know how to find the history page, you won't know to look immediately below it to find the Contributors link. And I didn't see it in Vector; why are we producing something for newbies and non-editors if one must be familiar with Special:Preferences to see it? Not a big deal, but it's somewhat in the way, and I can't see how it will accomplish the goals mentioned above. Nyttend (talk) 14:44, 1 September 2014 (UTC)
  • Oppose We already have a history button. I don't like the idea of a computer sorting the value of contributions based on volume. Volume is not an accurate measurement of contribution quality. It could lead to gaming to get to the the high score position by making lots of small edits. Chillum 14:42, 1 September 2014 (UTC)
  • Oppose because of problems exposed here. First, we don't have the technology to do this satisfactorily and without crediting large-scale copyright violations, essays, rants and protracted edit-wars. Second, the premise that a "list of authors would increase transparency to our readership" is dubious; only an experienced editor of Wikipedia would find that a typical list of Wikipedia pseudonyms increased transparency or confidence. NebY (talk) 15:35, 1 September 2014 (UTC)
  • Comment I removed this experimental hack trough the template. Absolutely not acceptable from a technical perspective. If you want to experiment with something like this, write a gadget and enable it by default, but we are not adding more of this relative positioned UI elements that are a hell to support in skins, alternate views and and that are defined in CONTENT. —TheDJ (Not WMF) (talk • contribs) 21:54, 1 September 2014 (UTC)
      • Consensus for it on medical articles is here [9]. If you have a better way of implementing it happy to look at. Right now it is being tested to see if any of the concerns raised are legitimate. After this data has been gathered (3 month or so) we can have a wider ranging RfC. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:04, 2 September 2014 (UTC)
  • Support - but consider using wording like "written by contributors like you", to nudge people towards becoming editors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:15, 1 September 2014 (UTC)
  • Oppose. I just stumbled across this on some medical pages, and at first I thought it was some kind of bugzilla thing. Personally, I hate the idea of placing the link so prominently, because this is supposed to be about the content, not the editors. Readers already know that it's "the encyclopedia that anyone can edit", so they can figure out that those "anyones" must be some people. It's not rocket science. As for giving credit to which editors it was on a given page, if I wanted credit, I wouldn't be calling myself Tryptofish. And I have a big objection to the way it has been implemented, by tying it into some infoboxes, so it appears on some pages and not others. Either there is widespread consensus to have it all across the English Wikipedia, or it shouldn't be plopped out on an ad hoc basis. All in all, this thing seems to me to be a slap in the face to everything that Wikipedia stands for. --Tryptofish (talk) 18:23, 2 September 2014 (UTC)
    • Comment And, the whole "It won't fly with wiki-wide community consensus, so damn the torpedoes, let's start another discussion elsewhere (stacked with 100% supporters), and we'll just do it in our project" thing speaks to the whole system-gaming that is denied elsewhere in this very discussion. GenQuest "Talk to Me" 19:19, 2 September 2014 (UTC)
    • There hasn't been much research done on readers (i.e., non-editor readers), but about a fifth of them aren't aware that they can edit, according to what's probably the biggest survey done so far. WhatamIdoing (talk) 22:25, 4 September 2014 (UTC)
      • I don't doubt that research, but it tells me that about a fifth of them have not noticed where it says "anyone can edit". (Well, maybe, if I want to be snarky, it means at least a few of them are too stupid to be editing here anyway.) The real solution would be to have something prominent that says something like "you can edit!", and that links to a help page. This link is not the right solution. --Tryptofish (talk) 23:00, 5 September 2014 (UTC)
  • Strong oppose I also stumbled on this on Tularemia and went to MediaWiki talk:Gadget-ContributorsHack.js asking that is be turned off. I have the following concerns: 1) the information is already accessible in the history tab (both by looking through the page and the first external link on that page; 2) its current location interferes with at least one other gadget; 3) it presents as an internal wikilink but instead directs to an external site not under Wikipedia's control, principle of least astonishment seems to apply; 4) this should be a sitewide approach or at least tied to MediaWiki:Tagline rather than a "hack" attached to an infobox but hovering somewhere which makes it hard to know where the thing is coming from (I found it by searching for the URL in MediaWiki space). Having said that he we included in the tagline in brackets as suggested above a link to the page history not an external link manifesting as an internal link I think that would be a good idea. Callanecc (talk • contribs • logs) 13:21, 4 September 2014 (UTC)
    @Callanecc: It's not MediaWiki:Gadget-ContributorsHack.js. That is a test gadget, enabled for about two users (I'm one of them) showing how the links currently built in to {{infobox disease}} could be done in a different, less controversial, manner. More at User talk:TheDJ#Gadget, Template talk:Infobox disease#Position of floating contributors link and Wikipedia:Village pump (technical)#Contributors link. --Redrose64 (talk) 14:48, 4 September 2014 (UTC)
  • Comment Evidently this is now being inserted in a template on certain articles. Protonk (talk) 13:43, 4 September 2014 (UTC)
    • Yes there was consensus [10] to trial it locally and thus we are. I agree maybe this is not something that is needed on non scientific articles. We are also looking at improving the page that it links to. Doc James (talk · contribs · email) (if I write on your page reply on mine) 15:12, 4 September 2014 (UTC)
      • You wrote elsewhere that We are now testing the concerns on medical articles to see if they are legitimate[11] and Currently we are looking to see if it generates any of the concerns that were brought up during discussion a WT:MED[12]. Can you explain how you will determine if those concerns are legitimate or the problems raised are occurring, and how you will determine the efficacy of this insertion in meeting its stated aims? NebY (talk) 15:46, 4 September 2014 (UTC)
Was going to look at editor numbers with the help of User:West.andrew.g before and after it was turned on on this set of articles and before and after it was not turned on on the rest of the medical wikiproject articles. Also members of Wikiproject Medicine more or less watch all these articles thus we would pick up specific concerns or benefits if they occurred.
Was also going to ask the few hundred academics I am speaking to in a couple of weeks at this conference [13]. So a mix of methods. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:10, 5 September 2014 (UTC)
Aha! The plan doesn't test all concerns raised above but the before/after treated/untreated comparisons look like a good start on examining efficacy. I could make suggestions (some less practicable, e.g. divide your few hundred academics into groups to be asked by different experimenters) and I'm sure others here could make better ones. But what stands out is that the experiment relies on not implementing this proposal to roll out the insertion across Wikipedia. Is it too late to recast this proposal as "We're running a limited experiment (hope you don't mind) which we think should run for x months. Suggestions for experimental design welcome" ? NebY (talk) 08:45, 5 September 2014 (UTC)
Yes so the discussion here was to implement across Wikipedia but there is obviously not sufficient support for that. Thus the discussion with respect to testing it on medical articles here [14] which did get support. Hope is than to come back with some data in 4 months or so and possibly discuss further. Doc James (talk · contribs · email) (if I write on your page reply on mine) 10:18, 5 September 2014 (UTC)
We are also looking at improving the data linked to / possibly moving the data to Wikipedia space. Doc James (talk · contribs · email) (if I write on your page reply on mine) 10:19, 5 September 2014 (UTC)

Scope

I've sat back and commented mostly from a technical point of view, but think there is are some components of this discussion that should be directly addressed:

Should non-content features such as this be consistent across all articles? My inclination is that yes they should, and "consensus" driving for this type of change should be project wide on these non-content components of pages. A discussion on WT:MED determined that there was consensus to make these types of changes, but only to articles that those project members were looking at. This can open the door for a lot of scope creep, if every project team rolls out their own layout changes, especially as many articles overlap multiple projects. Not to wander too far down the slipper slope, but where would this project-specific page layout decision making process end? Should all non-content components of articles be consistent is a question that deserves some more discussion. — xaosflux Talk 14:49, 1 September 2014 (UTC)
Sadly, some projects already so that. And the wider community is unwilling to address, or incapable of addressing, the matter. Even Arbcom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:22, 1 September 2014 (UTC)
These can easily get at odds with eachother, and the overlap potential is huge, not to mention if someone decides to create Wikipedia:Wikiproject User Interface ... — xaosflux Talk 22:41, 1 September 2014 (UTC)
Well some appear to be arguing that:
  1. People do not care about who the contributors of the text are except maybe in medicine
  2. Very few people use real names so this is a bad idea
  3. People will game this
So as we at WPMED think it is a good idea. We believe people do care who writes the content in questions. Many of us do use our real names. And if people try to "game" this by writing good and featured medical articles we do not have an issue with that. So we are testing it out on medical articles to determine if these concerns exist. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:00, 2 September 2014 (UTC)
That's not really what I'm talking about, yes those are valid concerns related to this specific feature, and I don't really have a strong opinion on the matter...my point is that the user interface should be consistent across the entire encyclopedia, and that the consensus required for this level of change is far beyond the agreement of topic-specific editors. Say you had a medical article that is also a stub, and the stub project agreed that stubs should have something else in the tagline, it makes sense to them, but will having different UI's across articles benefit the reader? — xaosflux Talk 01:27, 2 September 2014 (UTC)
That is not a proper comparison. Disease related articles that contain infobox disease are primarily medical in nature. These articles have primarily been edited by members of this project. Thus the group that has developed this content has weighed in in supporting a trial of this idea.
We also do not want a situation like were an outside group like the WMF telling the German Wikipedia that they must have Media Viewer because we need consistency of UI between all Wikipedias.
Doc James (talk · contribs · email) (if I write on your page reply on mine) 02:46, 2 September 2014 (UTC)
It doesn't need to be hacked into {{infobox disease}}: it's a script hosted at Labs (specifically toollabs:xtools/articleinfo/), so it could be built into a gadget. There is already at least one gadget that amends the tagline: at Preferences → Gadgets, enable "Display an assessment of an article's quality in its page header (documentation)" and view any article, e.g. Lionel Palairet. --Redrose64 (talk) 08:17, 2 September 2014 (UTC)
And I already built it. See gadget prefs. Not yet enabled for all yet, and triggers on the hidden category Category:Articles with contributors link, but the idea is clear. Example page. —TheDJ (Not WMF) (talk • contribs) 09:24, 2 September 2014 (UTC)

Get wikipedia to participate in Go-Slow Day!

WP:SNOW close, per below. There is clearly not a consensus to proceed with this. From the below comment by NinjaRobotPirate, if this is really an issue, pouring a bucket of water over your head while editing Wikipedia may help raise awareness (although from what I've read over the past few months, awareness is already pretty high, and I'm not even in the US.....) --Mdann52talk to me! 17:50, 9 September 2014 (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.

There is a movement called 'Go-Slow Day' where websites will show slow loading icons to symbolically show what a slow lane, non net neutral world could look like in a protest against proposals by the FCC for paid prioritization, to show them what kind of negative impact can come from their decision. Larger tech companies are already joining in, and more can be found here on reddit: http://www.reddit.com/r/news/comments/2fg8ky/large_us_tech_firms_plan_go_slow_day_in_protest/ If Wikipedia joined in that would be amazing. It is one of the largest sites in the world, and many would follow in their footsteps.

Thanks for your time. — Preceding unsigned comment added by 68.196.80.164 (talk) 18:32, 4 September 2014 (UTC)

I agree, a discussion and vote needs to be set-up quickly to make a decision on this event. Wikipedia has done so in the past (SOPA-blackout), and this effort should at the very least be discussed. Omegastar (talk) 18:52, 4 September 2014 (UTC)
If you want to slow WP down, at least for editors, then simply opt in to the Visual Editor. Eric Corbett 18:59, 4 September 2014 (UTC)
I knew that SOPA protest would turn out to be the thin end of the wedge. If you want to join a political pressure group then that is your perogative but I'd prefer it if you didn't try to turn Wikipedia into one.--Ykraps (talk) 20:15, 4 September 2014 (UTC)
Strongly agreed. I strongly oppose any further use of Wikipedia for political pressure tactics. 0x0077BE [talk/contrib] 21:26, 4 September 2014 (UTC)
Oppose. I don't think Wikipedia should get involved in political action unless there's an existential threat to the project or a direct threat to our contributors, neither of which are present here. --Yair rand (talk) 21:31, 4 September 2014 (UTC)
Oppose. Yair rand has expressed my view perfectly. HiLo48 (talk) 21:59, 4 September 2014 (UTC)
For. This sets a dangerous precedent that should be neither ignored nor allowed. The internet must remain neutral to protect freedom of information and expression. --Ambrosius5c (talk) 23:32, 4 September 2014 (UTC)
Can you not see the irony in asking for Wikipedia to become non-neutral so that the Internet can remain neutral? HiLo48 (talk) 23:36, 4 September 2014 (UTC)
Indeed I can.--Ykraps (talk) 23:43, 4 September 2014 (UTC)
Perfectly Opposed. I blame the SOPA action for setting precedent for these all-too-numerous to count requests to turn Wikipedia into somebody's soapbox. I opposed even bothering with SOPA, and I oppose even bothering with this. The FCC is doing a fine job, and so are you, so can we get back to writing an encyclopedia now? Thank you, GenQuest "Talk to Me" 00:31, 5 September 2014 (UTC)
No thanks. SOPA/PIPA was a much clearer threat to the kinds of things this project relies on and resulted in attention to a cause with a path for measurable action. This isn't our fight. Protonk (talk) 01:11, 5 September 2014 (UTC)
(edit conflict)Meh. I liked the SOPA protest, personally. Honestly, I'd rather these decisions be made by the WMF. That way, we can blame them and maintain our neutrality, while still getting to participate. But I'm sure if the WMF actually did that the resulting wiki-drama would be... dramatic. --NYKevin 01:13, 5 September 2014 (UTC)
I'm not really too enthused about this. It sounds more annoying than useful. Why don't you write a letter to your Congressperson? Or I guess you could dump a bucket of ice water on your head. That seems to be the trendy form of activism these days. NinjaRobotPirate (talk) 02:48, 5 September 2014 (UTC)
  • Oppose The Wikipedia Foundation seems to be one of the players who are acting against net neutrality. Looks like double standards. --Stefan2 (talk) 10:47, 5 September 2014 (UTC)
  • Oppose FCC is a government agency and will not succumb to pressure that may work on politicians. So this would be a waste of effort. Pressure your congress representative instead. Larger companies can refuse to sign contracts or alter contracts with the other companies that have objectionable behaviour to them. There is no use for Wikipedia to punish all consumers for the actions of some service providers. Graeme Bartlett (talk) 22:03, 5 September 2014 (UTC)
  • Oppose per Yair Rand. Green Giant (talk) 22:58, 5 September 2014 (UTC)
  • Oppose I'm glad we did act on SOPA, and I do think Net Neutrality is important, but I oppose this one. Wikipedia should not (and doesn't) frivolously jump up on every soapbox that we like, but Wikipedia can and will do so if there is extraordinary cause for it. I hope those objecting to Wikipedia ever using the soapbox take note that this proposal looks to be snowballing Oppose. It is important that we CAN soapbox, and important that we avoid soapboxing. Alsee (talk) 05:33, 6 September 2014 (UTC)
  • Big support. Net Neutrality MUST be maintained. A non-neutral Internet would destroy the Internet as we currently know it. It would have direct ramifications on people's access to free information. It would allow a few mega corporations to control what people see, hear, and read. It would have direct ramifications for Wikipedia and its readers and editors. With a non-neutral Internet, things like a monthly Wikipedia usage charge could start appearing on your bill from your service provider. Anybody who thinks this is "not our fight" or that Wikipedia shouldn't be making political statements doesn't understand the battle and doesn't see the big picture. Also note that "Slow Down Day" isn't going to literally slow down websites as OP said. It just going to have a "loading" graphic that would help people understand what a non-neutral Internet might be like. Jason Quinn (talk) 15:10, 6 September 2014 (UTC)
    • This particular issue (an FCC decision) only seems to affect some users of Wikipedia (namely, those who are located in the United States). Would you support a similar campaign if it were about something in some other country (say, Wikipedia Zero, which prevents net neutrality in Russia, India and several other countries)? Do you think that Wikipedia should look different to everyone, or only to users in the United States? --Stefan2 (talk) 15:38, 6 September 2014 (UTC)
      • If the system administrators can target US-based IP addresses, then that would be fine. As for the other countries question, it depends whether raising awareness makes sense. However, we must be careful not to trivialize the unique position of the United States in regards to the Internet. What an arbitrary country does with there Internet isn't in the same league as what the United States does. People must realize that a non-free Internet in the US will affect non-American Internet users and non-English speakers. As such, I wouldn't be opposed to raising awareness world-wide. Plus if the US goes non-free, you can bet your bottom dollar that many other countries will follow. I am flexible on the world-wide awareness idea but the Wikipedia absolutely ought to raise some awareness. Targeting US-based IP addresses would be an appropriate step for the WMF to do. Jason Quinn (talk) 23:33, 6 September 2014 (UTC)
        • There is approximately a 0% chance that this will happen, so I don't think we need to bother with coming up with justifications for this terrible, terrible idea. 0x0077BE [talk/contrib] 00:11, 7 September 2014 (UTC)
          • If you are going to call something a "terrible, terrible idea", why don't you actually try to articulate why it is such a terrible idea? You've contributed nothing to the discussion except to say that you don't think Wikipedia should be used for "political pressure tactics", a myopic idea that could ultimately be self-harming to Wikipedia. Does it include all "political" legislation like SOPA? The Village Pump is for discussion of ideas. Opinion quips without detailed reasoning are often noise. This is a complex topic and doesn't boil down to simple "bad idea" remarks. Jason Quinn (talk) 12:33, 7 September 2014 (UTC)
            • Wikipedia isn't going to soapbox without heavy support. The original post is an IP address, and one support has a single edit (the vote here). That puts it at 12 to 2 against. This is Snowed. Alsee (talk) 16:42, 7 September 2014 (UTC)
            • I responded earlier supporting Ykraps' opinion. I also agree with many of the other reasons given for why it's a terrible idea - Wikipedia shouldn't be a soapbox, I found SOPA to be borderline at best - and at least SOPA was trying to make a point about a new law that was going to be in place. This protest is about getting something we've never had (the FCC does not currently regulate net neutrality), and something that would undermine the WMF's efforts with Wikipedia Zero, so clearly this is hardly a clearcut case of needing to act. Plus, as Alsee points out (and as I did in the pipelink), it's pretty clear that this will never pass, so this is an obvious case of WP:SNOW. Consider that we couldn't even get the main page unified with all mass-surveillance related stuff for Stop Watching Us - and that's not even a protest, that one was actually fairly neutral. So yeah, I wonder if we can get "participate in such-and-such-protest" added to WP:Perennial proposals at this point. 0x0077BE [talk/contrib] 21:35, 7 September 2014 (UTC)
  • Support; I would like to see Wikipedia join with other websites in the internet slowdown scheduled for September 10. Wikipedia was very effectively involved with the internet blackout to bring attention to net neutrality issues and I believe that bringing attention to the possibility of the FCC fast lane policy is in the same vein. The potential of tiered service is not something that should be dismissed, and a weak showing of support for even one area of net neutrality weakens other areas. I understand that some of the websites we would be allying ourselves with are not exactly in line with the image Wikipedia tends to portray, but net neutrality is that important. It is about Redtube, Youtube, Netflix, Google, Dogpile, and Wikipedia all having the same access to their users without a tiered service, without the need to pay ISPs for preferential treatment.
  • Oppose - Wikipedia is an encyclopaedia, being encyclopaedic is at the core of our policies and guidelines, we strive to emulate other encyclopaedias, and I don’t see other encyclopaedias getting involved in politics! What is the difference between taking part in this protest and writing a POV article slating the FCC? When I started editing WP, there was no indication that it was a political pressure group, and if there had been, I would never have joined! If you wish to protest please do but stop trying to get Wikipedia to fight your battles for you. We are neutral and apolitical! --Ykraps (talk) 19:11, 8 September 2014 (UTC)

And it hasn't gone unnoticed that your only contribution to this encyclopaedia is this proposal!!!--Ykraps (talk) 20:09, 8 September 2014 (UTC)

You can't be sure about that. 68.196.80.164 is a dynamic IP address owned by Optimum Online. They could easily have edited under several other IPs both before and after starting this section. --Redrose64 (talk) 21:17, 8 September 2014 (UTC)
Fair enough. I have no idea how to ascertain that.--Ykraps (talk) 21:32, 8 September 2014 (UTC)
  • Oppose, regardless of what an individual editor's opinion is regarding this subject of Net neutrality, I have to look at what policies state. Although it is not article content I am with others who point to WP:NOTSOAPBOX and WP:NOTADVOCATE as good reasons as to why Wikipedia shouldn't join. This community is based around the five pillar policies, one of which is neutrality; if Wikipedia joins a movement, one way or the other, it is in violation of its own core policy. It is better to create a neutral article about the subject, and keep it up for all interested in reading that content's well cited and verified content than to do what occurred during the SOPA shutdown.--RightCowLeftCoast (talk) 07:34, 9 September 2014 (UTC)

Call to close discussion

Can someone close this per snow and add "Web-based Activism by Wikipedia" to perennial proposals as suggested. Thanks. GenQuest "Talk to Me" 19:38, 8 September 2014 (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.

Use {{div col}} for categories

At present category listings use a fixed 3-up format. I propose that they should use the HTML equivalent of {{div col|colwidth=16em}} so that people using the wide windows that seem to be so prevalent these days can see more columns. As an example look at list of Pakistani actors and change your window width the while. If you have a decent browser, the number of columns will change in response. I have tried this with four different browsers under Android and they too are happy with it. (The value of 16em is negotiable but that seems about right.) — RHaworth (talk · contribs) 14:47, 10 September 2014 (UTC)

Note that this would require a software change, specifically to [15]. Jackmcbarn (talk) 14:52, 10 September 2014 (UTC)
Cat listings are laid out using a one-row three-column table. Each of the three cells is 33.3% width, and contains one or more <h3>...</h3> elements, each of which is followed by a <ul>...</ul> element enclosing one or more <li>...</li>. --Redrose64 (talk) 16:02, 10 September 2014 (UTC)

IPA tooltips

(I wasn't getting any responses after posting on the template's talk page, so...)

See Template talk:IPA-en#Make like IPAc using Lua?. I propose that Template:IPA-en (and perhaps similar templates) have automatically generated tooltips explaining the sounds represented by the IPA symbols. Example: /ˈwɜrd/ --Yair rand (talk) 02:23, 11 September 2014 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_113&oldid=1251406098"