This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
because i'm in china
any chance you can accept local cards
Check your credit card to see if it has the logo for China UnionPay on it (you can see the logo on the linked article). If it does, follow these steps:
1) Go to the bar on the left of any Wikipedia page and click on "Donate to Wikipedia"
2) Leave the drop down currency selector in "USD - $", and type in the amount the amount you wish to donate, in US dollars (remember 1 USD is about 6.3 RMB, or 6.1 RMB after the bank charges a currency conversion fee).
3) Click the button that says "Donate via PayPal"
You will be taken to a new screen.
If you already have a PayPal account, click the login link and donate as normal. If you don't:
4) On the new screen, the first field says "Country". Click the drop down menu and select China if it isn't already selected.
The page will load for a bit, and you will then see the UnionPay logo added to the list of accepted card types.
5) Type in the number of the credit card that has the UnionPay logo on it. When you're done, a button will light up that allows you to create an account. Click that, and you'll have an account.
6) If it dosen't log you in right away, you'll have to log in. Once you do so, you can pay as normal.
7) Optional 7th step: Write a letter to the WMF reminding them that China is the second largest economy in the world, and it might be a good idea to make it easier to donate from there.
I've also been informed of this donation form. I'm not sure why I, editing from a China Unicom IP, in China, didn't reach it (it could only be accessable from zh.wikipedia) but that's the other, easier option, however it does not allow you to pay by UnionPay. Sven ManguardWha?17:39, 18 November 2011 (UTC)
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 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). fg07:21, 15 November 2011 (UTC)
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)
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.
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. fg19:05, 18 November 2011 (UTC)
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 ManguardWha?19:33, 18 November 2011 (UTC)
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). fg21:42, 18 November 2011 (UTC)
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)
Sven says leader and Pichpich says cult. Jeeze! No wonder threads on these discussion pages get so heated and confused. fg12:49, 19 November 2011 (UTC)
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)
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.
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)
They won't directly track you, like they do with anything that has a unified login with Facebook, but they can still connect information every time you click the Wikipedia share button... and then sell that information to advertisers the same as if you used their button. Anything that posts to Facebook, no matter what we do on our end, gives them information, which they will sell, period. Sven ManguardWha?07:56, 23 October 2011 (UTC)
Sven; the implication if someone clicks "share to Facebook" is that they wish to, well, share it on Facebook :) Whatever your or I think, politcally/morally, about Facebook isn't really relevant if readers want to share on FB. An they do... --Errant(chat!)09:39, 24 October 2011 (UTC)
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)
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)
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)
.... which flies in the face of the whole separation of Wikipedia and commercialism thing that everyone seems to agree is really important. Sven ManguardWha?12:20, 22 October 2011 (UTC)
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 ManguardWha?18:39, 21 October 2011 (UTC)
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.
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. AgnosticAphidtalk21:01, 21 October 2011 (UTC)
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)
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 | Talk21:16, 21 October 2011 (UTC)
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 | Talk21:32, 21 October 2011 (UTC)
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. AgnosticAphidtalk21:29, 21 October 2011 (UTC)
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-C05:08, 22 October 2011 (UTC)
Oppose. Wikipedia isn't a social networking site, and this would just distract from the main purpose of Wikipedia, which is to edit and improve it.Jasper Deng(talk)21:28, 21 October 2011 (UTC)
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.
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)
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. -- fgTC21:40, 21 October 2011 (UTC)
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)
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)
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)
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)
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)
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)
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¢. ~ MatthewrbowkerSay hi!23:56, 21 October 2011 (UTC)
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)
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. -- fgTC00:00, 22 October 2011 (UTC)
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. -- fgTC00:00, 22 October 2011 (UTC)
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)
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." -- fgTC00:42, 22 October 2011 (UTC)
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. -- fgTC04:20, 22 October 2011 (UTC)
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)
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)
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)
Sadly, it's not that simple; it appears that Facebook (and probably others) record reading pages with those buttons in, even without them being used. If we can find a way to prevent this, it wouldn't have to be not a game-killer, but the standard implementation currently in use is problematic. Shimgray | talk | 12:13, 22 October 2011 (UTC)
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)
I have yet to be distracted by the new "Wikilove" icon. If it makes Wikipedia more fun then edits and productivity will go up. MarcusQwertyus04:24, 22 October 2011 (UTC)
Oppose. Wikipedia is not a social networking site, nor supported by ads. If newpspaper and magazines want to have blogs for each article and share/like/follow/tweet buttons, that's their decision. It shouldn't be ours. — Arthur Rubin(talk)02:42, 22 October 2011 (UTC)
Strong oppose. Wikipedia is not a social networking site and it's already in danger of becoming one. Sharing it would agtract the wrong kind of dialogue to talk pages, and worst of all, it would attract more vandalis and more unwanted new pages. Wikipedia is doing fine as it is, but new page patroll, vandalism patrol, and AfC are already overburdoned. Kudpung กุดผึ้ง (talk) 03:13, 22 October 2011 (UTC)
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)
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.
The BBC, NYT and Nature aren't editable and hence it is not possible to share a link to a vanity/spam/vandalism page using those sites. MER-C04:46, 22 October 2011 (UTC)
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-C04:43, 22 October 2011 (UTC)
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)
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)
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)
I don't think your tone about the "denseness" of people and all those rants are warranted. If we're all idiots, then what is your Highness doing here? The fact is that buttons like this give the impression — in terms of style/layout/look — of a social-networking site. Choyoołʼįįhí:Seb az86556> haneʼ09:31, 22 October 2011 (UTC)
Tone issues aside, TheDJ makes a good point. The Wikipedia Signpost has used sharing buttons for quite some time, without relying on third-party inline frames or scripts - i.e. no privacy concerns at all, unless and until one chooses to click "share". — This, that, and the other (talk)09:49, 22 October 2011 (UTC)
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)
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)
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)
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)
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)
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? PowersT15:57, 22 October 2011 (UTC)
That's the "Like" button, not a Sharing facility. No one has suggested putting the Like button on any Wikipedia page. PowersT19:35, 22 October 2011 (UTC)
Weak Support Per User:This, that and the other and User:TheDJ. The feature is reader, not editor, -centric, and (I say this as a computer programmer) so long as we don't use particularly fancy widgets, there will be no danger of tracking. We will still remain WP:NOTMYSPACE since there will be no integration with Wikipedia/Wikimedia user accounts, and all sharing, commenting, etc. will be happening off-wiki. --Cybercobra(talk)20:25, 22 October 2011 (UTC)
Oppose Maybe a third party app could be developed for readers that want a share button. Then it is someone else's support problem, not ours. Unscintillating (talk) 21:19, 22 October 2011 (UTC)
Support Wikipedia needs additional editors and active readers dipping a toes into the oceans of social networking may help. It is certainly worth testing. Capitalismojo (talk) 22:44, 22 October 2011 (UTC)
Suggestion To possibly alleviate some concerns of the opposition, making this feature opt-in rather than having to opt-out might be advisable. -- fgTC00:25, 23 October 2011 (UTC)
All of those are already possible and happen currently without an integrated sharing feature. We'd be saving submitters one copy-paste; that doesn't seem a huge enough difference to unleash the torrent of badness you seem to be envisioning. --Cybercobra(talk)02:52, 23 October 2011 (UTC)
That that ugly rant was posted by a Wikipedia admin is something far more fearful than a new way to share knowledge. -- fgTC03:17, 23 October 2011 (UTC)
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. -- fgTC08:45, 28 October 2011 (UTC)
Strong Oppose per Unscintillating. This can all be done browser-side via plug-ins. No need for the project to get its hands dirty if there truly is a need for "sharing".VictorianMutant(Talk)01:57, 23 October 2011 (UTC)
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? ▫ JohnnyMrNinja05:07, 23 October 2011 (UTC)
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. -- fgTC18:18, 23 October 2011 (UTC)
Support everyone else has a share button - you aren't required to use it. And browser plugins aren't an acceptable solution to the 99% of non-geek users. -- Eraserhead1 <talk> 09:31, 23 October 2011 (UTC)
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)
Weak oppose. I don't mind "sharing knowledge" in principle and I can see how this might attract beneficial editing, but what exactly needs to be shared/linked/plussed/digged/etc.? WP is already top search for most topics and I don't quite see how copying the URL is so hard? I also don't want to link my Wikipedia account to any social bookmarking websites I happen to be logged into unless Mediawiki does its own implementation. Additionally, I don't think an open source project should link to arbitrarily selected commercial websites. WMF has already previously rejected non-open source projects and I believe that's the way to go. — HELLKNOWZ ▎TALK10:09, 23 October 2011 (UTC)
Copying the URL is hard because people aren't generally technologically savvy. You could make the same argument about the BBC etc. -- Eraserhead1 <talk> 10:25, 23 October 2011 (UTC)
Nobody is supporting linking WP and Facebook accounts, check out Wikipedia:Wikipedia Signpost to see how the buttons work. They do not send user info to any of the sharing sites, only the link to be shared. The only info Facebook can glean from that is that you did another thing on your Facebook account, no WP user data is compromised. ▫ JohnnyMrNinja12:22, 23 October 2011 (UTC)
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)talk12:29, 23 October 2011 (UTC)
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)
Oppose. Can't see why we really need this. Facebook and Wikipedia are two very different entities. As I understand it, it is already possible to share links to any website on Facebook anyway. Cloudbound (talk) 13:22, 23 October 2011 (UTC)
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
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)
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)
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.
(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)
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)
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)
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)
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/contributions19:02, 24 October 2011 (UTC)
oppose we have no issues with lack of traffic or SEO. If someone wants to share something cut and paste works perfectly well. Ridernyc (talk) 00:32, 24 October 2011 (UTC)
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)
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)
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)
Successful organizations don't rest on their laurels. Unsuccessful ones do. — Preceding unsigned comment added by Herostratus (talk • contribs)
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):
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)
'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)
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)
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)
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)
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)
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)
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)
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? -- fgTC11:32, 24 October 2011 (UTC)
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 ManguardWha?11:43, 24 October 2011 (UTC)
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)
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). -- fgTC12:39, 24 October 2011 (UTC)
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 ManguardWha?12:46, 24 October 2011 (UTC)
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 ManguardWha?14:09, 24 October 2011 (UTC)
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)
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. -- fgTC13:19, 24 October 2011 (UTC)
"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)
An increase in traffic and (over all else) the benefit is ease of use for readers and an encouraged sharing of knowledge. -- fgTC15:15, 24 October 2011 (UTC)
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://wiki.riteme.site/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)
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)
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. -- fgTC09:00, 28 October 2011 (UTC)
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)
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)
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. -- fgTC15:15, 24 October 2011 (UTC)
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)
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)
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)
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)
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)
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 Bebacktalk00:21, 25 October 2011 (UTC)
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)
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 Bebacktalk18:26, 31 October 2011 (UTC)
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)
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. -- fgTC02:02, 25 October 2011 (UTC)
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. AgnosticAphidtalk18:01, 25 October 2011 (UTC)
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) - talk17:26, 27 October 2011 (UTC)
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)
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)
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)
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)
Support. There's a lot of FUD here about "Wikipedia isn't Facebook" and bogus NPoV concerns, but this is a proposal to add a tool to help our readers promote us to people in their social circles. When added, such facility probably belongs in or under the "toolbox".. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits10:33, 30 October 2011 (UTC)
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)
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)
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)
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)
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)
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 Fox09:35, 4 November 2011 (UTC)
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)
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. SnowolfHow can I help?08:15, 22 November 2011 (UTC)
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)
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 thereshivers. 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.
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)
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)
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. -- fgTC00:54, 25 October 2011 (UTC)
@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)
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. AgnosticAphidtalk17:54, 25 October 2011 (UTC)
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. AgnosticAphidtalk19:43, 25 October 2011 (UTC)
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. AgnosticAphidtalk17:47, 25 October 2011 (UTC)
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)
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. ▫ JohnnyMrNinja14:15, 25 October 2011 (UTC)
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)
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)
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)
The Sharebox user script uses the AddThis bookmarking service to add e-mail and share buttons to the Wikipedia toolbar. As of October 2011, AddThis supports 345 services. A few highlights:
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. AgnosticAphidtalk23:26, 1 November 2011 (UTC)
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. DangerHigh voltage!01:57, 8 November 2011 (UTC)
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)
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)
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)
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)
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.
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.
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)
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.
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)
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)
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)
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)
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)
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 ManguardWha?05:07, 30 October 2011 (UTC)
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. fgtc05:47, 30 October 2011 (UTC)
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. fgtc07:31, 30 October 2011 (UTC)
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)
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)
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) --Chris06:53, 30 October 2011 (UTC)
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)
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)
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)
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)
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)
If Wikipedia's future consists ofhinges on pampering each other with artificial kittens, then the rest of the Internet is not going to be very impressed. –MuZemike21:24, 31 October 2011 (UTC)
I doubt the WMF would keep it on if the community consensus was against it. (I oppose the extension's removal, btw.) --Yair rand (talk) 16:38, 2 November 2011 (UTC)
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 SoWhy17:28, 2 November 2011 (UTC)
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)
'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. Blofeld19:00, 4 November 2011 (UTC)
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)
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)
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)
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)
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 | Talk21:20, 14 November 2011 (UTC)
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)
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)
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)
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. fgtc15:03, 11 November 2011 (UTC)
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. --JaGatalk17:32, 11 November 2011 (UTC)
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)
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. fg10:14, 12 November 2011 (UTC)
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)
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. fg23:48, 11 November 2011 (UTC)
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)
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)
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)
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)
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 ManguardWha?13:35, 12 November 2011 (UTC)
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.
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.
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
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. HansAdler10:01, 22 November 2011 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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. bibliomaniac1505:30, 23 November 2011 (UTC)
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)
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)
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)
If we can trust these users with all of these rights, and further trust them to use them within a very limited scope, why can't we trust them with the full sysop package? Ajraddatz (Talk) 14:47, 23 November 2011 (UTC)
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. --Jac16888Talk15:13, 23 November 2011 (UTC)
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)
Well, we have about 730 active admins and 550 semi-active. We're losing about 200 a year, mostly through attrition. We're gaining, what? A handful. So in a few years we are going to run out admins. There are all sorts of ways to address this. This is one. If you don't like it, OK, but then we need some other approaches. Herostratus (talk) 17:55, 23 November 2011 (UTC)
The purpose of this is to have admins who do not have to judge community consensus in things like community ban discussions, deletion discussions, and edit warring discussions.Jasper Deng(talk)19:47, 23 November 2011 (UTC)
Let me second Jac16888's bad idea. This is not the right solution to the problem - even leaving aside the question of balancing the particular rights. If the problem is losing more admins than we're gaining, there are really only two possible solutions - a) start nominating more good editors for adminship and b) (if relevant) encourage lower standards at RfA. Creating semi-admins or temporary admins isn't the way to counter the problem. --PhilosopherLet us reason together.03:09, 24 November 2011 (UTC)
As an example of the unbalanced rights, why on earth should this guy be able to block editors but not give them rollback? It takes essentially the same kind of judgment for both - and more of it for the block than for the rollback. --PhilosopherLet us reason together.03:11, 24 November 2011 (UTC)
No - while the proposal is trying to find a way to reduce backlogs, I think it would create much more work than it eliminates. LadyofShalott03:27, 24 November 2011 (UTC)
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--Jac16888Talk11:00, 24 November 2011 (UTC)
Oppose the idea of admin-lite has been proposed and shot down multiple times for good reason. If I trust someone to be able to block, I trust them for the whole package. If I don't trust them to block, I don't trust them for any package. For pretty much every other item that hasn't been unbundled yet, you can replace 'block' with the other right and the statement will still be true. Sven ManguardWha?11:43, 24 November 2011 (UTC)
Oppose as extremely over-complicated, and thus likely to cause massive arguments over the minutiae of all those rules. Chzz ► 18:51, 24 November 2011 (UTC)
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.
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 nameFrom 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 nameFrom 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)
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)
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)
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)
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? PowersT15:38, 21 November 2011 (UTC)
A possible compromise would be to simply make the redirection notice "(redirected from Alternative name)" slightly larger/more prominent. fredgandt00:44, 22 November 2011 (UTC)
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)
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. PowersT04:04, 23 November 2011 (UTC)
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 zosterFrom 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).
Medical condition
Village pump (proposals)/Archive 81
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...
Current (from redirect):
Herpes zosterFrom 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).
Medical condition
Village pump (proposals)/Archive 81
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...
Ideas (from redirect):
ShinglesFrom 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).
Medical condition
Village pump (proposals)/Archive 81
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).
Medical condition
Village pump (proposals)/Archive 81
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...
Herpes zoster also known as ShinglesFrom 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).
Medical condition
Village pump (proposals)/Archive 81
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...
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)
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 ([6]). 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)
"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)
"(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)
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)
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). fredgandt18:53, 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). --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 "redirected" at no less than 1/4 size (of page name). No extra words just up the font-size and link one word. fredgandt19: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. Uniplex (talk) 08:09, 26 November 2011 (UTC)
Celebration for 5 millionth edit
How about a small celebration for the 5 millionth edit? We are currently at 1,255,952,719, so we only need −755,952,719 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)
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)
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)
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 755952719 edits past the five millionth edit. ACEOREVIVED (talk) 15:55, 24 November 2011 (UTC)
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)
I suggest this thread is closed as it is clearly now redundant and seems to be nothing more than a bone of contention. fredgandt18:37, 25 November 2011 (UTC)
Actually some folks already work on such feature (I don't know details), however you can visit irc channel on freenode to be able to talk to others :) Petrb (talk) 11:26, 26 November 2011 (UTC)
People interact with each other by adding and editing pages in the encyclopedia. We also have Talk pages for direct discussions. Further, there are pages like the Village Pump where you can discuss ideas, as we're doing here. Did you want something more than that? What, specifically, do you want to achieve, that the present functionality doesn't provide? — JohnFromPinckney (talk)11:35, 26 November 2011 (UTC)
There is a difference between talk page and live chat, if you don't believe it, try it yourself, that's probably what he meant ;) Petrb (talk) 11:45, 26 November 2011 (UTC)
Petrb, it isn't that I didn't believe there's a difference; I just didn't see what Tegra3 wanted to achieve with something called "toolbar chat". Frankly, I get nervous at the prospect of see more stuff like this, this, this or especially this and don't want to encourage things that come close. If Tegra needs to IRC with others and I can easily ignore every word, then that's fine with me. I just don't need to see discussions about Tegra's cat or digestion problems (or the cat's digestion problems). — JohnFromPinckney (talk)12:16, 26 November 2011 (UTC)
My Books
For those of us who are utilizing Wikipedia as a Search Engine to drive a research project, the set up to enter My Books is an arcane nonsensical process.
MY suggestion:
1. Log IN should be on the face page, not the second page
2. MY books Link should be where My Talk link is.
You guys have this all configured for those contributing, and not for those who are referencing. Make it a bit more user friendly.
Secondly My Books seems to be VERY fragile. I have now LOST two extensive books, and have absolutely no idea how I did it. Deleting the entire book should be about a tripple are you very sure apparatus.
Wikipedia is a fabulous tool. I continuously use it in my research. The second I have two extra nickels, I will send the first to Doctors without Borders, and the second to you guys. Thank you, thank you, thank you for your work. — Preceding unsigned comment added by Fredwage (talk • contribs) 11:17, 26 November 2011 (UTC)
You do not seem to have made any books with this logon, perhaps your work was not saved? Or did you use a different logon to do this? (This means I do not know what to undelete to assist you). If remembering a page is very important, I would suggest book marking it on your browser, as well as adding it to your watch list. If you do log on the suggest place to put your books is User:Fredwage/Books/something. But there is nothing there. Graeme Bartlett (talk) 01:53, 27 November 2011 (UTC)
different language versions of particular article in mobile view
Hi. I use Wikipedia in Bulgarian and very often switch to English version, when there is no enough information about what i read in Bulgarian. Sometimes I don`t know the English word for something and I use Bulgarian version for starting point for my search in English Wikipedia.
But I can`t do that on my Kindle because in mobile version of Wikipedia there is no side menu for different Languages. And every time I have to select the link "View this page on regular Wikipedia".
I wanted to propose this language menu to be included somehow in mobile version of Wikipedia.
When I use Wikipedia on my desktop computer and click on "Mobile view" in the end of article page, I see a drop-down list with different languages between search field and the title of article (and two buttons - HOME and RANDOM). But when I search the very same article trough my Kindle, this drop-down list and 2 buttons are missing. I thought the problem is in my Kindle, but on my brother`s smartphone the drop-down language list is missing too.
I`m sorry if this is not the right place to tell this all :) — Preceding unsigned comment added by 78.90.19.22 (talk)
The short answer is, someone's working on it :-) The upgraded version of the mobile site (mw:Athena) includes a prominent "language" button. I don't know when it's expected to go live, though. Shimgray | talk | 18:25, 26 November 2011 (UTC)
Warning about {{DEFAULTSORT:}} when moving a page?
I suggest that when a page containing a {{DEFAULTSORT}} is Moved, the editor moving the page should be alerted to remind them to update the DEFAULTSORT if necessary.
This could be either:
A warning at the time of the page move if the DEFAULTSORT is not updated, by a red text message similar to those when a file is saved with references but no {{reflist}} (although there could be cases where the DEFAULTSORT was originally wrong and was correct after the move), or
A warning posted on the editor's talk page, on the lines of "You have just moved [Thispage] to [Thatpage]. It has a DEFAULTSORT of [Old-default-sort]. Is this still correct? To edit it, click [here]." Ideally the edit link would go right to the {{DEFAULTSORT}} line of the moved file.
Forgot to include: there should be an opt-out so that editors who move a lot of pages and are confident that they never forget to update the sort key can choose not to get the alerts! PamD23:17, 27 November 2011 (UTC)
The last proposal on enabling this extension received near unanimous support. It sounds like a very useful tool. Perhaps it's time to revive this discussion for another round. -- Ϫ10:41, 27 November 2011 (UTC)
Oppose: People might not want the pages. Users find the pages, and adds them. We do not need a body to push useless pages on our watchlists. ~~Ebe123~~ → report on my contribs. 16:58, 27 November 2011 (UTC)
It's not clear from the extension page, but you have to "subscribe" to having random articles pushed onto your watchlist. Don't subscribe and you won't have your watchlist messed with. Personally, I wouldn't use it. But judging by the linked discussion, many people would. Anomie⚔17:25, 27 November 2011 (UTC)
My point still stands as if we wanted pages on our watchlists, we put them ourselves. How about just a page where users could suggest pages, and then the user can put them at will. ~~Ebe123~~ → report on my contribs. 19:45, 27 November 2011 (UTC)
It looks like a very handy tool, and while I would not use it myself, I think that it should be enabled since it gives users the choice. I really don't understand where problems arise from giving users the option to do something. Ajraddatz (Talk) 18:31, 27 November 2011 (UTC)
From #wikimedia-tech in September 2009:
<Annemarie> TimStarling: Why did you disable PovWatch on
test.wikipedia?</message>
<TimStarling> because I was surprised it was still enabled, it was meant to be
a trial
<TimStarling> I'm not sure if it works anymore
<TimStarling> nobody has used it since it was written, 2 years ago
This would need a lot of thought as to how this is going to work - ie who is allowed to put pages onto peoples watchlists and for what reasons - this needs to be very carefully thought out as it could be easily used to push POV or effectively canvass - i.e. send pages out to editors with the same POV as yourself.Nigel Ish (talk) 21:52, 27 November 2011 (UTC)
Consensus to develop as an opt-in only feature for users who wish to show their online/offline status. SilkTork✔Tea time 11:19, 28 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.
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)
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. -- fgTC11:08, 29 October 2011 (UTC)
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)
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)
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)
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)
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)
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)
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)
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 ▎TALK12:16, 29 October 2011 (UTC)
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)
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 ▎TALK13:30, 29 October 2011 (UTC)
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)
(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)
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)
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)
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)
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)
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)
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)
What's the point of this? Wikipedia isn't Facebook. We have IRC if someone needs to find an admin/steward in case of "emergency". /ƒETCHCOMMS/19:30, 29 October 2011 (UTC)
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)
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)
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)
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. fgtc01:38, 30 October 2011 (UTC)
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)
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)
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)
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)
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)
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)
Already done - Use importScript('User:Ale_jrb/Scripts/statusCheck.js'); to accomplish the same thing. Unfortunately, nobody uses it. →Στc.19:44, 29 October 2011 (UTC)
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)
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)
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)
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)
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)
Question But what about people, like me, who use a different template for their status info, like {{Useronline}}? This has a completely different design, which I like better then the design of {{Statustop}}. Will this feature have more designs? I wouldn't use it if would only designed after {{Statustop}}, but would make the necessary edits further. Sir ArmbrustTalk to meContribs21:22, 29 October 2011 (UTC)
This feature was designed for this aswel, it creates magic word which can be used in templates so that you can create custom template aswell. Petrb (talk) 08:04, 30 October 2011 (UTC)
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)
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)
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. Resolute01:37, 30 October 2011 (UTC)
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 ManguardWha?05:14, 30 October 2011 (UTC)
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)
Support. Eliminating all the useless revisions and time-wasting edits to status pages is a good reason to support. The ability to customize the design is also appealing. -- Ϫ08:48, 30 October 2011 (UTC)
Oppose Apart from my suspicion of ever-more social networking gadgets, the extensive commenting above without actually saying anything about what actually happens is an indication that the gadget is unlikely to have much encyclopedic benefit (see response to "how does it know?" above). Johnuniq (talk) 09:41, 30 October 2011 (UTC)
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)
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)
Support as opt-in feature. For those complaining that this would add unwanted social networking functionality, people who like it are already using it, but in a way that adds pointless revisions, messing up the edit history. I certainly won't use it, but I'm absolutely fine with others doing so. Nageh (talk) 14:03, 30 October 2011 (UTC)
Support Per Sven Manguard. There have been so many times I have wondered whether or not a user is online. Adding an opt-in auto-updating status gadget would be quite useful. This feature will not turn Wikipedia into a social networking site. All it will do, is improve communication between users. Alpha_Quadrant(talk)02:10, 31 October 2011 (UTC)
Support useful feature - I already use the statuscheck tool, but it is quite slow & tends to be a bit resource heavy. Knowing with a glance whether someone is accessible/online is extremely useful for collaboration. --Errant(chat!)10:12, 31 October 2011 (UTC)
Support but only if it's optional. I do agree that creating subpages that are updated manually every time one logs in or out is a waste. I don't like the concept either, but I think this automated tool is a good compromise. — Train2104 (talk • contribs • count) 13:44, 31 October 2011 (UTC)
Oppose per "the timestamp shows when the user last read a page ". It think this contravenes the foundation:privacy policy: "No more information on users and other visitors reading pages is collected than is typically collected in server logs by web sites. Aside from the above raw log data collected for general purposes, page visits do not expose a visitor's identity publicly" (emphasis mine). ASCIIn2Bme (talk) 16:31, 31 October 2011 (UTC)
If that is problem I can customize it so that data are collected only for people who use this. Also I don't understand why you don't have troubles with other things like checkuser which already violates the foundation policies... Petrb (talk) 17:16, 31 October 2011 (UTC)
I don't think that's the case. Does checkuser track when people read pages? I though it was tracking only when they edit pages. ASCIIn2Bme (talk) 17:42, 31 October 2011 (UTC)
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)
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)
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)
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)
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)
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)
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. –MuZemike21:32, 31 October 2011 (UTC)
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)
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)
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 ≠ wiser23:39, 5 November 2011 (UTC)
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)
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)
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. DangerHigh voltage!01:38, 8 November 2011 (UTC)
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)
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)
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)
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)
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)
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)
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
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.
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)
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)
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)
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)
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)
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)
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)
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 (T34128), you're looking at much more than a week. Happy‑melon00:07, 21 November 2011 (UTC)
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)
Socializing builds a better and more collaborative encyclopedia
Just thought I'd throw it out there. Everyone opposing on the grounds that this will make the encyclopedia more like Facebook is mistaken. Facebook is for Facebook, and Wikipedia hardly has the capabilities to be a worthy social site. However, knowing that editors who work on topics that you do are online is a valuable tool. Claiming IRC performs this function is a double take - Do you dislike socializing or do you think its beneficial? IRC is still socializing, no matter how you swing it. Do editors who use IRC contribute more productively to the encyclopedia? YES!
Further, an editor popping on your talk page and saying "nice day" actually is beneficial. It brightens your mood (unless you're a crabby old hermit), and it makes you feel appreciated for the efforts you put in. While I'm sure some people would love an egoless world where everyone is happy doing without praise, you're fighting an uphill and losing battle against human nature. - ʄɭoʏɗiaɲτ¢15:47, 26 November 2011 (UTC)
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.
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:
If set to anything else or omitted, add the media and/or the template itself to some sort of maintenance category.
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)
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 ManguardWha?16:30, 24 November 2011 (UTC)
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)
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)
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)
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)
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)
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. --PhilosopherLet us reason together.18:10, 24 November 2011 (UTC)
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)
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)
(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)
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.”
First off I would divide communication into two categories.
Output
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. fredgandt00:58, 25 November 2011 (UTC)
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. RichFarmbrough, 17:43, 25 November 2011 (UTC).
The User-en templates are part of a family of templates, located on all the Wikipedias, and should be kept in line with the rest of the family. The {{User he-3}} text says "משתמש זה מסוגל לתרום ברמה מתקדמת של עברית", which means "This user is able to contribute with an advanced level of Hebrew". And the German Wikipedia {{User en-3}} has the current wording of our {{User en-3}}. עוד מישהוOd Mishehu08:21, 28 November 2011 (UTC)
Hey guys, I'm trying to advertise this straw poll to get consensus not only from those heavily involved in did you know?, but those who would be interested if new changes were implemented. I'm trying to do so without falling afoul of WP:CANVASS. Hope this is ok! Thoughts and additional suggestions very, very welcome. PanydThe muffin is not subtle17:46, 28 November 2011 (UTC)
Possible long term codification of the ArbCom elections
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 ManguardWha?11:34, 24 November 2011 (UTC)
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)
Automatically add user JavaScript and CSS pages to watchlist when imported (cascading) (retrospective)
All JavaScript and CSS pages should be added automatically to a users watchlist if imported to any of their own script pages. This action should be retrospective (once active all watchlists update to show all imports, not just from now on) and should act to add all cascading imports as well. fredgandt03:56, 27 November 2011 (UTC)
Suggestions
Suggest that all imported scripts (and their imports ad infinitum) when changed are blocked from being loaded until the user has accepted the new draft. A popup alert could have three buttons: 1) Accept 2) Diff 3) Later. If Later is clicked the script's block continues. Diff takes the user to the script's diff (between when they first imported it and the latest draft). Accept simply unblocks the imported script and allows the new version (whatever it does) to run. All this could also apply to CSS too (although clearly less importantly). fredgandt04:38, 27 November 2011 (UTC)
Most users who import JS scripts probably don't know JS, and so would have little to base their decision on. Your suggestion would probably be difficult to implement, since MediaWiki would need to parse the JavaScript in a user's .js pages to determine what pages are being imported. Ucucha (talk) 05:08, 27 November 2011 (UTC)
Assuming you're right (that most users don't know JS), some therefore must. So some would get the benefit from seeing the difference. Assuming that most users have some common sense, most would be able to tell if the script had changed significantly and could act however they felt was appropriate on being informed of the change. As it stands, few of the most you refer to would therefore be technically minded enough to think of how the functionality of the script might change over time, or be aware of how that warning message might actually mean something. Denying users a choice on the grounds that they might not know what to do with it is quite frankly disgusting.
Difficult to implement? The Mediawiki software is some of the most advanced on the web. Do you really think such a small change would be beyond Wikimedia? I seriously doubt it. The text added during the addition of an import is already being parsed. Grabbing the script address, its revision id, and slapping a watched tag on it would be next to child's play compared with the vast majority of the complex processes going on here 1000's of times a day. Even if it was difficult, so what? Has the proposal any value? I believe so. Informing users that a script they are using has been changed is something I think most would insist on knowing if they knew how much it could matter under certain circumstances. fredgandt09:17, 27 November 2011 (UTC)
We are encouraged to be bold. This includes our use of the servers and bandwidth (within decent reason). Lets not kill the idea because Wikimedia may not like it. Lets explore the idea considering its possible value, then if put on Wikimedia's desk, deal with the technical drudgery.
Imperfection is a universal constant. Is there such a thing as a perfect article? I think not. Should we delete them all then? No. Why not? because they can be improved. That an idea is not perfect is an opportunity to improve it not a reason to smother it. fredgandt09:17, 27 November 2011 (UTC)
On pl.wikipedia there is a script for debugging JS scripts, and it lists the scripts which are loaded by the current user. Maybe it could be adapted to create another user script which, when imported by those interested, would inspect which other user scripts are being imported by the current user and compare the list with the user's watched list to see if there is any (local) user scripts which the user is not watching. If so, it could suggest the user to add it to its watchlist. Helder12:37, 27 November 2011 (UTC)
I think most if not all of what I have proposed can be accomplished by user script. But since that user script would be one of the scripts that needs watching it all gets kind of catch-22-ish. Further to that, if the user script wasn't imported the protection it offered wouldn't be in place. As a Mediawiki extension, the protection would be in lace for all. I know we have warnings now but they (even if heeded) only warn about the current version. fredgandt22:54, 27 November 2011 (UTC)
Oppose This wouldn't be helpful for most user, as js and css pages can only edited by the user, in who's userspace this pages are, and administrators (and maybe others, not sure). The fact is, that most editors can't edit an other editors js or css pages and many of us (like me) wouldn't even understand, what effect a change on the function of the user-script has. ArmbrustTalk to meabout my editsreview05:17, 28 November 2011 (UTC)
Oppose: most user a) don't understand JS and how should they informed about the changes? What happens if a script is broken? The user has to be forced to use the correct script then! And everybody who is not willing to use a updates script can easily copy and paste the old cope into it's own userspace and include/import that! mabdul12:56, 30 November 2011 (UTC)