Wikipedia:Village pump (proposals): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 22:04, 18 December 2017

Table of contents
First discussion
End of page
New post

Shortcuts

New ideas and proposals are discussed here. Before submitting:

Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
Consider developing your proposal at Village pump (idea lab).
Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
Proposed policy changes belong at Village pump (policy).
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Wikipedia and the Dec. 12th “Break The Internet” day of action for net neutrality

Considering it is now December 15 in parts of the world, I think this discussion is effectively moot. (non-admin closure) Narutolovehinata5 ^tccsdnew 00:33, 15 December 2017 (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.

Background

On December 14th the US Federal Communications Commission (FCC) will vote on a proposal to dismantle net neutrality protections in the United States and reclassify broadband Internet access providers as ‘information services’ under the Communications Act of 1996. This move will allow broadband providers to block sites or services on the basis of their content, charge websites, apps and services fees just to be able to reach an ISP's subscribers, slow down or speeding up services, and charge sites for privileged “fast lane” access. The impacts on donation-supported access to knowledge projects like Wikipedia could be significant.

The agency’s scheduled December 14th vote would remove the legal foundation for enforcing net neutrality at the FCC, and will strip away the specific provisions banning blocking, throttling, and paid prioritization. As a result, Internet users and businesses across the country will be largely unprotected from a wide array of traffic management practices the country’s largest ISPs could use to enact tolls on the open internet.

The agency’s final order was made available on November 22, 2017 and is available here: https://transition.fcc.gov/Daily_Releases/Daily_Business/2017/db1122/DOC-347927A1.pdf

The Wikimedia Foundation policy team has released a statement opposing the repeal, reiterating many of the arguments they made to the FCC in a filing earlier this year. They recognized that a loss of net neutrality would create barriers to accessing Wikipedia and other access to knowledge projects. They recognize that a loss of net neutrality will create barriers to the creation of primary sources, as well as the ability for contributors to edit and create entries. Moreover, Wikipedia would have to dedicate a higher percentage of their donations to bandwidth costs to ensure their site is “prioritized” by ISPs or even loads at all.

When the U.S. bill “The Stop Online Piracy Act” or “SOPA” threatened Wikipedia’s ability to exist by encouraging ISPs to block websites containing even small amounts of copyrighted material, the Wikipedia community, in this very forum, decided to “black out” its site for a day, alerting visitors to the legislative threat and inviting them to contact elected officials. See Wikipedia:SOPA_initiative.

As a result, nearly unprecedented numbers of people did so, and the legislation stalled. Proposed changes to net neutrality rules would allow similarly bad behavior by ISPs. and—like SOPA—these rules could be averted by a large number of calls to Congress, according to experts at leading organizations such as Public Knowledge and the Electronic Frontier Foundation

Now net neutrality advocates are organizing are calling on Internet users, websites, apps, and small businesses to participate in “Break the Internet,” an online protest starting 48 hours before the FCC’s scheduled vote, where participants will use widgets and banners to creatively “break” their online presence in some way, driving phone calls to Congress.

Proposal and Discussion

Should the Wikipedia community join the December 12th ‘Break the Internet’ day of action?
Should the Wikipedia community do *something* to keep the rules in place short of participating officially in the action (e.g. a message inviting visitors to call elected officials)?
What would be a creative way to “break” Wikipedia for a day and garner public attention?

— Preceding unsigned comment added by Jdtabish (talk • contribs) 19:42, 7 December 2017 (UTC) — Jdtabish (talk • contribs) has made few or no other edits outside this topic. [reply]

Strong oppose. I was opposed to SOPA but had reservations about even that action; I was afraid it would lead to this sort of slippery slope. But SOPA was arguably an existential threat. This is not. Wikipedia should not be taking political sides. --Trovatore (talk) 19:38, 7 December 2017 (UTC)[reply]
Power level 6000000000 Support. I think it's important to Wikipedia that anyone be able to access it's content regardless of who your ISP is. While Wikipedia might not be directly affected by the end of net neutrality it could harm people's ability to access it. Those people unable to afford the 'nice lane' might have trouble reaching our site in the future. The whole purpose of Wikipedia is to share knowledge and Wikipedia's ability to do this will likely be affected by the bill. I concede that it's not the Wiki foundation's problem if not everyone can afford a nice internet connection, but if we are in a position to take preventative action against legislation that allows ISPs to slow down people's connection to Wikipedia's service, we should. SpartaN (talk) 20:07, 7 December 2017 (UTC)[reply]
Strong Support in general, but I doubt wikipedians will be up for it. They are so apolitical, they'll rather sell their soul to the devil than take any form of stand. I'd just start throttling all traffic from Verizon, Comcast and AT&T and redirect all traffic from Washington DC to the Net Neutrality article for a week or so. Should be a nice and quiet. —TheDJ (talk • contribs) 20:09, 7 December 2017 (UTC)[reply]
- Comment Wikipedians as individuals can be as political or apolitical as they like, but Wikipedia qua Wikipedia needs to preserve its impartiality. --Trovatore (talk) 20:30, 7 December 2017 (UTC)[reply]
  - No our articles do, our community is political by nature. The whole idea of free knowledge for everyone is a political statement in itself. —TheDJ (talk • contribs) 20:37, 7 December 2017 (UTC)[reply]

- - - I disagree. If Wikipedia becomes a pressure group, its impartiality in presenting information will also be suspect. --Trovatore (talk) 20:40, 7 December 2017 (UTC)[reply]
Oppose Are we forgetting Wikipedia Zero? We'd be protesting something we've been lobbying for. Hawkeye7 (discuss) 20:11, 7 December 2017 (UTC)[reply]
- I don't see why. "Imagine a world in which every single human being can freely share in the sum of all knowledge." comes before being holier than holy about network neutrality in my list of priorities. —TheDJ (talk • contribs) 20:35, 7 December 2017 (UTC)[reply]
- Excellent point. There is more than one side to this. Natureium (talk) 20:48, 7 December 2017 (UTC)[reply]
- Wikipedia Zero, because it undermines net neutrality, does, sadly, more harm than good. --Anthonyhcole (talk · contribs · email) 08:36, 8 December 2017 (UTC)[reply]
Support initially I thought this was different than SOPA, and in some ways it is. However, Wikipedia Zero, while the exception that would be nice, could also be turned on its head. For-profit encyclopedias (or Wikipedia mirrors loaded with ads) could cut deals with ISPs and have preferential treatment over us. Or Verizon et al could very well try to extort money from the WMF so that Wikimedia projects get throttled/blocked in favour of other competitors. This possibility alone warrants opposing any weakening to net neutrality, and I believe this is infinitely more likely than Wikipedia Zero becoming a thing in the USA. As such, repealing net neutrality is a threat to Wikipedia. While out articles need to be impartial about net neutrality and the laws governing it, we as a community need not be apolitical about this. (I'm Canadian, so I'm unaffected by this either way.) Headbomb {t · c · p · b} 20:38, 7 December 2017 (UTC)[reply]

Comment If you're curious I found an article on how it might affect Canadians here: https://www.nationalobserver.com/2017/12/04/analysis/yes-us-net-neutrality-debacle-will-impact-people-canada-no-we-cant-sit-sidelines

- That's speculation. As I understand it, the repeal proposal would return the state of affairs to what it was in 2014. Why didn't this parade of horribles happen then? I don't see any SOPA-level threat to Wikipedia here. --Trovatore (talk) 20:52, 7 December 2017 (UTC)[reply]
  - This wouldn't take us back to 2014. 2014 had net neutrality protections from the 2010 net neutrality rules. Before 2010, net neutrality was protected by the FCC's 2005 policy statement, by enforcement actions (Madison River 2004, Comcast/Bittorent 2008), merger conditions (Comcast/NBC, AT&T/SBC) and spectrum auction rules. The U.S. internet has always been under de facto net neutrality. -- rsingel
  - It'll affect us, but very indirectly. Kinda like how US elections affects us indirectly. Headbomb {t · c · p · b} 20:57, 7 December 2017 (UTC)[reply]
Strongly oppose How about Wikipedia:Do not disrupt Wikipedia to illustrate a point? We do not need to be getting more political. Natureium (talk) 20:48, 7 December 2017 (UTC)[reply]
Support While SOPA was directly more about free speech, and its impact on Wikipedia more about what-ifs rather than a direct immediate threat (but still a threat nevertheless), this is a more direct threat in that we know the Internet providers are chomping at the bit to make internet fast lanes to favor content they prefer, which is going to be large commercial media corporations. There's a lot fewer steps should this be voted in favor of that would harm WP directly (since it is stored in the US) compared to SOPA. Yes, this is principally a move from the Republican side, but I disagree protesting here is a political element - it is about freedom of speech which is one of the reasons WP was made, to be empowered by that. --Masem (t) 20:53, 7 December 2017 (UTC)[reply]
Oppose a local US issue that is not too serious to Wikipedia at all. Graeme Bartlett (talk) 20:56, 7 December 2017 (UTC)[reply]
Strongly oppose disrupting Wikipedia to prove a dubious political point affecting only a single country; if you want to run a political campaign, get a blog. SOPA at least had a potential impact on Wikipedia; this does not. (Indeed one of the WMF's showcase projects is explicitly against net neutrality.) FWIW, I've lived for 30 years now in a country without net neutrality and have yet to notice the sky falling in. ‑ Iridescent 20:59, 7 December 2017 (UTC)[reply]
- The US also didn't have "net neutrality" until 2014, so it's not like it's ever been a big problem in practicality. Natureium (talk) 21:03, 7 December 2017 (UTC)[reply]
  - This is false. Repealing the existing rules wouldn't take us back to 2014. 2014 had net neutrality protections from the 2010 net neutrality rules. Before 2010, net neutrality was protected by the FCC's 2005 policy statement, by enforcement actions (Madison River 2004, Comcast/Bittorent 2008), merger conditions (Comcast/NBC, AT&T/SBC) and spectrum auction rules. The U.S. internet has always been under de facto net neutrality. -- rsingel
  - You mean they didn't have a law to protect net neutrality, a concept originally so coined in 2003, but that existed in practice long before that as unwritten rules that made the Internet so successful. The law was a response to parties like Comcast trying to break that model, at a time where the Internet became so fundamental in going about your daily life. —TheDJ (talk • contribs) 21:35, 7 December 2017 (UTC)[reply]
While I personally support net neutrality I'm not convinced that this is as someone above said an existential threat to us, or a global as opposed to merely a US issue. Then of course there is as Hawkeye points out the whole WikipediaZero thing..... Would our involvement in this add to the strength of the net neutrality campaign, or weaken it because our WikipediaZero campaign shows we don't back net neutrality where it suits us not to. Ϣere SpielChequers 22:22, 7 December 2017 (UTC)[reply]
Strongly oppose using Wikipedia for political activism. Rentier (talk) 21:08, 7 December 2017 (UTC)[reply]
While I personally support net neutrality I'm not convinced that this is as someone above said an existential threat to us, or a global as opposed to merely a US issue. Then of course there is as Hawkeye points out the whole WikipediaZero thing..... Would our involvement in this add to the strength of the net neutrality campaign, or weaken it because our WikipediaZero campaign shows we don't back net neutrality where it suits us not to. Ϣere SpielChequers 22:22, 7 December 2017 (UTC)[reply]
Strongly Support The battle to preserve net neutrality in the US is the defining fight for the internet. Wikipedia has to care about how the larger internet functions in its largest and most important geography (by number of readers + editors).
Strongly Support When Wikipedia did what it did during the SOPA protests, it did not compromise it's neutrality. So why then, would this? This affects Wikipedia as much as anything else. A blackout is absolutely necessary. Retroity (talk) 05:52, 9 December 2017 (UTC)[reply]

Some counterpoints to those opposing:

(1) If net neutrality goes, it is definitely an existential threat to Wikipedia; editors will not necessarily be able to cite on Wikipedia in the way they used to, and it's not even clear if Wikipedia itself will be affected by differential access speeds. If this isn't an existential threat, I don't know what is.

(2) Wikipedia 0 is not a conflict with net neutrality. There are many, many differences between Wikipedia 0 and what the FCC is now proposing. We don't pay; we are a valuable, essential, public service. Protecting and promoting us (you could say) is a fundamental duty of the internet. For those in the US, it's like sending taxpayer money to preserve Yellowstone National Park. Wikipedia is the public park of the internet, and providing access to it through whatever means and incentives is a public service, not a net neutrality conflict.

(3) Using Wikipedia as a political weapon: I totally agree. Wikipedia isn't a soup kitchen for causes. But it has been a powerful force in the past to protect itself (when protesting SOPA PIPA) and it has to do the same now. Or else, we're just giving in to something we could actively block, as we did before, and hastening our own destruction.

(4) It's not just a US issue. If net neutrality falls in the US, that sends a powerful signal to other big countries around the world that it's fine to kill net neutrality there. I live in India. All those telcos that have bought the current proposals to end net neutrality in the US also operate here. This could happen everywhere if we allow it to happen in the US.

(5) Wikipedia lives in the internet, and is enabled by it. The idea that the US internet is this other thing that has nothing do with us is nonsense; the worse the general state of the internet is in the US, the more it directly impacts how and whether someone can access us, read Wikipedia, and much worse, edit Wikipedia, because the ability to edit Wikipedia is directly connected to the ability to freely consult the wider internet.

For others out there, still on the fence, do please consider joining this protest. If you would like some more information on what's at stake, the NYT has a deep story on the fight to preserve net neutrality; worth a read. --aprabhala 04:53, 8 December 2017 (UTC)[reply]

Support It would be awesome to not be sullied by dirty politics, to remain morally aloof and above such petty things, but this issue directly impacts Wikipedia itself and we could be seriously compromised by remaining silent. Sometimes doing something is less painful than doing nothing. If there was an issue to act on, this is it. -- GreenC 04:40, 8 December 2017 (UTC)[reply]
Oppose - Regardless of the issue, an overall Wikipedia stance would have to represent the views of a majority of Wikipedia editors. Those views are not going to be determined by a self-selected handful of editors at the Village Pump. ―Mandruss ☎ 04:49, 8 December 2017 (UTC)[reply]
- I've added this to {{Centralized discussion}}. I can't think of a better forum than this for the discussion, but it does need to be more widely popularized to be binding. power~enwiki (π, ν) 06:17, 8 December 2017 (UTC)[reply]
  - Still not nearly enough. ―Mandruss ☎ 08:38, 8 December 2017 (UTC)[reply]
    - This doesn't look like it's going to reach a consensus for any specific action, so your procedural concerns probably won't matter. power~enwiki (π, ν) 19:35, 8 December 2017 (UTC)[reply]
Oppose Not that I'm not concerned about the repeal, but I think the Wikipedia Zero criticism would eat us alive. --Rs chen 7754 06:48, 8 December 2017 (UTC)[reply]
Strongly Oppose any Wikipedia activism, and per the above. This shouldn't affect us. As someone above stated, start a blog... GenQuest ^{"Talk to Me"} 07:46, 8 December 2017 (UTC)[reply]
Oppose. Arguably, Wikimedia breaks net neutrality itself through Wikipedia Zero. This is not the type of existential threat that Wikipedia should protest. We are not a political organization. ~ Rob₁₃^Talk 08:20, 8 December 2017 (UTC)[reply]
Strongly Support. Net neutrality is absolutely fundamental to everybody's use of the internet. The current US legislative proposals are dangerous, and much more serious than the earlier SOPA affair. Remember that doing nothing is also a political act, because Wikipedia then becomes complicit in this sordid business. --NSH001 (talk) 08:27, 8 December 2017 (UTC)[reply]
Support. Wikipedia Zero, because it undermines net neutrality, is, in sum, at the end of the day, when you think through the wider effect, stupid and bad. Always has been. Wikimedians are, on the whole, far too myopic and self-serving to grasp this very simple point. --Anthonyhcole (talk · contribs · email) 08:36, 8 December 2017 (UTC)[reply]
Strong Support I couldn't care any less about what the WMF is doing with Wikipedia Zero in terms of me supporting or opposing something. Anything that undermines net neutrality for anyone anywhere should be antithetical to any website that calls itself "The Free Encyclopedia", including the ridiculous zero-rating. Additionally, the comments saying that "We shouldn't be political" or that this won't affect but one country miss the mark entirely and makes me wonder if they even know what they are commenting on. Nihlus 08:47, 8 December 2017 (UTC)[reply]
Comment What should we do if this gets enough support? No attention has been paid to whether Wikipedia join "Break the Internet", or merely put up a banner about it. Presumably, if this gets support, we're at least going to have a banner about net neutrality at the top of pages. Break the Internet is only 4 days away and the vote is 8 days, meaning we should work on such things beforehand. SpartaN (talk) 10:27, 8 December 2017 (UTC)[reply]

Comment-Whatever is done let it only be shown to IPs originating in the US. — comment added by Force Radical (talk • contribs) 11:47, 8 December 2017 (UTC)[reply]

Oppose There is a great deal of fear, uncertainty, and doubt (FUD) over this and Wikipedia should not be feeding into that. People are loosing their shit over hypothetical scenarios or are just "taking someone else's word for it". It will also further push Wikipedia into political advocacy, and once you head down that road, it is increasingly hard to turn back. I should also not that this "proposal" was made by a single purpose account whose only purpose is to use Wikipedia as a soapbox by disrupting service to illustrate a point. —Farix (t | c) 12:25, 8 December 2017 (UTC)[reply]

@TheFarix: There are now a bunch of SPA votes and an IP vote signed "A Student". SPI filed. – Train2104 (t • c) 19:34, 8 December 2017 (UTC)[reply]

Support - Internet neutrality is important for everyone. WP should do what it can to support it. Renata (talk) 13:32, 8 December 2017 (UTC)[reply]
Oppose It's an important issue, but we shouldn't use Wikipedia as a political soapbox. Wikipedia shouldn't take sides on any political issues, really, regardless of importance. SkyWarrior 13:49, 8 December 2017 (UTC)[reply]
Oppose Per SkyWarrior.--Kevin Dewitt (talk) 14:37, 8 December 2017 (UTC)[reply]
Strong oppose picking a side in a political dispute and disrupting Wikipedia in the name of supporting it. – Train2104 (t • c) 15:37, 8 December 2017 (UTC)[reply]
Strong support—Providing universal access to free knowledge is the core purpose of Wikipedia.--Carwil (talk) 16:10, 8 December 2017 (UTC)[reply]
Strong oppose There is nothing "neutral" about the federal government regulating anything - the name is biased and misleading. WP should not be involved in political issues like this. MB 16:19, 8 December 2017 (UTC)[reply]
Oppose Not every wikipedian feels the same way about the issue. Plus, I joined 10 years ago to build a free encyclopedia, not be part of a political movement. Dennis Brown - 2¢ 17:37, 8 December 2017 (UTC)[reply]
Support. I propose that we implement a sneak peek of what charge-per-use internet would look like, and set up a monetization structure for that day, where we require all visitors (and editors) to pay ten cents per page visited (and edited) for the day. Maybe fifty cents per page for high-traffic pages or very large pages. Although we can't know the monetary assessment in advance, because providers will be able to set those arbitrarily, this will be a fair approximation of the result. bd2412 T 17:51, 8 December 2017 (UTC)[reply]
Very strong support I proposed at the meta wikimedia forum logged out (by mistake, look for 68.233.214.74 in the history) that we implement the script found [battleforthenet.com here], and as I am directly affected by net neutrality being broken down, please do something like that. The script loads an alert once per day per user and is easy to dismiss. Bardic Wizard (talk) 18:00, 8 December 2017 (UTC)[reply]
Strong Support I believe that Wikipedia, as a free source of information for anyone in the world, much less the US alone, should stick with the ideal of free access to information. Loss of net neutrality will negatively affect that ideal, and Wikipedia should do everything it can to maintain net neutrality - A Student — Preceding unsigned comment added by 128.237.175.221 (talk) 19:15, 8 December 2017 (UTC)[reply]
Oppose per WP:POINT, WP:SOAP + Dennis Brown's argument: I joined 10 years ago to build a free encyclopedia, not be part of a political movement. Also, the contradiction with WP:ZERO would make us look ridiculous. — JFG ^talk 21:37, 8 December 2017 (UTC)[reply]
support not that there'll be any consensus so I'll just put down my view for the record. jcc (tea and biscuits) 21:39, 8 December 2017 (UTC)[reply]
Hesitant. I definitely support Net Neutrality, however something like this needs particularly high participation and a particularly high level of support. I am willing to join the support *if* there is a solid viable plan and strong participation and strong support (70% is extremely borderline, preferably at least 75%). This would have to be some sort of banner, rather than "break the Wikipedia". It should almost certainly be targeted to US viewers. It would almost certainly need WMF moral-and-technical support. Given the short time frame and the non-trivial rate of opposes, I think it unlikely that this proposal will succeed. Alsee (talk) 22:45, 8 December 2017 (UTC)[reply]
Oppose People writing an encyclopedia have no business using the platform to make political statements. Chris Troutman (talk) 01:49, 9 December 2017 (UTC)[reply]
Oppose. Initially I wanted to support this, but after seeing the break the internet advocacy site, I changed my mind. Under this proposal, Wikipedia would join in the ranks of GitHub, Reddit, PornHub, and other illustrious such websites of minor importance. Meanwhile, Google, Amazon, NetFlix, and others that actually stand to lose the most appear not to be participating in this blackout. If it were that essential to their bottom line, they'd be leading the charge like they were on SOPA, etc, not some random advocacy site that has managed to ensnare a few token extreme libertarian sites. Sławomir Biały (talk) 02:09, 9 December 2017 (UTC)[reply]
Google, Amazon, Netflix do not need net neutrality, and are able to cut preferential deals with ISPs. I don't see why we should support that over the long tail of small websites who can't do that. —Kusma (t·c) 21:47, 9 December 2017 (UTC)[reply]
Support and cancel Wikipedia Zero while we're at it. James (^talk/_contribs) 09:24, 9 December 2017 (UTC)[reply]
Oppose – Wikipedia is not a vehicle to promote the political views of its editors. The project should not be taking a stance on political issues because it undermines our ability to maintain a neutral point of view for the issues we take a stance on. Additionally, there is a significant lack of clarity as to whether Wikipedia Zero is compatible with net neutrality. As our article on it mentions, it has been held to violate net neutrality in at least one jurisdiction (Chile). The broader Wikimedia movement’s relationship with net neutrality is therefore complicated, no matter how you spin it. Mz7 (talk) 11:07, 9 December 2017 (UTC)[reply]
Weak support This may have a potential effect to American Wikipedia readers and editors. The WP0 thing is a bit embarrassing, but I'd consider such an argument to be whataboutery, and not important to the current situation. !dave 20:36, 9 December 2017 (UTC)[reply]
Oppose per above JFG. If this occurs please limit it to US readers and do not disrupt the whole world's English WP for a US issue (at present). --Tom (LT) (talk) 21:29, 9 December 2017 (UTC)[reply]
Support some form of participation in protest, including protesting against Wikipedia Zero. —Kusma (t·c) 21:47, 9 December 2017 (UTC)[reply]
Support some form of protest. Enterprisey (talk!) 04:05, 10 December 2017 (UTC)[reply]
Strongest Oppose Don't disrupt Wikipedia to make a point. You have an awful lot of advanced permission editors like myself and many of you above who can a lot of damage very quickly if you annoy us. I have worked a lot on Wikipedia to keep it presentable, useful, legal, informative, etc for the people of Earth, and don't take kindly to using it as political forum. I disaprove of power tripping jerk moves like the black out and I disaprove of disrupting the entire world over net neutrality. Y'all didn't do Wikipedia against Donal Trump, or Wikipedia Against Brexit, or Wikipedia Against Racism. L3X1 (distænt write) 04:24, 10 December 2017 (UTC)[reply]
Support. To do otherwise is to surrender the Internet & its freedom of speech to corporate interests -- many of whom have an international reach. This is not just an issue local to the US. -- llywrch (talk) 05:06, 10 December 2017 (UTC)[reply]
Strongest possible oppose Wikipedia must remain neutral at all costs and not be a soapbox for random issues. There are other sites for that. 128.180.138.57 (talk) 05:33, 10 December 2017 (UTC)[reply]
Strong oppose Wikipedia must remain neutral at all cost and not join a political issue where opinion is clearly divided.If anyone wants to join they are free to do so.But do not want Wikipedia to join the protest.Pharaoh of the Wizards (talk) 17:04, 10 December 2017 (UTC)[reply]
You can't even consider opposing this. I'm sorry, but as a Wikipedia lover and someone who has large amounts of clout on several Wikia pages, I cannot oppose this. As for blackout ideas, rig an automated system so that whenever someone tries to access Wikipedia, it sends an email to the FCC telling them what bullshit this is, and then blacks out the site. Unsigned comment by MitchG74 who has made few edits outside this topic and may be ducky
Oppose. This is not an existential threat, and therefore our absolute neutrality is completely mandatory. Wikipedia will continue to exist regardless of what happens to net neutrality, and that is the determining factor for whether we can get involved. --Yair rand (talk) 22:23, 10 December 2017 (UTC)[reply]
Support Yes we should advocate for equal and fair access to information. Access to information is political. Many of us opposed the ban of Wikipedia in Turkey for example. Access to information hopefully is not a partisan issue, though it might be in some places in the world. Just because one supports Wikipedia Zero does not mean one must support no regulations on the Internet at all. Doc James (talk · contribs · email) 22:42, 10 December 2017 (UTC)[reply]
Oppose. I am as much in favor of net neutrality as the next Wikipedian, but this is a U.S. domestic political dispute, not something that Wikipedia should get involved in. Sandstein 08:24, 11 December 2017 (UTC)[reply]
Strong Support. The internet as we know it is in danger.— Preceding unsigned comment added by Kmcinnis1091 (talk • contribs) 14:49, 11 December 2017 (UTC)— Kmcinnis1091 (talk • contribs) has made few or no other edits outside this topic. [reply]
Support The very act of creating a free encyclopedia, one that is generally free from commercial goals, free from advertisements, free to access, free to redistribute, free to write about almost anything regardless of religion, government, or authoritarian control, free to consume on any device, free to see the code that makes it work - all are radical acts political in nature. Maybe not from where you are sitting. But many people who get daily value from the work of volunteer contributors have no other source of knowledge. Many contributors - themselves in less than ideal situations - do so out of no external motivation. We do it because we believe it has value to others, to our society and the world as a whole. Wikipedia won't die because we didn't invest in some new whizz-bang technology. It will die because we let it bleed slowly, to wither. A healthy editorship, a civil community, standing up for something as important as unrestricted access to the entire internet - those are the things we need now. Ckoerner (talk) 23:10, 11 December 2017 (UTC)[reply]
Support per above. We already know that there are editor WP:BIASes on Wikipedia that either degrade the quality of articles, or limit who can edit them. At the same time, the is an impoverished class in the US that may not have access to WP:ZERO. Wikimedia supports this. I believe it is the moral decision to make. Buffaboy ^talk 09:35, 12 December 2017 (UTC)[reply]

A general background note

Those asking "Well, we didn't have net neutrality protection in 2014 or before, why would this affect us now?", I suggest reading through this good history of Net Neutrality from 2015. Key is that leading into 2014, the Internet providers were looking to implement preferred lanes, the FCC issued statements that said "No you can't do that" and issued initial net neutrality rules before 2014. Verizon challenged those and won in court in early 2014, since the court ruled internet providers were not common carriers and thus not regulated by the FCC, though did agree FCC should regulate broadband networks. The 2014 FCC quickly put into place a revised ruleset for of Net Neutrality that has prevented internet providers since from favoring traffic. That 2014 ruling is what the FCC is planning to revoke next week.

So the short answer is that ever since there was discussion of favoring traffic by the Internet providers, there has been some type of net neutrality protection from the FCC to stop it, just not necessarily in its current form. The upcoming vote will be the first that that that will change and allow providers to do what they want. --Masem (t) 21:49, 7 December 2017 (UTC)[reply]

Moot point for those of us that do not want Wikipedia to ever turn political, regardless of the consequences, for this or SOPA or whatever comes next. This also assumes everyone here agrees on Net Neutrality, which unlike Free Speech, is not the case, so you would alienating editors who have a different opinion and forcing them to say something against their political philosophy or leave the community. Dennis Brown - 2¢ 19:52, 9 December 2017 (UTC)[reply]

Closing

Are we ready to close this as no consensus? It has been open for more than 24h, everybody had a chance to participate, and there is no way consensus either way could be established here.--Ymblanter (talk) 21:53, 8 December 2017 (UTC)[reply]

I think it's best to just let people talk, as long as it remains non-acrimonious (which so far it seems to be). Discussions that do not need urgent closure are typically left open for longer to allow for comments from people who edit less frequently. Yes, in this case, the calendar imposes a deadline, but we may as well let the clock run out on the thread. Oftentimes, closing conversations early is more trouble that it's worth. isaacl (talk) 05:33, 9 December 2017 (UTC)[reply]

I agree with Isaacl here. Leaving it open might be pointless insofar as changing the consensus, but it's one of those topics that people want to opine and debate, and cutting it off early might be seen negatively. Better to keep the discussion in one place, particularly as it has been very civil up to now. Dennis Brown - 2¢ 19:47, 9 December 2017 (UTC)[reply]

Should we close this soon? Today is the 12th, and any decision made after today would essentially be moot. SkyWarrior 11:33, 12 December 2017 (UTC)[reply]

Bumping. The 12th is already past for our friends on the other side of the Atlantic, and it will soon be past for us in the States as well. This should be closed as it is effectively moot now. SkyWarrior 02:43, 13 December 2017 (UTC)[reply]

Individual action

What can we do (on-wiki in particular) as individuals? Cunningham's Law applies. Tag edit summaries in some consistent way during the event? Userboxes? Organize an edit-a-thon for the day of around the topic of the internet, FCC, etc? How can the enthusiastic share ideas and participate as indivusls? Without disruption, of course. :) Ckoerner (talk) 23:16, 11 December 2017 (UTC)[reply]

Tagging edit summaries is a very big no from me, and it might be a little too late to create an official edit-a-thon, giving that the 12th is tomorrow. Userboxes are perfectly fine, however, and I think that may be the only thing we should do as individuals. SkyWarrior 00:34, 12 December 2017 (UTC)[reply]

Here's some tweet examples you can consider, with links to either the EFF action page or the foundations blog post:

—TheDJ (talk • contribs) 14:03, 13 December 2017 (UTC)[reply]

Game over:(. 17:43, 14 December 2017 (UTC)

The internet lost. Bardic Wizard (Tell your congressman to vote against net neutrality) 20:20, 14 December 2017 (UTC)[reply]

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

Require every animated image in the article to include a method to start/stop animation

Every animated image should include a method to stop/start the animation. It will be nice if it was possible to stop/resume the animation.

Animated images are supremely distracting when one is trying to read the rest of the article. Some animations are so strong that one is forced to print out the page (if feasible) just for the heck of reading it in peace.

Animated images do serve a useful purpose. This is not a proposal to abandon them. It is strictly about retaining usability of the published page.

Nor am I the only one raising this concern - see [[1]]. That discussion got sidetracked into technical minutiae. Obviously not much visible has come out of that proposal.

For an example, see https://en.wikipedia.org/wiki/Hall_effect_sensor. It is nearly impossible to focus on the content without tiring oneself out. — Preceding unsigned comment added by 50.250.203.165 (talk • contribs)

You can disable animations through your preference page. (You might consider taking this to Wikipedia:Village pump (technical) Hawkeye7 (discuss) 20:15, 7 December 2017 (UTC)[reply]

Those just disable CSS animations, not GIFs and animated PNGs —TheDJ (talk • contribs) 20:20, 7 December 2017 (UTC)[reply]

(e/c) There are tickets related to this like phab:T101644. If you want something visible, someone will have to do the work. Discussions are not enough to make something happen. Unfortunately we just had the community wishlist, which would have been a perfect opportunity to nominate this as a work item to take on this year. Maybe next year you could propose it ? —TheDJ (talk • contribs) 20:19, 7 December 2017 (UTC)[reply]

this would not seem very difficult--we do lots of fixes in addition to the ones on the wishlist, which tend to be major. And there is another approach. (I care because I am one of those who have great trouble if there is an animated image of any sort--and, if it is important, I usually need to be able to slow it down: We should have it as part of accessibility policy that we do not use automatically moving images--that every image we use has to move only if clicked on. There would still be a problem converting all those we do have, but at least there would be no more. DGG ( talk ) 04:21, 12 December 2017 (UTC)[reply]

As an editor strongly sympathetic to the breadth of visual impairments people may have to deal with, I wanted to lend some support to what DGG mentioned above. Perhaps a non-technical stopgap would just be an accessibility policy of referencing motion graphics footnote style? That'd keep them quarantined from the text, easily viewable, and wouldn't require any coding or scripting work. Jasphetamine (talk) 11:14, 14 December 2017 (UTC)[reply]

RfC: Populating article descriptions magic word

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

In late March - early April 2017, Wikipedia:Village pump (proposals)/Archive 138#Rfc: Remove description taken from Wikidata from mobile view of en-WP ended with the WMF declaring[2] "we have decided to turn the wikidata descriptions feature off for enwiki for the time being."

In September 2017, it was found that through misunderstanding or miscommunication, this feature was only turned off for one subset of cases, but remained on enwiki for other things (in some apps, search results, ...) The effect of this description is that e.g. for 2 hours this week, everyone who searched for Henry VIII of England or saw it through those apps or in "related pages" or some such got the description "obey hitler"[3] (no idea how many people actually saw this, this Good Article is viewed some 13,000 times a day and is indefinitely semi-protected here to protect against such vandalism).

The discussion about this started in Wikipedia:Village pump (policy)/Archive 137#Wikidata descriptions still used on enwiki and continued mainly on Wikipedia talk:Wikidata/2017 State of affairs (you can find the discussions in Archive 5 up to Archive 12!). In the end, the WMF agreed to create a new magic word (name to be decided), to be implemented if all goes well near the end of February 2018, which will replace the use of the Wikidata descriptions on enwiki in all cases.

We now need to decide two things. Fram (talk) 09:58, 8 December 2017 (UTC)[reply]

How will we populate the magic word with local descriptions?

Initially, copy the Wikidata descriptions by bot
With a bot, use a stripped version of the first sentence of the article (the method described by User:David Eppstein and User:Alsee in Wikipedia talk:Wikidata/2017 State of affairs/Archive 5#Wikipedia descriptions vs Wikidata descriptions)
With a bot, use information from the infobox (e.g. for people a country + occupation combination: "American singer", "Nepali politician", ...)
Start with blanks and fill in manually (for all articles, or just for BLPs)
Start with blanks, allowing to fill in manually and/or by bot (bot-filling after successful bot approval per usual procedures)
Other

Discussion on initial population

#5 – allows bot operations for larger or smaller sets of articles per criteria that don't have to be decided all at once, and manual overrides at all times. --Francis Schonken (talk) 10:28, 8 December 2017 (UTC)[reply]
#5 is my preference following the reasoning below:
Option 1, copying from Wikidata, will populate Wikipedia with a lot of really bad descriptions, which will remain until someone gets around to fixing them. My initial rough estimates are that there are more bad/nonexistent Wikidata descriptions than good ones. I strongly oppose this option unless and until someone comes up with solid data indicating that it will be a net gain.

Option 2, extracting a useful description from the first sentence or paragraph seems a nice idea at first glance, but how will it be done? Has anyone promoting this option a good idea of how effective it would be, how long it would take, and if it would on average produce better descriptions than option 1? This option should be considered unsuitable until some evidence is provided that it is reasonably practicable and will do more good than harm.

Option 3, copying from the infobox, may work for some of the articles that actually have an infobox with a useful short description, or components that can be assembled into a useful short description. This may work for a useful subset of articles, but it is not known yet how many. I would guess way less than half so not a good primary option.

Option 4, start with blanks and fill in manually, is probably the only thing that can be done for a large proportion of articles, my guess in the order of half. It will have to be done, and is probably the de facto default. It is easy, quick and will do no harm. It is totally compatible with option 5, for which it is the first step.

Option 5 is starting with option 4 and applying ad hoc local solutions which can be shown to be useful. Any harm is localised, Wikidata descriptions can be used when they are appropriate, extracts from leads can be used when appropriate, mashups from infoboxes can be used when appropriate, and manual input from people who actually know what the article is about can be used when appropriate. I think there is no better, simpler, and more practical option than this, and suggest that projects should consider how to deal with their articles. WPSCUBA already has manually entered short descriptions ready for use for more than half of its articles, which I provided as an experiment. It is fairly time consuming, but gets easier with practice. Some editors may find that this is a fun project, others will not, and there will inevitably be conflicts, which I suggest should be managed by BRD as simple content disagreements, to be discussed on talk pages and finalised by consensus. In effect, option 5 is the wiki way. It is simple and flexible, and likely to produce the best results with the least amount of damage. · · · Peter (Southwood) ^(talk): 11:26, 8 December 2017 (UTC)[reply]

(There was an edit conflict here and I chose to group all my comments together · · · Peter (Southwood) ^(talk): 11:26, 8 December 2017 (UTC))[reply]
#5. Whether a Wikidata description is suitable or not is very different across many groups of articles. It should be decided (and possibly bot populated) per group, sometimes per small group, and for that we need to start from blank descriptions.--Ymblanter (talk) 11:23, 8 December 2017 (UTC)[reply]
Start with not using it anywhere, only use it as override per situation. —TheDJ (talk • contribs) 12:09, 8 December 2017 (UTC)[reply]
TheDJ, To clarify, is this an Option 6: Other that you are proposing here? i.e. Only add the magic word to articles where the Wikidata short description is unsuitable, and use Wikidata description as default in all cases until someone finds a problem and adds a magic word, after which the short description will be taken from the magic word? If this is the case, what is your opinion on reverting to Wikidata description for any reason at a later date? · · · Peter (Southwood) ^(talk): 14:53, 8 December 2017 (UTC)[reply]
@Pbsouthwood: Correct. I have no opinions on reverting at a later moment. —TheDJ (talk • contribs) 13:42, 11 December 2017 (UTC)[reply]
#5. That doesn't deal with all the issues, but it comes closest to my views, given the choices. See also my comments at WT:Wikidata/2017 State of affairs/Archive 12 and WT:Wikidata/2017 State of affairs. - Dank (push to talk) 14:06, 8 December 2017 (UTC)[reply]
- Peter asked me for clarification. If people have specific questions, or if they want a summary of my previous posts, I'll do my best to answer. - Dank (push to talk) 15:30, 8 December 2017 (UTC)[reply]
#5 but don't wait too long to fill in where possible. Fram (talk) 14:14, 8 December 2017 (UTC)[reply]
Fram Are you recommending a massive short term drive to produce short descriptions to make the system useful? · · · Peter (Southwood) ^(talk): 15:09, 8 December 2017 (UTC)[reply]
- Yes, although this isn't in my view necessary to proceed with this, only preferable. No descriptions is better than the current situations, but decent enwiki-based descriptions is in many cases better than no descriptions. No need to throw out the baby (descriptions to be shown in search and so on) with the bathwater. Fram (talk) 15:21, 8 December 2017 (UTC)[reply]
#6 - don't use it. There has been no consensus to have this magic word in the first place - that is the question that should have been asked in this RfC (see discussion here). I personally think it is a bad idea and a waste of developer time. It's better to focus on improving the descriptions on Wikidata instead. Mike Peel (talk) 15:27, 8 December 2017 (UTC)[reply]
#6 — Find a solution that monitors and updates Wikidata descriptions — If a description is good enough for Wikipedia(ns), it should be on Wikidata. If vandalism is blocked on Wikipedia, it should be simultaneously reverted on Wikidata. Wikidata is the hub for interwiki links and a storage site for both descriptions and structured data that then are harvested by external knowledge-based search engines (think Siri, Alexa, and Google's Knowledge Graph). For interwiki purposes, we should want to ensure that short descriptions at Wikidata are accurate, facilitating other language Wikipedias when they interlink to en.wiki. For external harvesting, we should want to prevent vandalism from being propagated. The problems regarding vandalism and sourcing on Wikidata are real, but the solution is for Wikipedians and our anti-vandalism bots to be able to easily monitor and edit the relevant Wikidata material. Possible solutions would include: (a) Implementing a pending changes-like functionality for changes to descriptions on high-traffic or contentious pages; (b) Make changes to short descriptions prominently visible on Wikipedia watchlists, inside the VisualEditor, and as a preference option for Wikipedia editors; (c) Develop and implement in-Wikipedia editing of Wikidata short descriptions using some kind of click-on-this-pencil tool.--Carwil (talk) 15:46, 8 December 2017 (UTC)[reply]
- After those solutions are implemented, you are free to ask for an rfC to overturn the consensus of the previous RfC which decided not to have these descriptions. This RfC is a discussion to get solutions which give you what you want on enwiki (descriptions in VE, mobile, ...) without interfering in what Wikidata does (they are free to have their own descriptions or to import ours). Fram (talk) 16:01, 8 December 2017 (UTC)[reply]
Carwil, How do you propose that Wikipedia controls access by vandals to Wikidata? Are you suggesting that Wikipedia admins should be able to protect Wikidata items and block Wikidata users?
The easy options are… "undo" functionality for Wikidata descriptions in Wikipedia watchlists, and option (a) I proposed above, something like pending-changes that protects pages on Wikipedia from unreviewed changes from Wikidata. Transferring anti-vandalism bots from Wikipedia to Wikidata would also be helpful.--Carwil (talk) 16:47, 8 December 2017 (UTC)[reply]
Cluebot already runs on Wikidata. ChristianKl (talk) 15:19, 17 December 2017 (UTC)[reply]
Strongly oppose 4 and strongly oppose 5—Let's reject any solution that mass-blanks short descriptions: these are a functional part of mobile browsing and of the VisualEditor. As an editor and a teacher who brings students into editing Wikipedia, the latter functionality is a crucial timesaver. Wikipedia is increasingly accessed by mobile devices and short descriptions prevent clicking through to a page only to find it's not the one you are looking for.--Carwil (talk) 15:46, 8 December 2017 (UTC)[reply]
Have you analysed the overall usefulness of Wikidata descriptions and found that there are more good descriptions than bad, or found a way to find all the bad ones so they can be changed to good? If so please point to your methods and results, as they would be extremely valuable. What methods have you used to indicate the comparative harm done by bad descriptions versus the good done by good descriptions? · · · Peter (Southwood) ^(talk): 16:14, 8 December 2017 (UTC)[reply]

Yes, I have analyzed a sample here. I found that 13 of 30 had adequate descriptions (though 7 of them could be improved), 13 had no descriptions at all, 1 was incorrectly described (not vandalism), 2 were redundant with the article title (i.e., they should be overridden with a blank), and 1 represented a case where the Wikipedia article and the Wikidata entity were not identical and shouldn't share the same description. The redundant descriptions would cause no harm. Mislabelling "Administrative divisions of Bolivia" with the subheading "administrative territorial entity of Bolivia" would cause mild confusion. The legibility provided by descriptions easily outweigh the harms. (The only compelling harm is due to vandalism, which should be addressed by improving vandalism tools not forking the descriptions between the projects.)--Carwil (talk) 16:47, 8 December 2017 (UTC)[reply]

The options 4 and 5 are not to blank anything, they are to put short descriptions, which are text content, into the article they describe, where they can be properly, (or at least better), maintained, by people who may actually know what the article is about. Wikidata can use them if their terms of use allow, and if they are actually better for Wikidata's purposes, which is by no means clear at present. · · · Peter (Southwood) ^(talk): 16:14, 8 December 2017 (UTC)[reply]

Options 4 and 5 involve starting with blanks everywhere. The whole proposal assumes that we should fork a dataset describing Wikipedia articles into two independently editable versions. Forking a dataset always creates inconsistencies and reduces the visibility of problems by splitting the number of eyes to watch for problems. Better to make Wikipedians' eyes more powerful and spotting problems (which are unusual) rather than to throw up wall between the two projects. My sample suggests that 90% of the time, or more, the two projects are working towards the same goal here.--Carwil (talk) 16:47, 8 December 2017 (UTC)[reply]

They do, but it is unlikely the WMF will switch until the Wikipedia results are no worse than the Wikidata results, though I have no idea how they would measure that, since they don't seem to have much idea of the quality they will be comparing against, or if they do, are not keen on sharing it.

The dataset does not suit Wikipedia. We should not be forced to use it. A dataset that suits Wikipedia may not suit Wikidata. Should we force it on them? Two datasets means Wikipedia can look after their own, and Wikidata can use what they find useful from it, and Wikipedians are not coerced into editing a project they did not sign up for. Using shitty quality data on Wikipedia to exert pressure on Wikipedians to edit Wikidata may have a backlash that will harm either or both projects, not a risk I would be willing to take, if it could affect my employment, unless of course I was being paid to damage the WMF, but that would be conspiracy theory, and frankly I think it unlikely.

I also did a bit of a survey, my results do not agree with yours, and they are also from such a small sample as to be statistically unreliable. I also wrote short descriptions for about 600 articles in WPSCUBA, but did not keep records. Most (more than half) articles needed a new description as the Wikidata one either did nor exist or was inappropriate. There were some which were perfectly adequate, but less than half of the ones that actually existed, from memory. It would be possible to go back and count, but I think it would be a better use of my time to do new ones, if anyone is willing to join such a project. Maybe Wikiproject Medicine, or Biography, where quality actually may have real life consequences, but I don't usually work much in those fields and hesitate to move into them without some project participation. I have already run into occasional unfriendly reactions where projects overlap, but fortunately very few. · · · Peter (Southwood) ^(talk): 18:18, 8 December 2017 (UTC)[reply]

@Pbsouthwood: I don't think there's much daylight between Wikipedia's purpose for these descriptions (which hasn't been written yet), the value of them for the mobile app, the value of them for the VisualEditor (as disambiguators for making links), and the value for Wikidata as discussed here. There, the requirements include: "a short phrase designed to disambiguate items with the same or similar labels"; avoiding POV, bias, promotion, and controversial claims; and avoiding "information that is likely to change." Only the last one seems likely to differ from the ideal Wikipedia description and only marginally: e.g., "current president of the United States" would have to be replaced with "45th president of the United States."--Carwil (talk) 22:11, 12 December 2017 (UTC)[reply]
There have been extensive discussions between community and WMF on the description issue. I wish this RFC had gone through a draft stage before posting. There may be other options or issues that may need to be sorted out, potentially affecting the outcome here. A followup RFC might be needed.
The previous RFC[4] consensus was clearly to eliminate wikidata-descriptions, and that is definitely my position. An alternate option would be to skip creating a description-keyword at all, and just take the description from the lead sentence. That has the benefits of (1) ensuring all articles automatically have descriptions (2) avoiding any work to create and maintenance on descriptions and (3) it would avoid creating a new independent independent issue of description-vandalism. The downside is that the lead sentence doesn't always make for a great short description.
If we go with a new description keyword, #5 #2 and #1 are all reasonable. (#3 and #4 are basically redundant to bot approval in #5). However as I note in the question below, #5 can be implemented with a temporary wikidata-default. This gives us time to start filling in local-descriptions before the wikidata-descriptions are shut off. This would avoid abruptly blanking descriptions. Alsee (talk) 21:49, 8 December 2017 (UTC)[reply]
#2, with #5 as a second preference. The autogenerated descriptions look like they're good enough for most purposes. Sandstein 16:14, 10 December 2017 (UTC)[reply]
Sandstein, How big was your test sample, and how were the examples chosen? · · · Peter (Southwood) ^(talk): 16:36, 10 December 2017 (UTC)[reply]
5. Mass-importing WD content defeats the purpose of getting rid of WD descriptions. James (^talk/_contribs) 16:30, 11 December 2017 (UTC)[reply]
Only true for a limited period until someone gets round to changing them where necessary. If the problem is big enough, there will be bot runs to do fixes, so over a medium term it does not make much difference as once the descriptions are in Wikipedia we can fix them as fast as we can make arrangements to do so and will no longer be handicapped by WP:ICANTHEARTHAT obfuscations from WMF. The important part is to get them where we have the control so we can start work getting them right. · · · Peter (Southwood) ^(talk): 07:47, 13 December 2017 (UTC)[reply]

I don't understand any of this. Could someone please explain this to me? Hydra Tacoz (talk) 21:49, 18 December 2017 (UTC)[reply]

@Hydra Tacoz: Some uses of Wikiepdia have short descriptions of articles (e.g. in the Wikipedia app or for search engines). Where and how we get or store this info is what is being discussed. A logical place to keep it is Wikidata but there are some problems with that. ―Justin (koavf)❤T☮C☺M☯ 21:55, 18 December 2017 (UTC)[reply]

@Koavf|Justin Thank you! So, how is the Wikidata a safe place? What exactly is the Wikidata? Hydra Tacoz (talk) 22:04, 18 December 2017 (UTC)[reply]

What to do with blanks

What should we do when there is no magic word, or the magic word has no value?

Show the Wikidata description instead
Show no description
Show no description for a predefined list of cases (lists, disambiguation pages, ...) and the Wikidata one otherwise (this is the solution advocated by User:DannyH (WMF) at the moment)
Other

Discussion on blanks

#2 – comes closest to having no description per initial aborted RfC; those who want them can write them, or fill in automatically (per usual bot approval procedures). --Francis Schonken (talk) 10:28, 8 December 2017 (UTC)[reply]
#2 The Wikidata description should not be allowed as a default where there is no useful purpose to be served by a short description. An empty parameter to the magic word must be respected as a Wikipedia editorial decision that no short description is wanted. This decision can always be discussed on the talk page. Under no circumstances should WMF force an unwanted short description from Wikidata as a default. Nothing stops anyone from manually adding a description which is also used by Wikidata, but that is a personal decision of the editor and they take personal responsibility as for any other edit. Automatically providing no description for a predefined list of classes has problems, in that those classes may not be as easily defined as some people might like to think. For example, most list articles don't need a short description, but some do. The same may be true for disambiguation pages. Leaving them blank as the first stage and not displaying a short description until a (hopefully competent) editor has added one is easy to manage for the edge cases, and may be managed by other methods per option 5 of population. It is flexible and can deal with all possibilities. There is no need to make it more complicated and liable to break some time. Ideally the magic word could be given a comment in place of a parameter where an explanation of why there should not be a short description would be useful. In this case the comment should not be displayed and is there to inform editors who might wonder if it had been missed. · · · Peter (Southwood) ^(talk): 11:43, 8 December 2017 (UTC)[reply]
#1 - Show the wikidata description in stead. —TheDJ (talk • contribs) 12:10, 8 December 2017 (UTC)[reply]
#2. No magic word (and magic word with no parameter) should result in no description, not some non-enwiki data being confusingly shown to readers (while being missed by most vandalism patrollers apparently). Today, for 8 hours, we had this blatant BLP violation on a page with 10,000 pageviews per day. Using these descriptions by default (or at all) is a bad idea, and was rejected at the previous RfC. Fram (talk) 14:21, 8 December 2017 (UTC)[reply]

#1 - From the WMF: We're proposing using Wikidata as the fallback default if there isn't a defined magic word on Wikipedia, because short descriptions are useful for readers (on the app in search results, in the top read module, at the top of article pages) and for editors (in the Visual Editor link dialog). For example: in the top read module from September pictured here, 3 of the 5 top articles benefit from having a short description -- I don't know who Gennady Golovkin and Canelo Álvarez are, and having them described as "Kazakhstani boxer" and "Mexican boxer" tells me whether I'm going to be interested in clicking on those. (The answer on that is no, I'm not really a boxing guy.) I know that Mother! is a 2017 film, but I'm sure there are lots of people who would find that article title completely baffling without the description. Clicking through to the full list of top read articles, there are a lot of names that people wouldn't know -- Amber Tamblyn, Arjan Singh, Goran Dragić. This is a really popular feature on the apps, and it would be next to useless without the descriptions.

We want to create the magic word, so that Wikipedia editors have editorial control over the descriptions, which they should. But if the magic word is left blank on Wikipedia -- especially in the cases where Wikipedia editors haven't written a description yet -- then for the vast majority of cases, showing the description from Wikidata is better than not showing anything at all. As a reader looking at that top read module, I want to know who Gennady Golovkin is, and the module should say "Kazakhstani boxer," whether that text comes from Wikipedia or Wikidata.

I know that a big reason why people are concerned about showing the Wikidata descriptions is that the Wikidata community may sometimes be slower than the Wikipedia community to pick up on specific examples of vandalism. The example that Fram cites of Henry VIII of England showing "obey hitler" for two hours is disappointing and frustrating. However, I think that the best solution there should be to improve the community's ability to monitor the short descriptions, so that vandalism or mistakes can be spotted and reverted more quickly. The Wikidata team has been working on providing more granular display in watchlists on Wikipedia, so that Wikipedia editors can see edits to the descriptions for the articles that they're watching, without getting buried by other irrelevant edits made to that Wikidata item. That work is being tracked in this Phabricator ticket -- phab:T90436 -- but I'm not sure what the current status is. Ping for User:Lydia Pintscher (WMDE) -- do you know how this is progressing?

We've talked in the previous discussions about types of pages where the Wikidata descriptions aren't useful for article display, because they're describing the page itself, rather than the subject of the article. The examples that I know right now are category pages (currently "Wikimedia category page"), disambiguation pages ("Wikimedia disambiguation page"), list pages, and the main page. Those may be helpful in the case of the VE link dialog, especially "disambiguation page", but there's no reason to display those at the top of the article page, where they look redundant and kind of silly. We're proposing that we just filter those out of the article page display, and anywhere else where they're unnecessary. I'd like to know more examples of pages where short descriptions aren't useful, if people know any.

For article pages, I don't know of any examples so far where a blank description would be better for the people who need them (people reading, searching or adding links on VE). If we're going to build the "show a blank description" feature, then we need to talk about specific use cases where that would be the best outcome. That's how product development works -- you don't build a feature, if you don't have any examples for where it would be useful. If people have specific examples, then that would help a lot. -- DannyH (WMF) (talk) 14:58, 8 December 2017 (UTC)[reply]

"For article pages, I don't know of any examples so far where a blank description would be better " Check the two examples of vandalism on pages with 10K+ pageviews per day I gave in this very discussion, including one very blatant BLP violation which lasted for 8 hours today. In these examples, a blank description would have been far preferable over the vandalized one, no? Both articles, by the way, are semi-protected here, so that vandalism couldn't have done by the IPs here (and would very likely have been caught much earlier). "specific use cases where that would be the best outcome." = all articles, and certainly BLPs. Fram (talk) 15:19, 8 December 2017 (UTC)[reply]

If you want another example of where no description would be preferable over the Wikidata one, look to the right. This is what people who search for WWII (or have it in "related articles", the mobile app, ... see right now and have seen since more than 5 hours (it will undoubtedly soon be reverted now that I have posted this here). This kind of thing happens every day, and way too often on some of our most-viewed pages. Fram (talk) 15:38, 8 December 2017 (UTC)[reply]

I agree that the vandalism response rate on Wikidata is sometimes too slow. I think the solution to that is to make that response rate better, by making it easier for Wikipedia editors to monitor and fix vandalism of the descriptions. I disagree that the best solution is to pre-emptively blank descriptions because we know that there's a possibility that they'll be vandalized. I'm asking for specific examples where editors would make the choice to not show a description on the article page, because a blank description is better than the majority of good-to-adequate descriptions already on Wikidata. -- DannyH (WMF) (talk) 16:10, 8 December 2017 (UTC)[reply]

And I am saying that this is a red herring. Firstly, you claim that there exists a majority of good-to adequate descriptions on Wikidata, without any convincing evidence that this is the case. I am stating that out of several hundred short descriptions that I produced, there were a non-zero number of cases where a short description made no apparent improvement over the article title by itself. · · · Peter (Southwood) ^(talk): 16:21, 8 December 2017 (UTC)[reply]

DannyH (WMF), Filtering descriptions out of the article page view means that they will be invisible for maintenance which is very bad, unless they are filtered out based on content, not on page type, which may be technically problematic - you tell me, I don't write filter code. Can you guarantee that no vandalism can sneak through by this route?. As long as they are visible anywhere in association with the Wikipedia article they are a Wikipedia editorial issue. · · · Peter (Southwood) ^(talk): 15:39, 8 December 2017 (UTC)[reply]

We are not asking for a development feature to leave out descriptions that don't exist, it is the simplest possible default. Please try to accept that simply displaying whatever content is in the magic word parameter is the simplest and most versatile solution, and that if we leave it blank that is because we prefer it to be left blank. If anyone prefers to have a short description in any of these cases, they can edit Wikipedia to put in the one they think is right, and if anyone disagrees strongly enough to want to remove it, they can follow standard procedure for editorial disagreement, which is get consensus on the talk page. It is not rocket science, it is the Wikipedia way of doing these things. If it is difficult for the magic word to handle a comment in the parameter we can simply put the comment outside. There may be a few more cases where people will fail to notice that it is there, but probably not a train smash. Is there any reason why a comment in the parameter space should not be parsed as equivalent to no description? I have asked this before, and am still waiting for an answer.· · · Peter (Southwood) ^(talk): 15:39, 8 December 2017 (UTC)[reply]

#1 - and focus on improving the descriptions on Wikidata. Mike Peel (talk) 15:27, 8 December 2017 (UTC)[reply]
- See discussion at Wikipedia_talk:Wikidata/2017_State_of_affairs#Circular_"sourcing"_on_Wikidata - I've posted a random sample of 1,000 articles and descriptions, of which only 1 description had a typo and none seemed to be blatently wrong - although 39% don't yet have a description. So let's add those extra descriptions / improve the existing ones, rather that forking the system. Thanks. Mike Peel (talk) 00:14, 12 December 2017 (UTC)[reply]
  - That sample includes the many typical descriptions which are right on Wikidata and useless (or at least very unclear) for the average enwiki reader: "Wikimedia disambiguation page" (what is Wikimedia, shouldn't that be Wikipedia, and even then, I know I'm on Wikipedia, and we don't use "Wikipedia article" as description for standard articles either...) There are also further typos ("British Slavation Army officer"), useless descriptions ("human settlement", can we be slightly more precise please), redundant ones (Shine On (Ralph Stanley album) - "album by Ralph Stanley")... And the basic issue, that language-based issues shouldn't be maintained at Wikidata but at the specific languages, is not "forking", it is taking back content which doesn't belong at Wikidata but at enwiki. Fram (talk) 05:45, 12 December 2017 (UTC)[reply]
- You may add "Descriptions not in English" to the problems list from that sample: "Engels; schilder; 1919; Londen (Engeland); 1984". Fram (talk) 06:01, 12 December 2017 (UTC)[reply]
- And "determined sex of an animal or plant. Use Q6581097 for a male human" is not really suitable for use on enwiki either (but presumably perfect for Wikidata). Neeraj Grover murder case - "TV Executive" seems like the wrong description as well. Stefan Terzić - "Team handball" could also use some improvement. Fram (talk) 07:56, 12 December 2017 (UTC)[reply]
  - OK, so maybe 4/1000 have typos/aren't in English/are wrong - that's still not bad. Most of the rest seems to be WP:IDONTLIKEIT (where I'd say WP:SOFIXIT on Wikidata, but you don't want to do that). Yes, it is forking - the descriptions currently only exist on Wikidata (we've never had them on Wikipedia), and they aren't going away because of this - so you want to fork them, and in a way that means the two systems can't later be unforked (due to licensing issues). That's not helpful, particularly in the long term. Mike Peel (talk) 19:58, 12 December 2017 (UTC)[reply]
    - I gave more than 4 examples, some 40% don't have a description (so can hardly be wrong, even if many of those need a description), and many have descriptions we can't or shouldn't use. Basically, you started with 0.1% problem in your view, when it is closer to 50% in reality. Please indicate which licensing issues you see which would make unforking impossible. It seems that these non-issues would then also make it impossible to import the Wikidata descriptions, no? Seems like a red herring to me. By the way, have you ever complained about forking when Wikidata was populated with millions of items from enwiki (and other languages), where from then on they might evolve separately? Or is forking only an issue when it is done from Wikidata to enwiki, and not the reverse? Fram (talk) 22:28, 12 December 2017 (UTC)[reply]
      - Only a few of your example problems seem to be actual problems, the rest are subjective. You're proposing that we switch to 100% without description, so I can't see how you can argue about the 40% blank descriptions (and they weren't a problem at the start of this discussion). I'm not saying 0.1%, but ~1% seems reasonable here. Enwp descriptions are CC-BY-SA licensed, which means they can't be simply copied to Wikidata as that has a CC-0 license (and yes, this isn't great, and copyrighting the simple descriptions doesn't make any sense, but it is what it is) - although that means that we can still copy from Wikidata to here if needed. I'm complaining that we're forking things here to do the same task (describing topics), and that we're trying to do so using the wrong tool (free text with hacks) rather than a better tool (a structured database). Mike Peel (talk) 23:01, 12 December 2017 (UTC)[reply]
        Ah, the old "structured database" vs "free text with hacks" claim, I wondered why it wasn't mentioned yet. In Wikidata, you are putting free text in aa database field, which then at runtime gets read and displayed. In enwiki, you are putting free text in a "magic word" template, which then at runtime gets read and displayed. Pretending that the descriptions in Wikidata aren't free text and in enwiki are free text is not really convincing. However, what is the wrong tool for the task is Wikidata, as that is not part of the enwiki page history and wikitext, and thus can't be adequately monitored, protected, ... The only "hack" is the current one, using Wikidata to do something enwiki can do better (and which philosophically also belongs on enwiki, as it is language-based text, not some universally accepted value). Fram (talk) 07:53, 13 December 2017 (UTC)[reply]
#2, or transition from #1 to #2. I have engaged significant discussions with the WMF on the descriptions-issue on the Wikidata/2017 State of affairs talk page. The WMF has valid concerns about abruptly blanking descriptions, and we should try to cooperate on those concerns. Temporarily letting a blank keyword default to wikidata (#1) will give us time to begin filling empty local descriptions before shutting off wikidata descriptions (#2). But in the long run my position is definitely #2. Alsee (talk) 21:02, 8 December 2017 (UTC)[reply]
This could work. While we are filling in short descriptions, whenever we find an article that should not have a short description, we could put in a non-breaking space to override an unnecessary Wikidata description. We will need to see the actual display shown on mobile on desktop too, so we can see what we are doing. As long as there is a display of the short description in actual use on desktop, it might be unnecessary to switch. That would reduce the pressure to rush the process, which may be a good thing, but also may not. · · · Peter (Southwood) ^(talk): 10:12, 9 December 2017 (UTC)[reply]

Alsee, thanks. I've been staying out of conversations about if/when/how the magic word gets used/populated, because I think those are the content decisions that need to be made by the English WP community. I want to figure out how we can get to the place where Wikipedia editors have proper editorial control over the short descriptions, without hurting the experience of the readers and editors who are using those descriptions now. -- DannyH (WMF) (talk) 23:29, 11 December 2017 (UTC)[reply]

You can enable a view of the Q-code, short description and alias via this script: [[5]].--Carwil (talk) 13:01, 9 December 2017 (UTC)[reply]

Carwil, This is exactly the kind of display I had in mind. It is easily visible, but obviously not part of the article per se, as it is displayed with other metadata in a different text size. To be useful it would have to be visible to all editors who might make improvements to poor quality descriptions, so would have to be a default display on desktop. This may not be well received by all, but it would be useful, maybe as an opt-out for those who really do not want to know. It still does not deal with the inherent problems of having the description on Wikidata, in that it is not Wikipedia and we do not dictate Wikidata's content policies, control their page protection, block their vandals etc, but it does let us see what is there, and fixing is actually quite easy, though maybe I am biased as I have done a fair amount of work on Wikidata. I would be interested to hear the opinions of people who have not previously edited Wikidata on using this script. I can definitely recommend it to anyone who wants to monitor the Wikidata description. Kudos to Yair rand.· · · Peter (Southwood) ^(talk): 16:15, 9 December 2017 (UTC)[reply]

It also does not solve the problem of different needs for the description. When the Wikidata description is unsuitable for Wikipedia, we should not arbitrarily change it if it is well suited to Wikidata's purposes, but if it is going to be used for Wikipedia, we may have to do just that.· · · Peter (Southwood) ^(talk): 16:21, 9 December 2017 (UTC)[reply]

#2. Any Wikidata import should be avoided because that content is not subject to Wikipedia editorial control and consensus. Sandstein 16:16, 10 December 2017 (UTC)[reply]
Sandstein, My personal preference is that eventually all short descriptions should be part of Wikipedia, and not imported in run time, however, as an interim measure, to get things moving more quickly, I see some value in initially displaying the Wikidata description as a default for a blank magic word parameter, as it is no worse than what WMF are already doing, and in my opinion are likely to continue doing until they think the Wikipedia local descriptions are better on average. If anyone finds a Wikidata description on display that is unsuitable, all they have to do is insert a better one in the magic word and it immediately becomes a part of Wikipedia. If you find a Wikidata description that is good, you can also insert it into the magic word and make it local, as they are necessarily CC0 licensed. The only limitation on getting 100% local content is how much effort we as Wikipedians are prepared to put into it. Supporters of Wikidata can improve descriptions on Wikidata instead if that is what they prefer to do, and as long as a good short description is displayed, it may happen that nobody feels strongly enough to stop allowing it to be used. I predict that whenever a vandalised description is spotted, most Wikipedians will provide a local short description, so anyone in favour of using Wikidata descriptions would be encouraged to work out how to reduce vandalism and get it fixed faster, which will greatly improve Wikidata. Everybody wins, maybe not as much as either side would prefer, but more than they might otherwise. As it would happen, WMF win the most, but annoying as that may be to some, we can live with it as long as we also have a net gain for Wikipedia and Wikidata. · · · Peter (Southwood) ^(talk): 16:58, 10 December 2017 (UTC)[reply]
2. We have neither the responsibility nor the authority to enforce WP guidelines on a project with diametrically opposed policies. Content outside of WP's editorial control should not appear on our pages, period. James (^talk/_contribs) 16:34, 11 December 2017 (UTC)[reply]
2 comes closest to my views, given the choices. See my comments at WT:Wikidata/2017 State of affairs/Archive 12 and WT:Wikidata/2017 State of affairs. Also see the RfC from March; most of what was said there is equally relevant to the current question. - Dank (push to talk) 21:01, 11 December 2017 (UTC)[reply]
Comment from WMF: I want to say a word about compromise and consensus. I've been involved in these discussions for almost three months now, and there are a few things that I've been consistent about.

First is that I recognize and agree that the existing feature doesn't allow Wikipedia editors to have editorial control over the descriptions, and it's too difficult for Wikipedia editors to see the existing descriptions, monitor changes, and fix problems when they arise. Those are problems that need to be fixed, by the WMF product team and/or the Wikidata team.

Second: the way that we fix this problem doesn't involve us making the editorial decisions about the format or the content. That's up to the English Wikipedia and Wikidata communities, and if there's disagreement between people in those communities, then ultimate control should be located on Wikipedia and not on Wikidata. In other words: when we build the magic word, we're not going to control how it's used, how often, or what the format should be. I think that both of these two points are in line with what most of the people here are saying.

The third thing is that we're not going to agree to a course of action that results in the mass blanking of existing descriptions, for any meaningful length of time. I recognize that that's something that most of the people here want us to build, but that would be harmful to the readers and editors that use those descriptions, and that matters. This solution needs to have consensus with us, too, because we're the ones who are going to build it. I'm not saying that we're going to ignore the consensus of this discussion; I'm saying that we need to be a part of that consensus. -- DannyH (WMF) (talk) 15:13, 12 December 2017 (UTC)[reply]

How many people have actually complained in the 8 months or so that descriptions have now been disabled in mobile view? "readers and editors that use those descriptions": which editors would that be? Anyway, basically you are not going to interfere in content decisions, unless you don't like the result. But at the same time you can't be bothered to provide the necessary tools to patrol and control your features (and your first point is rather moot when this magic word goes live and works as requested anyway). Which is the same thing you did (personally and as WMF) with Flow, Gather, ... which then didn't get changed, improved, gradually accepted, but simply shot down in flames, at the same time creating lots of unnecessary friction and bad blood. Have you actually learned anything from those debacles? Most people here actually want to have descriptions, and these will be filled quite rapidly (likely to a higher percentage than what is provided now at Wikidata). But we will fill them where necessary, and we will leave them blank where we want them to be blank. You could have suggested over the past few months a compromise, where either "no magic word" or "magic word with no description" would mean "take the wikidata description", and the other meant "no description". You could have suggested "after the magic word is installed, we'll take a transitional period of three months, to see if the descriptions get populated here on enwiki; afterwards we'll disable the "fetch desc from wikidata" completely". Instead you insisted that the WMF would have the final say and would not allow blanks unless it was for a WMF-preapproved list of articles (or article groups). Why? No idea. If the WMF is so bothered that readers should get descriptions no matter what (even if many, many articles don't have Wikidata descriptions anyway in the first place), then they should hire and pay some people to monitor these and make sure that e.g. blatant BLP violations don't remain for hours or days. But forcing us to display non-enwiki content against our will and without providing any serious help in patrolling it is just not acceptable. Fram (talk) 15:44, 12 December 2017 (UTC)[reply]

Fram, those compromises are what I'm asking for us to discuss. I'm glad you're bringing them up, that's a conversation that we can have. I'm going to be talking to the Wikidata team next week about the progress on building the patrolling and moderation tools. We don't have direct control over what the Wikidata team chooses to do, but I want to talk with them about how the continued lack of a way to effectively monitor the short descriptions is affecting this conversation, this community, and the feature as a whole. English Wikipedia editors need to have the tools to effectively populate and monitor the descriptions, and you need to have that on a timeline that makes sense. I need to talk to more people, and keep working on how to make that happen. I'm going to talk with people internally about the transitional period that you're suggesting. -- DannyH (WMF) (talk) 16:04, 12 December 2017 (UTC)[reply]

I think the major concern is the lack of control over enwp content. There are currently only two outside sources of enwp content over which the local community has no control: Commons and Wikidata; it has taken some years for Commons to build a level of trust over their content policies and failsafes to prevent abuse at enwp through Commons. The only reason today that the use of Commons materials here is two-fold 1) they've proven they can handle their business, and 2) there exists local over-rides that are transparent and easy to enact. For Wikidata to be useful and to avoid the kind of acrimony we are seeing here, we would need the SAME thing from Wikidata. Point 1) can only occur over time, and Wikidata is far too new to be proven in that direction. Recent gaffes in allowing vandalism off-site at Wikidata to perpetuate at enwp does not help either. If the enwp community is going to feel good about allowing Wikidata to be useful going forward, until that trust reaches what Commons has achieved, we need point 2 more than anything. Defaulting to local control over off-site control is necessary, and any top-down policy that removes local control, either directly or as a fait accompli by subtling controlling the technology, is unlikely to be workable. If Wikidata can prove their ability to take care of their own business reliably over many years, the local community would feel better about handing some of that local control over to them, as works with Commons now. But that cannot happen today, and it cannot happen if local overrides are not simple, robust, and the default. --Jayron 32 17:32, 12 December 2017 (UTC)[reply]

"English Wikipedia editors need to have the tools to effectively populate and monitor the descriptions, and you need to have that on a timeline that makes sense." You know, yiou have lost months doing this by continually stalling the discussions and "misinterpreting" comments (always in the same direction, which is strange for real misunderstandings and looks like wilful obstruction instead). You just give us the magic word, and then we have the tools to monitor the descriptions: recent changes, watchlists, page histories, ... plus tools like semi- or full protection and the like. We can even build filters to check for these changes specifically. We can build bots to populate them. From the very start, everyone or nearly everyone who was discussing these things with you has suggested or stated these things, you were the only one (or nearly the only one) creating obstacles and finding issues with these solutions where none existed. "I'm going to be talking to the Wikidata team next week about the progress on building the patrolling and moderation tools." is totally and utterly irrelevant for this discussion, even though it is something that is sorely needed in general. Patrolling and moderating Wikidata descriptions is something we are not going to do; we will patrol and moderate ENWIKI descriptions, and we have the tools to do so (a conversation may be needed whether the descriptions will be shown in the desktop version or not, this could best be a user preference, but that is not what you mean). Please stop fighting lost battles and get on with what is actually decided and needed instead. Fram (talk) 17:54, 12 December 2017 (UTC)[reply]

I'm talking to several different groups right now -- the community here, the WMF product team, and the Wikidata team -- and I'm trying to get all those groups to a compromise that gives Wikipedia editors the control over these descriptions that you need, and doesn't result in mass blanking of descriptions for a meaningful amount of time. That's a process that takes time, and I'm still working with each of those groups. I know that there isn't much of a reason for you to believe or trust me on this. I'm just saying that's what I'm doing. -- DannyH (WMF) (talk) 18:02, 12 December 2017 (UTC)[reply]

Indeed, I don't. I'm interested to hear why you would need to talk to the Wikidata team to find a compromise about something which won't affect the Wikidata team one bit, unless you still aren't planning on implementing the agreed upon solution and let enwiki decide how to deal with it. Fram (talk) 22:28, 12 December 2017 (UTC)[reply]

Fram, you're saying "us", "we", etc. here rather freely. Please do not speak for all editors here, particularly when putting your own views forward at the same time. There's a reason we have RfC's... Thanks. Mike Peel (talk) 21:11, 12 December 2017 (UTC)[reply]

Don't worry, I'm not speaking for you. But we (enwiki) had an RfC on this already, and it's the consensus from there (and what is currently the consensus at this RfC) I'm defending. There's indeed a reason we have RfC's, and some of us respect the results of those. Fram (talk) 22:28, 12 December 2017 (UTC)[reply]

I'm glad you're not speaking for me - but why are you trying to speak for everyone except for me? What consensus are you talking about, this RfC is still running (although I'm worried that potential participants are being scared off by these arguments in the !vote sections)? And what consensuses are you accusing me of disrespecting? Mike Peel (talk) 22:40, 12 December 2017 (UTC)[reply]

FWIW, Fram definitely speaks for me. James (^talk/_contribs) 23:24, 12 December 2017 (UTC)[reply]

You don't really seem to care about the results of the previous RfC on this, just like you didn't respect the result of the WHS RfC when your solution was not to revert to non-Wikidata versions, but to bot-move the template uses to a /Wikidata subpage which was identical to the rejected template. Basically, when you have to choose between defending Wikidata use on enwiki or respecting RfCs, you go with the former more than the latter. Fram (talk) 07:53, 13 December 2017 (UTC)[reply]

ok... I propose that from this point on, DannyH, User:Mike Peel and User:Fram, cease any further participation in this RfC. You three and your mutual disagreements are again completely dominating the discussion, the exact thing that the Arbcom case was warning against. This is NOT helping the result of this discussion. —TheDJ (talk • contribs) 14:24, 13 December 2017 (UTC)[reply]

#3 – This makes the most sense to me for reasons I stated above. I would amend #3 only by saying: Immediately populate a local description for any pages being actively protected from vandalism which could just mean protected pages, or could mean (where appropriate) pages subjected to arbitration enforcement as well.--Carwil (talk) 18:02, 13 December 2017 (UTC)[reply]
#1 This whole idea is just adding complexity over a rather small problem. The less duplication on the datas, the better. We should focus on ways to follow more project add glance and focus on better tools to follow change on Wikipedia rather than splitting the Wikimedian forces on all the different project. Co-operation and sharing are the essence of these projects, not control, defiance and data duplication. TomT0m (talk) 16:34, 15 December 2017 (UTC)[reply]
#1 per DannyH. Additionally, we can configure protected articles to never display data from Wikidata. It's worth noting that this option allows you to run a bot that puts " " as description for a specific class of articles when you don't like the kind of descriptions that Wikidata shows for those articles. ChristianKl (talk) 15:29, 17 December 2017 (UTC)[reply]
For clarification, Is your claim that we can configure protected articles to never display data from Wikidata based on knowing how this could be done, and that it is a reasonably easy thing to do, or a conjecture? Bear in mind how WMF is using the data on the mobile display. I ask because I do not know how they do it, so cannot predict how easy or otherwise it would be to block from Wikipedia side. Ordinary logic suggests that it may not be so easy, or it would already have been done. · · · Peter (Southwood) ^(talk): 04:44, 18 December 2017 (UTC)[reply]
Without the magic keyword being active, it's not possible to easily prevent the import. However, once the feature is implemented you will be able to run a bot quite easily that creates "magic keyword = ' '" for every article that's protected or for other classes of articles where there's the belief that the class of article shouldn't import Wikidata and is better of with showing the user a ' ' instead of the Wikidata description.

Additionally, I think the WMF should hardcode a limitation that once a Wikipedia semiprotects an article the article stops displaying Wikidata derived information. That would take some work on the WMF, but if that's what they have to do to get a compromise I think they would be happy to provide that guarantee. ChristianKl (talk) 12:31, 18 December 2017 (UTC)[reply]
I would be both encouraged and a bit surprised to see WMF provide a guarantee. So far they have been very careful to avoid making any commitments to anything we have requested. I will believe it when I see it. I have no personal knowledge of the complexity of coding a filter that checks whether the article is protected or semi-protected and using that to control whether a Wikidata description is used that is fast and efficient enough to run every time that a short description may be displayed. but I would guess that this is an additional overhead that WMF would prefer to avoid. Requiring such additional software could also delay getting the magic word implemented, which would be a major step in the wrong direction. This needs to be simple and efficient, so the bugs will be minimised and speed maximised. Putting in a blank string parameter that displays as a blank string is easy and simple and requires no complicated extra coding. This can be done by any admin protecting an article where there is no local short description. · · · Peter (Southwood) ^(talk): 16:33, 18 December 2017 (UTC)[reply]
#1 Most of the time, for most purposes, the Wikidata descriptions are fine. #1 gives a sensible over-ride mechanism for cases where there is particular sensitivity. Jheald (talk) 20:55, 17 December 2017 (UTC)[reply]
Unless you have a reasonably robust analysis to base this prediction on, it is speculation. However it will make little difference in the long run, as it will be easy to override the Wikidata descriptions through the magic word. It is just a question of how tedious it would be, depending on what proportion of 5.5 million will have to be done.· · · Peter (Southwood) ^(talk): 04:44, 18 December 2017 (UTC)[reply]

Separate hidden categories into "tracking" and "maintenance" categories

Hello, I think that on pages the Category:Hidden categories should be separated and broken down into two groups – tracking categories (for items that need no editor input, like Category:Articles with hAudio microformats or Category:Wikipedia articles with VIAF identifiers) and maintenance categories (for items that need fixing, like Category:Unknown parameters or Category:All BLP articles lacking sources).

Right now all hidden categories are lumped into one batch on pages and it is hard to see if there are issues that were flagged, or if the categories are just there for the sake of being there. For example, hidden categories on Valdas Adamkus look like this:

Among the 12 categories, 11 are tracking and 1 is the maintenance. This category (Category:Wikipedia articles needing clarification from January 2011) gets lost in the visual clutter of stuff that needs no attention from an editor. It would be very helpful if the maintenance categories were separated out in their own basket so that any flagged issues could be seen in a few seconds, instead of parsing thru numerous irrelevant categories.

The change would require a tweak to the Mediawiki software, and I have no clue how that works, but I don't image it would be too difficult of a change. Renata (talk) 17:37, 9 December 2017 (UTC)[reply]

More difficult than you seem to think: the software would have to be changed to have additional magic words to replace __HIDDENCAT__; various places that check the resulting page property would have to be updated to check the new page properties too (not just the bit that actually does the category display), some in non-trivial ways to avoid duplicated entries if something has more than one of these new magic words on it; and then everything on the wiki that uses that magic word would have to be changed to use the new magic words. Anomie ⚔ 16:41, 10 December 2017 (UTC)[reply]

Comment There are maintenance categories that aren't hidden. This very page is categorized in Category:Wikipedia proposals, for example. How would that be addressed? Brightgalrs (/braɪtˈɡæl.ərˌɛs/)^[1] 21:28, 11 December 2017 (UTC)[reply]

IMDb character

Hi everyone. I've just proposed this theme on the IMDb character template talk. I'll do a summary: the section of characters on IMDb doesn't exit yet, but it can be recovered using Web Archive. What shall we do? Please, I prefer those who read this proposal, answer here, so it's easier to following the discussion. Thanks. Labordeta (talk) 12:01, 11 December 2017 (UTC)[reply]

Medical template may be needed

My proposal is as follows. If a person has recently died, a tag going at the top of the article on that person may appear (this is currently the case with the article on Keith Chegwin). If a country is in the news, a tag may be put at the top of the article on that country - this was the case with the article on Zimbabwe at the time Mugabe was forced to resign. There are sometimes medical stories which head the news, such as tonight (December 11 2017), when there was a report on research into Huntington's disease. This action of providing templates could go to top articles on medical conditions, so that people know that changes to the article may not reflect the most recent research findings. Vorbee (talk) 18:15, 11 December 2017 (UTC)[reply]

Existing current event templates are listed here: Wikipedia:Current event templates. Maybe bring this up on Wikiproject Medicine and see what they have to say. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)^[1] 21:57, 11 December 2017 (UTC)[reply]

Skool vacations

Not a whisper of support for the well-intentioned proposal, and opposition from 9 editors, including some of our most esteemed (wear that if you like), including both anecdotal and hard evidence contradicting the premise. Even the OP's support was tentative. S/he asked, "Would it be against our credo...?", and the answer appears to be "Yes." Seems snow-worthy to my eye, but anybody including the OP is welcome to revert me. ―Mandruss ☎ 03:27, 13 December 2017 (UTC)[reply]

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.

We are coming up to that time of year again when many school kids have a short winter break. During such times WP gets inundated with higher levels of vandalism from bored children, just at the very times we wish to sit back and relax. Would it be against our credo to suspend the creation of new accounts and anonymous edits for these periods? WP is so big now, that current active editors are having to spending more time policing than adding content – yet we 'need' new editors from the younger generation to join us. Thus, I am at sixes and sevens over this. The only real silver lining I can see to this suggestion is that they turn their attentions to vandalizing Facebook and Twitter instead. Aspro (talk) 15:12, 12 December 2017 (UTC)[reply]

No, we don't prevent good-faith new editors from joining us because we're too lazy to deal with vandals. Just no. --Jayron 32 16:07, 12 December 2017 (UTC)[reply]

It is nothing to do with wanting to be lazy, rather than the distraction and shear volume of these one-or-two-or-three edit disruptions, plus the extra time required read through and then revert them – sometimes, several times in quick succession on the same article when a Wikiholiday would help avoid this. Aspro (talk) 18:35, 12 December 2017 (UTC)[reply]

The distraction and sheer volume is always there. We'll deal. We always have been, and we're going to keep doing so. --Jayron 32 18:39, 12 December 2017 (UTC)[reply]

[citation needed]. I've always found that the amount of vandalism is drastically reduced when schools are not in session. The increase in vandalism in September and January, and correlation with school hours, is actually quite noticeable. I'd suggest that there's probably more recognition and peer pressure behind it. Plus maybe the vandal kids are just more easily bored in school? They've probably got more interesting ways to get in trouble during the holidays, and probably don't want to spend too much time looking at encyclopaedias. -- zzuuzz ^(talk) 19:08, 12 December 2017 (UTC)[reply]

Anecdotally, I have to agree that there is more vandalism in September. Also, what about the college students who are bogged down in work during the semester, and break is the time for them to venture onto Wikipedia? If we locked them out, we could lose a lot of valuable, energetic, constructive editors. —C.Fred (talk) 19:14, 12 December 2017 (UTC)[reply]

You don't need to be anecdotal—see the activity level chart (the first red-shaded graph) and you can see for yourself that activity levels significantly and consistently drop during school vacations in the US, and rise again when the schools are back in session. ‑ Iridescent 23:00, 12 December 2017 (UTC)[reply]

Absolutely not. Even if your during such times WP gets inundated with higher levels of vandalism from bored children claim were true—which it isn't—we're not going to change our core operating model just it happens to be the time when you personally wish to sit back and relax. ‑ Iridescent 22:48, 12 December 2017 (UTC)[reply]
No as per Zzuuzz - We shouldn't stop people from registering and potentially becoming well respected and well loved editors all because of a few bored knobheads, If the kids vandalise they get blocked and FWIW kids will vandalise whether they're in school or out of school. –Davey2010^Talk 23:08, 12 December 2017 (UTC)[reply]

To be more accurate, kids will vandalise significantly more when they're in school (where Wikipedia will likely be the only user-editable site the schools' Webmarshall software will allow them to access), than when they're not in school and have a free run of the internet. Normal children don't generally tend to spend their vacation time reading a text-based online encyclopedia. ‑ Iridescent 23:13, 12 December 2017 (UTC)[reply]

I absolutely agree (and somewhat off topic but during my school years various software was introduced that could block websites (even game sites!) and by 2006 virtually every website was blocked and that was in 2006 so I assume since then software in schools has probably got even worse and as such Wikipedia is probably the only website kids have access too! - Thinking about it I assume most kids when at home would be interested in Netflix and Instagram so yeah I have to agree WP probably becomes more of a target in schools then it does when they're at home). –Davey2010^Talk 23:31, 12 December 2017 (UTC)[reply]

NO. This goes against all of Wikipedia's core principles and foundation. ~Oshwah~^{(talk) (contribs)} 23:36, 12 December 2017 (UTC)[reply]
Nah dawg As per Oshwah and friends, it's kinda called "the something everyone can something" for a reason. Drewmutt (^ᴥ^) talk 23:39, 12 December 2017 (UTC)[reply]
No even if there are more vandals, it also means there are more Hugglers. It would even out, and the net loss would be tremendous. TonyBallioni (talk) 23:39, 12 December 2017 (UTC)[reply]
Oppose: Constructive editors may also create accounts while time off-work allows them to. —Paleo Neonate – 01:36, 13 December 2017 (UTC)[reply]

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

Free encyclopeadia that anyone can edit

I have been editing Wikipedia on and off for more than twelve years now, and I can remember the days when if one read an article in Wikipedia, it would have a sign saying "Wikipedia - the free encyclopeadia that anyone can edit" heading the article. My proposal is that we go back to having this sign, as this would inform newcomers to Wikipedia that Wikipedia is a wiki website.Vorbee (talk) 19:52, 17 December 2017 (UTC)[reply]

You want to readd the "anyone can edit" part? L3X1 (distænt write) 14:11, 18 December 2017 (UTC)[reply]

If we're going to re-add that, can we change it to read "anyone can edit (but there's no guarantee that your edit will last more than a nanosecond before someone deletes it)"? Truth in advertising? Better for keeping the newcomers we attract with the motto? Regards, TransporterMan (TALK) 14:58, 18 December 2017 (UTC)[reply]

I see no need to have it atop every page. And surely there's no need for, "and so can everyone else" since it's obvious. Jim.henderson (talk) 15:10, 18 December 2017 (UTC)[reply]

I don't think this is necessary. Natureium (talk) 15:58, 18 December 2017 (UTC)[reply]

See also prior discussions at MediaWiki:tagline. — xaosflux ^Talk 16:35, 18 December 2017 (UTC)[reply]

@@ Line 258: / Line 258: @@
 :I don't understand any of this. Could someone please explain this to me? [[User:Hydra Tacoz|Hydra Tacoz]] ([[User talk:Hydra Tacoz|talk]]) 21:49, 18 December 2017 (UTC)
 ::{{Ping|Hydra_Tacoz}} Some uses of Wikiepdia have short descriptions of articles (e.g. in the Wikipedia app or for search engines). Where and how we get or store this info is what is being discussed. A logical place to keep it is Wikidata but there are some problems with that. ―[[User:Koavf|Justin (<span style="color:grey">ko'''a'''vf</span>)]]<span style="color:red">❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯</span> 21:55, 18 December 2017 (UTC)
+:::@Koavf|Justin Thank you! So, how is the Wikidata a safe place? What exactly is the Wikidata? [[User:Hydra Tacoz|Hydra Tacoz]] ([[User talk:Hydra Tacoz|talk]]) 22:04, 18 December 2017 (UTC)
 ===What to do with blanks===