Jump to content

Wikipedia:Village pump (proposals): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
MiszaBot II (talk | contribs)
259,776 edits
Uniplex (talk | contribs)
937 edits
Line 1,090: Line 1,090:
Actually, maybe we should just add a link to [[Help:Redirect]]? Then whoever is astonished to find a "wrong" name will have a chance to find out what happened (and how to fix it if it is really wrong - after all, everyone is a potential editor - we should never look at the readers as if they were ''just'' readers). --[[User:Martynas Patasius|Martynas Patasius]] ([[User talk:Martynas Patasius|talk]]) 19:19, 25 November 2011 (UTC)
Actually, maybe we should just add a link to [[Help:Redirect]]? Then whoever is astonished to find a "wrong" name will have a chance to find out what happened (and how to fix it if it is really wrong - after all, everyone is a potential editor - we should never look at the readers as if they were ''just'' readers). --[[User:Martynas Patasius|Martynas Patasius]] ([[User talk:Martynas Patasius|talk]]) 19:19, 25 November 2011 (UTC)
:Agreed if combined with an increased scale. So we have the Page name in big, the original search term at maybe 1/2 size and "[[Help:Redirect|redirected]]" at no less than 1/4 size (of page name). No extra words just up the font-size and link one word.&nbsp;[[User:Fred_Gandt|'''<span style="font-family:arial;font-size:130%;color:#044;">f<i style="color:#0dd;font-size:60%;">red</i>g<i style="color:#0dd;font-size:60%;">andt</i></span>''']] 19:25, 25 November 2011 (UTC)
:Agreed if combined with an increased scale. So we have the Page name in big, the original search term at maybe 1/2 size and "[[Help:Redirect|redirected]]" at no less than 1/4 size (of page name). No extra words just up the font-size and link one word.&nbsp;[[User:Fred_Gandt|'''<span style="font-family:arial;font-size:130%;color:#044;">f<i style="color:#0dd;font-size:60%;">red</i>g<i style="color:#0dd;font-size:60%;">andt</i></span>''']] 19:25, 25 November 2011 (UTC)
::You're misrepresenting the proposal: the "also known as" indication was suggested only for names (unlike ABCDEFGHIJKLMNOPQRSTUVWXYZ) that are listed as such in the lead sentence, and naturally wikilinked elsewhere (not just searched for). Anyway, you seem sure of what you want, so I'll leave it to you. [[User:Uniplex|Uniplex]] ([[User talk:Uniplex|talk]]) 08:09, 26 November 2011 (UTC)


== A simple "last best version" marker ==
== A simple "last best version" marker ==

Revision as of 08:09, 26 November 2011

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


« Archives, 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


Does Wikipedia need a “share” button?

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.
No consensus for or against a share button. Graeme Bartlett (talk) 09:29, 22 November 2011 (UTC)[reply]
Supporters wanted to bring Wikipedia up to date with social network sites and help readers link to articles they like. Opposers claimed that this idea was not in line with the mission of Wikipedia, and would help vandals promote their work. A discounted fear was that it would invade privacy. Graeme Bartlett (talk) 21:26, 22 November 2011 (UTC)[reply]

Recently, on wikitech-l there was a discussion about adding a “share” button to Wikipedia. Someone suggested that this should be discussed here. Is this something that people would find useful? — ☠MarkAHershberger☢(talk)☣ 16:13, 21 October 2011 (UTC)[reply]

Do you mean you want a social networking button to spam your friend's talk pages with articles that you like? I'm not sure I'd find that useful, but there may be some who do. RJH (talk) 18:33, 21 October 2011 (UTC)[reply]
I guess he means something like this. emijrp (talk) 18:37, 21 October 2011 (UTC)[reply]
No, more like the below-mentioned SignPost version. --Lexein (talk) 08:13, 24 October 2011 (UTC)[reply]
He means a social networking button to let Facebook track what you're reading on Wikipedia, so that the data can be sold to advertisers. --Carnildo (talk) 01:06, 22 October 2011 (UTC)[reply]
No, he does not mean a tracking "like" button, which is why he used the word "Share". "Tracking" and "privacy" are just irrelevant FUD here. People pass information to other people, and in doing so, identify each other to each other (many times by pseudonyms, which vary). Get over it. --Lexein (talk) 08:13, 24 October 2011 (UTC)[reply]
.... which flies in the face of the whole separation of Wikipedia and commercialism thing that everyone seems to agree is really important. Sven Manguard Wha? 12:20, 22 October 2011 (UTC)[reply]
It's extremely easy to craft a version of this that does not permit such tracking to occur. --Cybercobra (talk) 08:18, 23 October 2011 (UTC)[reply]
Such as the below-mentioned SignPost version. --Lexein (talk) 08:13, 24 October 2011 (UTC)[reply]
  • Strong Oppose This same like/share idea comes up every month, sometimes several times a month, and gets shot down by a wide margin. Wikipedia is a) not a social networking site, b) has fundamentally different objectives from social networking sites, and c) a community of people who by and large do not enjoy the idea of linking their Wikipedia accounts to their real life identities. There are many, many other reasons why this keeps getting shot down, but suffice to say that a like button would probably have a negative impact on editor retention, there's already quite a bit of grumbling about the perception that Wikipedia is moving towards the social network model in one way or another. Sven Manguard Wha? 18:39, 21 October 2011 (UTC)[reply]
A share button is for sharing content, and that is a Wikimedia goal. Sharing buttons have existed before any social network, nobody remember the "mail this link" buttons? Obviously, may be privacy problems, but we can think other solutions.
And about "a like button would probably have a negative impact on editor retention" you know what I say --> [citation needed] <-- . Regards. emijrp (talk) 18:58, 21 October 2011 (UTC)[reply]
Just because wikipedia isn't a social networking site doesn't mean that its mission couldn't be advanced by allowing people to more easily share WP articles on social networking sites. I mean, the New York Times' website isn't a social networking site either, and they allow you to share their articles on social setworking sites. I can see how maybe there would be concerns about whether or not the "share" button constitutes an advertisement, but overall I think this is a pretty good idea. Nobody's trying to force you to link your facebook profile on your user page. This request is about making it more easy for people to share articles they find interesting. AgnosticAphid talk 21:01, 21 October 2011 (UTC)[reply]
I view a Share button as a distraction - otherwise it would be perfectly acceptable.Jasper Deng (talk) 21:35, 21 October 2011 (UTC)[reply]
Wikipedia is a publisher of reliably sourced knowledge. The "Create a book / Download as PDF / Printable version" buttons are publishing tools, and are not distractions. A Share button (as implemented at SignPost) is no different. It could be next to "Create a book", or next to "Read/Edit" (whichever is less distracting. It merely allows publishing to other venues and people. WP is an advertiser, as we radically internally link our articles. We also "advertise" our sources, in the References and External links sections. The Share button advertises nothing but other venues for our content, for the purpose of bringing in prequalified readers to specific articles, with the intended side benefit that those readers might become editors,which the Foundation has stated is a desirable goal. --Lexein (talk) 02:44, 24 October 2011 (UTC)[reply]
  • Strong oppose - anybody can do a simple URL for a Wikipedia article now. What we would really be doing would be serving as enablers for the creators of spam and vanity articles, for the paid "editors" showing their employers that they've delivered the goods, and for the vandals (and POV pushers) who want to show off what they've done to Wikipedia articles. I can see the messages now: "o wow the lolz see what I did to show that our skool is run by zombies and principle zanexki is a jew pedofile - rotfl - wiki is so totaly pwned!!!!" --Orange Mike | Talk 21:16, 21 October 2011 (UTC)[reply]
On a more personal note: if I wanted to play Farmville or win free jewels for my Gaia Online avatar, I'd be doing that. Instead, I'm trying to help build an encyclopedia, not show off my drawings of my imaginary flying unicorn best friends! --Orange Mike | Talk 21:32, 21 October 2011 (UTC)[reply]
But, as you note, this is already possible. You just have to enter your "o wow teh lolz" post manually with a manual reference to the wikipedia article. Is there a current problem with paid editors doing this? I didn't realize vandalism was such a problem. Is there some way to address related issues (I'm not well-versed technologically, really, but maybe artificially inflated search engine rankings or something?) within WP? This proposal presents the question of how user-friendly it's going to be to share wikipedia articles on networking sites. I feel like your comment is more oriented toward banning links to wikipedia articles altogether so that they can only be found by searching google or the home page. What's the point of purposely making it kind of difficult to share links and find articles? I feel like WP's goals would be better served by making it easier to access content. AgnosticAphid talk 21:29, 21 October 2011 (UTC)[reply]
It is precisely that difficulty that discourages the sharing of pages by drive-by vandals/spammers/ego boosters -- the additional time and effort to figure out you can do this and to copy and paste the URL over isn't worth it. MER-C 05:08, 22 October 2011 (UTC)[reply]
Please tell me exactly how a Facebook "Like" button and "Like" counter will do good for Wikipedia? I have little doubt that the Facebook article would get zillions of "Likes" if we added a "Like" button and "Like" counter to Wikipedia articles, because obviously our obsessed-with-Facebook-and-Twitter world really, really likes Facebook. We already have "Rate this Page" boxes at the bottoms of articles that allow readers and users to rate how Trustworthy, Objective, Complete, and Well-written articles are, so please tell me how the Facebook "Like" rubbish will do good for Wikipedia.
Regards,
—{|Retro00064|☎talk|✍contribs|} 21:34, 21 October 2011 (UTC).[reply]
I don't want to speak for the OP, but they are suggesting a Share button, not a Like button (which I agree, would be dumb). A Quest For Knowledge (talk) 21:44, 21 October 2011 (UTC)[reply]
You could say that I was directing that comment at Erimjp's comment above. As for the "Share" button, I have no opinion except a request that, if the "Share" button is implemented, it be made as maybe a gadget that can be turned on and off in Special:Preferences. I do not want to have the Facebook and Twitter icons/links staring at me on Wikipedia. I am just going to sit back and watch the community slug this out. —{|Retro00064|☎talk|✍contribs|} 21:53, 21 October 2011 (UTC)[reply]
We already have a de facto "Like" button; it's the Wikipedia:Article Feedback Tool. –MuZemike 18:59, 22 October 2011 (UTC)[reply]
  • Comment The purpose of Wikipedia is not to edit it (stated above). The purpose is for readers to learn stuff. If readers learn something and want to share it, I think that's a great thing. I'm not opposed to sharing in any fashion but find "share this" buttons unpleasant due to my personal dislike of most social networking sites (I like real friends and prefer to not be collected) and would prefer to not be so frequently reminded of them. Not opposing or supporting. -- fgTC 21:40, 21 October 2011 (UTC)[reply]
Comment: Well, behind the scenes, WP really is a single-purpose, single-output closed social network of editors, closed in the sense of not interacting outside Wikipedia. But simplifying distribution of content to external social networks, as a user option, and/or a login checkbox option, does not devalue WP or distract from WP's goal. I see it as a publishing tool similar in value to "Create a book / Download as PDF / Printable version". --Lexein (talk) 22:56, 21 October 2011 (UTC)[reply]
  • Strong support as a Preferences Gadget which simplifies publishing Wiki content (URL, Article title, highlighted text), out to social tools. I do not support any non-native gadgets like Facebook "Like" buttons which track IP addresses or place cookies. I expect this would a very popular gadget anyways. It would also accelerate bringing in new editors, a very desirable thing, according to the Foundation. Wikipedia's purpose is to be an encyclopedia which is wide open to dynamic improvement and expansion. The more people share out (publish) WP content, with WP URLs, the more likely more editors will come in and correct and expand. On a personal note, I've been impressed by the increased number of quality IP edits in my watchlist lately. Hopefully that's not a temporary thing. I would also support offering this as a checkbox option at both signup and login. --Lexein (talk) 22:56, 21 October 2011 (UTC)[reply]
  • Oppose for now on the aesthetic grounds that it looks non-serious. Other than that I really don't mind; there have been times that I've sort of wished for such a button myself. But I think it's important for Wikipedia not to go too populist, image-wise. There may come a point when such buttons are so routine that no one would think of them that way, and then I would withdraw my objection. (By the way we should also get rid of Wikilove and the "ratings" bars at the bottom of articles, for similar reasons). Now you kids get off my lawn. --Trovatore (talk) 23:09, 21 October 2011 (UTC)[reply]
Trovatore: Can you please take a look at this article, UCLA Neurosurgery gets $2M donation to establish endowed chair in epilepsy research? I don't think that the Share button makes that site look non-serious. A Quest For Knowledge (talk) 23:19, 21 October 2011 (UTC)[reply]
The users of that site only read. The users of Wikipedia also edit. No unnecessary distractions like "Share" buttons please.Jasper Deng (talk) 23:22, 21 October 2011 (UTC)[reply]
Perhaps more to the point, that's a public-relations-slash-news-release. It's not an encyclopedia article. PR people and journalists will have "share" buttons and this is expected. But we don't do PR and we don't do journalism. We're expected to be just a bit stodgier than that, and if we're not, it reflects negatively on our seriousness. --Trovatore (talk) 23:28, 21 October 2011 (UTC)[reply]
Trovatore: Well, how about Nature (journal), the world's most cited interdisciplinary scientific journal according to the Science Edition of the 2010 Journal Citation Reports?[3] I think that is stodgy enough. A Quest For Knowledge (talk) 23:39, 21 October 2011 (UTC)[reply]
It's a journal. It's not an encyclopedia. --Trovatore (talk) 23:40, 21 October 2011 (UTC)[reply]
OK, if you want an encyclopedia, the Encyclopedia Britannica has a Share button for their articles.[4] A Quest For Knowledge (talk) 23:45, 21 October 2011 (UTC)[reply]
They also have tons of ads. Presumably the only way they can pay for it, but sorry, looks unprofessional. --Trovatore (talk) 23:53, 21 October 2011 (UTC)[reply]
Trovatore: Adding a Share button doesn't mean we also have to have ads. In your opinion, which sites do look professional to you? A Quest For Knowledge (talk) 00:05, 22 October 2011 (UTC)[reply]
Other sites are not particularly relevant. This is my opinion of what is best for the image of Wikipedia. Yours is obviously different. You have the right to a different opinion, but I have expressed mine, and others will agree or disagree based on their own intuitions. --Trovatore (talk) 00:09, 22 October 2011 (UTC)[reply]
Don't forget that I think people are not talking about a large, glaring, separate button, but an (optional) same-color addition to the Read/Edit/star/ row with a dropdown menu. I think. --Lexein (talk) 00:27, 22 October 2011 (UTC)[reply]
  • Oppose(edit conflict × 2) I really feel that a share button would be counter-productive to our mission. People (especially younger editors) would use it like a Facebook page. And I feel it would clutter the workspace.
Also, one of the things that would need to be discussed would be how the system would work. Would it be visible to anonymous editors? Which buttons would be available? (we'd have to be careful with our selections. People might view it as "endorsing" a certain site.) I feel like this is an area that is a huge can o' worms. Just my 2¢. ~ Matthewrbowker Say hi! 23:56, 21 October 2011 (UTC)[reply]
In my vision, it would live next to the Read/Edit buttons, like the Twinkle button with a dropdown menu. For IP editors, it would be On by default, because though we don't know, and don't want to know, their identifying information, only the destination website wants it. Sharing could be Off by default, but controllable by registered users: enabled by a checkbox at login time, or permanently in Preferences/Gadgets. In Preferences, a long list of checkboxes for destinations is presented, this controls the length of the dropdown list. I'm looking for good examples of Share buttons which preserve privacy until the user is at the destination site. http://AddToThis.com is a good visual example, though ours would be handrolled. There may already be an open-source example. --Lexein (talk) 00:23, 22 October 2011 (UTC)[reply]
  • Comment A possible issue: Many vandals add to their contributions little notes that seem to indicate that they will share their work with others. Making it quicker and simpler could encourage greater vandalism. I think the possibility is not so great that we should panic unduly but, I think it is a possibility. However, if employed "share buttons" could have their use stats monitored so that admin could quickly decide if (on regularly vandalised pages) the button is being used often immediately after a vandal has contributed and follow it up with a (perhaps limited term) disablement.
Further Lets not forget that Wikipedia is all about sharing knowledge. This idea should be considered an extension of that goal. -- fgTC 00:00, 22 October 2011 (UTC)[reply]
  • Decided to support Even though I vehemently dislike most social networking sites, they are popular and Wikipedia has a lot to offer. I would like to see people reference it more easily and often. -- fgTC 00:00, 22 October 2011 (UTC)[reply]
  • Question: What does a "share" button do exactly? What things would change here if implemented? Does the button changes something here when pressed, or does it change something in facebook? (I don't want to interrupt the discussion, just point me an article or page with this info, and I will formulate an opinion later). Cambalachero (talk) 00:36, 22 October 2011 (UTC)[reply]
A share button would not change Wikipedia articles at all. It would add a (possibly formatted) link to the wall of the user at the social site being shared with. It's a simple way to say "Hey guys! Look what I found." -- fgTC 00:42, 22 October 2011 (UTC)[reply]
It would be a huge distraction to the editors of Wikipedia, though, and an unnecessary use of Wikimedia's resources.Jasper Deng (talk) 03:29, 22 October 2011 (UTC)[reply]
Jasper: You have said repeatedly that it would be a huge distraction to the editors. I'm an editor and it wouldn't be a distraction to me. Please speak for yourself. I fail to see how it would be distracting to anyone. As mentioned in the discussion it would probably be no more than a tab atop the articles that would only be enabled by choice. As for the resources: It would use few of them compared with everything else that's going on here. I sincerely doubt it would be more than a drop in the ocean as far as measurable server strain would be concerned. -- fgTC 04:20, 22 October 2011 (UTC)[reply]
We're here to build an encyclopedia, not a social network. A "share" button encourages WP:NOTHERE (in a different way than usual) by encouraging new users to simply use Wikipedia as a "hey, look at this" medium, instead of useful editing, which is what we want. Server resources would be wasted answering all of that.Jasper Deng (talk) 04:30, 22 October 2011 (UTC)[reply]
You have offered no evidence that a share button (implemented either as seen at Sign post, or as a discreet bar button next to "read/edit") would encourage WP:NOTHERE. A test of the feature would measure the frequency of this occurrence (if any). I advocate testing, anyways. --Lexein (talk) 06:58, 23 October 2011 (UTC)[reply]
  • Oppose: Facebook is known to use those buttons to track what people are doing, and I presume the other "share" sites do the same. I don't know about you, but I'm opposed to letting anybody track my Wikipedia reading habits. --Carnildo (talk) 01:10, 22 October 2011 (UTC)[reply]
  • Not willing to share? I assure you, if you search up anything in Google, the relevant Wikipedia article will be within the top 10 search results. We have our information available, and all the readers must do is find it. →Στc. 01:25, 25 October 2011 (UTC)[reply]
Hm. There's no danger of WP becoming a "social" social network - several wide-ranging and highly social initiatives have already come and gone - I can't remember their names. You've offered no evidence to support the claim that a Share button would add to "the wrong kind of dialogue." Testing, of course, would prove or disprove your thesis. --Lexein (talk) 18:35, 24 October 2011 (UTC)[reply]
  • Support. Adding to other "support" points mentioned above:
    • This feature would be for our readers, not our editors. Readers might find a quirky tidbit that they want to share with their Facebook friends, for example. Wikipedis was hailed as one of the most significant Web 2.0 sites, and we should embrace "social browsing" such as Share buttons.
    • Many editors would not care about this sort of thing, and I can imagine that many would disable a "Share" tool, just as many editors turn off the Article Feedback tool and the Vector skin. (I'm not one of them.) But we shouldn't let that hold us back.
    • I find the argument that "it would distract from the purpose of building an encyclopedia" a bizarre argument, since this would be a reader-facing tool: virtually no readers are here to WP:BUILD - they are here to partake in the "sum of all human knowledge", or whatever Jimbo said.
    • I also find the argument about WP:NOTMYSPACE hard to comprehend - BBC is not a social networking site either, yet it offers this feature.
    • Could it encourage vandalism? Possibly. But it's unlikely to attract the attention of vandals, since sharing features are commonplace across the Web.
    • The only opposing argument I buy is the one about tracking and privacy - this doesn't bother me personally, but it bothers others.
  • — This, that, and the other (talk) 04:33, 22 October 2011 (UTC)[reply]
  • Strong oppose. I agree very much with Kudpung and OrangeMike -- this will attract the kind of (l)users we don't want. There is also a real danger of the WMF's Privacy Policy being violated here, especially if the tool is opt-out. MER-C 04:43, 22 October 2011 (UTC)[reply]
Again, no evidence offered that articles sent to friends will engender "(l)users we don't want." Anyways, I'd !vote to make sure it's opt-in. Nobody is required to use it. It's just a publishing tool like "Create a book/ Download as PDF/ Printable version". Most readers will likely use it rarely/never, some occasionally, and only a few, frequently. Oh, and because it's a publishing button, it won't be visible on Talk pages, or while editing/viewing history/watchlist/etc., just like the above publishing buttons. --Lexein (talk) 18:35, 24 October 2011 (UTC)[reply]
  • Comment. Looks like Wikipedia:Signpost has a share button (see "Share this [show]" on the right), so no privacy concerns here? By the way, people here don't know what a social network is. The user pages + userboxes stuff is more like a social network than a button to share a link. emijrp (talk) 08:32, 22 October 2011 (UTC)[reply]
  • Support wow, the amount of people who simply have NO clue about these share icons, yet strong opinions. First of all, a share button doesn't automatically let Facebook track you, only if you use THEIR share buttons. There are ways to share articles using plain links, that have no privacy problems at all. The signpost uses those, as do many other websites. Also, sharing articles != Wikipedia being a social network and people saying that have 0 clue whatsoever about what that guideline means. It's like saying we shouldn't allow uploading of foto's because 'we are not Flickr". It's the most dense argument in this discussion and noise like this from people who clearly have no idea what our guidelines entail is what stifles many developments within our community. We are about spreading knowledge in a fun and engaging way. If we add PROPER support for sharing articles, then there that can only help our mission. Also the idea that we could attract the 'wrong kind of users' .. sigh, how far the community has fallen into protectionism of 'our knowledge'. You know, WP:OWN in spirit goes beyond a single article. As much as you don't own an article, you don't own the encyclopedia either... —TheDJ (talk • contribs) 09:27, 22 October 2011 (UTC)[reply]
Sure. And the sign-up form give the impression in terms of style/layout/look of a social-networking/forum site. emijrp (talk) 09:48, 22 October 2011 (UTC)[reply]
No, it doesn't. It's as plain and simple as it can get. Choyoołʼįįhí:Seb az86556 > haneʼ 11:59, 22 October 2011 (UTC)[reply]
  • Support. I have to say, I've been sceptical. But I asked myself: why? There seems to be no good reason to withhold such a feature. It may even help to strengthen Wikipedia's position at a time when it is facing teh editor retention problem. Grandiose (me, talk, contribs) 09:53, 22 October 2011 (UTC)[reply]
  • Oppose Sharing articles that we are reading on to facebook, like buttons on Youtube? Ridiculous and this would become a conflict of interest and WP:NPOV violation fiasco.Curb Chain (talk) 00:25, 24 October 2011 (UTC)[reply]
  • Support I can see problems but Wikipedia needs to fit into and try and educate the world as it is. If millions of our potential targets persist in walking in the front of traffic whilst twiddling their thumbs on a smartphone then yeah that's what outreach is. Dmcq (talk) 11:24, 22 October 2011 (UTC)[reply]
  • Oppose Absolutely not. --cc 12:09, 22 October 2011 (UTC)[reply]
  • Strong Oppose - I do not want facebook tracking what pages I view/edit. It's bad enough the "like" links are already everywhere (I have AdBlock to deal with them). We don't need them on Wikipeida. All they will do is provide information about pages we access. We might as well grant the facebook employees Checkuser, as that is effectively what they would have. The only difference being, instead of being restricted by a set of guidelines, we have no control of when and how they access this information. I don't mind sharing my knowledge, but I have a big problem with the idea of sharing my personal information with facebook and their non-existent privacy policy. If someone wants to "share" a Wikipedia article, they can copy/paste the URL, or they could use facebook's mirror copy of Wikipedia. Wikipedia is not a social networking site. Adding a set of spam buttons will hinder our attempts at building a neutral encyclopedia. I am here to build an encyclopedia, not wasting time "sharing" edits I've made. We already have such a feature, it's called Special:Contributions. Alpha_Quadrant (talk) 14:24, 22 October 2011 (UTC)[reply]
This concern has been addressed. There's no way a "Like" button will ever be used - it's a "Share" button which does nothing but navigate to the selected website when clicked. If you don't click on the Facebook link, then Facebook will never know you were here. --Lexein (talk) 18:35, 24 October 2011 (UTC)[reply]
  • Support, but mostly I wanted to decry the ridiculous amount of misinformation in this discussion. I don't see any way in which a share button allows Facebook to track what pages you're viewing -- on the off chance that it does, coding our own share button would be an easy way around it. I also don't see any way that this feature would "distract" editors; it's a feature for readers, a segment of our audience that seems to get forgotten an awful lot around here. No one who would vandalize an article would be deterred by the absence of a share button. But ultimately -- aren't we supposed to be all about sharing knowledge? Shouldn't we encourage readers to promulgate our articles as far and as widely as possible? Powers T 15:57, 22 October 2011 (UTC)[reply]
See Facebook 'Like' button draws privacy scrutiny, and it really is a stinker that way. However there's absolutely no earthly reason why it should do anything more than the obvious on Wikipedia so there's no privacy concers for us in providing such facility. Dmcq (talk) 18:01, 22 October 2011 (UTC)[reply]
That's the "Like" button, not a Sharing facility. No one has suggested putting the Like button on any Wikipedia page. Powers T 19:35, 22 October 2011 (UTC)[reply]
Case in point, https://www.facebook.com/sharer/sharer.php?t=Main_Page&u=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMain_Page is just a URL. All Facebook would get is the referer. --Cybercobra (talk) 08:14, 23 October 2011 (UTC)[reply]
That that ugly rant was posted by a Wikipedia admin is something far more fearful than a new way to share knowledge. -- fgTC 03:17, 23 October 2011 (UTC)[reply]
With a whopping 3 deleted edits, you cannot properly comprehend the "ugly rant". →Στc. 01:25, 25 October 2011 (UTC)[reply]
Excuse me? Perhaps you can explain why you think my ability to comprehend "ugliness" and "ranting" is so deficient due to 3 deleted edits. What exactly have they got to do with this discussion? I assume they have something to do with this? Perhaps you could tell us what edits were deleted and how they are relevant to this discussion. Don't forget to tell us here. Once one starts doing laundry in public I believe it best to carry on regardless. -- fgTC 08:45, 28 October 2011 (UTC)[reply]
  • Strong Suggestion - Obviously there has been a mild amount of interest in adding share functionality for a while now. This kind of voting is helpful in-that we can voice some concerns and show the amount of support, but nobody in their right minds thinks we're going to launch social-network features of any kind without testing first, and we don't even have a tool to test. So instead of proposing it, and then debating until we are lukewarm (again and again), why not make a simple gadget? If someone is tech-minded enough, why not make a simple JS tool that adds (locally-hosted) icons to article, portal and file pages (no user, talk or project pages), only visible for users who add the script. We can then refine that tool until it is ready for a proposal. We do not need a consensus for users to write JS, or to use it, and it will only be used by editors knowledgeable enough to know that it exists. So instead of arguing about the problems that might occur based on possible functionality, why don't we hammer together a lowest-common-denominator tool and work from there? ▫ JohnnyMrNinja 05:07, 23 October 2011 (UTC)[reply]
If a tree falls in a forest.... What's the point of knowledge if not shared? Why would it not be good for Wikipedia to actively encourage sharing it? -- fgTC 06:46, 23 October 2011 (UTC)[reply]
As one of the top five most visited websites, we don't have the problem of trying to get our content out. Yours is a false argument. Sven Manguard Wha? 07:56, 23 October 2011 (UTC)[reply]
Making it easier to "get our content out" (I prefer to think of it as the content) is what this feature would offer. Wikipedia's success is due in part to it being a radical idea. Knowledge changes all the time and so does the content of Wikipedia. The tools we use must change too or we may find ourselves petting a dinosaur. This is not to say that a "share button" is strictly necessary, it is just to say that we must adapt to survive and as with genetic evolution, some changes (however crazy) may just be the very thing that lifts us. I realise that Wikipedia is already popular but it's present popularity is no good reason to curb it gaining more. -- fgTC 18:18, 23 October 2011 (UTC)[reply]
The "Everyone else has it" argument is pretty weak... "Everyone else" has ads on their website. So because "everyone else does" we should too? I don't think so. VictorianMutant(Talk) 11:42, 23 October 2011 (UTC)[reply]
The BBC doesn't have ads on their website. People only have ads on their websites if they are commercial websites that need to make money. Even Sourceforge, that well known commercial software website, has a like button. -- Eraserhead1 <talk> 11:48, 23 October 2011 (UTC)[reply]

TheDJ/Sharebox has been available for quite some time. It allows you to share an article with Facebook and over 50 other sites. The script uses the third-party AddThis and does not use cookies or flash that allows tracking. Privacy concerns are addressed on the doc page. ---— Gadget850 (Ed) talk 12:29, 23 October 2011 (UTC)[reply]

Right, and as an editor with 20000 edits I'd never heard of it before. It is completely unreasonable to expect our average reader to have heard of that. -- Eraserhead1 <talk> 12:33, 23 October 2011 (UTC)[reply]
Wrong, you just copy the URL into a status or wall post. Done. Ian.thomson (talk) 20:42, 23 October 2011 (UTC)[reply]
  • Support Everyone needs to realize that this isn't a referendum on social media. A share button helps drive more traffic, which gives more pageviews, which nets more editors, which ensures the continued survival of the project.--GrapedApe (talk) 14:09, 23 October 2011 (UTC)P[reply]
  • Strong Don't Care as long as privacy issues are addressed and it is easy to opt out of. Anomie⚔ 15:20, 23 October 2011 (UTC)[reply]
  • Strong oppose This RfC asks if we need a "share" button. Intuitively we do not "need" this feature! It is not inherently a bad thing, and no one would be forced to press the button; but it would appear as an imitated feature and infer that Wikipedia desires in some way to emulate facebook. To my impression, Wikipedia is the foremost example of functionally productive networking with lasting social value, (in website terms) and we need to continuously develop our own unique niche. Our "like" button, or "share" button is here called an "edit" button; and more importantly, a "save" button. Pressing those are where we measure success, and by doing so, as I once did when creating the Chemical weapon article, starts the share option we are most committed to. One measure of success is the many sites which mirror our content, like this facebook example; which you are welcome to like and/or share, according to their manner.
I would favor a feature that was site specific, like a real time notification system if and when your watchlisted parameters are met. Currently, if someone edits my talkpage, I will not be alerted until my next refresh. There are times when periods pass, or I exit directly from a read, and miss a message until much later than perhaps necessary; or I refresh far more often than otherwise necessary, if I am anticipating some particular edit. Such an ability to share things internally would be a better direction, and use of resources. IMO -- My76Strat (talk) 18:02, 23 October 2011 (UTC)[reply]
I get email notifications already. -- Eraserhead1 <talk> 19:56, 23 October 2011 (UTC)[reply]
  • Conditional support As a long-time Wikipedian and Facebook user, I don't see how sharing links to interesting articles with one's FB network will turn WP into a "social networking site." I think it's just one more great way to build traffic and awareness. Of course, I share the concerns of others that such a functionality not lead to online tracking issues. Shawn in Montreal (talk) 20:19, 23 October 2011 (UTC)[reply]

Looking over the discussion...

-The argument that we'd be selling reader info is properly countered by pointing out that it's circumventable on our end.

-The argument that we're not a social network ignores the fact that Facebook is.

-The argument that the site would turn into a social network because "kids" stinks of fuddy-duddy-ism.

But:

-It's easy enough to just copy a Wikipedia URL into a status or wall post on Facebook (or any other site). Noone capable of using either site needs a like button.

-There's been no explanation on how a share button would help us acquire good editors. "It couldn't hurt" is not a good reason, and anyone who knows what facebook is knows about Wikipedia already. The only people who would discover Wikipedia because of a like button would be the sort of techno-throwbacks who believe checking email requires IT training (*glares at grandfather*). The idea that people on Facebook don't know about Wikipedia is honestly damn stupid. What helps acquire new editors is letting (the right people) know that anyone can edit (within the guidelines), and a like button won't help with that. Only talking with your friends will help with that, and that allows us to let stupid friends continue to think we had to go through proper job applications, get circumcised, and join the Masons to "work" here.

-Several years ago, this discussion would have been about Myspace (anyone remember that?), so who knows what social network's feature we'll be discussing in the next decade? By saying that we'll give a feature to Facebook but not Myspace or anyone else's site is showing a preference to and support for Facebook, which is not neutral.

So: Oppose, on grounds that it is unnecessary for either site's users, and for WP:SOAPBOX (because it is helping Facebook). Ian.thomson (talk) 20:42, 23 October 2011 (UTC)[reply]

Nice argument. I'm not sure I entirely agree, but its a fair point. -- Eraserhead1 <talk> 20:48, 23 October 2011 (UTC)[reply]
  • (I wish it hadn't been full left-justified, interrupting the !vote bullets).
    It was asked how a share button would help bring in good editors": A shared link to an article (and only mainspace articles, btw) will bring in a new and interested reader, who has been invited/alerted by a friend of similar interests, to a specific article. This newcomer is a prequalified interested person, who won't click on the link if they aren't interested, who likely had not previously considered Wikipedia or that topic at Wikipedia as something of interest to read. Now, because a friend alerted them, they might visit. These people (lots of them) won't visit a particular article unless and until they are aware of its presence. I believe that such alerted people will be more likely to take an interest in editing, than if they had not been invited or alerted. Testing will show. This is a two-step "take the plunge" for a newcomer: the first is to read a particular article here (lots of people don't, don't laugh), the second is to edit here. It's a numbers game. IMHO invited readers (whom we don't scare off) are more likely to become editors because the effort to get to an article is less (no searching). This is a class of Internet users who did not know of a specific article at WP, or who didn't think editing Wikipedia is easy or allowed. This tool isn't for the people who already avidly read and edit, it's for readers to invite readers. It's a numbers game of small percentages: it's about conversion, in the parlance of SEO: converting readers to editors, by bringing in prequals. IMHO the quality of edits performed by these newcomers will match the spectrum of all newcomer edits: some good, some poor but good faith, some bad, some vandalism. Thr ratios don't vary, and should be no deterrent to allowing readers to invite new readers (who might happen to become editors). There's a new editor born every minute, they just don't know it. It's our task to make them good editors once they start editing here.
    Waiting for searchers to land here is insular, cloistered, arrogant. It presumes there is infinite time: there is not. WP:There is a deadline - against linkrot and source rot. Simplifying/reducing the complexity of/ sharing pages with people of similar interest is a valid way to get more readers who-might-become editors in here to help with building the encyclopedia against the tide of destruction of knowledge, and the maintenance and improvement of those 3500000 articles which are not GA yet.
    Necessary/unnecessary should never have been the pivot of this RfC. The claim of "Unnecessary" isn't the main argument on the table. The Print/export: Create a book / Download as PDF / Printable version buttons are not de facto necessary, but they are excellent tools for publishing articles in mainspace (only!). Adding to that list a Share dropdown menu would simply be another excellent publishing tool. Yes, saving clicks and keystrokes is of interest - those publishing links do that too: they offer uniform shortcuts to publishing, rather than having to puzzle out whatever the native OS&Browser provides. --Lexein (talk) 16:53, 27 October 2011 (UTC)[reply]
  • oppose I'm failing to see why we need to provide adverts for third party companies and use up valuable screen real estate to address the issue of what I suspect is a relatively small number of people who can't copy and paste a URL.©Geni 20:50, 23 October 2011 (UTC)[reply]
  • whatever - probably a good thing, as in the day someone adds this feature I'll immediately stop wasting some of my time in here. - Nabla (talk) 22:52, 23 October 2011 (UTC)[reply]
  • Support as long as privacy issues are avoided. Moving into the modern age to net more readers and editors is what Wikipedia should be doing. --Patar knight - chat/contributions 23:04, 23 October 2011 (UTC)[reply]
  • We're in the top 5 websites. We have readers. Anyone who knows enough about the net to have a Facebook account knows about this site and uses it. It won't help at all. In 10 years, we'll be out of date for having a Facebook like button, just as we'd be out of date for having a "share on Myspace" feature today. A "like" button won't let readers know that they can edit. Ian.thomson (talk) 01:07, 24 October 2011 (UTC)[reply]
  • Generic traffic to Wikipedia is not the issue. The "Share" button (not like) will allow a reader to invite another specific person to read a specific article. This "prequalified" visitor is selected based on presumed interest, by a trusted friend. This new visitor to that article may have higher interest in it, and may therefore be more likely to edit that article to improve it. I consider the Share button as a publishing and topic editor recruitment tool. --Lexein (talk) 02:44, 24 October 2011 (UTC)[reply]
  • Lexein summed it up nicely. This will help recruiting specialized knowledge as well as general editorship (including specialized editors who become more generalized). Also, not everyone who uses Facebook as well as Facebook is technologically competent to paste URLs, so this would be helpful. --Patar knight - chat/contributions 19:02, 24 October 2011 (UTC)[reply]
  • Generic traffic to Wikipedia is not the issue at all. See above. We cannot presume to know all the reasons people will "Share", but should not preemptively prohibit it. I consider the Share button as a topic editor recruitment tool. --Lexein (talk) 02:44, 24 October 2011 (UTC)[reply]
  • Support. Join the 21st Century Express my friends. We're a publisher. We have a business model. That model includes includes seeking broad readership (as opposed to acquiring cachet through exclusivity, for instance). That we're both free and nonprofit is germane but peripheral: we need broad readership to thrive just as Time magazine does. Getting many more links into Facebook or whatever is an excellent way to advertise our wares. A way to make it easier to make this happen is good marketing. "He not busy being born / Is busy dying" -- Bob Dylan. Herostratus (talk) 01:19, 24 October 2011 (UTC)[reply]
    • We're in the top 5 most viewed sites on the net. We have readers. Can you honestly find anyone on your Facebook friends list who has never used Wikipedia? If you do, I'll find someone on your friends list who is a liar. There's no point in burning more fuel when you're well beyond the finish line and it's not going to catch up to you. Ian.thomson (talk) 02:29, 24 October 2011 (UTC)[reply]
  • Wikipedia is not a for-profit business. Wikipedia's good qualities include being free of ads and other "dirty" Internet traits, let's keep it that way. I agree wholly with Ian.thomson.Jasper Deng (talk) 02:31, 24 October 2011 (UTC):[reply]
  • Oppose – WP:NOT. What will be the result of making this site friendlier to the current immature, Facebook-y generation without the skill to format even bold text without a visual editor? New users completely devoted to talkspace edits, new trolls, new pages pretending to be articles, heavier backlog on AfC, FEED, and NPP, sharing an attack page with the victim ("hey foobar wiki sayz ur a c0cksuking wh0rfag :D"), paid spammers showing their employers their "articles" ("Advertisement deployed, O Capitalist. The share button has been used, with the advertisement now linked to 19,402,325 other computers."). What’s worse is that we don’t even have automated processes to help alleviate the resulting NPP super-backlog, like we have for regular vandalism edits. In any case, how hard is it to type http://enwp.org/PAGENAME? →Στc. 07:03, 24 October 2011 (UTC)[reply]

'Oppose The reason was given above, of driving traffic into our site. That's not our purpose:. Our purpose is providing an encyclopedia. The traffic comes to our site from people who want to use a free comprehensive web encyclopedia, and as long as we're the best available, we'll get the traffic. It's not as if we needed to build awareness of our existence. What we need to attract is prospective good editors, and if anyone can show that this might do so, there might be an argument. My own view is it would drive them away, just as advertisements would. What it will much more likely attract is spam and vandalism. DGG ( talk ) 07:18, 24 October 2011 (UTC)[reply]

  • Oppose - Let's not risk diluting the message that encyclopedic knowledge is Wikipedia's core. Keep it free of sitewide links to a commercial enterprise. Keep it visibly, unambiguously neutral and independent: a project with a serious purpose. Don't blur boundaries with websites with different values. Also - for every straightforward "look at this article" Facebook share there might well be two look-at-this-joke-or-propaganda-edit shares.Lelijg (talk) 09:42, 24 October 2011 (UTC)[reply]
    • This despite the fact we prominently link to other commercial sites - in references, in ISBN's etc. Your last sentence seems speculative and without evidence to support the hypothesis it is uncompelling. --Errant (chat!) 09:55, 24 October 2011 (UTC)[reply]
      • Well, I like to think each article-based link to a commercial site is individually considered, in its particular context, to be relevant to a particular topic. A "social" link on every page seems quite different. And I'm sorry you find my speculation uncompelling! I was trying to express a genuine sense of how things could go wrong, based partly on my observations of countless unhelpful edits. In some situations you can't muster hard evidence and have to rely on experience, thinking things through etc. Lelijg (talk) 12:20, 24 October 2011 (UTC)[reply]
        • As far as I am aware we have no link consideration relating to sites being commercial or not - other than the obvious "no sales links". Most websites can be construed as commercial to some degree or another... and we link to them without concern (news articles, for example, which directly make money from our link via ad impressions!). As to the latter; the issue is that your taking something that happens already (i.e. vandalism) and implying (if I understand) that people will do more of it because they can easily share it with Facebook. I don't really follow that train of thought; either by logic or by instinct :) --Errant (chat!) 12:30, 24 October 2011 (UTC)[reply]

Support; this is primarily a reader tool, and making it easier to share and enjoy Wikipedia material is a great thing - it being our primary purpose. Opposition to that on the grounds: ** that we are not Facebook (great, an external share button does not make a social network... as you may notice social networks don't do such things)

  • that copy/pasting a link is easy (yes, easy for you - standard computer literate egotism at work there), that we don't need to "advertise" (why not? we should always attempt to increase the sharing of information)
  • that it will lead to an influx of not-very-good editors (how anyone connected up those dots I have no idea :P certainly they have no concept of causality and apparently a very disillusioned view of the people using social networks)
  • concerns of encouraged vanity use (which is amusing listed after an argument that it is already easy to share without a link...)

Aren't particularly compelling. Privacy concerns are important, of course, but that can be accounted for by using pure links. Certainly links to the bookmarking sites would be really handy for me, Facebook less so, but Twitter I might end up using. As editors we do an astonishingly poor job of empathising with the average reader - and consider Wikipedia a tool for us, not a tool for them. The second this becomes about us we have lost a serious battle. Readers first! --Errant (chat!) 09:55, 24 October 2011 (UTC)[reply]

  • Strong oppose - Is it really that hard to paste a Wikipedia URL? Furthermore I still don't see what Wikipedia would get in reward of providing that functionality. Anybody who knows how to use Facebook can paste the url to Facebook and publish it on their wall. Only because other websites include that functionality is not a reason for Wikipedia to do that too. Toshio Yamaguchi (talk) 10:36, 24 October 2011 (UTC)[reply]
No it isn't hard to paste an URL but why oppose an alternative? Does Wikipedia need a reward? Should it sit up and beg for treats? Some have argued that other sites use share buttons whilst pointing out how it has not detrimentally effected them. No one is suggesting that because other sites use share buttons, we should. What exactly is your strong opposition? -- fgTC 11:32, 24 October 2011 (UTC)[reply]
Why, exactly, are you pushing it so hard. Is a button that saves you a half second of time really so important to you that you're willing to combat a great deal of a) legitimate privacy concerns, b) concerns about Wikipedia's direction, and c) dislike for social networking sites? You're fighting pretty damned hard for a half second of time. Your edit summary "So many strong opinions and nothing to hang them on." implies that you, in fact, have something to hang your opinion on (something so clearly and universally good that it allows you to snub the opinions of others, it appears). So, what is it? Sven Manguard Wha? 11:43, 24 October 2011 (UTC)[reply]
The problem in that paragraph is the word "you" :) Because this is not about us; the idea is that this would be a reader tool. Remember; the readers should always be our primary focus because the aim is to provide a repository of knowledge to as many people as possible. Once it becomes about "us" then we have lost sight of that (and this happens way too often). To try and respond to your points, though.. The privacy matter can be addressed - and if you are clicking a link to push to a third party site there is implicit intention to publish on that site. I struggle to follow concerns that this could link editors to their RL accounts - given that it requires a specific action, and even then a shared link contains no user data. I've never quite "got" the "we are not a social network argument" in this context - given that a share button is not by any means a feature of social networks (instead a social network tries to get people to share to it). I'm struggling to understand why a share button makes us into a social network rather than actually moving us away from the social stuff by pushing that sort of interaction to other sites. And, finally, dislike of social networking sites is a poor reason to oppose links to them! (i.e. IDONTLIKEIT). --Errant (chat!) 12:37, 24 October 2011 (UTC)[reply]
I almost certainly won't be using the button if we get it. I don't use the sites that most of the share options lead to. If I find a site on the list that I do use I would be surprised but pleased to share my discoveries by using a share button. So, I am not concerned by how many half seconds I can save. Also, I am not pushing any harder for the button than you are pushing against it. I don't consider my taking part here combat or a fight. Privacy concerns have been repeatedly calmed. Wikipedia's direction is hardly going to be detrimentally altered by a share button if all it does is "saves you a half second of time" (a flimsy weasel). My edit summary was the summary for one response to one other edit. That edit (as you can see above) made a few strong statements against having this feature. I failed to see the strength in the statements or any rationale for them being considered strong. We are all entitled to share our views here. That includes me (if you don't mind). -- fgTC 12:39, 24 October 2011 (UTC)[reply]
You have a dozen posts, have made snide comments, and used equally snide edit summaries. You're not trying to particpate in a discussion, you're trying to force an issue. There's a difference, and I, at least, can see it. I'm not saying that you don't have the right to an opinion, but I am saying that you don't have the right to jam it down other people's throats. Sven Manguard Wha? 12:46, 24 October 2011 (UTC)[reply]
O.o -- fgTC 12:48, 24 October 2011 (UTC)[reply]
I snapped at you and I apologize for it. Since it is clear that we have both apparently come to the conclusion that any further debate between the two of use would not be productive, I think it best if I take my leave from this discussion. Sven Manguard Wha? 14:09, 24 October 2011 (UTC)[reply]
The strength in my opposition is based on the fact that (and some of this might just be my personal opinion):
  • I still don't see ANY STRONG argument for having this functionality
  • we should not spend efforts on things that are not supported by such arguments
So you still have to show me what exactly the benefit of this functionality would be (apart from saving those who want to share articles that way the sec copy-pasting a url into a field at facebook). Toshio Yamaguchi (talk) 13:03, 24 October 2011 (UTC)[reply]
Share buttons would actively encourage readers to share Wikipedia content. Elsewhere on the net, users are used to seeing and using these buttons. Their popularity is evidence of their appeal/usage. Their familiarity could add a spontaneity to readers choice to share. This is something they may not have done without a quick-fire option to do so. Nothing Wikipedia is was supported by strong argument for it before it began. It was developed against a tide of ridicule[citation needed] (As I see it) and look how well that turned out! Sometimes good ideas don't need to have strong arguments in favour; they just need space to grow. -- fgTC 13:19, 24 October 2011 (UTC)[reply]
"Elsewhere on the net, users are used to seeing and using these buttons."
That might be true, but is in my opinion still not a reason to implement this functionality. Furthermore again people can share Wikipedia content by pasting the url into the field at facebook. As far as I am aware, you have to be logged in to facebook anyway to share content like that, so you can also simply just paste the article url. And even if we provided share buttons, what exactly would Wikipedia gain through this functionality? Do you have any measures proving this would bring Wikipedia more active contributors or increase donations or something similar? What exactly would Wikipedia achieve through this? Toshio Yamaguchi (talk) 14:59, 24 October 2011 (UTC)[reply]
An increase in traffic and (over all else) the benefit is ease of use for readers and an encouraged sharing of knowledge. -- fgTC 15:15, 24 October 2011 (UTC)[reply]
An increase in traffic! What more traffic do we need, seeing as Wikipedia currently has a site rank of 5? I still fail to see how difficult it is to type http://enwp.org/PAGENAME or copy/paste http://en.wikipedia.org/PAGENAME, and why we need to cater to the unskilled who still can't format bold text without a visual editor. →Στc. 00:47, 25 October 2011 (UTC)[reply]
I strongly disagree with the last sentiment there are many skilled professional people who are not very computer literate and the unfriendly interface is a big put off for them. Any idea why a site that is read by hundreds of millions is only edited by a few thousand people? SpeakFree (talk)(contribs) 16:23, 26 October 2011 (UTC)[reply]
Why not cater for the unskilled? They could then become the slightly skilled and then maybe the almost capable. After a while they might very nearly be useful. Although, perhaps instead of only serving those who return the service maybe we could do what we can to help everyone without judging them on merit or worse, worth. -- fgTC 09:00, 28 October 2011 (UTC)[reply]
  • Support - users already "share" our articles by copying and pasting URLs. Why not make this easier for them and allow sharing via all the usual means (Facebook, Redit, e-mail, etc)? They're doing it already but with more effort. Rklawton (talk) 11:45, 24 October 2011 (UTC)[reply]
  • Support. Adding a share button doesn't magically turn Wikipedia into a social networking site. Times are changing, there is no need to stay in the dark ages of the internet. Ajraddatz (Talk) 14:12, 24 October 2011 (UTC)[reply]
  • Oppose, why make it easier to WP:CANVASS? --SarekOfVulcan (talk) 14:23, 24 October 2011 (UTC)[reply]
  • Suggestion Re: WP:CANVASS. I've searched the discussion and found no specific indication that this feature should or would be added to talk pages. If only added to article pages I (personally) doubt that a rise in canvassing would occur. Those who wish to rally support for their cause could and can do it with or without this feature. An increase in traffic (by any means) would bring an increase in ALL forms of traffic. We already deal with taking the rough with the smooth. Lets assume good faith. -- fgTC 15:15, 24 October 2011 (UTC)[reply]
    Exactly. Just like the Print/export: Create a book/Download as PDF/Printable version buttons, they would only work in main article space, not Talk pages. --Lexein (talk) 16:53, 27 October 2011 (UTC)[reply]
  • Support Sharing knowledge is the whole point of Wikipedia, and it should be as easy as possible for readers to share what they have found in Wikipedia with their friends. The NYT isn't a social network just because it has this button (and I've never understood the anti-social-network hysteria here anyways). It is a Good Thing if people who love Wikipedia share Wikipedia with their friends, and we need to get out of the stone age in terms of technology and usability. Why make people copy-paste URLs if a button would do the same thing, but in a more accessible way? I know my grandma uses Facebook and reads Wikipedia, but I doubt she could paste a URL between the two. Calliopejen1 (talk) 17:51, 24 October 2011 (UTC)[reply]
  • Support per Calliopejen1. Would make the site more usable for our readers. AGK [•] 21:56, 24 October 2011 (UTC)[reply]
  • Oppose I believe it is not in line with Wikipedia's purposes. An article can already be shared with the simple copy-paste of a link, why waste time and resources implementing such a trivial feature? Zidanie5 (talk) 23:02, 24 October 2011 (UTC)[reply]
    It's already implemented in one form: Signpost uses it. No waste involved. --Lexein (talk) 16:53, 27 October 2011 (UTC)[reply]
  • Oppose Per Sven Manguard, DGG, and others. We are not a social networking site; we do not need to use social networking to drive traffic into our website; these share buttons are creepy. Users can already share Wikipedia articles on Facebook by pasting the URL into their current status. Solve this non-problem with Greasemonkey if you have to. causa sui (talk) 23:54, 24 October 2011 (UTC)[reply]
    Re "creepy" - a simple Share link (a la SignPost's version) to an outside webpage does nothing and is not creepy. "Like" buttons are hella automated and are creepy, I agree. But we, again, are not at all talking about "Like". Just Share. --Lexein (talk) 16:53, 27 October 2011 (UTC)[reply]
  • Oppose Wikipedia content on any topic of interest is easily found using search engines. There's no reason to push specific articles onto Facebook. Being "liked" is not a useful measurement of article quality, and we already know that popularity does not equal importance. I don't see any net benefit to the project.   Will Beback  talk  00:21, 25 October 2011 (UTC)[reply]
    This is a publishing button, on a person-to-person basis. It's not about driving traffic, it's about literally sharing interest. Not everyone is "on" Facebook - saying no to this feature is saying no to everyone who would use it for non-Facebook purposes. Simplifying publishing for email - is that bad? Try thinking of it as just another link under Print/export: Create a book / Download as PDF / Printable version . --Lexein (talk) 16:53, 27 October 2011 (UTC)[reply]
    Perhaps I've misunderstood the proposal. Are you saying it has nothing to do with Facebook? Is this another name for an "Email this article" link? In other words, a registered user could use it to easily email a link to an article to someone outside of Wikipedia? If that's the case and if there was a mechanism to prevent spam or mass mailings, then I'd support that.   Will Beback  talk  18:26, 31 October 2011 (UTC)[reply]
  • If it will truly benefit the readers without damaging the content, let's do it, but I have my doubts. My main concerns regard privacy and entanglement. If we do this, I'd much rather we do it in a way that completely avoids any means by which third parties can track our readers in any fashion; I'm confident that we can avoid that, but I'd strongly prefer a solution on our end that's within our control. Beyond that, we've historically made a point of avoiding advertising and other propositions that might benefit funding and readership in the short term, for fear that they will damage our long-term goals of providing a neutral, comprehensive, quality encyclopedia. Will adding this feature compromise that in any way? Just as important, will it look like we've compromised it? Is this something our readers actually want? How will it affect their opinion of the site? – Luna Santin (talk) 01:05, 25 October 2011 (UTC)[reply]

Revoking unconditional support. Conditional support only Re: Neutrality concerns expressed in sub-section below. The condition is that if the feature were supported NO buttons would be supplied or specified by default but that Wikipedia simply adds support for a list of user-added buttons to be created. Wikipedia would then not be supporting or stifling any third-party social-network. I would like to see the feature but only if it does not compromise Wikipedia's neutrality. -- fgTC 02:02, 25 October 2011 (UTC)[reply]

I think this is a good idea; it allows readers and editors to tailor their WP experience to their own desires about whether to have a share button and if so where they'd like to share to. If the process of actually creating the button was complicated for some reason, you'd think that a reasonably perceptive business would have a staff member spend an afternoon writing some free wikipedia-compatible code for its users. AgnosticAphid talk 18:01, 25 October 2011 (UTC)[reply]
So do you *Support or *Oppose? Please indicate so at the beginning of your comment. --Lexein (talk)
This isn't a vote. Editors are neither obligated, nor even expected, to have to boil their comments down to one bold word for the sake of people who can't take the time to read and comprehend their arguments. Chris Cunningham (user:thumperward) - talk 17:26, 27 October 2011 (UTC)[reply]
  • Oppose. DQ and Sarek have raised a very important concern. An automated way of telling people off-site to "look at this" will easily become an automated way of canvassing on an unprecedented scale. Just imagine an influx of fans, unconcerned about our policies, into RfCs and AfDs. Yes, I know that people can do this already. But this proposal would automate the process in a new way, and the opening it creates will be filled. Wikipedia already comes up near the top of search engine results for a given topic. Any increased readership will be offset by disruption by people who come here not because they are interested in reading an article, but because someone told them to follow a link. --Tryptofish (talk) 17:23, 25 October 2011 (UTC)[reply]
FUD alert: Invalid concern. The Share link/button would be displayed on mainspace pages in read mode only. Nowhere else! The Print/export| Create a book / Download as PDF / Printable version links don't appear on Talk pages, so there's no reason for Share to go on Talk pages.
It's not automated. It's a manual click/hold/scroll/release, then enter your credentials on the target site. --Lexein (talk) 16:53, 27 October 2011 (UTC)[reply]
WTF alert: I have no idea what "FUD" means. I can just see it: an AfD notice at the top of a page, accompanied in read view by a share button. In your opinion, click/release is not automated: good for you. --Tryptofish (talk) 15:20, 28 October 2011 (UTC)[reply]
FUD is Fear, uncertainty and doubt: a tactic to exploit emotional triggers, rather than reason, to steer a discussion. The word "automated" triggers fears of "bots", or lack of control by users, and fear of "canvassing"; none of these has been shown to occur. The Share tool, like the Print/export: Create a book / Download as PDF / Printable version publishing tool would not exist on Talk pages. So, the AfD or RfC concerns you "imagine" are unproven and assume bad faith. The mere existence of a Share button on articles will not automate anything, and will not necessarily increase traffic to Talk pages unless people manually edit the pasted URL (and we're back to copy/paste/editing, which people won't bother to do). This is merely a publishing tool for articles, not Talk pages. --Lexein (talk) 16:48, 13 November 2011 (UTC)[reply]
Yes, I advocate this, but also an opt-in checkbox at login - that's how useful I think this tool would be. --Lexein (talk) 16:48, 13 November 2011 (UTC)[reply]
Precisely - right above or below the Print links. --Lexein (talk) 16:48, 13 November 2011 (UTC)[reply]
  • Strong support. This proposal would bring Wikipedia up to date with other sites, and make it easier for people to link to and reuse our content. Yes, it's possible people could use it to draw attention to their own vandalism, or to canvass for AFDs, but it's far more likely they'll use it to promote interesting and high-quality articles, which is what we want. The worries about privacy are entirely spurious. There is no good reason not to do this. Robofish (talk) 21:55, 30 October 2011 (UTC)[reply]
  • Oppose, especially if implemented as on-by-default, as was the Article Feedback Tool. 98.228.54.208 (talk) 00:38, 1 November 2011 (UTC)[reply]
  • Support, well, the "Like" buttons are nothing more but current fashion. Personally, I find them to be rather useless; I'm still one of the old-fashioned folk who meets "friends" in person, even though I theoretically have a Facebook account. But I see no reason why I should thus force this lifestyle ono other people; rather, I could at least understand it it were the other way around. It seems that there's a high interest in those "Like" buttons, and I'm sure that it's possible to deal with the mentioned issues, i.e. opt-out (either via preferences or CSS), possible canvassing (I mean, why should one like a talk page anyway?) and privacy issues (by simply using links instead of Facebook's social plugin). --The Evil IP address (talk) 11:57, 1 November 2011 (UTC)[reply]
  • Support. If this is implemented properly, there won't be any concerns about privacy - it will just be the same as copying and pasting a URL, only easier. I think this has great possibility for introducing new editors to the project because of the personalized nature of the links being sent. I am seeing a lot of negative comments here about new users, so I thought I'd share some wise words by Peteforsyth which I found on Rjanag's user page:

    It's my belief that most productive Wikipedians first arrive at the site wanting to do something that is against WP policy -- advance a point of view, cover something that doesn't meet the notability guideline, etc. We also often bring baggage from other Internet sites where the social norms or policies permit different kinds of behavior -- social networking activity, attacks, canvassing, what have you. None of this makes us bad people, just people who have not yet fully absorbed the Wikipedia ethos. (diff)

    As you can probably guess, I see getting more new editors on Wikipedia as a very good thing. With time and guidance, the vast majority of users will come to understand how this place works. About which social networks to include - I agree with TheDJ's suggestion below of including all of them via a clever interface. There is every possibility here for us to do this without promoting some social networks over others. — Mr. Stradivarius ♫ 11:24, 2 November 2011 (UTC)[reply]
  • Strongest possible oppose for a number of reasons. Firstly, these types of share button encourage the dumbing down of the Web. Wikipedia aspires to not be dumb. These things are dumb. We have a duty to avoid dumb things. If we put these things on the site, we might as well start offering free lobotomies to readers.
    The reason these things are stupid and unnecessary (and therefore ugly, because of their being unnecessary) is that there already is a universal way of sharing content on the web, namely copying and pasting URLs. This method absolutely guarantees that the user doesn't get infected with tracking cookies or does things they don't necessarily understand. Even though I'm an active user of Twitter, I never use "tweet this" links because I don't know ahead of time what kind of craziness they are going to get up to. Some send a pre-written (read: spammy) message to followers, others simply subscribe me to a Twitter feed associated with an account, while others send me down the OAuth garden path to authenticate and potentially provide access to my personal information, granting that application read-write access to my account. This kind of thing fails on the grounds of the principle of least astonishment.
    Secondly, it is impossible to be vendor neutral on this. You either pick the top three or four (Twitter, Facebook, Google Plus and Reddit, say). But then what happens when someone else comes along and wants to have their version of Yet Another Social Network on the system? How are we going to decide? Or just accept everything that looks vaguely social networky? Great. Then you end up with this kind of stupidity: a search box on your "add this" panel, so you can include both Blurpalicious (yeah, that's a real thing apparently) and Blogger. "AddThis" now has 335 different sites including such well-known services as "Throwpile", "OnGoBee", "mRcNEtwORK" (I aM nOt KIddInG aBoUT tHE SEEmInGLY RaNDOM cApITALiZAtION) and such not-at-all confusing things like having Digg, Digo and Diigo. I know, let's just exclude the unpopular ones from the list. And on what basis do we do that? WP:BIAS! We better not be introducing a US-centric, white male view of what's popular.
    Please, don't do this. These things are stupid, ghastly and commercial: everything that is loathsome about the commercialisation of the Internet is summed up by these stupid little buttons. I know that other Wikimedia sites including English Wikinews have them: I don't like them there either. —Tom Morris (talk) 09:13, 4 November 2011 (UTC)[reply]
Heh. "Please don't even test this" - wow. We don't work scared. It's not an app. It's not "Like". It's not "AddThis". It's not mandatory. It's a publishing tool, just like Print. We don't fear print, why fear publishing? The invocation of Least Astonishment is telling: you are conflating the invasive Like functions with this benign link forwarder. The included vendors can be selected by logged in users in their Prefs. It's not on Talk pages, it's for articles. --Lexein (talk) 16:48, 13 November 2011 (UTC)[reply]
  • Strongest possible, utterly interminable oppose - completely unnecessary, will clutter the website no matter how discreet these are, will do little to cement our "free" image (given that Facebook's "f" is a trademark, after all), and most importantly completely useless. We may need more writers, but this sure as hell isn't how to get them. — Joseph Fox 09:35, 4 November 2011 (UTC)[reply]
Despite all the dire fears, this is merely a publishing tool, like the Print links. Print isn't "clutter". Is it? Really? "Share" is optional, and only appears on mainspace pages, not Talk. This has a potential positive side effect of bringing in interested readers to articles (not Talk pages), who might become editors. You have, like all the other opposers, offered no evidence that "this isn't how to get them." Only testing could show any such evidence, so you should really be advocating testing, to prove me wrong. --Lexein (talk) 16:48, 13 November 2011 (UTC)[reply]
"per Fox and others?" With their easily disproven arguments? Really? --Lexein (talk) 16:48, 13 November 2011 (UTC)[reply]
  • Support. I see no harm here. Let the children play their games. — Dmitrij D. Czarkoff (talk) 17:59, 17 November 2011 (UTC)[reply]
  • Oppose. Canvass potential, clutter of one more unnecessary button which users can anyway add on their own if they desire to do so, issues with pointing to one specific service rather than multiple, issues with the image being all but free on a free encyclopedia and honestly, I don't see how it would improve the Encyclopedia at all. You want to share a link on X website? Go on X website and share it, nobody's stopping you from doing so. But expecting Wikipedia to provide you with a button to share you on website Y or X rather than R, only drags us into problems about which website we should include, for a plus side that I still fail to see. Snowolf How can I help? 08:15, 22 November 2011 (UTC)[reply]
  • Support - I think it will add traffic and help people communicate well. It is possible to make a very inconspicuous interface for those sorts of things. Greg Bard (talk) 09:00, 22 November 2011 (UTC)[reply]
The vast majority of users are reading articles in order to find something out. It is (I feel) fair to assume that they may have friends who share their interests both online and out there shivers. The purpose of a share button would be simply accessibility.
Scenario: Mr. or Ms. Visitor wants to know why the stars are all twinkly. They use a search engine and are offered a link to Wikipedia. They follow it and read a fascinating article about astronomy and follow a couple of internal links to other articles (all of which are equally fascinating). Later that day they are chatting with their friends on some dreadful social networking site or other and mention that they were "reading erm... a erm... Wikipedia erm... Well it was really interesting anyway. I'll see if I can find it again. How do I find my browsing history?" And so on.
Alternative scenario: Mr. or Ms. Visitor wants to know why the stars are all twinkly. They use a search engine and are offered a link to Wikipedia. They follow it and read a fascinating article about astronomy. At the side of the page they see a familiar looking icon. "Oooh! I can share this with Barbara. Cool". They follow a couple of internal links to other articles (all of which are equally fascinating) and similarly share those with Babs. Later that day Babs and our visitor have a lovely chat about the articles they have both now read.
This comment was brought to you with its tongue firmly embedded in its cheek. fredgandt 09:19, 22 November 2011 (UTC)[reply]

Share with which services?

Parallel question, and one that doesn't seem to be getting much attention here: supposing that we do add a "share" button, who is it going to share with? Which social media services would be included or excluded from this feature? On what basis? – Luna Santin (talk) 00:34, 25 October 2011 (UTC)[reply]

I sort of mentioned that earlier. Several years ago, we'd be sharing on Myspace, and if you asked my friends earlier this year where we'd be sharing ten years from now, most of them would say Google+. There's tons of Social networking websites, many rise and fall all the time, and while Facebook is currently popular, it's still just the "in-thing" and not something universal or unending (which this site is gonna do it's damndest to do). Choosing that one site over the others is playing favorites and is not neutral, and it kinda smacks of buzzword-ism, "Hey, Facebook is popular right now, so we gotta use it too because future." Facebook is only one facet of social networking, and we cannot determine whether it will succeed or fail, but we will be giving it non-neutral support if we provide it a feature that we do not provide other sites. Ian.thomson (talk) 00:45, 25 October 2011 (UTC)[reply]
Interesting argument (seems a valid concern). Ian, are you suggesting that either all or none should be supported? Or do you oppose any support? Genuine interest here. I'm not pulling your chain. -- fgTC 00:54, 25 October 2011 (UTC)[reply]
@Ian, agreed, adding a social networking feature could have the same effect on Wikipedia as if we were to put banner ads on the site. (Arguably, the share "feature" would be an ad.) Adding a "share" button would be a breach of our neutral point of view policy. That should also be taken into account before such a "feature" is added. Alpha_Quadrant (talk) 00:58, 25 October 2011 (UTC)[reply]
Why not just use the same ones Wikipedia Signpost does?[5] We already have a precedent for this. Let's just follow Signpost's example. A Quest For Knowledge (talk) 00:54, 25 October 2011 (UTC)[reply]
It would be impossible to support all of them, and it'd be too much of a hassle to go with only the notable ones. As for the Signpost suggestion, I'd agree except "The Signpost is an independent publication which is not affiliated with the Wikimedia Foundation." I'm not sure that really sets a precedent any more than a user essay. Ian.thomson (talk) 01:02, 25 October 2011 (UTC)[reply]
Withdrawing unconditional support re neutrality concerns. -- fgTC 01:52, 25 October 2011 (UTC)[reply]
Maybe the signpost isn't affiliated with the Foundation. But that doesn't mean that it's not a useful starting point for which social networking sites we could include. I agree that including support for all, or even all notable, social networking websites would be a futile and vexatious exercise. But there's got to be some way to include enough different websites to be universally useful while not trying to have support for 500 websites. Could we take a poll every 6 months to see what users' favorite networks are? Or maybe we could base inclusion on the network's number of users (if this can be readily determined)? Just throwing some ideas out there, I know there are some issues with these suggestions. AgnosticAphid talk 17:54, 25 October 2011 (UTC)[reply]
I don't really know enough about coding to make some of these statements. TheDJ makes it sound like it'd be easy enough to make something with support for 500 websites. So maybe this isn't an issue. AgnosticAphid talk 19:43, 25 October 2011 (UTC)[reply]
I think they would be applicably licensed for use. -- fgTC 04:20, 25 October 2011 (UTC)[reply]
Well, if we followed the Signpost example, there wouldn't need to be a logo. I don't think that merely having the plain text "Facebook" or whatever would raise advertising concerns. But I'm no expert. AgnosticAphid talk 17:47, 25 October 2011 (UTC)[reply]
Actually, I was wrong, the Signpost does indeed have logos. But if this is a sticking point they hardly seem necessary. AgnosticAphid talk 17:49, 25 October 2011 (UTC)[reply]
I'm quite sure that is rather new... They used to be text only. —TheDJ (talk • contribs) 19:17, 25 October 2011 (UTC)[reply]
It is not possible to explicitly license a logo for use on Wikipedia. Content used on Wikipedia must have been released under a free license which grants anyone the permission to use it for any purpose (including commercial use; see Resolution:Licensing policy). Toshio Yamaguchi (talk) 09:44, 25 October 2011 (UTC)[reply]
Those policies are all related to content. this would be site-specific UI, not content, which has never been a question before. Specifically, these icons would not appear in database dumps, so all existing policies and arguments for/against are irrelevant. ▫ JohnnyMrNinja 14:15, 25 October 2011 (UTC)[reply]
I see wholly no reason why we can't support all 300+ services that exist in the world. Just requires a bit of smart programming. If addthis can build it, then we can build it too. The most popular 4 would be easy accessible, the rest reachable via an 'other' option + ajax search dialog. If you use one of the 'other' options, you get a cookie, that ups the priority of that server next time you visit. Easy peasy. Seems fair enough to me, no neutrality issues there. We could even make it a seperate service for other OSS/Free/NGO projects. —TheDJ (talk • contribs) 19:17, 25 October 2011 (UTC)[reply]
  • Moderate Support - not really that bothered, but see no reason why not, and it may be useful for non-editor readers who want to share something interesting they've found. I see nothing that would suggest that it would track people (if it's just a share, not an integrated 'like'), except in the way that any share, whether or not integrated, would do. SamBC(talk) 23:08, 27 October 2011 (UTC)[reply]
  • Normally an RFC has a specific proposal at the top that clearly defines what is being proposed and what its purpose is. Given that this discussion is now extemely long to the point where we can't expect a person to read the whole tjhing just to figure out where they stand on it, such a statement would seem to be in order so that we are sure we are all talking about the same thing. Beeblebrox (talk) 18:47, 30 October 2011 (UTC)[reply]
We can either use AddThis, or marshal the resources to create our own tool do do the same job. ---— Gadget850 (Ed) talk 12:50, 1 November 2011 (UTC)[reply]
This is really great, thanks for putting it together. Wish it was better publicized as it seems at least some editors would find it useful. AgnosticAphid talk 23:26, 1 November 2011 (UTC)[reply]
  • Comment to those suggesting an opt-in implementation or a gadget. Remember that those functions would only be available to registered users, not the general readership. In order to have this encourage readership or whatnot, it would have to be opt-out. Danger High voltage! 01:57, 8 November 2011 (UTC)[reply]
  • Oppose - Who would decide which 'share' buttons to add? Facebook? Google+? Reddit? How many of these annoying little things would we need to add to remain neutral and independant? I don't see much upside in this - and the implicit suggestion that we support these commercial groups seems to be a bad thing. SteveBaker (talk) 15:25, 10 November 2011 (UTC)[reply]
  • Comment The proposal is ill-defined. I have spent the last half hour looking for an explanation of exactly what the proposed "share" button would do, without success. I have seen an mind-boggling variety of comments, objections, whinges, denials, claims, counterclaims etc, but no specification of the actual function of the proposed item. Out of general principle I am inclined to oppose such a poorly explained proposal on the grounds that it is not possible to make an informed decision. One particular point is glaringly unobvious. Who would the share button share with? Peter (Southwood) (talk): 05:49, 13 November 2011 (UTC)[reply]
  • Oppose The reasoning of: "Adding a share button will bring more internet traffic to the site. This will increase the amount of editors and users".... That makes no sense. Out of the millions of websites on the internet, Wikipedia is rated #5 as far as popularity and how much internet traffic visits the site.
  • How would adding a share button help the site? Whats the point? Why would someone want to share an article on Wikipedia, when you can just provide a link to it? I just don't see any point. Dusty777 (talk) 20:11, 13 November 2011 (UTC)[reply]
  • Oppose. There seems to be some confusion regarding the implications of this proposal. "Share" with what? As has been pointed out, there's a neutrality issue here: I don't think we should pick certain services and leave out others, and I don't think I've seen a feasible solution to that problem, at least not for non-registered readers. I do understand the supporting arguments, but I don't think what we win here is worth it. /Julle (talk) 04:50, 15 November 2011 (UTC)[reply]
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.

Wikipedia mobile page loading

In Wikipedia mobile you shouldn't have to wait till the opening page loads before beginning a search. You should be able to interrupt a page loading with a new search. You shouldn't have to wait for all the images to load before being able to scroll down the page (Mozilla worked this out c 1995 with Netscape navigator)

All these are infuriating when using Wikipedia mobile with slow download times. — Preceding unsigned comment added by 58.163.175.179 (talk)

Please see Wikipedia:Bug reports and feature requests. Wikipedians can't do anythign to help with this issue. עוד מישהו Od Mishehu 12:24, 23 November 2011 (UTC)[reply]

Disable WikiLove by default

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.
Do not disable wikilove. Graeme Bartlett (talk) 09:34, 22 November 2011 (UTC)[reply]
The idea of Wikilove is to encourage new editors. It can be disabled by individual users. The WMF can impose its will anyway. The minority of supporters of disabling Wikilove said that it was introduced without consensus and made the encyclopedia look less serious Graeme Bartlett (talk) 21:44, 22 November 2011 (UTC)[reply]

Because there is rather significant consensus against the WikiLove feature, I propose the following:

  • Users must opt in to be able to receive WikiLove messages (the heart symbol must be opted in to). Some users' talk pages are barnstar-free zones.
  • Users must opt in to be able to send WikiLove messages. I've seen this feature abused by vandals before, and it'll just save a lot of trouble.

Unfortunately, the WMF may not agree and may be refusing to budge on this.Jasper Deng (talk) 22:32, 29 October 2011 (UTC)[reply]

I don't know why it was enabled by default in the first place. I never saw a discussion for it. I'd prefer that we avoid this kind of thing. It's a bad precedent. —Designate (talk) 23:16, 29 October 2011 (UTC)[reply]
You may want to read Wikipedia:You don't own Wikipedia, I found it rather illuminating. Also, how did you determine there is significant consensus against it? Could you please link a RFC or other discussion where such consensus was reached? Yoenit (talk) 23:35, 29 October 2011 (UTC)[reply]
I remembered discussion either here or on Jimbo's talk page.Jasper Deng (talk) 23:55, 29 October 2011 (UTC)[reply]
To me this should be a rational place for objective discussion. Love hearts are sentimental and emotional trappings that don't belong. Let those who want such soppy add-ons actively seek them, but don't impose them on me please. HiLo48 (talk) 00:00, 30 October 2011 (UTC)[reply]
What about a magic word on talk pages that disables the WikiLove functionality for that user's page? Sort of like {{nobots}} but not a template. /ƒETCHCOMMS/ 01:55, 30 October 2011 (UTC)[reply]
What magic word should it be?Jasper Deng (talk) 02:33, 30 October 2011 (UTC)[reply]
I don't think there's a need for a new magic word. When a user disables WikiLove, that should simply disable it both ways.--Eloquence* 03:49, 30 October 2011 (UTC)[reply]
I disagree. I disabled WikiLove not (just) because I dislike the idea, but because the little red icon, as the only non blue-grey-black thing on my screen, toys with my latent ADD. That being said, I'm not opposed to receiving messages, and I still give Barnstars the old fashioned way. I just want the icon off my page, I'd hate for that to shut other users out. Sven Manguard Wha? 05:07, 30 October 2011 (UTC)[reply]
This is a serious question Sven: Would you be less bothered by the "wikilove" icon if it were not red? Maybe a feature to set the colour could be added or perhaps with consensus change the default to (blue?) another less aggressive colour. fgtc 05:47, 30 October 2011 (UTC)[reply]
It's easy to customize and a blue heart icon is already provided. See mw:WikiLove#Change the heart icon --Eloquence* 06:09, 30 October 2011 (UTC)[reply]
I see. But it is really the default appearance that matters I think. Also easy to customize is arguable. For some it would be far from easy. I'm not all that invested in this debate so am just saying it as I see it. I am surprised the default icon isn't a barnstar though. Surely that would have made more sense. I think we would very likely not be having this discussion if it were a barnstar by default. fgtc 07:31, 30 October 2011 (UTC)[reply]
A barnstar icon might cause confusion with the "add to watchlist" star in the Vector skin, esp. for new users not yet familiar with the concept of barnstars. But it's certainly possible to change the icon on a sitewide basis as well. Portuguese Wikipedia did so; they changed it to a "thumbs up" (see last lines of Common.css on Portuguese Wikipedia).--Eloquence* 07:51, 30 October 2011 (UTC)[reply]
  • Support this proposal. I sometimes use the WikiLove gadget as it makes it a lot easier to deliver barnstars and "wikilove", but it should have never been made a standard, non-optional feature. Furthermore, I believe the WMF, while it has every right to do so, takes the wrong approach by forcing such features down the throat of Wikipedians without initiating a community discussion. — CharlieEchoTango — 05:30, 30 October 2011 (UTC)[reply]
  • Oppose Get over it. You can disable it if you don't like it. It's not a big deal, and it does help some people. Also, as I understood it, one of the purposes behind this, was to make it easier for new users to give out barnstars etc, and increase the sense of community for them. By disabling it by default, it effectively nulls this advantage (most new users wouldn't even know it existed, let alone how to enable it) --Chris 06:53, 30 October 2011 (UTC)[reply]
  • Support removing it as a default. It should never have been implemented without a wide community discussion and consensus - and I suspect many, like me, would've objected to it on the basis of WP:NOTMYSPACE  Chzz  ►  08:54, 30 October 2011 (UTC)[reply]
  • Because it's easily disabled through My preferences/editing, I doubt it's worth wasting much effort convincing the WMF to change the default. It's their quick and dirty attempt to improve the social interactions on Wikipedia, which do need improvement indeed, but wikilove is just lipstick on a pig. ASCIIn2Bme (talk) 10:33, 30 October 2011 (UTC)[reply]
  • Oppose. There is a silent majority in favour, I would think. Claims of a significant consensus having it are deeply affected about who could be bothered to comment. It hasn't revolutionised the way I for one interacts with Wikipedia. But that doesn't mean that to most people it has been unhelpful. Grandiose (me, talk, contribs) 10:42, 30 October 2011 (UTC)[reply]
  • Undecided. On the one hand I think this feature does not really cause any harm directly (it is just one tiny icon at the top of a page, compared to the article feedback tool, which tends to clutter articles) and it in fact might really make it more easy for new users to give awards to other users and show appreciation. What I am much more concerned with is that this feature was rolled out without community discussion. The WMFs intention seems to be (at least to me) to aggressively make new users feel more welcomed within the community. I strongly believe that features expressing something such as WikiLove MUST meet the demand of the community and should NEVER be introduced without community discussion. It is this desire by the WMF to "control" or at least significantly influence the way in which members of the community interact with each other that I am very concerned about. The way the WMF is handling things lately demonstrates how much they have lost the touch with the community. This is where my main concern lies. This is just one symptom of a much more serious problem. Toshio Yamaguchi (talk) 12:39, 30 October 2011 (UTC)[reply]
  • Oppose Go read a newspaper or something similar outdated, and stop blocking Wikipedia's future. (there, same pointless hyperbole, different way around :D ) —TheDJ (talk • contribs) 14:03, 30 October 2011 (UTC)[reply]
If Wikipedia's future consists of hinges on pampering each other with artificial kittens, then the rest of the Internet is not going to be very impressed. –MuZemike 21:24, 31 October 2011 (UTC)[reply]
  • Even though I support the extension's removal (it really should be a gadget), this isn't going to happen. MER-C 08:50, 1 November 2011 (UTC)[reply]
  • Support per Chzz. Nev1 (talk) 16:46, 2 November 2011 (UTC)[reply]
  • Oppose Chris put it well; the point of the feature was to make it easier for new users to show appreciation for helpful edits by others. Disabling the feature by default would completely negate that purpose. Yes, some people don't like such messages and have even added messages to that effect to their talk pages. But a.) those are not the majority of users and b.) such sentiments are irrelevant for this proposal. Even if you have a big "NO BARNSTARS!!!!!!1111" banner on your talk page, you cannot stop people from adding them manually anyway. So why should those sentiments play any role here? You don't like using the feature? Don't use it. Don't like receiving barnstars? Tell people and hope they respect it. There is really nothing else to it. Regards SoWhy 17:28, 2 November 2011 (UTC)[reply]
  • Oppose The WMF is kinda like the honey badger: WMF does what the WMF wants. The point of the extension was for new users to be able to use it. By disabling it by default your are defeating that purpose--Guerillero | My Talk 21:06, 3 November 2011 (UTC)[reply]
  • Oppose. I know it's rather like buying a commercial greeting card instead of writing a proper personal letter, but disabling it by default defeats its primary purpose (giving new editors some idea of constructive ways to express appreciation, as well as a subtle hint that they ought to do this) and won't prevent the rest of us from filling Jasper's talk page with soppy messages manually. If you don't like them, ignore them. WhatamIdoing (talk) 18:41, 4 November 2011 (UTC)[reply]
  • 'Oppose Wikipedia needs to encourage its editors and a positive atmosphere as much as possible in an already shitty website in regards to how editors treat one another.♦ Dr. Blofeld 19:00, 4 November 2011 (UTC)[reply]
  • Oppose. (I have an obvious COI on this one, so feel free to discount my vote.) My opinion is that Wikipedia is a serious project with a serious goal. It also has a serious problem: it is often an unwelcoming and even hostile environment. As a new user you are several times more likely to get a templated warning than a friendly message from a real person. Even as someone who constantly preached being friendly to fellow editors, I found myself using Twinkle on a daily basis but rarely taking the time to manually put together a barnstar template. I don't think WikiLove is perfect, but I think it's a step in the right direction. I would really love to see some RfCs on changing WikiLove rather than just turning it off. Every feature in WikiLove is configurable. If people want the icon changed, it can be changed. If people don't want kittens, they can be removed or replaced with something else. I understand that some people just consider it a distraction, but for me, the more friendly messages I get from other Wikipedians, the more I feel motivated to keep contributing. Kaldari (talk) 06:38, 6 November 2011 (UTC)[reply]
  • Oppose. It's corny, but essential in my opinion. If you want to stop losing editors, you need to give them some sort of validation. A pat on the back. Wikilove makes it easy to do that. -- Adjwilley (talk) 01:11, 12 November 2011 (UTC)[reply]
  • Oppose. There are potential contributors with little computer experience who can benefit from this feature. Many of us have been using computers so long that we don't realize how bewildering the maze here can be. KIS. PhnomPencil (talk) 09:47, 13 November 2011 (UTC)[reply]
  • Oppose this nonsense. If you don't want to give barnstars out, don't give them out. If you don't want to receive barnstars, leave a note on your talk page, or an edit notice, saying you don't want to receive barnstars. Problem solved. elektrikSHOOS (talk) 20:47, 14 November 2011 (UTC)[reply]
  • Support - the problem is not barnstars, although they can be used in frivolous manner; the problem is all the "House Sparklypoo" kittens-and-bunnies crap. I feel that there is a line between being sociable and being Facebook or Gaia; and that WikiLove, from the smarmy name to the kawaii possibilities, lurched way the hell over that line. (And I'm self-aware enough to wonder whether the hate/love line on WikiLove correlates to gender identity at all, and perhaps to age as well.) --Orange Mike | Talk 21:20, 14 November 2011 (UTC)[reply]
  • Oppose. I didn't like the idea of WikiLove in the beginning, but having used it a few times, I've changed my mind. I've seen the older practice of giving barnstars used not so much to give positive reinforcement to someone, but instead to make a back-handed attack at someone else. Yeah, giving kittens to people is weird & off-putting (I write that as someone who lives with two adult cats who aren't always cute & cuddly), how can I offend someone by giving their on-Wiki antagonist some WikiLove? And there are other options -- & the tool can be reconfigured. (How about giving other people virtual library cards instead? That might reinforce the idea that we're here to create an encyclopedia, & not Yet Another genre of flame war.) -- llywrch (talk) 20:38, 15 November 2011 (UTC)[reply]
  • Oppose We need to support giving encouragement to other editors. The warning templates, warnings, personal attacks, rudeness, and lack of a welcoming attitude toward new and existing editors needs a counterweight. I agree that the name is corny, and this is just a start, but we really need more of this sort of thing, not less. First Light (talk) 02:52, 22 November 2011 (UTC)[reply]
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.

Time for rollback edits to be unambiguously identified as such (re-prop)

Rollback edit summaries should be clearly labeled with "using [[WP:Rollback#When to use rollback|RB]]", as done by AWB, Huggle, Twinkle, and others. Example edit summary:

(Reverted edits by 12.34.56.78 (talk) to last version by 11.22.33.44 using RB)

or

(Reverted edits by 12.34.56.78 (talk) to last version by 11.22.33.44 (RB))

(I proposed this at (policy). Once clarified, it received support from 3 editors, of four discussing, aside from me, but rolled off into the archives. So I'm re-upping its central point here for wider discussion and possible implementation.) Oppose? Support? --Lexein (talk) 14:40, 11 November 2011 (UTC)[reply]

(revised specific link above. --Lexein (talk) 14:13, 14 November 2011 (UTC) )[reply]
  • Comment It is possible this would encourage greater numbers of requests for the ability. I trust admin to determine who is given/denied the ability but wonder if the potential flood of requests for it might have two knock on effects. Namely 1) A backlogging 2) Admin rushing through the requests and perhaps being less inclined to consider them as carefully when doing so. Otherwise I think it's a fine idea and do not oppose it. fgtc 15:03, 11 November 2011 (UTC)[reply]
  • Seems OK to me (either). It looks like it's in MediaWiki:Revertpage  Chzz  ►  16:25, 11 November 2011 (UTC)[reply]
  • Comment I support this, but it would be even more useful if an edit identified as a rollback were flagged as such in the API. --JaGatalk 17:32, 11 November 2011 (UTC)[reply]
  • Comment - It's already linked; "Reverted edits by....". Also,
(Reverted edits by 12.34.56.78 (talk) to last version by 11.22.33.44) (RB)
Please point out an edit where the word "reverted" is already linked. I literally haven't seen it. All the "Reverted edits by" edit summaries I've seen have been unlinked. Did this just happen recently? Hm. Hm hm hm. I hope I haven't been mistaken this whole time. The linked "Reverted" goes to Help:Reverting, not WP:ROLLBACK. This doesn't explicitly state the tool used. So I'd still like (RB) added. --Lexein (talk) 07:06, 12 November 2011 (UTC)[reply]
Although I don't see any good reason why the tool needs to be identified; as long as the "reverted" link remains, my soft opposition to adding a link to "rollback" can be considered even softer. fg 10:14, 12 November 2011 (UTC)[reply]
I'd be reluctantly satisfied if the "reverted" link pointed to WP:ROLLBACK for rollback edits (because it lists explicit reasons for rollback/undo), and nothing else changed. --Lexein (talk) 14:13, 14 November 2011 (UTC)[reply]
  • Since Σ has pointed out what I had forgotten (I try and avoid using rollback per policy/guidelines) I must softly oppose. The link already present provides a page with exactly the sort of info editors would benefit from reading if they are the sort of editors who need any link at all (due to not understanding why their edits were reverted). So beyond "if it ain't broke don't fix it" I really think this would be a downgrade compared with what we already have. fg 23:48, 11 November 2011 (UTC)[reply]
Seems like a very long way around the horn for an editor to learn the reason for an edit, and guesswork, as opposed to an explicit statement of reason. We're trying to retain editors, and clear(er) edit summaries can help. I'd like to know the "conversion rate" of editors who were at first "bad" editors, who later became "good", and what role clear edit summaries played. --Lexein (talk) 14:13, 14 November 2011 (UTC)[reply]
  • Gently oppose. I just don't see the point. Who actually cares whether I click the red "Rollback vandal" button or the blue "Undo" button when I encounter vandalism? They have exactly the same effect on the article. WhatamIdoing (talk) 03:21, 12 November 2011 (UTC)[reply]
All other tools identify themselves. --Lexein (talk) 07:06, 12 November 2011 (UTC)[reply]
Rollback is a core feature of the mediawiki software, not a js script or external application. Per what Sven said below, in most cases a block is required to stop use of those, whereas rollback can just be removed. Ajraddatz (Talk) 15:53, 13 November 2011 (UTC)[reply]
Its status as a core feature does not seem like a good reason to provide no direct link to the actual rollback edit reasons. See Why: below. --Lexein (talk) 14:13, 14 November 2011 (UTC)[reply]

Rollback isn't a tool, in the way that TW is, and there's no real practical difference between a rollback done using rollback and one done using restore revision and one done by undo. More importantly, abusing the revert functions is handled by blocking. It's no longer possible to remove someone's TW access, so yes, you could revoke rollback, but then someone would switch to TW. That's why if talking dosen't work, you just block. I guess what I really want to know is "Why?" Sven Manguard Wha? 13:35, 12 November 2011 (UTC)[reply]

Why: Rollbacks offer 1. No edit reason (I get it), 2. no class of edit reasons (rollback), 3. no unambiguous identification of the tool AND 4. the "reverted" link points to the less specific Help:Revert (which surprisingly does not list the recommended reasons for rollback, or indeed undo), not WP:Rollback; this obscures the clear reason why the edit occurred. At least identifying the tool or using an appropriate link provides a reviewing editor with a class of reasons for the edit - that is, "the editor thought the reason fell within the Rollback set of explicit reasons", without having to waste time examining the diff to puzzle it out. Unambiguously identifying the tool adds trust and saves time.
Also, from a random editor's point of view, it's just a tool, and seems unique. --Lexein (talk) 14:13, 14 November 2011 (UTC)[reply]
And this differs from the undo button how, exactly? "Undo" offers "1. No edit reason (I get it), 2. no class of edit reasons (rollback), 3. no unambiguous identification of the tool AND 4." it doesn't even offer a link to Help:Reverted.
Why should one regular software feature (rollback) be held to a different standard than another regular software feature (undo)? WhatamIdoing (talk) 17:40, 18 November 2011 (UTC)[reply]

Oppose. I really can't see what possible good this could do. Per Sven above, half of the point of marking tool usage is so that people can be blocked when they abuse it - rollback is different, since it leaves a very distinguishable summary and can be removed from the user. What's next, adding (undo) to the end of the undo summary? I just cannot see any possible benefit to this proposal, or any need for it in the first place.

If this does go through, though, please at least change it to

(Reverted edits by 12.34.56.78 (talk) to last version by 11.22.33.44 using rollback)

which looks more professional and doesn't include meaningless acronyms. Ajraddatz (Talk) 15:50, 13 November 2011 (UTC)[reply]

See Why: above. --Lexein (talk) 14:13, 14 November 2011 (UTC)[reply]
I still don't see the point. These reasons are so minor that they are outweighed by the potential disruption due to lots of difficult new editors trying to get rollback revoked for the editors who reverted them. Only editors with some idea of how Wikipedia works (in particular not a bureaucracy) should be able to recognise rollback edits. Hans Adler 10:01, 22 November 2011 (UTC)[reply]

Comment This is a functionality of mediawiki, so I don't see it any more useful than like if we changed all edit summaries to have (MediaWiki) in there, reason why there is TW, HG etc is to notice that edit was done by tool and not by the interface itself, so I don't think it's really needed. Petrb (talk) 09:16, 14 November 2011 (UTC)[reply]

I wouldn't add "Mediawiki" to edit summaries, nor reduce them to state only "edit occurred." This isn't just MediaWiki, it's an instance, with its own guidelines, like WP:Edit summaries. See also Why: above. --Lexein (talk) 14:13, 14 November 2011 (UTC)[reply]
  • Weak support. Not terribly useful, but completely harmless AFAICT. ― A. di M.​  12:53, 14 November 2011 (UTC)[reply]
  • Slightly oppose: This doesn't immediately appear to add anything useful. Normally, when I see "Reverted edits by such-and-such," without a (TW), (HG) or (IG) attached, I assume it was a standard rollback. In addition, I'm concerned that adding a tag such as this might confuse some editors on the difference between a scripted tool such as Twinkle and a server action like rollback. In the end, though, it's two letters, so I don't particularly care either way. elektrikSHOOS (talk) 20:52, 14 November 2011 (UTC)[reply]
  • Comment re. why - there's at least a couple of reasons why it can be useful; 1, it helps when checking if a user is/isn't using rollback correctly, because it makes it easier to find 'em in their contribs, and 2, it helps with tools that can count certain types of edits by any user - see http://toolserver.org/~soxred93/autoedits/ - if it's working, that tool counts how many edits a user has made with twinkle/huggle/etc, by counting (TW) etc. in edit-summaries. Adding this unique string would mean we could count rollback-usage.  Chzz  ►  09:29, 17 November 2011 (UTC)[reply]
    Of course, you could do that right now, using the unique "Reverted" string, and unlike changing the format, that would be useful for all edits ever, not just those made in the future. WhatamIdoing (talk) 17:43, 18 November 2011 (UTC)[reply]

"Blocked" template tweak

Hi according to previous discussions about the archiving of talk pages of ip users, based on Chzz's suggestions I created an extension for mediawiki which allows creation of template which automatically change its content when user is unblocked, so that we could have templates which don't confuse especially new users who are using shared ip address, were blocked in past but don't understand that they were already unblocked, this extension is now installed on huggle test wp. If you need any detailed technical informations about it, let me know. Please let me know what do you think about it, if you support the idea, or have some comments how to improve this. Petrb (talk) 08:59, 12 November 2011 (UTC)[reply]


Technical details extensions introduces new word {{USERBLOCKED}} which substitutes to true of false based on that if block of user is active or not, that means we could make templates like this http://hub.tm-irc.org/test/wiki/Template:Blocked-test?action=edit which automaticaly change their content when block expires, as you can see http://hub.tm-irc.org/test/wiki/User_talk:Testy_Magee there. Petrb (talk) 20:51, 16 November 2011 (UTC)[reply]

Uh, why is CheckUser accesible to everyone?Jasper Deng (talk) 23:05, 12 November 2011 (UTC)[reply]
It is not a wikimedia site so they can do what they please... (I don't see where you are getting that idea from anyway) --Guerillero | My Talk 23:41, 12 November 2011 (UTC)[reply]
There is no permissions error when someone tries to access Special:CheckUser right there.Jasper Deng (talk) 04:12, 13 November 2011 (UTC)[reply]
The fact that you are stress testing other wikis is a tad troubling --Guerillero | My Talk 07:46, 13 November 2011 (UTC)[reply]
Isn't that irrelevant? we do more tests there, I am mediawiki dev, so there are some more extensions being checked, it's latest head from svn, so it seems that it's a bug (I started reviewing cu source for now to fix that), anyway if it's a problem I will disable cu there, so that you can try that tool I am talking about here, your ip address wouldn't be recorded if you just open the link I sent here (you would probably have to make some edits), but I will probably clean cu table after tests anyway. Petrb (talk) 10:36, 13 November 2011 (UTC)[reply]
If you wanted help with that, I could insert some more magic to this extension you could probably use for that ;) Petrb (talk) 20:40, 16 November 2011 (UTC)[reply]

Comment since this is a very simple extension it's quite possible that it could get deployed soon (if there was some support), so I would like to know if you wanted to change anything with that before that happens, Chzz suggested that it could return even the time when block expires so that template can show that, what do you think? is it necessary? Petrb (talk) 03:06, 15 November 2011 (UTC)[reply]

  • Template magic could do a lot of this, especially if people are using tools to block. Something like {{Blocked|2011-11-18 23:22|3 hours}} Rich Farmbrough, 02:08, 19 November 2011 (UTC).
    • {{Timed block}} for your delectation and delight. Rich Farmbrough, 02:59, 19 November 2011 (UTC).
      • Comment I think it would be better if the image were different when the block had expired (e.g. a pink X, or a translucent X, or something), so that it would be immediately obvious what the situation was without having to read the template. Because new users might not even be aware that the template changes at all and so might just see the obvious warning image and assume it meant "blocked", or only read it once (when the block was active, say) and not bother re-reading. It Is Me Here t / c 13:14, 23 November 2011 (UTC)[reply]
        • Absolutely! I expected someone else to take care of that - and the detailed wording! Let me spend a few minutes on it though. Rich Farmbrough, 15:34, 25 November 2011 (UTC).

Block expired

Block running

Rich Farmbrough, 15:39, 25 November 2011 (UTC).
  • Possible issue I'm concerned that a magic word like {{USERBLOCKED}} would be difficult in quite a lot of cases:
  1. Users may be blocked under more than one IPs, or IP ranges for example, or under a usual and alternate account (legit or socked). :# It would need thought whether a template based on "the IP/account who !owns this user page/user talk page is blocked" would cover IP users, dynamic IP users, users who edit as a username and as an IP.
  2. It is meaningless in some namespaces, not a problem per se but needs considering in design.
  3. It also needs thought whether it exposes Checkuser data and breaches privacy. If I want to check if user X is the same user as IP Y.Y.Y.Y, would I be able to post this template on User:X or User:Y.Y.Y.Y a minute before the block on one of these expires, or when the user is blocked, and see if its status is in sync with the block on the other? What about autoblock collisions?
Overall I prefer a templated approach as User:Rich Farmbrough suggests - more flexible, and no risk of any exploits which might allow non-public data to be verified. FT2 (Talk | email) 15:13, 19 November 2011 (UTC)[reply]
Actually it works only in userspace or talk, otherwise it return word unknown concerning the templates which works automaticaly with timestamp, it's good idea but they also have some issues, for instance if someone unblock the user before it expired, it wouldn't work, also it can't replace existing templates, and it's harder to submit such templates for sysops. I don't see any possible security or technical problems, it detects if user is blocked directly from User class in mediawiki, so there are no colissions or such issues. Actually I also heard idea to implement this to mediawiki core (from wmf dev) Petrb (talk) 09:12, 21 November 2011 (UTC)[reply]
Perfect idea, I will extend it right now. Petrb (talk) 07:52, 25 November 2011 (UTC)[reply]
Unfortunatelly current mediawiki doesn't have capability to support such feature, so maybe in future, sorry. Petrb (talk) 08:12, 25 November 2011 (UTC)[reply]

Proposal to take the "File namespace noticeboard" live

Hi there. I'd like to get some additional consensus for this board before taking it live. Once it's taken live, I would like for it to be linked to in the "Noticeboards and related pages" template that is at the top of many of the noticeboards, (it's the big one at the top of AN, AN/I, and this proposed page, among others. Sven Manguard Wha? 11:31, 12 November 2011 (UTC)[reply]

The following comments were from Village pump (idea lab). This was moved after interest was expressed for it going ahead.

I'd like some people to help me flush out User:Sven_Manguard/File_namespace_noticeboard before I formally propose that it's created. Sven Manguard Wha? 07:34, 11 November 2011 (UTC) [reply]

Wouldn't the function of this be covered by a number of existing noticeboards ( with respect to the licensing issues) at least?
I don't have a problem with collation of function in a single noticeboard though, the concern is duplication of effort.Sfan00 IMG (talk) 12:03, 11 November 2011 (UTC)[reply]
No. In theory these things would move over, gradually until the FNN becomes known. This would reduce effort for the file workers, because we'd have one primary center for all the threads that concern file issues, instead of having them spread out over AN, VP:P, VP:M, CENT, etc.. Sven Manguard Wha? 12:16, 11 November 2011 (UTC)[reply]

Above comments from Village pump (idea lab)

Thoughts? Sven Manguard Wha? 11:31, 12 November 2011 (UTC)[reply]

Question: do you have some example problems that were not handled either at all, or not well, by current venues? I have a certain scepticism about new boards, any examples would be helpful. Grandiose (me, talk, contribs) 09:56, 13 November 2011 (UTC)[reply]
A lot of the 'getting the word out' type messages (for backlog drives, etc.) are not effective because file workers aren't all watching the same pages. This would fix that. There were a few proposals that I, for one, tried to get out, which never really got seen, such as a proposal that, in hindsight, might have saved featured sounds. Sven Manguard Wha? 03:48, 14 November 2011 (UTC)[reply]

Using Wikipedia As A Universal Portable Health Record and Electronic Medical Record

Personal opinion: Wikipedia presents the most advanced platform for a universal medical record that could dramatically impact collaboration and knowledge generation on the human condition.

I have been a independent researcher and have spent the past five months intensely studying the problems of healthcare.

The problem for myself and many of my colleagues is that health information is abstracted so poorly into current electronic medical records, so that the human story and experience becomes reduced to a series of data points in the absence of context.

Stunning and transformative realization in my research this year that humans remain by far the best sensors. Sight, hearing, smell, taste, touch, emotion. These are truly the only instruments needed to arrive at 80% of the diagnosis for most conditions.

Imagine the impact of teaching individuals how to become "lead investigators" for their personal health experiences and relegating healthcare practitioners to lab partners, rather than "directors" of their attempt at easing human suffering.

We are incredibly powerful, and with collaborative technology and policies such as Wikipedia is developing for Encyclopedic knowledge storage, inverted to help the individual journal their own experiences in a standardized, comparable fashion, we may produce the greatest body of research on the human condition and our imperfect attempts to improve it.

I would happily devote the rest of my life to contributing to such a cause. — Preceding unsigned comment added by Laith Bustani (talk • contribs) 05:56, 15 November 2011 (UTC)[reply]

  • I don't think Wikipedia is the right place for the project you have in mind (if I understand the proposal correctly it wouldn't be encyclopaedic but entirely OR) but MediaWiki is definitely great software and WikiMedia may support a new project (I don't know). fg 07:21, 15 November 2011 (UTC)[reply]
  • Oppose For (obvious) legal reasons as well as the fact that it's not Wikipedia, but as fg said, what's stopping someone from using the MediaWiki software to do this independently? It doesn't have to be a part of Wikipedia proper to use the Wikipedia form. Writ Keeper ⚇♔ 14:39, 15 November 2011 (UTC)[reply]
  • Response Thanks Philosopher. I will consider posting at meta:Proposals. One key factor in the success/failure of such a scheme is the "community" behind the site. I've seen many WikiMedia projects come and go, tried a few myself. The most powerful feature about Wikipedia is that it is an organically evolving democracy of ideas powered by passionate volunteers, and this would be incredibly powerful as a concept in Medicine. As soon as you obscure the author of ideas and begin allowing corporate agendas to distort truth, the confusion propagates. There are no doubt several privacy concerns, issues, etc. But, it is my firm belief that patients and medical professionals can be trained (just as they are trained to contribute to WikiMedia) to understand what should and should not be posted. What is it about "society" that we so easily underestimate each other's potential to "do the right thing?". The most important factor in reversing the spiralling cost of health care is to stop delegating the responsibility for our health to other people and take personal charge of seeking out the best advice possible recognizing the powerful potential of the reduced friction/energy requirements for any two people to communicate. The framework of our current healthcare system is too rigid to adapt to advances, but the industrial complex, tempered by competition, finds more and more ways to siphon resources away from individuals interacting, which is the historical root and fundamental power of the healing arts. I had a patient who was very interested in trying this and consented (along with his family) to try. We put an abstracted progress note, devoid of any personal identifiers, accessible only through a random string that the patient could then look up my documented impression, edit/append/copy it in real time, and contribute additional ideas/insights to fulfilling their full health potential. There were problems with it, and I decided to remove the note, but the problems were easily solvable with enough smart people focused on a "moon shot" for humanity. I stopped looking at the computer/chart before speaking with the patient, because the patient was always able to tell me what they needed "right now". I go back to the chart/computer once I know how to use it to most effectively (and most efficiently) help the patient. Here is an example of such an interaction. My team (nurses, PT/PT/SW/CCAC/colleagues) are all first rate and they will alert me if I trust them to prioritized medical issues (as do I to them), but fundamentally, the single most important improvement in the quality of care I was providing was to surrender control of my time and agenda to the patient. This can only work when we all see it as our individual responsibility to help out. The rigid roles/responsibilities tend to bread the reflexive response "not my problem" or "can't help you", which is a symptom of time pressures exerted on us. If we were able to count on our colleagues easing our burden, then our energy would flow most naturally to where it provides the most benefit. We all need checks/balances/skills, but the only way to get these things is to learn them from people who have the time to teach. I would contend that patients who are in need of assistance and at the mercy of the healthcare system are in an excellent position to teach the system providers how to most effectively achieve their goals. This is a well established concept in medical education referred to as Patient Centered Care.

It is well established that N_of_1_trial are the most valid for of scientific evidence. What I have realized is that life is the ultimate laboratory and the goings on at the hospital are in fact the most ethical research institutions available. The thing is, patients need to be the lead investigators for their own health. The rest of the healthcare system must approach the patient as a "concierge" to leverage who/what is available at a given time/place to ease the patients suffering. This is the often quoted/envied philosophy of the Mayo Clinics in the US. No one comes to hospital unless they are suffering. No one seeks a "professional" unless they are suffering. What we have done, in delegating the responsibility we each hold towards each other to "abstract concepts" is pervert the simple truth that any two people interacting have the potential to exchange knowledge and stories and come away richer for the experience. Money has distracted us from this truth. The failing economy is a symptom of this forgotten lesson. Wikipedia and all of you contributing to it may just be my nominees for the Nobel Peace Prize. Thank you. You are all inspiring. You are all my teachers. User:Laith Bustani November 16th 2011 11:59 EST.

O-P-P-O-S-E. Wikipedia can not give any medical advice. PaoloNapolitano 18:19, 20 November 2011 (UTC)[reply]

A heretical idea: "closing articles"

I have always been primarily a reader of wikipedia, though I do help out when I see something I feel I can do.

Over the years, I have noticed that a number of articles have gotten really, really good and then have begun to decay. A committed group works on an article, brings it to a decent status, and then moves on. Meanwhile, less experienced or knowledgeable editors wander across the page and slow start filling it with unverified information or even start changing previously excellent sections. Then maybe someone else recognizes that the section has become full of inconsistencies and decides to just remove the entire paragraph. Thus, what was once an accurate well-written piece entirely disappears, not all at once but slowly through multiple edits. While this can technically be dealt with using present policy, it requires a large amount of dedication and there is nothing like fixing the same problems over and over again to incite fatigue.

What if there was a list of criteria by which certain articles could be considered "finished" or "closed?" What I am basically talking about is long-term protection, but for the sake of maintaining quality. I don't mean they could never be re-opened, but that there would have to be a consensus that it was time to re-open. This seems like more work, to go around judging articles and getting consensus, but I think for certain articles it would actually be less work than continually re-improving once good articles. Exactly what level of protection would have to be worked out, but I know I am basically at the point where I am very reluctant to do any improvements at all because I know that no matter how much I work on an article, that work could be gone in 6 months. Wikipedia is good at reverting obvious vandals, but less good about maintaining quality on less-watched articles where hard work is not washed away in a single prank but rather through a slow process of less than careful edits when no one is looking. Wickedjacob (talk) 13:06, 15 November 2011 (UTC)[reply]

Don't think much of that but it might be possible to make the 'article milestones' on talk pages more prominent and do more with them like list the last one on the article page. Dmcq (talk) 13:15, 15 November 2011 (UTC)[reply]
  • I'm very much in favour of a mechanism whereby articles could be closed to public editing once they reach a certain point in their evolution. I know it's a bit heretical, but you're not the first person to tell me that they're reluctant to contribute to Wikipedia for this reason. Selecting articles for this type of protection would be a far more useful activity than (or could be combined with) the selection of "good" or even "featured" articles.--Kotniski (talk) 14:34, 15 November 2011 (UTC)[reply]
Well, while you have a point, one of the main functions of WP is that articles are considered NEVER complete. While it's true that for some articles it's rare that anything substantially new to the world content could be added, even FAs almost always have little things here and there that can easily be tidied, sources that no one happened to use with good unique info, and so forth. Closing editing to our best articles would be just as bad as closing articles to the really bad ones. Not everyone knows how to easily make an edit request, and for little things are unlikely to bother. What needs to be done, I think, is a much more push toward "if you think you're helping please do it" so the reluctance will be gone. Yes it's possible some will degenerate, but I'm sure the net value of articles as a whole only goes up, and would ever more if less people were "reluctant". Plus, if those who brought the article up to quality "move on" from it....well then they didn't care about their work so much to see it maintained. ♫ Melodia Chaconne ♫ (talk) 14:46, 15 November 2011 (UTC)[reply]
I don't quite understand what message you want to send to "reluctant" editors to make them more willing. (The message we send at the moment is "Your contributions are valuable, but not so valuable that we're prepared to do anything to protect them, so if you want them to be of continued value, we'll need you to log on to Wikipedia twice a day for the rest of your life to fight with vandals and idiots." Something like that, anyway.) --Kotniski (talk) 15:01, 15 November 2011 (UTC)[reply]
(edit conflict)In response to the moving on point you make; I don't think it's so much that they don't care about their work, as much as there's just so much to look after. For anyone who has created hundreds of articles (I say this as a guess - I've only created two or three), looking after those articles could easily become their only on-wiki activity. For editors who help out by copyediting articles on request, or collaborating on a certain subject, there really isn't any way to maintain those articles all the time, without using all their time. Nolelover Talk·Contribs 15:08, 15 November 2011 (UTC)[reply]
(edit conflict)Yes this is arguably a good idea. It's probably a perennial proposal and isn't likely to gain main traction at this time. I recall back in 2005 seeing a chart showing the lifespan of an article: a rapid rise in quality at first, after which the article kind of just bumped up and down a little as people added stuff, took stuff out, futzed with wording, people adding unref'd or trivial or POV material and other people deleting it, etc.
There are, basically, two paradigms for moving forward. One is to continue steady as she goes. The other is consider changing the nature of the Wikipedia to take into account various changes in the nature of the Wikipedia, such as all the really important stuff having already been written about, declining numbers of contributors, and so forth.
The Foundation is committed to steady as she goes. Their thrust is entirely oriented toward maximizing the number of active editors and reversing any decline, using various outreach and editor-retention strategies. I'm skeptical whether this is possible or even necessarily desirable, although I could be dead wrong about that. But as long as this is the operative strategy, then locking down articles is not likely to fly. Herostratus (talk) 15:09, 15 November 2011 (UTC)[reply]
I don't see why not - I see it very much as an editor-retention strategy ("if your work goes towards making something really good, we'll protect it for you" - makes editing Wikipedia seem just that little bit more worthwhile). --Kotniski (talk) 15:53, 15 November 2011 (UTC)[reply]
You make a good point. I would consider supporting this, although it's probably quixotic at this time. Herostratus (talk) 17:41, 15 November 2011 (UTC)[reply]
Take a look at a 1911 encyclopedia article. Those were "locked" onto paper and were good at the time. But even if the facts haven't changed, styles and tone do. Quick sample: "After the death of Shelley, for whom she had a deep and even enthusiastic affection, marred at times by defects of temper; Mrs Shelley in the autumn of 1823 returned to London. At first the earnings of her pen were her only sustenance; but after a while Sir Timothy Shelley made her an allowance, which would have been withdrawn if she had persisted in a project of writing a full biography of her husband. In 1838 she edited Shelley's works, supplying the notes that throw such invaluable light on the subject. She succeeded, by strenuous exertions, in maintaining her son Percy at Harrow and Cambridge; and she shared in the improvement of his fortune when in 1840 his grandfather acknowledged his responsibilities and in 1844 he succeeded to the baronetcy." Rmhermen (talk) 16:05, 15 November 2011 (UTC)[reply]
WP just celebrated its tenth birthday. In that span, have grammatical styles really changed that much? Yes, in 100 years, a lot can happen, but this is a solution for a short term (in the sense that WP may very well not even be around in 2111) problem. Plus, Jaga's idea below would help to solve your objection. Nolelover Talk·Contribs 17:32, 15 November 2011 (UTC)[reply]
The FA process in March 2002: But if you come across a particularly impressive page, why not add it to the list as your way of saying "Thanks, good job"? Things have indeed changed... --Stephan Schulz (talk) 17:54, 15 November 2011 (UTC)[reply]
Right, "locked for 100 years" would be an OK compromise, I think... Herostratus (talk) 17:41, 15 November 2011 (UTC)[reply]

Instead of closing an article altogether, we could create a new level of page protection between semi and full. To edit, you would have to have a user right ("experienced user"? whatever) that is automatically conferred upon your 1000th edit but can also be granted or taken away. Then, when an article becomes featured, or just plain complete, it can be protected at this new level. It would slow decay, but not keep dedicated editors out. --JaGatalk 16:48, 15 November 2011 (UTC)[reply]

Yes, that's how I imagine this working. Something a bit similar to these flagged revisions we seemed to be trying out some time ago, but packaged in a more positive and less confusing way.--Kotniski (talk) 17:47, 15 November 2011 (UTC)[reply]
Or we could just have pending changes... (This user cowers in fear as the brickbats start being thrown.) —Tom Morris (talk) 14:19, 25 November 2011 (UTC)[reply]
  • Fully Support There is nothing more disheartening than watching a good article turn bad. All articles are open honey jars, attracting flies. There are some articles which are as complete as they'll ever be, so why not say "Well done everyone, this is complete". Heck, create a new project to nominate complete articles if needs be. Let's not pretend that Wiki is perfect - there's enough work to be done. BUT for those articles where no work can possibly build on what's gone before, why not bring up the drawbridge? doktorb wordsdeeds 17:08, 15 November 2011 (UTC)[reply]
  • No. If an article is good, and you want to keep it that way, no one is stopping you. But even featured articles can be improved, and we should never imply that even on our "best" articles that the work is done. It is never done, new information becomes availible, better pictures can be added, language can be made even better, etc. etc. No, this is a phenomenally bad idea. If you don't want to see decent articles degrade, stop it. But don't let "good enough" get in the way of "better". There is no good enough at Wikipedia. --Jayron32 18:34, 15 November 2011 (UTC)[reply]
    • Yeah, in theory. In practice, I'm not so sure. I think that nobody is saying completed articles can't be changed by anyone ever. The question is, should the same editing paradigm -- "anyone can edit it in any way" -- apply to stubs, mediocre articles that need work, and really good featured-article-quality articles? It does now. Should it? Why? It seems kind of like a one-size-fits-all approach that may no longer be optimal. Herostratus (talk) 18:43, 15 November 2011 (UTC)[reply]
This looks like a proposal that has come at the right time. All longtime contributors have had to deal with attempts that slowly downgrade the quality of a finished article. There is already a method available to stop most of these attempts: permanent semi-protection. This can be done by changing the policy of Wikipedia:Protection policy Each WikiProject can then designate which articles deserve this semi-protection and an admin can perform this task. This wouldn't exclude all vandalism or botched attempts at “improving” an article, but would certainly be a great help. JoJan (talk) 20:01, 15 November 2011 (UTC)[reply]
Support restricting (not closing). Is there be a way of spotting articles were the main contributing author is no longer active? (As these pages would be prime victims of non-patrolled vandalisms and good faith erroneous edits) --Squidonius (talk) 20:26, 15 November 2011 (UTC)[reply]
No. That's what the watchlist is for - you can throw an article on it and forget it, yet be alerted when it is changed so you can take a look at whether the changes were good and/or whether they can be improved. --Philosopher Let us reason together. 02:16, 16 November 2011 (UTC)[reply]
Personally, I don't know if this really works with massive amounts of articles on a watchlist (perhaps someone with, say, more then 1k can comment on how easy it is to follow every change), but even if I'm totally wrong, what's to say the watchlist is the "only" way we fix these articles. I mean, the "watchlist everything" method obviously isn't working now'... Nolelover Talk·Contribs 13:33, 16 November 2011 (UTC)[reply]
I have 3,982 pages on my watchlist, excluding talk pages, primarily split between deleted articles that I watch for re-creation, and active articles that I'm not really involved in but still want to keep an eye on. It works. --Philosopher Let us reason together. 08:42, 17 November 2011 (UTC)[reply]
And I had less then 300 at its max. Call me incompetent if you wish (no, I won't take offense :), but it was too much. Nolelover Talk·Contribs 13:10, 17 November 2011 (UTC)[reply]
I am the 5000th and something most active editor ever in en:WP (w/ ~9k edits), and I also can not keep up with 300 watchlisted pages. u:Philosopher, you are either lying (to us or to yourself) or you are super-human, and as such not a reasonable reference for the rest of us. - Nabla (talk) 20:15, 20 November 2011 (UTC)[reply]
Of course it depends on what one watches. I have 527 on mine, including all the village pumps and 35 have been changed in the past day. I can easily imagine watching 5000 pages that get almost no edits, especially if one considers archives and other pages that aren't supposed to be edited. Considering Philosopher said many of them are "to watch for re-creation" (i.e. they don't even exist) that right there is a large number of pages that won't get edited. ♫ Melodia Chaconne ♫ (talk) 20:54, 20 November 2011 (UTC)[reply]
However, if you have a bunch of redlinks on your watchlist that you're just watching for recreation, then that doesn't help this problem at all. The "watchlist method" only works if actual articles (not WP: pages, not userspace) are on people's watchlist and are actively being checked. I just cleaned my WL of a bunch of articles that, even when they would pop up, I didn't really check. All this to say that there are a lot of problems with believing that people watching articles alone will solve this problem. Nolelover Talk·Contribs 21:18, 20 November 2011 (UTC)[reply]
Comment. Regarding the Watchlist, I'd like to say my tuppence's worth, I find it quite flawed:
  • as mentioned by Nolelover if you have too many it become unwieldy,
  • when expert editors become non-active their pet in-depth esoteric pages loose their watchmen (I have gone on "wikipedia vacation" for a while due to work stress only to "come back" to derelicted pages)
  • successive edits are not visible in the watchlist, only the last (I have seen vandalisms becoming fixed due to reverts of the last edit not all edits)
The watchlist does help, but does not solve the problem in my opinion. --Squidonius (talk) 20:35, 16 November 2011 (UTC)[reply]
Support restricting . Going by other multi-volume encyclopedias (like the old print editions of E. Britannica) I should think about 100,000 articles cover most of the essential areas of science, philosophy, deceased historical biographies of high notability etc. Most of these articles, should be ready for semi-protection right now as they are likely to be closely watched. This would be a start -and from the experience gained in completing this effort, a firm policy can be hammered out. That leaves a huge number of many times that figure that beginners can still wreak. There are good psychological reason too. It will not only help to stem the loss of good editors with knowledgeable and in-depth expertise but should encourage new editors to work on expanding stubs and learn wiki-code and WP policies without having edits immediately reverted. It seems that new editors are drawn to the well written and nearly complete article for the very reason they are good and are commonly read. This leaves an inexperienced editor very little room to make meaning full contributions. If they start on stubs, it will lead them to explore for templates and all the other bells and whistles we have – using the good articles as example of what can be achieved. By now, I don't think there is a schoolchild that hasn't heard from numerous friends and other sources, that to become a new editor it is an up-hill struggle in battle against the entrench Mafia of experienced editors already here. What we say on these discussion pages and within WP about welcoming and helping new editors just doesn’t reach them any more. It bonkers to carry on as we are. This is a historical practice that may once had a point -rather than a useful one. --Aspro (talk) 15:32, 17 November 2011 (UTC)[reply]
It is proposed herein to restrict editing of "mature" articles to stop them "rotting". We all agree that article get a burst of improvements get to an excellent level, but go down hill afterwards. However, several question remain open, in my mind at least:
  • When is an article mature? E.g. Is it when it gets to FA status or according to other criteria?
  • Who can edit the "restricted" articles? Protection stops IP users. Or are talking about something more stringent, although defining who is an expert is quite problematic, are they self-appointed (i.e. mavens) or are they nominated?
  • Who gets to "restrict" articles (admins?) and what process do other editors undertake to request it?

.--Squidonius (talk) 22:57, 17 November 2011 (UTC)[reply]

Comment: Good question; Who can edit the "restricted" articles? . A sub page showing the 'new edition' can be edited 'freely' and viewed openly and all can vote for the original to be replaced. The history of the original article will show all competent editors -they can ask for privileged voting rights. --Aspro (talk) 23:13, 17 November 2011 (UTC)[reply]
This recent discussion about preemptively protecting pages against vandalism has some content related to this thread. I suggested then that an automated guard could be employed to close articles that (measured by edit frequency) were under possible attack. For this proposal, similar methods could be applied. I also suggested that safe versions could be cached and presented to the public during times of page closure (just in case the closed page was in a damaged state) and that the safe version could be established by admins (just a suggestion that could be expanded to include community review etc). An extension of that idea could be to have drafts: a primary, agreed and established draft with edits to it stored for review rather than immediately applied. Another wiki I worked on uses (or used (can't find an example page)) a draft system on some more official pages (that contain legal statements or policies etc) that presents an agreed correct page. While the page can be freely edited, only the reviewed and accepted changes are applied to the final draft. I agree that levels of protection could be employed across the board here in any number of ways and believe the benefits out-way the costs. I almost waffled. fg 23:41, 17 November 2011 (UTC)[reply]

Amendment to the proposal

No article is ever "finished" of "perfect". I can see the value of some form of protection against quality rot by casual editors, vandals etc, but there must always be some way of allowing access by those of us who can and wish to improve an article. Perhaps a good quality article can be stored as a closed page for general access, so that people looking for information see a good quality product, but an alternative version will be open for improvement, with an icon in the header giving the option to the new edition under consrtruction? This way, if the page gets better, it can be subsituted after a review and the process started again. If it rots, it can be periodically reverted, and all the time the reading public sees the protected version first. This procedure may even discourage vandalism and edit warring if it is applied to cases where these are a problem. Since all versions are saved anyway, this shouldnt increase overheads. Decision to apply the process could just be a couple of requests to an admin, as the development version is still universally editable.

This form of protection could be automatically applied to all featured articles, and possibly to all good articles. Further down the line it is an option for problem and contentious articles, which could be given this protection after reaching a consensus, to tide them over while the squabbling continues on the development page.

The tool bar would be missing the "edit" button on the protected page. Instead a button would lead to "development version", where the edit button would be in its normal place. Some form of tab or icon indicating the status of the protected page would be clearly shown at the top of the page. I dont know what this should be called. Something like "Stabilised version N: This page can not be directly edited. Make changes to the development version". where N is the version number of the stabilised article. This way an interested reader can compare stabilised versions easily by referring to the edit summaries where they would be recorded. Peter (Southwood) (talk): 07:07, 18 November 2011 (UTC)[reply]

You realize that what you have proposed is also called pending changes? Nolelover Talk·Contribs 13:54, 18 November 2011 (UTC)[reply]
I did not, thank you for the information. Peter (Southwood) (talk): 06:22, 22 November 2011 (UTC)[reply]

It seems that two questions are which articles get protected and who can edit these protected articles. For the which, an easy start could be "all Featured and Good articles, automatically, and no others" for now. (This could possibly be broadened later, not sure how though). Who is a harder question. Right now we have (not counting Developers) four classes of editors:

  • Anon IPs
  • Non-autoconfirmed editors. Editors are autoconfirmed after four days and ten edits.
  • Everyone else (except admins)
  • Admins

Anon IPs cannot do many things (such as create pages I think) and non-autoconfirmed editors have a few restrictions (can't upload files or move articles). But after autoconfirmation one has the same rights at the most veteran editor, so the "everyone else" category includes editors from four-days-and-ten-edits to ten-years-and-100,000-edits (and on up). This is quite a broad range. Too broad? Maybe.

Suppose this was refined with a new category, I'll call it "established" but the name doesn't matter. So then we have:

  • Anon IPs
  • Non-autoconfirmed editors. Editors are autoconfirmed after four days and ten edits.
  • Non-established editors. Editors are established after X months and Y edits.
  • Everyone else (except admins)
  • Admins

Only established editors can edit Featured and Good articles (they can also request permission on the talk page for a specific edit such is down now for fully protected articles, or just informally suggest a change.) I don't know what the values for X and Y should be, this is a detail. (1 month and 100 edits, 3 months and 300 edits, 6 months and 600 edits, whatever.) Obviously this would require a software change and also would not entirely solve the problem.

The problem is, this would be a huge change culturally. It would require a software change and that's a big deal to get pushed through. With the reluctant exception of restrictions on anon IPs and non-autoconfirmed editors, which is mostly to restrict drive-by vandalism, we've always treated all editors as equal (admins have no special standing as regards content.) This makes little sense to me and most organizations don't do that I don't think, but it is what it is.

Any proposal to be simple and automatic, so you have objections like: non-established editor who is Professor Emeritus of Asian History at Columbia can't edit the article, established editor who is nonetheless a complete idiot can. The refutation of that is while specific individual-case objections can be raised against most anything, from a system-dynamics standpoint it'd be an improvement, but a lot of people won't buy that.

So I'm not seeing a way forward on this, beyond just continuing to talk it up and hope for a sea change. Herostratus (talk) 15:52, 18 November 2011 (UTC)[reply]

Unfortunately, I have to agree. While there is definitely a problem, there's no way in Hades that any sort of Pending changes-esque solution will be accepted in the near future, and the prospects of another "class" of editors probably aren't much better. Big, sweeping "cultural changes" aren't generally the easiest things to pass on WP. Nolelover Talk·Contribs 16:38, 18 November 2011 (UTC)[reply]
non-established editor who is Professor Emeritus of Asian History at Columbia can't edit the article,
Some of the above suggestions 'will' allow new editors to edit. However, this time they will be improving the 'new' edition of the article (on a sub-page) which will replace the old one. To make sense of the above suggestions, what we need is a table showing how this proposal is structured. A commonly agreed glossary of terms I think is needed as well- as this is geting like the tower of babel. For instance: Stable page or current edition or current impression, Sub-page or pending changes or second edition proof or something etc.
As I see it we can:
  • Freeze the current page of a featured article.
  • The normal edit tab is replaced with a 'edit next edition' tab.
  • The 'next edition' tab takes any editor to a sub page where the original 'copy' of the article can be improved.
  • Any editor on the talk page can then ask at any time for a vote on whether the new edition can/ is ready/should replace the old version.
  • An admin says yea or neigh.
What is the problem wit that?!!
New editors may even get better advice and guidance from experienced editors this way, since they are no longer messing up the 'live' articles and frustrating those competent editors have taken much time and effort to get right.--Aspro (talk) 17:56, 18 November 2011 (UTC)[reply]
  • I think this is the Mediawiki extension that would provide the ability to have stable (protected) and editable (unprotected) versions of each article, for different levels of user. I gather from the page's hat that Wikimedia are almost certainly not going to be implementing anything like it here within our lifetimes. I'm afraid we may just have to stick with page watching and vigilante-ism! If the Tool apprenticeship goes through we'll be swamped with eager young gun slingers too. Yee-haw! fg 18:10, 18 November 2011 (UTC)[reply]
I've decided that I flat out oppose this idea (sry). I have to side with Jimbo on this. There are currently 6,878,249 articles and they were created by all and sundry. Viewed in detail the content is in perpetual flux but, viewed from a perspective most readers have, this is an incredibly stable and full encyclopaedia. The ethos has proven itself. The proof in this pudding has been tasted. We are looking after it now.
I'm a programmer. I like and believe in code. I would have a T-shirt of ClueBot if I were a T-shirt person. If an automated way could be found to more rapidly guard pages, I'm all in favour. Machines are totally unbiased and ruthless. No sweet talking will sway them and they cannot have bad days (unless badly written). People are fallible and make mistakes and act in bad faith or in good faith but poorly. However, en-mass humans do manage to display The Wisdom of Crowds. That's how this remarkable project started and how it should continue. We each do our little part and natural equilibrium will continue. The OP (original proposal) was to find a way to save rotting articles. If those articles are worth anything to anyone, they will be turned around in time and rise again to good or better status. The idea to find, save and protect the gold-that-was is so very tempting, I was almost suckered in. But no; we must trust in the incredible system that got Wikipedia this far. Free editing for all, all the time (unless common sense dictates otherwise). Knowledge is constantly shifting and one can only assume it always will. We (Wikipedia) must adapt. If adaptation results in article occasionally falling by the wayside (think genetics) then so be it. Nearly 4million! We should have a party!! fg 18:41, 18 November 2011 (UTC)[reply]
Your missing the point! All articles can still be edited. Its just that the frozen page is frozen. A tab is still there to edit the page which will replace it. It is just a temporal displacement. WP will still be an encyclopedia that anyone can edit.--Aspro (talk) 18:24, 18 November 2011 (UTC)[reply]
Fred Gandt rightfully points out that this whole discussion is against rotting articles — a problem acknowledged by all in this discussion.
There are legions of editors, some are waxing and some are waning. Under the assumption that all editors have the same knowledge, wikipedia pages will continually get better eventually with some occasional periods of "article rot" as the decreasingly-active experts are substituted by increasingly-active experts. The problem is many editors are the sole experts of a set esoteric topics: editors have "pet articles" and often they and they alone are the only users that knows about the topic well enough to edit it. Consequently some (but not all) articles that rot tend to go down hill until they are noticed again, but without the expertise are deleted, merged or severely reduced. I am however not sure of what proportion of articles go down hill and never come back. --Squidonius (talk) 21:44, 18 November 2011 (UTC)[reply]
PS. Trying to find examples, I keep thinking of several cases where a interesting piece of information disappeared due to vandalisms being removed but not reverted and due to the last edits of a series of deleterious edits being reverted. These two are issues with the watchlist. So I am not too sure about my own stated theory above... --Squidonius (talk) 21:49, 18 November 2011 (UTC)[reply]
Correct me if I'm wrong (really) but articles would only disappear (by deletion) if they had gotten too small to be considered worth keeping, right? Assuming this is correct: A possible software solution could be to watch pages for significant shrinkage. If an article reaches an alarming stubbyness it is immediately added to a category for adoption. Volunteers could then pick them up, find out why they have shrunk from perfectly reasonable to not even a stub, and take it from there. This way would at least prevent forgotten articles fading away through lack of active guardianship. fg 21:59, 18 November 2011 (UTC)[reply]
Evolution by open editing is a noble goal, but we risk losing our dinosaurs. Not in this case with a bang, but with a whimper. Peter (Southwood) (talk): 06:22, 22 November 2011 (UTC)[reply]

To be able to own Wikipedia.

I have a suggestion that might make some money for Wikipedia and serve its goals at the same time.

I would like to be able to BUY a copy of a certain year of the entire site. I cannot say if this would be a set of DVD's or a large stand alone hard drive, but I would LOVE to have my own copy of the whole site. There are times that one's internet is not working and to have your own copy of the closest thing to an Encyclopedia Galactica would be delightful.

A second reason I think this is a good idea is that it would allow a researcher to document changes over time. For example, the word "soandso" only has a placeholder in Wikipedia 2011, but by 2012 it is a huge document. The phrase "soandso" appears to have entered the popular lexicon between 2011 and 2012.

We can learn a great deal about the past by looking at a popular encyclopedia at that time. What were the prevailing attitudes on certain subjects and what subjects might have been taboo. It would be a shame for Wikipedia to be moving forward in time and to leave nothing historical in its wake. The evolution of Wiki's or Wikipedia itself is a subject worthy of study, but unless there exists a static snapshot of a moment in time, that historical context is lost.

In the final analysis there is the fact that when civilization collapses, I'd like to know a few backups are out there somewhere.

See Wikipedia:Database download. You can download the whole site to your hard drive, for free. However, if civilization collapses, I think that the internet would be among the bottom of social priorities. Cambalachero (talk) 02:25, 17 November 2011 (UTC)[reply]
Do you know about page history? You can see all versions of every page, ever. For example, So and so began as a rather odd redirect in 2005 [6], and gradually expanded [7] [8]. (Not a great example; it's far more interesting to look at the historic versions of more substantial articles). Also, you might find nost:HomePage interesting, which is a frozen snapshot of Wikipedia from 2001 - e.g. nost:Earth.
There's various plans in place to provide a 'snapshot' of Wikipedia in various formats. I just hope they remember to write Don't Panic in large, friendly letters.  Chzz  ►  09:09, 17 November 2011 (UTC)[reply]


Wikipedia has never been for sale - Wikipedia always has been, and probably always will be, a free internet site, which is able to be accessed by any one who has access to the world wide web. ACEOREVIVED (talk) 20:53, 23 November 2011 (UTC)[reply]

Information page here on EN Wikipedia informing about the consequences for Wikipedia if IBB gets approved

See Wikimedia supports American Censorship Day. Could we perhaps create a page here on EN Wikipedia containing information about this bill and what the consequences for Wikipedia would be (something like WP:Internet Blacklist Bill)? I am not very familiar with this, thus I am not confident I could create that page myself right now. Toshio Yamaguchi (talk) 17:57, 18 November 2011 (UTC)[reply]

Perhaps I will create an essay about it. Toshio Yamaguchi (talk) 15:38, 20 November 2011 (UTC)[reply]

4 million article party

Take this as it's meant, a little light spirit in what can sometime seem a very contentious room. Wikipedia is fast approaching 4 million articles (according to the template {{NUMBEROFARTICLES}}). That's a seriously large book! I seriously propose a less than serious mass thank you and congratulations to be thrown in the general direction of The Wikimedia Foundation and the generous genius Jimmy Wales. I imagine WMF have already thought of this insofar that a banner may be worn across the encyclopaedia for a week or so but, I'm thinking of our thanks and grats to them. We may not be able to give Jimbo 4 million bumps (an English tradition of throwing people in the air as many times as they are old in years) but we could send him 4 million Barnstars! (although that might rather screw up the servers so maybe not). You get the general idea though right? When the clock reaches 4 million there should be a general "Hoorah!". Consider mine brewing. Thanks. fg 19:05, 18 November 2011 (UTC)[reply]

You'll find me at the front of a sizable list of people that have absolutely no desire to do anything for or with Jimbo Wales. Celebrate? Yes. Celebrate with our "genius" leader? Heck no. Sven Manguard Wha? 19:33, 18 November 2011 (UTC)[reply]
Not too many. 1 would do. So we could just have the sitenotice for a quick celebration. Keep it for 1 day. ~~Ebe123~~ → report ← Contribs 21:26, 18 November 2011 (UTC)[reply]
How about a count-up to 4 million from say 3900000 then 24 hours past the goal? It's quite a hefty achievement after all. Wouldn't you think that 1 day would be a bit of a damp squib? It would be a great opportunity to grab some headlines and raise some funds (if not just for pure celebration and site-wide sense of accomplishment). fg 21:42, 18 November 2011 (UTC)[reply]
I'm part of that sizable list Sven just described. I'm grateful that Jimbo founded Wikipedia but I'm also grateful to Larry Sanger, to the numerous developers who made MediaWiki what it is today, to everyone at the Foundation and perhaps most of all to the millions of editors who created 4 million articles and helped to improve or maintain them. So yes, I'm grateful to Jimbo and to you Fred and to you Sven and to you Ebe and Jimbo is no more deserving of 4 million whatever than you are. I'm not part of a Jimbo cult and never want to be associated with one. Pichpich (talk) 00:07, 19 November 2011 (UTC)[reply]
Sven says leader and Pichpich says cult. Jeeze! No wonder threads on these discussion pages get so heated and confused. fg 12:49, 19 November 2011 (UTC)[reply]
Wikipedia has outgrown the need to praise our godlike founder, in my opinion. There are so many more people who have done so much more for Wikipedia than he ever did. Ajraddatz (Talk) 19:39, 19 November 2011 (UTC)[reply]

Tracking misuse of the cquote template

I made a proposal yesterday evening at Template talk:Cquote#Proposal to track improper usage. My proposal was the first edit in over 2 weeks, however, so I'm bringing it here instead. The basic reasoning is as follows:

  • {{cquote}} is reserved for pull quotes. This is stated at MOS:QUOTE and on the template's documentation.
  • But it's widely used for generic block quotations, which contradicts the MOS.
  • There was consensus at TfD to correct the usage of the template, or change the MOS, rather than deleting it.
  • I've made a cursory search of the WT:MOS archives, but found no recent evidence of consensus to scrap that rule.
  • The template supports attribution parameters, like author. Since it's supposed to be used for pull quotes, which shouldn't need attribution, the template itself encourages misuse.
  • However, removing the parameters now, while the template is widely misused, would break a lot of articles' attribution, which is even worse.
  • Therefore, I propose that this template categorize any uses of those parameters into a new tracking category: Category:Articles with attributed pull quotes.

Once we've emptied that tracking category, we may want to scrap the attribution parameters. We should probably also tie this into WP:MAINT at some point. --NYKevin @746, i.e. 16:54, 19 November 2011 (UTC)[reply]

I guess. In my opinion, {{cquote}} is pretty, and the general block quote templates are ugly, and something like cquote should be used for quotes generally. So I personally can't get too exercised about editors voting with their feet in this way. A better solution might be to change the MOS and the cquote documentation to encourage more general use of the template. Herostratus (talk) 20:32, 19 November 2011 (UTC)[reply]
It's been almost two months since the TfD in question and so far as I can tell, no one cares enough to build a consensus to change MOS. If you want to preserve this usage, I'd recommend starting an RFC over there soonish. Obviously I would put this proposal on hold if such discussion materialized. --NYKevin @961, i.e. 22:04, 19 November 2011 (UTC)[reply]

Multilingual search results for registered Wikipedians.

RfC tag added on 23:59, 23 November 2011 (UTC).

Proposal: Enable users who have registered Wikipedia accounts to receive search results from multiple Wikipedias automatically.

Synopsis: Single language search is the wisest decision for the majority of users, but multilingual search results are incredibly useful for multilingual users, allowing them easier and more reliable access to information.

Cons against multi-language searches: Currently, there is a fairly fast and effective way to search for items in a language other than the wiki a user is visiting. By typing in the country prefix at the beginning of a search, we can navigate to a page that is not on the originating project. This is a smart balance between usability and technical performance when considering the average usage of the Wikipedias. For most users, the side language options in an article and the ability to specify a country prefix are more than enough options for effective information gathering. On top of that, it would be horribly inefficient to force the server to crawl every language whenever an anonymous user searched for something. It would also be hard on the servers to attempt to detect a language for each search call. Searching every database for a single item would be a Herculean task to perform even once, and the time it would take to do such a comprehensive search would severely detract from a usability standpoint. Although I am currently unfamiliar with Lucene, I am under the impression that a single call is made to a language's index when a search is made. The functionality of the searching and the availability of individual wikipedia language stats suggest that the articles reside on separate indexes. If this is the case, to find articles in multiple languages would require multiple searches to be made for a single request. This would also be a very large no-no from a performance standpoint if there were a large amount of languages being searched by a significant amount of active users.

Pros for multi-language searches: For articles that exist in both the language of the original search term and in the originating wikipedia's language, the user will most likely be redirected to the originating language version of the article. This is certainly a simplified explanation, as one might end up on a disambiguation page for that word. For example, if one searches for 愛 in the English Wikipedia, that user will be served with Love. Searching for Amore(Italian for love), however will redirect you to a disambiguation page for Amore. That page provides a link to the English article for love. It should be noted, however, that neither search will allow you to immediately reach the existing articles for love in the languages in which they were searched. It would be necessary to reach the article in the language of the wiki first before clicking on the language sidebar. This is acceptable, but not as user-friendly as it could be.

The above only relates to searches that involve articles that represent the concept in the searching wiki's native language. If a user creates a basic search for an article that does not exist in the language of the wiki being searched from, then the results page will display nothing. If one searches for the Japanese celebrity 温水洋一 (Yōichi Nukumizu) in the English wikipedia, it displays nothing. If you search for the romanization of his name, there is still no link to the Japanese article, but there are suggested articles that contain his name. As there is no article in English at the moment which talks about this person, there are much more limited search results on the English Wikipedia. This makes sense if the person doing the search doesn't understand Japanese, which would be understandably assumed about most users on the English Wikipedia. This isn't a valid assumption for users that explicitly specify that they would like to be unified with both the Japanese and English Wikipedias.

There will be much fewer users who unify their accounts with multiple languages. Therefore, the load would be significantly less taxing on the server to search those unified languages for a single search term.

Possible Solution: A registered Wikipedia User can specify whether or not they wish to receive search results from multiple languages. This option would be disabled by default. If this is still not a large enough limit, we could require the user account to be unified with the languages they selected.

For performance issues, I would recommend that by default when a user opts in to this functionality, all searches would be performed as they currently work. Therefore, if multiple languages have articles for the same concept, the user would be served with the page on the Wikipedia that was originally queried. Only when no result was found on that Wikipedia would there be a search for the other languages that had been opted for. If the user wishes, however, they could specify that they wish to given a choice of articles in the languages for which they opted. This would require some new functionality. The new manner of search could be done in multiple ways. If an Article exists on the language of the Wikipedia being searched, it could check for a corresponding interlanguage link and display all relevant choices from that information. This would save resources as there would be no need to search for a second time. Another option would be to run a separate search on the wikipedias opted, so that if an article exists in language, but has yet to receive an interlanguage link, the information won't be lost. Either way, I'll leave that up to people who are in charge of the technical matters and who have much more experience than myself. I'd think that it would be best to combine the two. If an interlanguage link exists, give those choices, if it doesn't exist for one of the languages opted for, make sure to search that language explicitely. This would also be a good way to find and report articles which should related via interlanguage links!


Example process flow for the various ways a search could be handled depending on the type of user:

anonymous Wikipedia user or registered user who has not opted for multilingual support:

(no change from current method)

registered Wikipedia user who has opted in for both ja.wikipedia and en.wikipedia support without specifically wishing for a choice of articles in both languages:

searches from en.wikipedia.org for “愛” -> en.wikipedia.org runs search in the current manner -> redirects user to Love. (no change from current method)

searches from ja.wikipedia.org for “愛” -> ja.wikipedia.org runs search in the current manner -> redirects user to 愛. (no change from current method)

searches from en.wikipedia.org for “温水洋一” -> en.wikipedia.org runs search in the current manner -> no results found -> runs a search for “ja: 温水洋一” -> redirects user to 温水洋一

registered Wikipedia user who has opted in for both ja.wikipedia and en.wikipedia support and specifically wishes for a choice of articles in both languages:

searches from en.wikipedia.org for “愛” -> en.wikipedia.org runs search in a new manner -> gives choice of both 愛 and love

searches from ja.wikipedia.org for “愛” -> ja.wikipedia.org runs search in a new manner -> gives choice of both 愛 and love

searches from en.wikipedia.org for “温水洋一” -> en.wikipedia.org runs search in the new manner -> no results found. runs a search for “ja: 温水洋一” -> redirects user to 温水洋一

Thanks for reading! I hope you think this is a worthwhile idea and look forward to your ideas. Also, I apologize for the informal nature of this proposal. It's my first wikipedia page and I'm just a dumb art student. Subcogitate

  • Oppose: We've considered it before, but most people don't know all the 20+ languages Wikipedia uses. One word in one language can mean something else in another, so users could get misinformed. I don't think it's worth the increased server latency. By the way, this is not a unique page - see Wikipedia:Your first article.Jasper Deng (talk) 23:42, 19 November 2011 (UTC)[reply]
  • ---Thanks for the feedback! If you notice, however... My proposal doesn't say anything about searching all the languages. Just ones that the users select. You might want to reread the entire article and gain a better understanding of what I am suggesting. Also, you are right about this not being a unique page, so thanks! :) Subcogitate
  • Nice idea. Well considered and presented. I'll think about it a bit before deciding one way or another though. First impression is that it could be a boon for those who speak multiple language to more quickly find matches across all Wikipedias. fg 01:43, 20 November 2011 (UTC)[reply]
  • -- It's nice to see people hoping for the same thing. The title of that bug is "search all languages" which is a bit different from what I'm suggesting... If that's not what the bugfix is supposed to do, then maybe it needs to be re-written to be more specific :) Thanks for the tip! I'll look into bugzilla from this point forward! Subcogitate


Personally, I think this could be quite a good idea. ACEOREVIVED (talk) 20:55, 23 November 2011 (UTC)[reply]

You might want to use http://www.qwika.com/, but I am not sure how relevant or how useful it is.
—Wavelength (talk) 21:29, 23 November 2011 (UTC)[reply]
  • Support Can't think of any down sides. I don't speak or read any other languages but English (except programming and scripting languages but that's different) so would not get the benefit but, I can see how useful it would be to a user who is multilingual. I can well imagine it being a boon for Wikipedia too since it would encourage cross language Wikiknomery etc. I also imagine it would be quite simple to implement. A quick extension to some php and a couple of tweaks to related UI and Bob's your uncle (as we say in blighty). fredgandt 23:53, 23 November 2011 (UTC)[reply]
  • I'd love to be able to search the French and German Wikipedias at the same time as I search the English one. We'd need to think about how the results were displayed, because with many things -- biographies, geographical locations, the sort of thing you'd actually want to use a foreign-language Wikipedia for -- the articles will have the same titles. I suggest using the standard Wikipedian prefixes, if this is technically possible, so if I used the search term "Goethe" the results would be listed as en:Goethe, de:Goethe and fr:Goethe.—S Marshall T/C 12:18, 24 November 2011 (UTC)[reply]
  • Support. As I'm regularly using the English, the French, the German and the Slovene Wikipedia, I find it a great idea to have the results for all of them listed in one place. This makes finding the relevant information easier, simplifies the comparison between the different versions and cross-checking and also allows for easier building of articles using information and references from different language versions. I'm really looking forward to have this enabled. --Eleassar my talk 12:50, 24 November 2011 (UTC)[reply]
  • I'm doing some translation right now, and this would certainly be helpful, especially as a little option on the search page. What would be cool would be having the interwiki result(s) pop up next to each search result so people can also see which languages have an equivalent article to what they're looking for. /ƒETCHCOMMS/ 19:01, 24 November 2011 (UTC)[reply]
  • Comment Don't forget Google "goethe site:wikipedia.org" - not great but better than nothing. Rich Farmbrough, 17:38, 25 November 2011 (UTC).
  • Support Sounds like a good idea. Dusty777 (talk) 23:56, 25 November 2011 (UTC)[reply]

Online Status

Please note that this extension doesn't introduce new feature, it is supposed to replace {{Statustop}} and the similar templates in order to do the same thing more effectively, without having to create thousands of new revisions to the database, what update of the template does - it is also an opt-in feature that mean it is disabled for all people who don't want to use it by default. This is not a discussion whether users should display their online status on their user pages, but about that how is it being done.
Hi, I would like to ask you what do you think about installation of http://www.mediawiki.org/wiki/Extension:OnlineStatusBar to enwp, as replacement for existing {{Statustop}}, which creates a lot of pointless revisions, I already asked on VPT but only about 4 people answered there, the extension is almost finished, it's example is available on huggle-testwp, the purpose of this extension is to allow people show their online status, instead of having to update their user pages everytime when they logout etc. current proposal is to have this extension disabled for all registered and unregistered people unless they choose otherwise. What is your opinion about installation of this extension to english wp? Thanks Petrb (talk) 10:06, 29 October 2011 (UTC)[reply]

Example of status: http://hub.tm-irc.org/test/wiki/User_talk:Petrb Petrb (talk) 10:14, 29 October 2011 (UTC)[reply]

How does it work: it writes all data to special table which is stored in operating memory, and periodicaly cleaned, everytime when user who does want to be tracked open any page on wikipedia it update the timestamp there, when user logout or their timestamp is too old, their record is removed from table., if you open their user page, and if they have feature enabled, it looks up the timestamp from that table, if user is there it consider them as online and render the status in their userpage, unless they wish to display it otherwise.

  • I agree that the present practice of updating User:Me/status repeatedly is ludicrous. Any automatic method would be better. I also agree that it should be opt-in not opt-out. Whether it is actually needed or not is debatable. Personally I like the idea and support it. I think it should be kept simple and free of friends lists etc. (if anyone felt the need to track fellow Wikipedians I'm sure a JavaScript could be created to read the status' and produce a sidebar display of your listed friends. I don't think it's Wikimedias job to support that functionality). Not only is that likely to create cliques but it would require a fair whack of extra server and page scripting. Nice and simple indicator seen only on each account users talk and main page. Nothing fancy. -- fgTC 11:08, 29 October 2011 (UTC)[reply]
You can see how does it look, it doesn't do more than showing the user status as current template does, only difference is that it doesn't make revisions to wikipedia as current template does. Petrb (talk) 11:37, 29 October 2011 (UTC)[reply]
Please note I am not implementing new feature, I am replacing the existing feature which consinst of thousands of pointless revisions. This feature of "I am online" is already there over existing template, I agree with you that it's wrong and that's why I created this extension, so I don't understand why you rather would like to have it as it is now. Petrb (talk) 11:36, 29 October 2011 (UTC)[reply]
I mean, the question wasn't "do you want to have this feature on enwp?", but "do you want this feature to be implemented over that template which does a lot of revisions seen in recent changes etc. or do you want this to be implemented over extension which doesn't touch wikipedia content tables and doesn't mess at recent changes"? :), just to clarify that.... Petrb (talk) 11:56, 29 October 2011 (UTC)[reply]
I do not want it implemented. Period. Also, there is no current feature. Editors can write whatever they want, within policy, and some write that. That is not a feature (templates are not features, as I see it). Once in a while warning that you are off-line may make sense - I've done it once - but continuous warning is not needed for any purpose - and come to think of it, my warning was not needed either, WP carries on, with or without me :-). If you think such edits are wrong then do not make them easier. Instead why not suggest that they are not allowed? Change policy, delete the template... I might even support the idea, though I don't mind these edits. - Nabla (talk) 12:07, 29 October 2011 (UTC)[reply]
I took a quick - and small, I know - sample of uses of the aforementioned template. Out of 6 users having it 5 got it wrong: either they are on-line but not editing for many months, or they are off-line since months ago but edited hundreds of pages today. The one 'correct' status wasw... "Unknown" :-) Useless. (actually, slightly counter-productive, as is misleading) - Nabla (talk) 12:23, 29 October 2011 (UTC)[reply]
That looks to me just as another reason to have it done using extension, nothing else... Petrb (talk) 12:29, 29 October 2011 (UTC)[reply]
No, that is an indication that this is not used. - Nabla (talk) 13:19, 29 October 2011 (UTC)[reply]
Thousands of people use this, which indicates something else, imho Petrb (talk) 13:24, 29 October 2011 (UTC)[reply]
Transclusion count: 1074, one thousand, not thousands. Used once, not use. Quite different. You do have some point for your suggestion (I don't agree, but you do) inflating fugures does not help you at all - Nabla (talk) 23:35, 29 October 2011 (UTC)[reply]
I am not inflating any figures, you counted transclusions of only one template used for this, and I counted revisions made by changes to all userpages transcluding all of those, which are thousands, even the transclusion count is much higher than 1074, I have direct access to sql as anyone else, so it's not a problem to count it... Petrb (talk) 12:25, 30 October 2011 (UTC)[reply]
  • I don't really oppose the whole thing of online status, but I don't find it useful either (though others might). I guess I don't really care if it becomes an opt-in automatic feature. I'd like to see some benefits listed though and someone who has genuinely found this useful beyond "Ah, I'll message them later since they are offline anyway". Does this really improve the encyclopedia? —  HELLKNOWZ  ▎TALK 12:16, 29 October 2011 (UTC)[reply]
Thanks for reply, and once more: this proposal is not about allowing or disallowing people doing it, it's only about the way how it's being done (there used to be even ticket it mediawiki bugzilla regarding those pointless revisions), but if you want to know opinion on that, I myself do not like the current way because it spam recent changes and disallowing people from doing anything is always stupid, so my opinion is, let them do that in proper way. And concerning if it's of any use: yes it is, certain people would like to let others know whether they are available atm or not, in the end it can improve the communication between people, let's say 10 people are from one project (like AFC), you need urgent response from someone who's is participant of that project, but you don't know who is available at the moment to help you, this feature could help you find them (one example) Petrb (talk) 12:28, 29 October 2011 (UTC)[reply]
I never said anything about disallowing this; I said I don't care if it becomes an automated feature (implying online statuses are already being used). I also didn't say it's not useful to anyone, I said it might be useful to some. —  HELLKNOWZ  ▎TALK 13:30, 29 October 2011 (UTC)[reply]
Ok, reply to your question is: it doesn't improve the content, but it could improve the communication between contributors. Or at least it would make easier for other contributors ignore changes to userpages of other people who use that template. Petrb (talk) 13:34, 29 October 2011 (UTC)[reply]
    • (ec x2) For normal users it is not so useful, but it would be helpful if you are trying to contact administrators/oversighters/checkusers and for whatever reason don't want to email RFO. Yoenit (talk) 12:29, 29 October 2011 (UTC)[reply]
bugzilla link to show that in past this used to be an issue: https://bugzilla.wikimedia.org/show_bug.cgi?id=13520 Petrb (talk) 12:39, 29 October 2011 (UTC)[reply]
Petrb, so te extension exists for 3.5 years! Why have it not been used so far?
Because it wasn't finished Petrb (talk) 13:25, 29 October 2011 (UTC)[reply]
mediawiki.org - Extension:OnlineStatus says: «Last Version 2009-08-22». Maybe the page is outdated? - Nabla (talk) 23:38, 29 October 2011 (UTC)[reply]
Yoenit, to contact an admin ask at the noticeboard. to contact a specific admin, as at the talk page, if you don't get a reply soon, s/he's off-line (or ignoring you) - Nabla (talk) 13:19, 29 October 2011 (UTC)[reply]
I am well aware of that, but some things are best discussed with a specific oversighter/checkuser who was previously involved. If I know they are online I can mail them directly for a fast response rather than having to use wp:RFO. Yoenit (talk) 14:14, 29 October 2011 (UTC)[reply]
  • Support. I think this upgrade of the status template is a good idea. Being automatic it would avoid all the pointless edits (on the current version). And editors who don't like the idea don't have to opt in which seems fair enough to me (they might even come up with a script to block themselves from seeing such templates). Maybe ask some more people who actually do use <code>{{Statustop}}</code>? - Benzband (talk) 12:46, 29 October 2011 (UTC)[reply]
Actually it's possible to implement option to hide status of other users in the extension if there were more people who'd like it. Petrb (talk) 12:49, 29 October 2011 (UTC)[reply]
  • Oppose Unless it's strictly opt-in. If people specifically want it, it's fine. If they don't, it could cause all manner of headaches of people seeing "oh X is online...ok why aren't they responding on their talk page!? Better spam them more!". ♫ Melodia Chaconne ♫ (talk) 13:52, 29 October 2011 (UTC)[reply]
Yes proposal is to have it strictly opt-in as I said. It is also default configuration of extension. Petrb (talk) 13:54, 29 October 2011 (UTC)[reply]
How who know what? Petrb (talk) 16:35, 29 October 2011 (UTC)[reply]
Source code of extension is at http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/OnlineStatusBar/ if you had question related to that Petrb (talk) 16:37, 29 October 2011 (UTC)[reply]
Could you briefly explain it to the general public, please? "Read the source, Luke" comes across as one of those replies from snotty IT staff. ASCIIn2Bme (talk) 22:15, 29 October 2011 (UTC)[reply]
Sorry, I didn't see this: I moved explanation to the head of this thread Petrb (talk) 11:18, 30 October 2011 (UTC)[reply]
Again, it's not about the "I am online" thing, that is already being used, it's about how is it done, this extension was developed to save the database (currently every update of template make a new revision) this affect the db dumps and also other users, because it's being recorded in recent changes. that's the point Petrb (talk) 19:53, 29 October 2011 (UTC)[reply]
For some reason people still think this is a discussion about that if users should display their online status on their pages, which it isn't, I updated the description of proposal and I hope it's more clear now. It only improve the way how it's being done now. Petrb (talk) 20:01, 29 October 2011 (UTC)[reply]
Actually, it is about the status thing. By making status displays more accessible, do you not admit that it will almost certainly result in more people choosing to display their status? And thus you must first consider whether that benefits Wikipedia or whether it is detrimental. What I consider good with this current system is that its annoying need for manual updating discourages its widespread adoption. So I will continue to oppose this proposal unless you claim that it will not have the effect of more users displaying their status, which would move Wikipedia in a direction with which I disagree. /ƒETCHCOMMS/ 00:56, 30 October 2011 (UTC)[reply]
I think it would certainly lead to more users displaying their on-line status. I can't imagine a good argument to counter that glaring fact. I'm personally still in favour of using an automated system rather than the one(s) we have now but, wonder if you may very well be right ƒETCHCOMMS. Maybe this sort of improvement would lead toward us being more sociable. I really didn't mean that to be quite as sarcastic as it reads. Most social networking sites bore and worry me so I am not in favour of Wikipedia becoming like those at all. I think the benefit past the obvious reduction in edit histories to pages with nothing but one word on them would be simply allowing users to interact in a more human way. Some frustrations could be calmed on disputed pages since "Why is this person not responding??" (but in capitals) would be answered in a flash. Maybe I'm just a soppy hippy but I think it's nice to get along and easier to get along with people if they are a little more interactive than a page full of text. fgtc 01:38, 30 October 2011 (UTC)[reply]
Indeed it's possible that it would lead more people to use it just like it is possible that it wouldn't, no one did such a research so far, I don't want to argue about that, but another fact is that it would probably be rather benefit, more users who display their online status would not harm encyclopedia even a bit, while pointless revisions do harm it seriously, we all know that every year people donate just enough to buy more storage in order to keep all the mess which is in database, but to me it looks like waste of money, while I see no problem in online status of people who want inform others about it, it isn't anyting more social, than having username instead of number. Petrb (talk) 12:19, 30 October 2011 (UTC)[reply]
And this is where I disagree. Thousands of pointless revisions don't hurt Wikipedia (actually, does anyone have numbers for how many extra revisions the status changer causes right now versus how many almost pointless minor edits are done by bots each day?), but creating a more social-networking-like environment is not conducive to Wikipedia's mission. I don't want people hitting up other users for a nice talkpage chat just because they're bored and see the "online" message. That would be pointless revisions. People donate millions every year, and the WMF has more than enough to buy extra servers and whatnot. If you think the WMF is wasting money, there are many other frivolous things to complain about (e.g., Wikilove) than a few extra edits each day. And yes, statuses are more social than usernames—"social" is not the same as "personal"; usernames are personal indicators, not social ones. A username does not invite people to chat with you. /ƒETCHCOMMS/ 17:52, 30 October 2011 (UTC)[reply]
I am a wikimedia developer, rather than searching things I can complain about, I try to improve them so that they don't suck that much so that no one needs to complain about them, as this one, indeed I disagree with wikilove as default, also you might be right that all the pointless revisions done by this template are not enough to be really harmful, but all pointless revisions done by templates like this (there is more that just online status, even talk pages are some sort of mess since there are liquid threads available for mediawiki) that all together makes mess in db which could be handled much better than donating more money so that we can purchase servers fast enough to handle all that crap, that's where I'd like to help. There are also many other better ways how we can invest all the millions donated by people than keeping alive system which is obsolete and doesn't work properly. It's also possible to update it so that it isn't so expensive, it's fascinating that it's easier to ask people for more money, than ask community to approve utility which could eventually make less resource-expensive something what is here and will be here, no matter of what result of this proposal would be (if people want to show their status on user pages, they will do show that and there is hardly a way to prevent them from doing that). Now I understand why many tools are enforced by wmf without asking community whether they want them (including moodbar and wikilove, as I just found in their documentation). I always respected the community and that's why I asked for your opinion here, of course when you disagree with that, I understand that and I wouldn't enforce anyone to have it here unless others would approve it, I just wanted to improve one of few things which could be improved, but it seems to me that many of people responding here, didn't even understand what is this proposal about. Petrb (talk) 20:34, 30 October 2011 (UTC)[reply]
You know, if we just banned the entire status update system, we'd probably end up saving the database a lot more trouble. And given that the WMF has the power to enact any sort of rules it wants, then why not solve the issue that way? Otherwise, we're targeting side effects rather than the underlying issue. But regardless, I think most people understand what your proposal is for, but like me, they don't like its consequences—which are increasing the social-networking side of Wikipedia. There must be a way to solve both the "extra edits" problem while balancing it with the "not Facebook" argument. /ƒETCHCOMMS/ 21:20, 31 October 2011 (UTC)[reply]
IMHO blocking people from being able to do something they like is not friendly, eventually could cause some leave wikipedia (or edit less often at least), which doesn't really help the project, goal of wmf is to make editing of wikipedia more entertaining and to bring more people to the project, not to discourage them, by adding extra rules. So far there aren't really rules on wikipedia, (for instance I follow only one rule: Ignore all rules) any unnecessary rule is counter productive to encyclopedia. It doesn't even make it look liberal, which it maybe isn't, but many people at least like to think that it is. Petrb (talk) 22:06, 31 October 2011 (UTC)[reply]
Making Wikipedia more Facebook like is similarly detrimental. That, too, has caused many users to leave. I find it unfortunate that the WMF's goal is to make editing more entertaining, because entertainment is in the eye of the editor. We should not be making Wikipedia more social-network-like or more of a game. I'm not sure what you're trying to achieve by going back-and-forth with me; I've stated my reasons plenty of times and if you disagree, then disengage as well. Regards, /ƒETCHCOMMS/ 14:34, 1 November 2011 (UTC)[reply]
Hardly, it's not possible to do this using java script. Petrb (talk) 19:53, 29 October 2011 (UTC)[reply]
Actually, some users do use the script. It isn't without it's drawbacks though. Currently, the script only tells an editor whether or not someone has edited in a given amount of time. Alpha_Quadrant (talk) 02:10, 31 October 2011 (UTC)[reply]
  • I'm not a fan of this. We're not a social networking site and we don't need social networking features. This will "legitimize" a practice that's outside our scope, and it will encourage people who aren't currently doing it to do it. You're mischaracterizing it by saying "People are already doi1ng it". If you make it official then more people will do it. And that'll just create more pressure to move the site in a bad (user-centric) direction. I don't want articles being "liked" even if people want to "like" articles on their own userpage. —Designate (talk) 20:19, 29 October 2011 (UTC)[reply]
Thanks for your reply, I am unsure what you mean by "like" this is not implementation of "like" button, also this is definitely not anything illegal atm so if someone would like to have that on userpage, they would add it no matter of implementation (which is the reason for this), I don't even see what does it have common with social networks, it's like if you said that whole "register an account" feature was making it social network. It's about removing pointless revisions from content database. That's all. While I agree with you that online status may look silly to some users on wikipedia (especially using template which is updated everytime when you log in - out, and I personally never used it), not allowing its improvement wouldn't stop people from doing that. And this extension would rather help to people like you who don't like that feature, because it would allow you to ignore it even better. Petrb (talk) 20:29, 29 October 2011 (UTC)[reply]
It's interesting that "wikilove" which definitely have character of social network has been smoothly approved, while this feature with merely technical context, which main purpose is to separate content from nonsense (those status-updating revisions are non-sense compared to other stuff in db including articles, which unfortunatelly are stored together), is really having troubles. Petrb (talk) 20:45, 29 October 2011 (UTC)[reply]
It's a slippery slope. Petrb points out that we have Wikilove, which is a social networking feature (the only reason it "was smoothly approved" is because I had no idea it was happening, and I would've been completely against it for the same reason). Once we have two official features, it'll be easier to promote a third, more objectionable feature, by pointing out that we already have several social networking features. Once we have three, it'll be easier to add a fourth. I don't care about people saying they're online. That's irrelevant to me. What I care about is the perception of the site changing. Officially adding social-networking features (this is one) will encourage people to formulate other, more obnoxious features (ones that can't be done manually). I don't want to encourage that kind of culture here. That's why I'm against this. —Designate (talk) 22:25, 29 October 2011 (UTC)[reply]
Yes it will be automatic and it would not touch content db. Petrb (talk) 08:04, 30 October 2011 (UTC)[reply]
Will I be able to change the status myself?Jasper Deng (talk) 22:01, 31 October 2011 (UTC)[reply]
Yes. But you can't create own status unless you create own template for that. Petrb (talk) 09:16, 1 November 2011 (UTC)[reply]
  • Support but I'd like to see the information exposed in a parser function or some such thing so that we can use arbitrary status templates with it. I'd also like to see documentation of precisely how it behaves (and don't tell me to read the source, that's insufficient). --NYKevin @027, i.e. 23:39, 29 October 2011 (UTC)[reply]
There is documentation on mediawiki, explaining how does it work, if it got installed on wp I will update meta aswell, atm updating it with stuff which isn't available is not of any use Petrb (talk) 08:04, 30 October 2011 (UTC)[reply]
  • Oppose, but with great respect to the coder of this extension. You mean well, but Wikipedia is not a social media site and we should not be codifying a bad idea just because the current implementation is poor. The better response is to deprecate {{Statustop}} and its clones. Resolute 01:37, 30 October 2011 (UTC)[reply]
  • Support I am probably one of the most vehemently anti-social networking people you've ever met, and I'm damn proud of that fact, but this is a feature that has legitimate uses on Wikipedia. During my GAN I was sending messages to people who I thought were receiving them, only to find out that they had gone offline just five minutes earlier. I was stuck in a holding pattern, not working on the article in question, because I thought a response to my question was just around the corner. Yes, this can be abused by social networking addicts, but so can other things we already have. Unlike the share button proposal, this proposal has merit for improving the encyclopedia. Plus, he already said it would be opt-in only. Sven Manguard Wha? 05:14, 30 October 2011 (UTC)[reply]
    • I don't how this feature would have helped you with that ("just five minutes earlier"). See how it works below; it keeps track of when someone last read a page. There's not way to tell from that if they went to the bathroom or if they went to bed. ASCIIn2Bme (talk) 16:38, 31 October 2011 (UTC)[reply]
That is not correct, even a bit. Petrb (talk) 19:17, 31 October 2011 (UTC)[reply]
I hope that explanation on top is what you meant by "what happens". It's not that it's secret, I just didn't notice the question. Petrb (talk) 11:24, 30 October 2011 (UTC)[reply]
Concerning benefit, there were many answers in thread, some of them were like: it improves the communication between people, it help prevent creation of pointless revisions to encyclopedia, it wouldn't spam recent changes and others... Petrb (talk) 11:25, 30 October 2011 (UTC)[reply]
It doesn't track people any more unless they use this feature, therefore your reason lost its point. Thanks for the opinion. Petrb (talk) 19:20, 31 October 2011 (UTC)[reply]
Please note that wikimedia servers already track ip addresses and other data when browsing pages for statistics, also this extension doesn't track your ip, just last time when you opened last page and only for the time you are online, so your reason was loosing its point from begining, but it's possible you just didn't know that or you oppose for some other reason, which I respect anyway, or you just don't like it, for no reason, I don't really care... Petrb (talk) 19:27, 31 October 2011 (UTC)[reply]
  • Also, I see no attempt to take into account editors' clicks on the "log out" button. So, to continue an example given by Sven Manguard above, this extension doesn't make any distinction between someone going to the bathroom for 5 minutes and someone who clicks "log out" and goes to bed. ASCIIn2Bme (talk) 16:53, 31 October 2011 (UTC)[reply]
    • It of course set you offline in that case, so this isn't true. I updated the description, I apologize if that confused you Petrb (talk) 19:13, 31 October 2011 (UTC)[reply]
      • Okay, others may find it useful now and the privacy issue seems addressed in the promise that "I can customize it so that data are collected only for people who use this". I see no reason to oppose it anymore, but I have no real reason to support it myself. ASCIIn2Bme (talk) 13:16, 1 November 2011 (UTC)[reply]
  • Support - improves existing functionality by making it more reliable and reducing meaningless diffs. (I'd make this a specifically opt-in support, but I see above that's already the case.)--SarekOfVulcan (talk) 17:14, 31 October 2011 (UTC)[reply]
  • Support. This is just an enhancement to an existing feature, so I can't see a good reason to oppose it. Thryduulf (talk) 17:35, 31 October 2011 (UTC)[reply]
  • Support, provided it's opt-in and that it doesn't reveal any additional private information. I don't think I would use it myself (as I used to use the scripted one in the past but became too lazy to update that one), but I also don't see the harm in including it if it helps the encyclopedia along. –MuZemike 21:32, 31 October 2011 (UTC)[reply]
  • Support Common sense change. Noformation Talk 08:39, 1 November 2011 (UTC)[reply]
  • Support A better version of an already-existing feature. --Philosopher Let us reason together. 02:34, 3 November 2011 (UTC)[reply]
  • Support As with Sven_Manguard, I'm not a big fan of social networking features. But people are already doing this, so we may as well do it in a sensible, sane way. And the problem isn't "social networking" per se: it's that sometimes you need to contact specific people in order to get things done on-wiki. If you are dealing with vandalism or serious user behaviour issues, sometimes you do need to contact specific admins by e-mail or talk page, and it's quite useful to be able to see if they are online. I already have a user script installed that shows me how long since their last edit (userinfo.js). This is utterly common sense: user page policy limits what is acceptable on user pages to that which helps build the encyclopedia. Like it or loathe it, real-time updating is the norm, and real-time collaboration is vital to the functioning of Wikipedia. Yes, yes, people can use IRC. But not everyone wants to. This is an utterly sensible thing to have, and opposition to it seems to stem from that utterly bizarre Wikipedian attitude of "well, it's okay if we have X, but so long as it isn't easy to do X" (e.g. barnstars good, Wikilove bad; templates good, visual editor bad; status updating on user pages okay, implementing it in a sensible way bad). —Tom Morris (talk) 12:39, 4 November 2011 (UTC)[reply]
  • Support. Like many of the above editors, I loathe adding social networking features to Wikipedia, but this does make sense. People have and will continue to do the online/offline thing (And I'm not sure if I will opt in if this proposal succeeds). Better to have a system which is automatic rather than one which 99% of the users fail to update regularly. VictorianMutant(Talk) 23:20, 5 November 2011 (UTC)[reply]
  • Support as opt-in. I've no intention of using it, but Wikipedia is a collaborative environment and this seems something that might facilitate collaboration for some editors. older ≠ wiser 23:39, 5 November 2011 (UTC)[reply]
  • Support as opt in. I don't see much down side to replacing the current template with this. I also don't see how this makes Wikipedia a social networking site. Even gmail has status indicators. Kaldari (talk) 05:58, 6 November 2011 (UTC)[reply]
  • Support - Wikipedians already do this anyway; an extension would just make easier what already happens. It would have to be opt-in so that those who do not want it are not troubled by it. Those who do not like the idea don't need to use it if they don't want to - that's fine by me. Unless one proposes that any form of online status should be banned form userpages, I see no real rationale for rejecting this. ItsZippy (talk • contributions) 21:45, 7 November 2011 (UTC)[reply]
  • Support This is a "social networking" instrument only in that it gives new editors access to the same information that we aged users do. It might save a few new editors blowing a gasket when I don't respond immediately because I'm sleeping, an unpleasant experience for both of us. Danger High voltage! 01:38, 8 November 2011 (UTC)[reply]
  • Support I use the Qui script system - it works well and I change the status with a click of the mouse, but it does add an edit every time to my status sub page. An automatic system would be better - but I think opt-in is required.  Ronhjones  (Talk) 22:47, 12 November 2011 (UTC)[reply]
  • Support as a parser so people can use it as they want. I see absolutely nothing wrong with giving people a choice. Ajraddatz (Talk) 15:47, 20 November 2011 (UTC)[reply]
  • Opposetracking. you're creating a tracking-system for all users, whether they choose to have it shown on their page or not. Choyoołʼįįhí:Seb az86556 > haneʼ 08:13, 21 November 2011 (UTC)[reply]
No, it doesn't track anyone unless they activate it, and even if they do, it doesn't save anything else than a timestamp. Petrb (talk) 08:47, 21 November 2011 (UTC)[reply]
Said facebook. I read your defense below, doesn't convince me. Choyoołʼįįhí:Seb az86556 > haneʼ 10:37, 21 November 2011 (UTC)[reply]
  • Support as a voluntary option of editors. Particularly for articles that might be contentious or whose subjects might be undergoing rapid change, it might be useful to be able to bring together all the "sides" involved, or people with access to all the relevant sources. And making it voluntary would not oblige anyone who doesn't want to take part to do so. John Carter (talk) 23:39, 21 November 2011 (UTC)[reply]
  • Support as a voluntary option. I don't really see any harm in adding this, and I'm sure that some people would find this useful. Regardless of what some people may claim, Wikipedia will not become Facebook or a social networking site. If people wanted to use it like that, they'd simply use a social networking site already made for that purpose.--Slon02 (talk) 01:56, 22 November 2011 (UTC)[reply]
  • Strong support.(with opted-out as the default) As a participant on other large collaborative open source projects that draw their core teams from across many time zones and from people with different levels of availability, it is often important to provide, and be given some indication of how long a response may be forthcoming. Arguments that there are plenty noticeboards, help desks, admins, and other people around are not convincing, as many items for discussion and/or action can only be addressed by one individual. One may argue that nothing here is urgent, but some are, and unless one has a friendly talk page stalker, articles may get deleted, users blocked, and users denied the opportunity to respond to other accusations of malpractice. I abhor social media sites and such a feature would not turn Wikipedia into any more of a social gathering than the collaboration on phpBB and it's help forum. I use StausChanger and wouldn't want to be without it, but it concerns me that it adds up to 3,000 edits a year my editcount. it will need more variable for user customisation that are being offered, and I for one would be happy to test it. If this proposal were to be implemented, its introduction would be discrete, and there is no reason to believe there would be a stampede to use it. If 1,000 of the busiest editors end up using it, that's a 1,000 reasons to adopt it. --Kudpung กุดผึ้ง (talk) 12:52, 22 November 2011 (UTC)[reply]

Online Status: How does it work?

The heading to this section has been updated with some information about what the proposed extension does. Could that please be clarified: This extension would maintain a table of [user_id, timestamp] records for all users? The timestamp shows when the user last read a page? The table is periodically purged to remove entries with an old timestamp? The time elapsed before a timestamp is regarded as old is a wiki-wide setting? What would be a proposed value? If some magic wikitext is present on a user page, that magic is expanded each time the user page is viewed? Does it work on user talk pages? On any other page? If user X puts the wikitext on user Y's user page, would everyone be able to see if Y is offline? Johnuniq (talk) 00:54, 31 October 2011 (UTC)[reply]

This extension would maintain a table of [user_id, timestamp] records for all users?
For most of registered users who visit wikipedia, just like the checkuser table or cache tables, data will not be accessible and would be only used when user allows that
For users who did enable this feature in their settings. Petrb (talk) 19:09, 31 October 2011 (UTC)[reply]
The timestamp shows when the user last read a page??
Timestamp shows when user who use this feature last opened any page (but doesn't store name of the page, it doesn't store anything else than timestamp as reference and username) on wikipedia when logged in. (if $wgOnlineStatusBarTrackIpUsers isn't true), otherwise even when not logged in
The table is periodically purged to remove entries with an old timestamp? The time elapsed before a timestamp is regarded as old is a wiki-wide setting?
default setting is 1 hour, it can be changed wiki-wide, it's not customizable by user.
What would be a proposed value?
That's up to you, otherwise it would be default value.
If some magic wikitext is present on a user page, that magic is expanded each time the user page is viewed? Does it work on user talk pages? On any other page? If user X puts the wikitext on user Y's user page, would everyone be able to see if Y is offline?
Text is expanded everytime page is purged, it does work in user and user talk space, if user X put that text on user Y page who doesn't have it allowed it expand to unknown, otherwise it shows their status.
Some informations on statuses:
This extension was not designed in the style of social network feature therefore the implementation of statuses may appear little bit too simple, but I believe that it's enough for purpose of extension:
The extension contains following statuses: Online as a general online status, Away for people who (as already noted) may become temporarily unavailable but not left for longer time, Busy for people who for instance work on some article and can't respond quickly - and that's all, also there is a status hidden which appears same as offline. It isn't possible to create own "fancy" statuses. It also isn't possible to change the appearence of icon of status and text, it's integrated to the mediawiki skin you choose so that it follows its preferences. For that you would need to create a custom template.

Thanks for question. Petrb (talk) 06:17, 31 October 2011 (UTC)[reply]

  • question Did I get it right that you wrote, or maintain, this extension and thus you - and you alone - control what it logs? And it may quickly changed from logging all user to logging opt-in users, as your above striken explanation suggests? In short, who controls the code? - Nabla (talk) 22:06, 1 November 2011 (UTC)[reply]
No you didn't it's is stored in mediawiki svn, so that any wikimedia developer with access to svn can change the code, also before deloyment it would need many reviews done by others. Having say that, everyone can see if it does what I say it does, and anyone could improve it or change. (Althougt I am maintaner now) Petrb (talk) 14:50, 2 November 2011 (UTC)[reply]
But you were true that I change it based on the feedback here. Any constructive ideas are welcome. Petrb (talk) 14:52, 2 November 2011 (UTC)[reply]
Thank you. Understood, no problem about it then. I understand we disagree, which is fine, I hope you also understand that when I ask not to implement this, I am not being "destructive" (as opposed to constructive). In my opinion, right or wrong I can't be sure, turning WP into a facebooky thing is very bad. To me personally it would be a very very good thing. You implement this and I am out the very next minute :-) It will gain me a few hours per week for other interesting things.... And I am only one, sure. But will this help WP? How many editors out there will avoid a WP site that turn (more) 'social'? And how many editors will WP gain? Is it worthy in the long run? - Nabla (talk) 01:57, 3 November 2011 (UTC)[reply]
I can't answer this, I just try to improve existing stuff which can be improved - I have seen a thing which I didn't like (that template) and instead of proposing to force people to stop using it I tried to improve it, I don't like idea of making more restrictions anywhere, I like freedom and having say that it already exist, I don't assume it change anything else than its technical implementation / functionality. Or I can eventualy implement stuff requested by community, wheter it harm it or not, that's something what community needs to answer (and that's why I asked here). Petrb (talk) 10:16, 3 November 2011 (UTC)[reply]

up?

So, is this up or not? When? - Nabla (talk) 14:14, 8 November 2011 (UTC)[reply]

Discussion is still open, I am just wondering why you dislike this so much while it's so minor update of system that you can't even see if it has been already installed or not... I can assure you that even if this discussion was closed in favor of installation, it would take at least week for it to happen. Petrb (talk) 20:17, 8 November 2011 (UTC)[reply]
You could be in the process of installing, as you say it. You do place an interesting question, though. If this is a minor update - and I may admit it is technically - why do I dislike it so much? Really... I do not know! I quite like the 'social' possibilities offered by the 'net. I enjoyed a lot playing chess by e-mail and being able to talk with the opponents was a major enjoyment factor. I've play some MMOG longer than I've been here, and enjoyed chatting in there. Yet one of the factors that drove me off of it was... these "social" thingies that help little, except in 'facebooking' the site. I enjoy meeting people in here (see this message :-) I am not able to tell exactly why, but I very much dislike the (specifically) social features. Probably the problem is about being "pushed" into a "social" site. I'm not here to meet people (if I do I go out and have a beer with some friends or I'll join the real facebook :-), I want to write, correct, organize, etc. And there is not a single urgent matter requiring prompt assistance from anyone specific. None whatsoever. There is nothing that can not wait until tomorrow OR be executed by any available editor/admin/... I wish the best of luck, in this in whatever else you code and do. But, to me, this is very bad. Fine, WP can live without any single editor, as I have just said:-) I am not leaving but this is bad, turning the whole net into facebook is silly. - Nabla (talk) 22:30, 12 November 2011 (UTC)[reply]
👍 1 user likes this. I couldn't agree more with Nabla. This hits the nail on the head. Toshio Yamaguchi (talk) 16:04, 20 November 2011 (UTC)[reply]
At the same time, Nabla, the entire internet is "upgrading" to be more like Facebook. Whatever stance you have on the issue, that is a fact. I think that it could be rather easy for Wikipedia to fall behind if it doesn't continue to improve methods of user interaction - while one person leaving won't make a difference, over time we could be looking at significantly more than that. Now, I'm not trying to scare everyone into enabling this minor change, but I do see the potential for some bad effects resulting from Wikipedia's unwillingness to improve (improvement being, of course, a very subjective term). Ajraddatz (Talk) 02:17, 21 November 2011 (UTC)[reply]
Well the sysadmins won't even think about installing it until it's had two rounds of code review, one for general code quality and then one for security and performance from Tim. Given that that process hasn't even started yet (Template:Bug), you're looking at much more than a week. Happy‑melon 00:07, 21 November 2011 (UTC)[reply]
actually it has been already reviewed by Ian (wmf), it had one more performance fix and it will be reviewed again once it's clear if community wants it. Petrb (talk) 07:29, 21 November 2011 (UTC)[reply]

Render title as alternative name (with Template:R from alternative name)

There are many articles in Wikipedia whose subjects have more than one commonly used name, for example: Herpes zoster and Shingles refer to the same article. Which alternative should be used when the subject is referenced in other articles, will depend on the context. With current practice, one of the alternative names is often chosen (perhaps arbitrarily, as the first that was used) as the 'title' name, and the other alternative names are implemented as 'redirects' to the title name. Thus, when following a wikilink to (or searching for an article for) 'alternative name', the following may be rendered:

Title name
From Wikipedia, the free encyclopedia
       (redirected from Alternative name)

This can be disconcerting to the reader, whose eye is drawn to the large text title and, especially if not familiar with the term 'title name', may be left thinking: "That's not the page I selected—has something gone wrong?" This could be easily solved by changing the rendering as follows:

Alternative name
From Wikipedia, the free encyclopedia
       (alternative name for Title name)

This would apply only in conjunction with the use of the existing "R from alternative name" template; redirects from mis-spellings, for example, would not be affected. Uniplex (talk) 08:14, 21 November 2011 (UTC)[reply]

I don't think there is an easy way to make the title show something completely different. Choyoołʼįįhí:Seb az86556 > haneʼ 08:20, 21 November 2011 (UTC)[reply]
The rendering of articles reached via redirect is already specialized; this would just specialize it a little more, so it seems hard to imagine that the implementation would be difficult. However, I think that the discussion here should focus initially on whether or not the proposal would enhance the user experience—if not, the question of implementation is moot. Uniplex (talk) 08:50, 21 November 2011 (UTC)[reply]
It could be worthwhile that if the redirect provides the right information to have a parenthetical reason after the redirect line, eg: "(Redirected from Alternate Name (common misspelling))" Given that not all redirects are done for alternative naming, this would be a better solution to explain to the reader why they're now at this page. --MASEM (t) 15:09, 21 November 2011 (UTC)[reply]
Templates "R from misspelling" and "R from alternative spelling" could of course be included in the proposal, though IMO, the effect of seeing a change in spelling from wikilink to article title, is less disconcerting than seeing a completely different term (e.g. per Shingles above), and one would hope that mis-spelled wikilinks would be corrected. Uniplex (talk) 15:31, 21 November 2011 (UTC)[reply]

I fear that this would result in more confusion than clarity. The title of an article implies a number of other properties, and those relationships would become unclear to the casual editor. For just one example, what value would magic words like {{BASEPAGENAME}} return? Powers T 15:38, 21 November 2011 (UTC)[reply]

A possible compromise would be to simply make the redirection notice "(redirected from Alternative name)" slightly larger/more prominent. fredgandt 00:44, 22 November 2011 (UTC)[reply]
In response to Powers, I would say nothing else should change: we're not trying to hide the fact that the article has another title, perhaps "break it to the reader more gently" (the alternatives will likely be discussed in the lead sentence). As Fred_Gandt surmises, the essence of the proposal is to change the relative size and position of two pieces of text; if there is a downside to doing both, a partial approach could give some of the benefit. Uniplex (talk) 06:06, 22 November 2011 (UTC)[reply]
My concern, then would be confusion caused by it not being clear what the actual (technical) title of the article is. Taking the Shingles example, we would have the article titled "Herpes zoster", but people who arrive by the "Shingles" redirect would see "Shingles" at the top, followed by a hatnote that says "'Shingles' redirects here". 'Shingles' redirects to 'Shingles'? It makes sense, but only after one stops and thinks about it for a bit, which is not good user interface practice. Also, consider the infobox; in this case, it's fine because the "real" title is the "technical" term, but in other cases it could look weird to have a different title for the infobox versus than at the top of the page. Powers T 04:04, 23 November 2011 (UTC)[reply]
I had considered the infobox, but for me at least, the eye is always drawn to the (much larger) title text first. Whatever we do, there's bound to be some weirdness that remains for the user. One other problem with the existing solution is that after being presented with a large, surprising title, the "Redirected from ... " is not much comfort: it gives no clue as to why the user has been redirected. "Alternative name for ..." is much clearer in this respect. Let's try it with the real example and look at a few more options:

Current (direct):

Herpes zoster
From Wikipedia, the free encyclopedia

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...


Current (from redirect):

Herpes zoster
From Wikipedia, the free encyclopedia
       (redirected from Shingles)

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...


Ideas (from redirect):

Shingles
From Wikipedia, the free encyclopedia
       (alternative name for Herpes zoster)

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...


Herpes zoster
       (also known as Shingles)
From Wikipedia, the free encyclopedia

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...


Herpes zoster
also known as Shingles
From Wikipedia, the free encyclopedia

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...

Uniplex (talk) 13:46, 23 November 2011 (UTC)[reply]

I think the last one looks best, removes the astonishment, and is broadly per fredgandt's compromise suggestion. So if there are no further comments, I'll raise the ticket. Uniplex (talk) 13:00, 24 November 2011 (UTC)[reply]
Er, sorry, but what exactly is gained from that? After all, the alternative name is supposed to be listed in the first sentence of the article in bold... Not to mention that in the example the "main" and "alternative" names get listed three times (yes, in other cases there will be less mentions). Also, change as such is undesirable: what about the users who expect redirects by now? Wouldn't they be astonished instead? Also, if the user interface shows "also known as [...]" after hitting a redirect, wouldn't the user be astonished after getting to the article some other way and learning that its subject isn't "also known as [...]" any more..?
And one more problem... At the moment hardly anyone cares about categorisation of redirects. But if they will be made more prominent, they will become more important too. And the interface will make some names look more "legitimate" than others. When exactly will we confer such "legitimacy"? For example, is Vilnius "also known as Wilno"? Is Burbiškis "also known as Burbiszki"? And yes, there was a discussion (and an edit war) if that Polish name should be listed in the article ([10]). Would we have to repeat it for a redirect (yes, thankfully, there is no real redirect in this case, but what about other cases?)? I guess we would do well to sacrifice some usability of our user interface (in this case that amount is extremely small and maybe even negative - I'd say the current system is just better (yes, a little)) to avoid those problems... --Martynas Patasius (talk) 19:47, 24 November 2011 (UTC)[reply]
"what exactly is gained from that?"— "Also known as" explains to the user why, when they clicked on a Wikilink, they ended up on what at first appears to be a wrong page. "change as such is undesirable"— transitory astonishment is preferable to permanent astonishment (and Jimbo urges that we should be BOLD in looking to the future). "learning that its subject isn't "also known as [...]" any more..?"— good point, this suggests the parenthesized version is better. “is Vilnius "also known as Wilno"?” the proposal is 100% agnostic on this. If consensus is that the "alternative name" is an alternative name (i.e. mentioned as such in the lead sentence) then being tagged as an alternative name is a consequence of this. Were someone to then suggest that no-one really cares about the tagging, that would likely be seen as an attempt to subvert consensus. (With the parenthesis back in place,) all the proposal is doing is making a pertinent piece of information prominent enough so that it is not missed, and changing the developer-centric phrase "redirected from" to the user-centric phrase "also known as" (with prior consensus that this is indeed the case). Uniplex (talk) 06:42, 25 November 2011 (UTC)[reply]
"(With the parenthesis back in place,) all the proposal is doing is making a pertinent piece of information prominent enough so that it is not missed, and changing the developer-centric phrase "redirected from" to the user-centric phrase "also known as" (with prior consensus that this is indeed the case)." - sorry, but what "prior consensus" do you have in mind here..? I don't think I understand that part... And it seems to be crucial to your point...
""change as such is undesirable"— transitory astonishment is preferable to permanent astonishment" - well, is there a proof that there is such "permanent astonishment"? So far I can only see that you assert that this is the case. Well, I can assert that it is not - do you have any data to show that real users are actually astonished? For otherwise, while it might be that "transitory astonishment is preferable to permanent astonishment" (though I would still hope that "intensity" of astonishment should be taken into account too), it is also true that we should care about real and known astonishment more than about imaginary or hypothesised.
"“is Vilnius "also known as Wilno"?” the proposal is 100% agnostic on this." - yes, I know. That is exactly why I am objecting. First of all we would need some guideline, only then we can consider such user interface change. Otherwise we will get a "rematch" of old edit wars. --Martynas Patasius (talk) 18:54, 25 November 2011 (UTC)[reply]

Herpes zoster
(Shingles automatically redirects here)

From Wikipedia, the free encyclopedia

Whatever whatever whatever... fredgandt 07:57, 25 November 2011 (UTC)[reply]
Well, I'd settle for it, but "automatically redirects here" is not quite as as informative. It tells the reader that the two terms are probably related in some way and that the article should contain some information on Shingles (in this case), but "Also known as" tells the reader that pretty much everything in the article is about Shingles. Also, for someone not familiar with the implementation of WP (and there's no requirement that any reader should be), "automatically redirected" is something of a technical term: it relates to the mechanism, not the reason ("also known as" is an everyday term). Uniplex (talk) 11:33, 25 November 2011 (UTC)[reply]
The problem being (as stated above) that "AKA" is going to cause endless arguments and confusion. If (e.g.) "Shingles" and "Herpes zoster" have found themselves linked by traditional means (Wikiwise), the mechanism(s) are in place to create hints to that link in (what is clearly arguably) the right places. I agree that more obvious and clear indication as to why the visitor (unfamiliar with redirects) has landed on some other page is needed, but do not think suggestions of alternative names should be applied. An example could be ABCDEFGHIJKLMNOPQRSTUVWXYZ. that is obviously not a pseudonymous for "alphabet", but the former does redirect to the latter (as does its lower case twin). With nearly 4millon articles it is fair to assume there are many cases where redirects are not for the purpose of "AKA"'s. Another example: Furries redirects to Furry fandom and neither can be considered an alternative for the other in any reasonable respect. Furries are members of Furry fandom (or a rock band). Too many differentials exist to whitewash the lot with "AKA".
A clearer statement showing that the search term is definitely something to do with this article is all that's needed and all that can (in all cases) be relatively guaranteed (since the redirect already exists). fredgandt 18:53, 25 November 2011 (UTC)[reply]

Actually, maybe we should just add a link to Help:Redirect? Then whoever is astonished to find a "wrong" name will have a chance to find out what happened (and how to fix it if it is really wrong - after all, everyone is a potential editor - we should never look at the readers as if they were just readers). --Martynas Patasius (talk) 19:19, 25 November 2011 (UTC)[reply]

Agreed if combined with an increased scale. So we have the Page name in big, the original search term at maybe 1/2 size and "redirected" at no less than 1/4 size (of page name). No extra words just up the font-size and link one word. fredgandt 19:25, 25 November 2011 (UTC)[reply]
You're misrepresenting the proposal: the "also known as" indication was suggested only for names (unlike ABCDEFGHIJKLMNOPQRSTUVWXYZ) that are listed as such in the lead sentence, and naturally wikilinked elsewhere (not just searched for). Anyway, you seem sure of what you want, so I'll leave it to you. Uniplex (talk) 08:09, 26 November 2011 (UTC)[reply]

A simple "last best version" marker

I know we're likely not to get Pending Changes any time soon, but I've got a few articles that I watch that will, at random times, be targets for anon vandalism from offsite sources, or other aspects that may introduce changes that can easily got lost and buried through attempts at manual fixing or reverting. Obviously nothing we can do about it without locking under semi-prot, but that's not ideal.

I am wondering if we can device some makeshift system whereby an editor of concern can tag specific revisions of an article as a "good version", marking that on the talk page, ideally alongside the other "Article Milestones" header, since actions like GAN or FAC do a similar action. The act of marking such should really only be done by a registered editor (so there's traceability in case the editor purposely or accidentally marks a bad version as "good"), with the possibility of IPs dropping a talk page tag request to have a third-party editor bless articles otherwise.

Technically, all this can be done with what we have now in wikicode and MediaWiki; a few templates here and there, a modification of the Article Milestone template, some process and rationale approach to when to do it, etc. The only thing that I'd would like to add is to have this marking record be in a separate space (like Page Notices) which is blocked from anon IP editing, simply to avoid attempts to vandalize the record. (named editors can still vandalize it, but this is at least traceable).

All this is to bless certainly versions, so that when an article "wrecked" beyond a certain degree due to fighting vandalism, a quick check of the past marked versions can give us the last best revision and a copy-paste to fix things can be done, followed by diff checking to re-add good new info. It's not required at all, it's to be used as editors see fit (not day-to-day, but month-to-month or more often for high-visibility articles), and certainly has none of the "the encyclopedia anyone can edit"-stigma that Pending Changes would have had. Plus its lightweight and requires no Mediawiki code modification.

I know technically I can do this right now by dropping such notes on a talk page, but I'm suggesting that we can formalize this with a few templates and the like. --MASEM (t) 15:07, 21 November 2011 (UTC)[reply]

Not far above us there is a similar conversation going on. fredgandt 00:48, 22 November 2011 (UTC)[reply]
Probably a good idea, but probably also worth digging through Wikipedia:Flagged revisions/Quality versions, Wikipedia:Stable versions, meta:Reviewed article version, Wikipedia:Flagged revisions/reliable revisions. Fences&Windows 00:49, 22 November 2011 (UTC)[reply]
The flagged-revisions feature proposal explicitly included something quite similar - a lightweight method of marking a revision as "patrolled", which was only a log entry and did not affect what was shown to readers. It was to be a second phase of the trial, but seems to have been poisoned by association with the trainwreck that was FR, and never appeared. It seens it would do the job admirably, albeit without the registration on the talkpage. Perhaps it would be easier to get that small section turned back on than developing a new method?
Alternatively, if you're looking for a stopgap, you can try null edits - make a trivial change, leave an edit summary with something like "clean stable version, 22/11/11". When you return to the page it's relatively easy to find that one edit in the history, do a diff from there to now, and see what's happened. Shimgray | talk | 13:52, 22 November 2011 (UTC)[reply]

Non-controversial admins

Consensus is pretty clear here that this isn't something that we want, or is likely to happen. Steven Zhang The clock is ticking.... 01:37, 25 November 2011 (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.

This is a large proposal, very similar to what has been discussed here. The proposal is to create a new class of users who have the technical ability to:

  • Make blocks of any non-sysop;
  • Delete/undelete pages
  • Revdelete
  • Protect pages
  • Edit protected pages
  • Rollback
  • Reviewers (if PC is activated again)

However, the differences between these and regular sysops are:

  • Unblocking is limited to unblocking noncontroversial blocks made by self.
  • Blocks of autoconfirmed users must be brought to ANI or AN.
  • Rangeblocks must be brought to AN before a block.
  • No ability to change user rights of anyone
  • Editing protected pages may be done only within the user's own userspace, or if the protection was for vandalism or sockpuppetry purposes. They may not edit if the full protection was for any other reason. They cannot accept edit requests to fully protected pages, but still can accept them for semi protected pages.
  • Protection is limited to the userspace (excluding talk page), and for vandalism and sockpuppetry reasons.
  • Revdelete is limited to RD2 and RD3
  • Deletions of pages are limited to non-controversial (unrelated to things like arbcom statements) userspace pages (within own namespace), G1, and G3. If enough consensus is established here, G10 and G11 can be included as well.
  • Revoking talk page and/or email access is limited to vandals and socks.
  • Cannot accept or decline unblock requests, but can endorse or oppose block; admin still gets final decision.
  • Cannot close AN or ANI discussions, and no deletion discussions.
  • Except when it matches LTA, socks must be forwarded to SPI (if there is consensus for this in the discussion for this proposal).
  • Blocks are limited to VoAs, spam accounts, long-term abuse socks, and IPs.

Added after discussion:

  • Users who gain this right must have at least 2000 edits and be active for at least 1 year before requesting.
  • Users who gain this right must have at least 50 accepted requests to RPP, and at least 75 accepted requests to AIV and UAA, combined. The ratio of declined:accepted must be less than 1:20 for RPP requests and 1:50 for AIV/UAA requests.

Admins and higher user levels can assign/revoke this userright. The process for gaining this userright is proposed to be similar to the one for edit filter managers. Violations of this code may be reported to ANI.Jasper Deng (talk) 05:13, 23 November 2011 (UTC)[reply]

That's a pretty long list you have there! Seems to be a lot of trouble to memorize, and I can imagine the gray areas to be even more trouble. bibliomaniac15 05:30, 23 November 2011 (UTC)[reply]
This is a perennial proposal. no --Guerillero | My Talk 05:30, 23 November 2011 (UTC)[reply]
It is not, since the process for gaining the right is not the same as the one specified at the perrenial proposals page (not RfA).Jasper Deng (talk) 05:33, 23 November 2011 (UTC)[reply]
HaHaHa. Then its a hell no. a snowball has a better chance in hell then this passing. We do not need to hand out mini-admin privileges to every kid that passes by who found TW last week and has become a super vandal fighter. --Guerillero | My Talk 05:42, 23 November 2011 (UTC)[reply]
The admin backlogs warrant it. AIV requests are not all that are needed. Edit filter manager requests are somewhat between RFP (requests for permissions) and RFA in contentiousness. Adding edit count requirements and activity requirements.Jasper Deng (talk) 05:44, 23 November 2011 (UTC)[reply]
This would require several software changes (or else, trusting lightly vetted people to refrain from doing things they have been given the ability to do.) Something we can't always trust regular admins to handle well. Rmhermen (talk) 06:03, 23 November 2011 (UTC)[reply]
It's easy. All we need to do is add some lines to the CommonSettings.php configuration file, and possibly an extension for the first suggestion.Jasper Deng (talk) 06:05, 23 November 2011 (UTC)[reply]
This is a terrible idea, for starters it would cause an insanely large amount of work for who ever has the job of monitoring these mini-admins. Every single block/deletion/protection would need to be double checked. Say deletion is limited to g1, 3 etc. How do you stop someone deleting another page and calling it a g1? Not to mention the fact that you don't even need to be an admin to close AN or ANI discussions, and deletion discussions. --Jac16888 Talk 15:13, 23 November 2011 (UTC)[reply]
This is why we need the users to be long-term. This tool can be revoked, just like Rollback. I'm sure we don't need to double-check obvious socks and VoAs (especially those with inappropriate usernames).Jasper Deng (talk) 19:45, 23 November 2011 (UTC)[reply]
Rollback cannot do noticeable damage to the project if abused. There is no way technically to only allow someone to block vandals and socks, or only delete vandalism & self-resquests. Therefore all of these mini-admins must either be trusted enough to not do the things they're not supposed to, in which case they should be able to pass an rfa anyway, or they must be carefully monitored, which just makes an even bigger backlog. Take a hint from the fact nobody is supporting this, and drop it. It's not a good idea--Jac16888 Talk 11:00, 24 November 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page, such as the current discussion page. No further edits should be made to this discussion.

I propose an easy way for someone to make their facebook comunity/friends aware of Wikipedia's need for money.... a button to attach a personal appeal from Wikipedia founders or programmers onto a person's facebook page. If there is a fear of social network sites, then someway to easily spread the news.

You could mention it yourself on your own personal facebook page, but there is very, very little chance that the community will approve having the facebook logo on the fundraising banner, that's too much. Sven Manguard Wha? 11:34, 24 November 2011 (UTC)[reply]
Yes, it would be good to spread knowledge of the campaign, but the problem with these little "share" buttons is that they also serve as ads for that site. I wouldn't see a problem with adding those buttons to, say, the last page you reach after clicking "donate". The odds of that reaching consensus, though, are comparable to a proposal to donate the project to Burger King. Thanks for the idea though, and keep 'em coming, we may figure something out. PhnomPencil (talk) 17:35, 24 November 2011 (UTC)[reply]

Celebration for 5 millionth edit

How about a small celebration for the 5 millionth edit? We are currently at 1,239,236,067, so we only need −739,236,067 more edits. If you think about it, it's not alot. A small sitenotice maybe? ~~Ebe123~~ → report on my contribs. 12:07, 24 November 2011 (UTC)[reply]

You mean 500 millionth edit? :) (with near on 4 million articles we'd be looking at barely 1.2 edits per page :) for a total of 5 million) --Errant (chat!) 12:22, 24 November 2011 (UTC)[reply]
No, it's 19.55 by average edits per page. ~~Ebe123~~ → report on my contribs. 20:25, 24 November 2011 (UTC)[reply]
Indeed it is; which equates to either 74 Million edits to article space, or 500 Million (half a billion) overall edits. We passed 5 million many moons ago :) --Errant (chat!) 12:55, 25 November 2011 (UTC)[reply]

If we are now on the number which is quoted, that means we have aleady passed the five millionth edit- was this figure quoted in error? ACEOREVIVED (talk) 15:54, 24 November 2011 (UTC) More specifically, it means that we are 739236067 edits past the five millionth edit. ACEOREVIVED (talk) 15:55, 24 November 2011 (UTC)[reply]

The number quoted is the magic-word {{NUMBEROFEDITS}}, and thus constantly updating. When the message was posted, it was under 500M. When you read it, I suppose it was over that. Chzz  ►  18:58, 24 November 2011 (UTC)[reply]
I suggest this thread is closed as it is clearly now redundant and seems to be nothing more than a bone of contention. fredgandt 18:37, 25 November 2011 (UTC)[reply]

Proposal for a new free image category

Some free image licenses (e.g. any CC-BY license) require attribution, which we usually provide here by linking the image to its description page and including the necessary information there. And some free image licenses (e.g. GPL (section 3), GFDL (sections 2 & 6)) require a notice appear in connection with any "distribution" of the image, which we again provide by linking the image to its description page and including the necessary information there. And some free image licenses (e.g. CC0, public domain) have no such requirements.

It would be helpful if we had a category along the lines of Category:All free media to indicate this information. So I propose modifying {{free media}} to take a "link needed" parameter which does the following:

One possible use for this would be to make it easier both to identify images to which WP:ALT may be applied (setting "|alt=|link=" for accessibility) and to which "|link=" has been incorrectly applied to an image requiring attribution. In both cases it would be helpful if someone could convince Commons to implement this proposal as well (any volunteers?). Anomie⚔ 15:51, 24 November 2011 (UTC)[reply]

We should just do it by license transclusions. Every file tagged with one of the licenses that has special requirements should be in a category with all the files with that special requirement, based on having the license on its file description page. I'm pretty sure that'll save a lot of time and achieve the same result. Sven Manguard Wha? 16:30, 24 November 2011 (UTC)[reply]
All free license templates themselves transclude {{free media}}. I have no objection to also creating a category for "All free media requiring a link to the description page", although we may have issues then if someone decides to dual-license an image under CC-BY-SA and Kopimi or something like that. The category for images not requiring a link would IMO generally be more useful, as it's safer to assume an image requires the link unless specifically marked otherwise than vice versa. Anomie⚔ 00:50, 25 November 2011 (UTC)[reply]
  • All free files should be moved to Commons. Commons only have free files (except for the copyvios not yet found) so Commons does not need a category for "All free files". So if anything needs to be done on Commons it should probably be by editing the license templates. --MGA73 (talk) 16:52, 24 November 2011 (UTC)[reply]
    How about those images that are free in the US but not in the country of origin? Move them to Commons and they'll be deleted. Or how about images that are created to illustrate a discussion here and are absolutely useless for any other purpose? They might be deleted from Commons for that reason, if some ... "user" at Commons decides to get a bug up their butt.
    Anyway, what would need to be done at Commons to implement this would be for the various license templates to apply the "does not require link" category, just as is being proposed here. It's just that here we already have a bit of infrastructure in the form of {{free media}} since we do need to make the free/non-free distinction. Anomie⚔ 00:50, 25 November 2011 (UTC)[reply]
    The PD US-files does not require require attribution so they are not a problem. On Commons we have the rule that a file that is in use is in scope. So if someone gets something up their butt on Commons then admins will close the DR as keep. If the admin deletes anyway we can undelete and spank the admin. --MGA73 (talk) 20:35, 25 November 2011 (UTC)[reply]
    My point is that there is currently no way to automatically determine (i.e. from a script) whether or not a file with a PD-US tag or any of the many other free license tags needs a backlink for license compliance. At present, for a locally uploaded image you would have to check for any of over 200 categories to reliably guess at this, and hope that you didn't miss any. And on Commons the situation is even worse, I gave up trying to enumerate the full subcategory tree of commons:Category:Public domain. Anomie⚔ 22:16, 25 November 2011 (UTC)[reply]
  • Given the number of free files we have on en.wikipedia right now, this may be a good idea. However, ultimately we should have only a very few free files, if any, here (Cue shameless advertisement) there is a drive to move them coming up in January, FYI. --Philosopher Let us reason together. 18:10, 24 November 2011 (UTC)[reply]
    See above. And then there are some editors who are just sick of the problems at Commons and want no part of it. Anomie⚔ 00:50, 25 November 2011 (UTC)[reply]
    I think that it is better to solve the problems than to create systems for a few users. For example if I think that interwiki bots are annoying because they sometimes add stupid links. Can I then select 20 articles and move the interwiki links into a template? And add a "Don't touch the interwiki templates"? --MGA73 (talk) 20:35, 25 November 2011 (UTC)[reply]
    Re:Anomie, I did say "good idea." It's unnecessary to bring up at Commons, though, as it already has commons:Category:Attribution, which is added by adding commons:Template:Attribution to a page. --Philosopher Let us reason together. 21:54, 25 November 2011 (UTC)[reply]
    I think you misunderstood. commons:Category:Attribution appears to contain only images that are licensed using commons:Template:Attribution. It doesn't contain commons:File:Cone-response.svg, even though the CC-BY-SA-3.0 license used requires attribution. And a backlink for uses of that file is also needed because both the CC-BY-SA-3.0 and GFDL licenses require a notice that the file is under those licenses. Anomie⚔ 22:16, 25 November 2011 (UTC)[reply]
    (edit conflict) Re: MGA73: The fact of the matter is that, whether or not you approve of the practice, we do have many free images uploaded locally and we do have {{KeepLocal}} here. Can we discuss the proposal instead of being sidetracked into a "every free image should be uploaded to Commons, and damn the opposition!" argument? Anomie⚔ 22:16, 25 November 2011 (UTC)[reply]

Suggestion for User-en templates

As user's level of English, doesn't only mean its abillity of well contributing, should we include one, major additional thing, and that is communicating?

So, except an user contributes to Wikipedia, other important thing is its level of communication with other users. Current text on User en-3 template is:

  • “This user is able to contribute with an advanced level of English.”, and my suggestion includes:
  • “This user is able to contribute and communicate with an advanced level of English.”

Thank you. Alex discussion ★ 19:54, 24 November 2011 (UTC)[reply]

First off I would divide communication into two categories.
  1. Output
  2. Understanding
If output is understood as contribution in the sense that everything submitted to Wikipedia is a contribution (including contributions to discussions), we can leave contribute as it is and the templates meaning can be considered accurate regarding a user's ability to output a language at whatever level.
Understanding of a language and the ability to output that language are not directly tied. One may be able to read a language far better than one can write or speak it, and vice versa.
So, if any change were to be made to the wording of the template it should be to clarify point 2 insofar that the user can understand the language as well as they can contribute with/in it.
With this in mind I'd suggest a wording more along the lines of "This user is able to understand, and contribute with an advanced level of English." if any change were to made at all.
However, if the user is not able to understand as well as they can write or speak a language, the template in that form would not be at all accurate. Therefore a template redesigned to offer this clarification would require an argument/variable which when used, could alter the template to state the original (that is that the user can contribute to whatever level etc. etc.) text. fredgandt 00:58, 25 November 2011 (UTC)[reply]
This is the funniest thing ever. It is certainly clear that there are scores of Wikipedians with major communication difficulties - many of them native English speakers. However I don't see most of them (however modest they may be in other areas - or not) labelling themselves as having low communication skills. Rich Farmbrough, 17:43, 25 November 2011 (UTC).
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=462537447"