Ed Erhart (WMF) (talk | contribs) →Proposal implemented: tweak |
|||
Line 402: | Line 402: | ||
#'''Continue for the next 9 days''' trial will end on April 7 anyway. I support in general improving articles and the way we communicate article content; part of this involves trying new things. Trying things inherently carries a component of risk (on wikipedia at least: mainly to the proposer of a trial's mental health and wellbeing). This was a small trial with local consensus that has a defined endpoint in 9 days. What a storm in a teacup.--[[User:LT910001|Tom (LT)]] ([[User talk:LT910001|talk]]) 17:12, 27 March 2016 (UTC) |
#'''Continue for the next 9 days''' trial will end on April 7 anyway. I support in general improving articles and the way we communicate article content; part of this involves trying new things. Trying things inherently carries a component of risk (on wikipedia at least: mainly to the proposer of a trial's mental health and wellbeing). This was a small trial with local consensus that has a defined endpoint in 9 days. What a storm in a teacup.--[[User:LT910001|Tom (LT)]] ([[User talk:LT910001|talk]]) 17:12, 27 March 2016 (UTC) |
||
#Oppose, forum shopping after [[Wikipedia:Templates_for_discussion/Log/2016_March_8#Template:Research_help]] with no notice to participants there (those pings did not work), plus only a couple days left anyway. [[User:The ed17|Ed]] <sup>[[User talk:The ed17|[talk]]] [[WP:OMT|[majestic titan]]]</sup> 01:12, 3 April 2016 (UTC) |
#Oppose, forum shopping after [[Wikipedia:Templates_for_discussion/Log/2016_March_8#Template:Research_help]] with no notice to participants there (those pings did not work), plus only a couple days left anyway. [[User:The ed17|Ed]] <sup>[[User talk:The ed17|[talk]]] [[WP:OMT|[majestic titan]]]</sup> 01:12, 3 April 2016 (UTC) |
||
#Oppose per above, it's ending soon anyway, and could be possibly useful. I would prefer it if more consultation was done before implementing something like this, though. I am also concerned with the implementation of a result here by the person who proposed it. [[User:Ajraddatz|Ajraddatz]]<small> ([[User Talk:Ajraddatz|talk]])</small> 03:54, 3 April 2016 (UTC) |
|||
===Neutral=== |
===Neutral=== |
Revision as of 03:54, 3 April 2016
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
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 the idea lab.
- Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
- Proposed policy changes belong at Wikipedia: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.
Close down Possibly Unfree Files
At this discussion, we reached consensus to close down non-free content review and instead send all such discussions to Files for Discussion. Possibly unfree files (PUF) has many of the same issues. It doesn't get enough attention - current there are unclosed discussions from December. And, more importantly, it isn't clear to many editors, nor to any new editors, whether such a deletion discussion should happen at PUF or FFD. Files for discussion is perfectly capable of handling the additional discussions.
The proposal is this: Close down Possibly Unfree Files, with all future discussion at Files for discussion Oiyarbepsy (talk) 03:48, 6 March 2016 (UTC)
Close PUF
- Support closing. While they may officially have different purposes, in practice they duplicate each other, and we'd do better to have less processes rather than more anyways. --Jayron32 16:30, 7 March 2016 (UTC)
- Support. With the way that the English Wikipedia has evolved over the years, it just makes sense to have all discussions for "File:" namespace pages to happen in the same place. Steel1943 (talk) 19:02, 7 March 2016 (UTC)
- Support - It only makes sense to limit the places that deletion discussions take place; having a different place for each specific reason for discussion leads to bureaucracy. It does make sense to have different places for files, templates, categories, articles, and "other" pages, but since FfD and PUF are essentially duplicating work and many (if not most) editors are not aware of PUF (for example, I was not aware PUF existed), they need to be merged. — Jkudlick • t • c • s 13:34, 8 March 2016 (UTC)
- Support - Easier just to have one place to discuss all the particular aspects of files local to Wikipedia, most of which relate to a files particular free-ness. Redirect to FFD or mark historical with a big pointer to FFD. --Izno (talk) 14:21, 8 March 2016 (UTC)
- Support – I've had users respond with confusion when I took a file to PUF rather than FFD, the former being less well known. Would be simpler and easier for everyone just to have the one venue for everything. CT Cooper · talk 18:06, 8 March 2016 (UTC)
- Support. Seems like unnecessary duplication. --Regards, James(talk/contribs) 18:14, 8 March 2016 (UTC)
- Support Per all the above. Having too many forums for discussion of basically th same thing is unhelpful to the project. Beeblebrox (talk) 18:35, 8 March 2016 (UTC)
- Support – Reduces bureaucracy, improves efficiency. RGloucester — ☎ 19:17, 8 March 2016 (UTC)
- Support - decreases red-tape, and increases performance. — Cirt (talk) 01:39, 9 March 2016 (UTC)
- Support. The distinction was often unclear to me, too. Sandstein 08:15, 9 March 2016 (UTC)
- Support as IMHO it's a completely pointless board - It's pretty much a duplicate of FFD so there's not much point in keeping it around, FFD seems to be the best choice here. –Davey2010Talk 03:07, 10 March 2016 (UTC)
- Support simplification and centralization and elimination of this and other bureaucratic cul de sacs. Carrite (talk) 12:29, 11 March 2016 (UTC)
- Support: fewer is better. Esquivalience t 20:57, 12 March 2016 (UTC)
- Support I never understood why it was necessary to have multiple venues for files in the first place. — JJMC89 (T·C) 22:00, 12 March 2016 (UTC)
- Support per nominator. Reduction of confusion in regards to "where to go" by removing essentially duplicate spaces is appreciated. I, JethroBT drop me a line 01:24, 14 March 2016 (UTC)
- Support. This is a logical next step for reasons already stated above. I'd be interested in feedback from PUF regulars on what they would need to be best accommodated in FFD. czar 03:29, 14 March 2016 (UTC)
- Support Thanks to the broadening of FFD's mandate it now can handle non-deletion outcomes. Also, I see rather frequently the freeness of an image being disputed in FFD when PUF would be the right place.Jo-Jo Eumerus (talk, contributions) 17:21, 14 March 2016 (UTC)
- Support. Simpler. -- Ϫ 01:56, 15 March 2016 (UTC)
- Support – when a process does not get much activity, and can easily be replaced by another process, it is best to close it down. sst✈ 05:45, 15 March 2016 (UTC)
- Support --- PUF doesnt get much anyway Ⓩⓟⓟⓘⓧ (talk) 18:52, 16 March 2016 (UTC)
- Support -FASTILY 21:59, 16 March 2016 (UTC)
- Support per the KISS principle. Andrew D. (talk) 17:44, 18 March 2016 (UTC)
- Support Hamid Hassani (talk) 16:47, 20 March 2016 (UTC)
- Support. Good reduction in WP:BUREAUCRACY and WP:CREEP, and consistent with the previous closure of the other redundant process of this sort. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:55, 21 March 2016 (UTC)
- Support. In the long run, PUF is just a specialization or a branch of FFD. Anything at PUF can also be conered at FFD. epicgenius (talk) 13:56, 22 March 2016 (UTC)
- Support - PUF gets little attention. It serves the same purpose as FFD. It is therefore redundant and should be closed. Ethanlu121 (talk) 15:56, 22 March 2016 (UTC)
- Support - I'm a relatively experienced user yet have been confused by this. Arguments for simplification are compelling. --LukeSurl t c 14:15, 24 March 2016 (UTC)
- Support I'm very concerned if the page might be overwhelmed or not, I simply hope not. The idea seems good, imo. --QEDK (T 📖 C) 16:29, 25 March 2016 (UTC)
- Support Seems to make the process similar. Other supports make good arguments. Particularly swayed by SST's support. Wugapodes (talk) 00:47, 28 March 2016 (UTC)
Keep PUF
- Support keeping PUF. PUF and FFD have clearly distinct purposes, and the discussions are typically closed after around a week. Also, most PUF discussions are closed by the same users as those who close the FFD discussions, so if you close down PUF because you think it's backlogged, you will just move a backlog from one place to another place and thus not achieve anything. --Stefan2 (talk) 11:19, 6 March 2016 (UTC)
- Yeah, the policy pages say they're different, but when you actually look at the discussions, they aren't. And giving the closers one place to look instead of two will reduce the backlog for that simple reason. Oiyarbepsy (talk) 16:33, 6 March 2016 (UTC)
- Exactly, ×2. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:56, 21 March 2016 (UTC)
- Yeah, the policy pages say they're different, but when you actually look at the discussions, they aren't. And giving the closers one place to look instead of two will reduce the backlog for that simple reason. Oiyarbepsy (talk) 16:33, 6 March 2016 (UTC)
- Keep as the file is not so often deleted. Graeme Bartlett (talk) 00:16, 14 March 2016 (UTC)
- WP:FFD is "files for discussion", not "files for deletion". RGloucester — ☎ 00:37, 14 March 2016 (UTC)
- User:Graeme Bartlett, when non-free content review was closed down, Files for Deletion was renamed to Files for Discussion so that it could handle all the issues that non-free content review covered. For examples, many recent discussions have ended with the result of remove from this and that article without deleting the image. Similarly, with PUF merged in, you could have discussions ending with the result image is free or image is not free, without actually deleting it. Oiyarbepsy (talk) 01:38, 14 March 2016 (UTC)
- Keep PUF as it's more streamlined. Stifle (talk) 10:35, 1 April 2016 (UTC)
Discussion (PUF)
- Comment: Just wondering how the cleanup is going to proceed if this RfC is approved. Just going by what happened after the NFCR/FFD merge, it seems there were many in favor of the merge who decided to not get involved in the cleanup, thus causing it to take much longer than it probably should have. A few editors really spent a lot of time updating templates, closing discussions, etc. and few admins worked their way through NFCR files which were added to FFD to help reduce the backlog. Not sure how many PUF discussions will be added to FFD, but it would be nice if there was also some consideration given to the post-merge cleanup. -- Marchjuly (talk) 02:24, 9 March 2016 (UTC)
- @Marchjuly: I already have a bit of an overview about what will need to take place after this merge is approved. This merge probably will not be as complicated as the FFD rename since rather than a forum being shut down and a forum renamed, instead, we only have a forum to shut down. The technical details will include AnomieBOT having to stop creating daily subpages after the merge is finalized, Twinkle needing to be updated to have the WP:PUF option removed, and the instructions at WP:FFD to be updated to encapsulate everything. And, with this proposal, almost no templates should need to be updated due to no forum being renamed (I know that was the biggest headache with the NFCR to FFD merge.) Steel1943 (talk) 03:24, 9 March 2016 (UTC)
- Although I didn't mention you by name Steel1943, you were one of the editors who did a lot of the heavy lifting post merge. So, if you feel things will not take as much time as before than that's good enough for me. Still there may be some discussions on PUF which require further discussion or an admin to close. Is the plan to relist them in stages at FFD like was done with NFCR or will everything be moved at once? Not sure which approach is best. I guess it depends on the number of unresolved discussions at the time of the merge. -- Marchjuly (talk) 04:16, 10 March 2016 (UTC)
- @Marchjuly: I think the first step is to have what I outlined above accomplished first (halting the creation of the daily subpages.) Afterwards, if after a while PUF entries do not get closed, then relating could be an option. (I do not see the need to relist PUF discussions on FFD immediately being as necessary as the NFCR to FFD merge since PUF has daily subpages and most of those discussions are being closed in a somewhat more orderly fashion than NFCR was.) Steel1943 (talk) 21:51, 13 March 2016 (UTC)
- Although I didn't mention you by name Steel1943, you were one of the editors who did a lot of the heavy lifting post merge. So, if you feel things will not take as much time as before than that's good enough for me. Still there may be some discussions on PUF which require further discussion or an admin to close. Is the plan to relist them in stages at FFD like was done with NFCR or will everything be moved at once? Not sure which approach is best. I guess it depends on the number of unresolved discussions at the time of the merge. -- Marchjuly (talk) 04:16, 10 March 2016 (UTC)
- I'll add that this should be way easier to close since PUF actually has daily subpages, making things trackable, unlike NFCR which had squat. Oiyarbepsy (talk) 04:03, 9 March 2016 (UTC)
- That's a good point Oiyarbepsy that I forgot about. You also were one of the editors who helped clean things up post merge so if you feel things are going to be more manageable this time, then everything sounds good to go. -- Marchjuly (talk) 04:19, 10 March 2016 (UTC)
- With regards to the existing backlog, in case it isn't clear - for NFCR, the page was just left open and listed at WP:ANRFC, and new requests were directed to FFD by a template. Sunrise (talk) 06:00, 9 March 2016 (UTC)
Proposal: Enable Hovercards by default
Hovercards is a Beta feature that displays a short summary of an article and an image when a user hovers over a link. When enabled, there is an option to disable it by clicking on the gear icon and selecting "Disable previews", which can be undone by clicking a link in the footer, similar to the disabling system used by Reference Tooltips.
Hovercards can be tested via Special:Preferences#mw-prefsection-betafeatures. Currently, about 46,000 English Wikipedia users are testing the feature.
Some background information: Navigation popups, a tool providing easy access to article previews and several Wikipedia functions, was created as a user script in 2005 primarily by User:Lupin, with help from numerous other Wikipedians. It was made into a gadget in 2007, and became one of the most popular gadgets, with over 40,000 users opting in to use it on the English Wikipedia, and nearly 40,000 more users on other Wikipedias. In 2014, the Wikimedia Foundation started working on "Restyling and Enhancements" for the feature, greatly simplifying the appearance of the popups, emphasizing the lead image, and hiding by default the extra Wikipedia functions, targeting the feature primarily towards casual readers. The new version was re-branded as "Hovercards", and made into a Beta feature. In 2015, Hovercards was rolled out to all users on the Greek and Catalan Wikipedias for a two month test, gathering feedback via a survey, which mostly received positive responses, along with many bug reports and suggestions for improvement.
Note that this feature still has several remaining bugs, including the popups occasionally getting "stuck" and not vanishing properly, and popups having issues with certain types of article leads. Hovercards is also still lacking many features supported by navigation popups. (Currently, if one has navigation popups enabled and selects "Advanced" mode to use the extra features, navigation popups-style popups are displayed instead of Hovercards-popups.) For links to certain articles, an image not directly related to the article topic is displayed, due to a bug in the PageImages API.
If anyone considers any particular bugs/gaps/tasks to be blocking (that is, we should wait until they're fixed before enabling the feature by default), please say so. Waiting until certain things are fixed is an option. Simply not turning the feature on by default at all is also an option. So is waiting until it has received more testing on other projects. The WMF is willing to work on this as necessary, provided the community actually wants the feature.
Should Hovercards by enabled by default on the English Wikipedia? --Yair rand (talk) 10:29, 16 March 2016 (UTC)
NOTE: There is a discussion at policy talk: Non-free_content#Hovercards. It seeks to determine whether it is acceptable for non-free images to appear in Hovercards. Alsee (talk) 16:55, 16 March 2016 (UTC)
Discussion
- Wait until the extension has reached feature parity with navigation popups, then reconsider. Note that popups have always been opt in for editors. MER-C 11:03, 16 March 2016 (UTC)
- Hovercards are primarily intended for readers who don't need all the fancy bells-and-whistles of Lupin's navigation popups. These are also the people who can't easily "opt-in" or "opt-out" of this feature, as most of them aren't logged-in. Power-users can easily disable Hovercards using the button on the card. With 45,955 registered users already having opted-in at the moment, I think "enable by default with an easy opt-out" would be the sensible default setting. —Ruud 11:34, 16 March 2016 (UTC)
- This will never happen (within the next five years), nor was it a goal of hovercards. (disclaimer, i'm a former navigation popups developer) —TheDJ (talk • contribs) 12:24, 16 March 2016 (UTC)
- In which case, oppose for editors. Let's make it opt in for readers first while the bugs are squashed then try to measure how many readers found it useful and how many turned it off, and perform A/B tests. MER-C 06:50, 23 March 2016 (UTC)
- I need to understand "(Currently, if one has navigation popups enabled and selects "Advanced" mode to use the extra features, navigation popups-style popups are displayed instead of Hovercards-popups.)" -- As I don't use NPopups, is the "Advanced" mode part of popups or hovercards? Does that basically mean that popups is hooking into hovercards? --Izno (talk) 11:39, 16 March 2016 (UTC)
- @Izno: The option for "Advanced" mode is in the Hovercards menu, but the option currently only appears when one also has Navigation popups turned on, and those popups themselves come from Navigation popups. Hovercards normally suppresses Navigation popups to avoid duplication. I'm pretty sure that all the "Advanced" setting does is turn off Hovercards and remove the suppression of the Navigation popups. (I imagine the eventual plan is to have "Advanced" mode actually be fully part of Hovercards and not use the gadget.) --Yair rand (talk) 11:58, 16 March 2016 (UTC)
- Enable by default. However, I would consider either phab:T105782 or phab:T92932 to be blockers of the definite sort and not just the "kinda'" sort that we usually associate with blockers in Phabricator, so one of the two needs to be resolved prior to enabling by default. --Izno (talk) 12:21, 16 March 2016 (UTC)
- I've been using Hovercards for at least a few months now and the "getting stuck" thing happens perhaps once a week or so. The easy solution is to press F5 and refresh the page. So it's not really a blocking issue for me. But if it could be fixed, that would be better, yes. —Ruud 12:44, 16 March 2016 (UTC)
- Oppose. Should be opt in only. NOT enabled by default. These things are quite cumbersome when reading articles anywhere on the Internet and bothersome. They are extremely incredibly distracting to readers and editors alike. Both during the reading process or editing process. — Cirt (talk) 14:39, 16 March 2016 (UTC)
- Well, I personally find this feature to be incredibly useful. You actually need to hover your cursor over the link for a while before the card opens, so I rarely open it by accident. The survey among readers does indeed show that there is a strong "love it" or "hate it" response:
- but 1) the people that like it vastly outnumber the people that don't (6 to 1) and 2) it's much easier to disable this thing (click the button on the card) than it is to enable it (create an account and find a checkbox hidden on one of the preferences tabs). —Ruud 15:45, 16 March 2016 (UTC)
- Enable by default I find Hovercards to be very useful and based on the number of people that have enabled this Beta feature and the survey responses I think this will be useful for a majority of the readers. Most of those readers won't be able to enable this feature if it remains as an opt-in feature, while those that find this a nuisance can disable it quite easily. —Ruud 16:51, 16 March 2016 (UTC)
- Enable by default, but first they should add the standard "X" at the top right allowing the user to close the card, doubleso if there is a bug that sometimes prevents them from closing automatically. Diego (talk) 17:51, 16 March 2016 (UTC)
- Enable by default provided there's a means to disable the feature from the card itself. (Disclaimer: I've used Lupin's popups for the past several years.) —Jeremy v^_^v Bori! 21:03, 16 March 2016 (UTC)
- Very Strong Enable by Default This is very, very useful. When I get on WP at lunchtime from work to just browse stories, I find it horrible that I have to actually click a term link to find out the bare info about it. Annoying. I am on several computers a night and hardly ever in the same location again. To me, the hovercard is a godsend for quick reading about items and terms I may not be that familiar with. With my casual reader hat on, I find it is a huge time saver. It should be available standard, with an opt-out feature for those who don't like it. GenQuest "Talk to Me" 22:28, 16 March 2016 (UTC)
- Oppose Just leave NAVPOPS alone(Redacted)--Stemoc 23:36, 16 March 2016 (UTC)
- Enable - I've used hovercards for years. I like hovercards. And I'm not going to argue with the data at mw:Beta_Features/Hovercards#Qualtrics_Survey_Results. But the WMF should just get more data to avoid these discussions where input is limited to a small group of power-users who are not representative of the audience and have no insight into design or usability. Just run A/B tests on x% of the audience, find out how hovercards effect their behaviour. Bring in volunteers on site in SF and do eye-tracking or something. Anything to expedite circular discussions on-wiki. - hahnchen 23:55, 16 March 2016 (UTC)
- Enable For once a Mediawiki beta feature that is really good and everyone should get. Oiyarbepsy (talk) 04:41, 17 March 2016 (UTC)
- Oppose per Cirt. Any kind of pop up content should be disabled by default. I assume that be having this on by default, page load time would be increase and that there would be further drain on client resources by Javascript. - MrX 12:56, 17 March 2016 (UTC)
- Oppose - one of the most annoying things on web pages is when unexpected popups appear. While anyone who wants this would certainly not complain, it shouldn't be forced on anons, nor enabled for registered users except by explicitly asking it to b enabled (such as in the "Preferences" page). עוד מישהו Od Mishehu 15:42, 17 March 2016 (UTC)
- Try hovercards, if they were default on, those popups would not be unexpected - they only appear after hovering over a link for a second. The reader survey above suggests that "forcing" this upon anons would prove useful. - hahnchen 16:46, 17 March 2016 (UTC)
- You move the mouse carelessly, happen to leave it on a link, and then a popup shows up... that would certainly be unexpected. I do use Lupin's popups, but would certainly oppose it being imposed on anons or enabled for registered users by default. עוד מישהו Od Mishehu 18:14, 17 March 2016 (UTC)
- Try hovercards, if they were default on, those popups would not be unexpected - they only appear after hovering over a link for a second. The reader survey above suggests that "forcing" this upon anons would prove useful. - hahnchen 16:46, 17 March 2016 (UTC)
- @Od Mishehu: Note that we have already decided to enable the very similar Reference Tooltips popups as an opt-out feature for both registered and for non-logged-in users (Wikipedia:Village_pump_(proposals)/Archive_89#Reference_Tooltips).
- I think that it is to be expected that there are going to be some users who will like these popups and some that are going to be annoyed by them. (The survey that was run shows that 76% of readers like them, 13% don't like them, and the remaining ones don't care either way.) Whether you want to use them should indeed be an individual choice. But if we leave this as an opt-in for registered users only, most people will not have the opportunity to make that choice, simply because they have no way of knowing that making the choice to enable this feature is an option. Making this an opt-out feature is probably the closest we're going to get to giving everyone a chance to make that explicit choice for themselves. Yes, a few people will be annoyed when these popups appear, but disabling them is easy. Enabling them, on the other hand, is nigh impossible for most readers at the moment. —Ruud 19:53, 17 March 2016 (UTC)
- Reference links are quite a bit smaller than regular links, so I'm not sure the comparison works all that well. --Yair rand (talk) 21:49, 17 March 2016 (UTC)
- If my first experience with Wikipedia had been a popup showing up unexpectedly, I would have probably decided it was a spam site and stayed away from it. עוד מישהו Od Mishehu 14:47, 18 March 2016 (UTC)
- Reference links are quite a bit smaller than regular links, so I'm not sure the comparison works all that well. --Yair rand (talk) 21:49, 17 March 2016 (UTC)
- Oppose Who the hell do you people think you are? So now you think we should have users experience pop-ups by default without them specifically asking for it? That's nonsense. Look, I use navigational popups and I think everyone should but I'm not supporting enabling intrusive features for users without their consent. I'm guessing someone wants to push hovercard use and isn't happy with the number of opt-ins; this is a sad measure to force the issue. Chris Troutman (talk) 21:32, 17 March 2016 (UTC)
- Oppose. Great feature, but no way this should be enabled by default. Doing so will only cause confusion for those who have dealt without them for so long, some of which may have never touched the "Preferences" tab before. However, as a caveat, I am neutral on this being enabled by default for IP editors only; this opinion is similar to how the "media viewer" ended up being set up. — Preceding unsigned comment added by Steel1943 (talk • contribs)
- Oppose - No it fucking shouldn't be the default, I've just enabled it and well I absolutely hated it .... so it's now disabled and I'd rather leave it like that, If I wanted to know what for example a "convertible" was I would read a dictionary not expect some irritating pop up to tell me every single linked word my mouse goes over!, Although I do support enabling it for IPs as that way IPs might hate it as much as I do and would hopefully signup .... Anyway no don't enable it - Just let people who want it to enable it via their preferences. –Davey2010Talk 22:50, 17 March 2016 (UTC)
- Oppose. This would reduce article traffic, and interferes with the reading of text when readers unintentionally hover their cursor on a wikilink. Personally, I find this feature annoying. sst✈ 02:03, 18 March 2016 (UTC)
- How would it reduce article traffic? Hovercards are very simple to understand, and users can still just click on the link to open the article in a new page, there's no difference in behaviour there. If you feel that by serving up the lead to readers in a hovercard, that the reader will not then read the rest of the article, you are saving time and resources needed to serve a new page. - hahnchen 23:43, 18 March 2016 (UTC)
- Comment – I can see the use for this, but I can also see how it can become really annoying. What we really need is a solution that would make it much easier for readers (that is, non-editors) to notice these add-ons and enable them voluntarily. Something like a prominent "reading preferences" menu at the top of the page, next to "Create account", that all of our users could have to personalize their reading experience. If there is widespread support for a particular add-on from this setup, a discussion of whether to enable by default would be more successful. Mz7 (talk) 05:03, 18 March 2016 (UTC)
- @Mz7: How would you define "widespread support"? (Currently there are 46,071 registered users who enabled this beta. A survey among anonymous users found that over three quarters found this useful, one in eighth disliked it.) —Ruud 09:56, 18 March 2016 (UTC)
- @Ruud: Careful with statistics! Those 46,071 are less than 0.2% of the 47,567,573 registered users of English WP – is that widespread support? How self-selecting were those who responded to that survey among anonymous users? Stanning (talk) 10:21, 18 March 2016 (UTC)
- @Stanning: It would indeed be very interesting to know not only how many people have enabled a particular feature, but also how many enabled it at some point and then decided to disable it again. So we could classify people into "tried it and liked it", "tried it and didn't like it", and "didn't try it yet". We could even break this number further down into categories for "very active registered users", "active registered users" and "registered users that don't edit". And plot these numbers over time. All of this information should ideally be visible on the Beta tab.
- But even if we know these numbers, my original question still stands. How should we define "widespread support"? —Ruud 11:12, 18 March 2016 (UTC)
- @Ruud: I didn't envision any sort of quantitative definition of "widespread support." A lot of the opposition (and support) in this discussion is based on personal preference; if we notice that one add-on feature is generally getting more attention among our readership than others, then that would indicate that our readers prefer the feature and could be a more solid basis on which to enable by default. The statistics you mentioned are encouraging to that effect, and as of now, I'm not strictly opposed to enabling Hovercards by default. I still think, perhaps for future feature add-ons, that giving our readers a centralized "reading preferences" menu would allow them to personalize their Wikipedia experience in the way they like it, rather than trying to force a feature on everyone. If we do end up enabling Hovercards by default, then it is important that we make it very easy for users that don't want it to opt-out. Mz7 (talk) 18:33, 18 March 2016 (UTC)
- How about a large scale A/B test on the English Wikipedia? While the data we have from the Greek and Catalan Hovercards trial is useful, we could do with a lot more. Instead of solely relying on survey responses (which is still useful), the foundation should be looking at performance impacts, hovercard disable rates, hovercard "alive" times (are people reading the hovercards), click-through rates (do hovercards encourage more page views, or do they keep the reader focused on the current one?). At some point, there should be enough data one way or another that those arguing on "personal preference" can be mostly ignored. - hahnchen 23:43, 18 March 2016 (UTC)
- @Ruud: I didn't envision any sort of quantitative definition of "widespread support." A lot of the opposition (and support) in this discussion is based on personal preference; if we notice that one add-on feature is generally getting more attention among our readership than others, then that would indicate that our readers prefer the feature and could be a more solid basis on which to enable by default. The statistics you mentioned are encouraging to that effect, and as of now, I'm not strictly opposed to enabling Hovercards by default. I still think, perhaps for future feature add-ons, that giving our readers a centralized "reading preferences" menu would allow them to personalize their Wikipedia experience in the way they like it, rather than trying to force a feature on everyone. If we do end up enabling Hovercards by default, then it is important that we make it very easy for users that don't want it to opt-out. Mz7 (talk) 18:33, 18 March 2016 (UTC)
- Oppose. I agree with Mz7: can be useful, can be annoying. But no way should it be enabled by default, even for IPs, even with a little gear-wheel to turn it off (if you know what the gear-wheel means).
As Mz7 says, it'd be good anyway to make Preferences, or some of them, available to IP users (I guess that'd mean a WM change to keep some preferences on the device, instead of centrally, for non-logged-in users).
Maybe a compromise would be to enable it by default once only and on first pop-up include a line saying something like "Do you want this feature? Click here to enable it" and if the user doesn't click, turn it off at once (not the other way round).
Personally I dislike pop-ups because usually they're ads or otherwise irrelevant. Of course on WP we're pure and undefiled, but that doesn't mean that we should feel free to push features like this, however 'cool' they seem to us. Stanning (talk) 09:41, 18 March 2016 (UTC) - Oppose for now. I would support if they contained no images. The current WMF fad to include large images in everything (this, related articles, Gather before it was disabled, apparently some new search as well) is very annoying; we are a knowledge engine (ha!) that also includes images, not an image repository with some accompanying text. (The indication of how long ago the hovered page is last edited is also completely unnecessary, as it gives no information related to the hovercard text or even interesting to 99.9 of the people using the hovercard) Fram (talk) 11:37, 18 March 2016 (UTC)
- I think an image usually adds value to the card. What I don't particularly like is that the PageImage extension tries way too hard to extract an image from the article. If we have an image in the lead section, great, use it. But don't pick an image that's several sections down in the article. You can find complaints all over the place about this, ranging from nonsensical images being displayed, to outright problematic ones. —Ruud 12:00, 18 March 2016 (UTC)
- Oppose per the KISS principle. Andrew D. (talk) 17:49, 18 March 2016 (UTC)
- Oppose It's a useful feature but I would expect it be a preference to have enabled or not, and starting with it on by default is not good as well made impede people on older computers or browsers. I would reasonably expect to have a banner announcement that this feature is now available and how to enable it for those that want it. --MASEM (t) 18:00, 18 March 2016 (UTC)
- Oppose forcing it on readers as the default - not everyone is going to know they can turn it off and may want to for the reasons given above. Doug Weller talk 11:50, 19 March 2016 (UTC)
- comment (leaning on oppose). I use them for some time. They are quite good in giving us a glimpse about the linked to article, often that is enough to get why it is linked from 'here' and to know if we want to get there. Still they have two issues that make me think that not having it by default is better. One, these things can be quite annoying when you do not want them, so I'd rather have people missing them for a while until they realise they can have them, than annoying the readers. Two, the images, as many already said, are often a poor choice. Don't try too hard to have an image, if there is not one in the lead, do not look any further (if there was a good image, generally describing the subject in a whole, full, proper way, our editors will push them to the lead soon enough, no need to have a script making guesses) - Nabla (talk) 18:22, 19 March 2016 (UTC)
- Oppose: I have reason to believe that activating this feature by default would only give more ground to North America exceptionalists to created unnecessary templates like {{Football squad start2}}, {{football squad player2}}, etc. while using accessibility as their excuses. Cédric wants to abolish "Convention №. 2" like abolishing slavery. 21:49, 19 March 2016 (UTC)
- @Cendric than cantonais:: Please explain. What you've said doesn't mean anything concrete to most of us, especially since football squads (soccer teams, in American English) are little-known in North America, so the examples you provide don't seem to illustrate anything about "North America[n] exceptionalism". — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:43, 21 March 2016 (UTC)
- @SMcCandlish: Glad to explain. Templates like {{Football squad start2}}, {{football squad player2}} are specially created for and are only used for in articles of North American association football teams. Certain users has argued that templates like {{Football squad start2}}, {{football squad player2}} are created so readers on mobile devices can access these pages more easily, but the way I see it, these templates (along with certain "conventions" like "Don't decorate captains in articles of North American association football teams") exists for promoting North American exceptionalism and little else.
- @Cendric than cantonais:: Oddly enough, I just addressed some of this in a different context, at WT:CFD. Short version: MOS:TIES, though basically an article content rule, can affect templates, if they generate content for articles; so, it is essentially required that there be AmEng templates that use AmEng terms in lieu of Commonwealth English ones, for AmEng articles. There is also a consensus against using US state flags for things; MOS:ICONS wants flags in sport to be for sporting nationality, period, and this has been arrived at through years of contentious discussion. If this still doesn't address your concern, I must be missing too much of the back-story regarding disputes about these particular templates. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:55, 21 March 2016 (UTC)
- When it comes to enabling hovering images, my main concern is that North American exceptionalists would attempt to come up with new "conventions" like "Don't use certain kind(s) of images in North-American-related articles". Cédric wants to abolish "Convention №. 2" like abolishing slavery. 21:47, 21 March 2016 (UTC)
- @SMcCandlish: Glad to explain. Templates like {{Football squad start2}}, {{football squad player2}} are specially created for and are only used for in articles of North American association football teams. Certain users has argued that templates like {{Football squad start2}}, {{football squad player2}} are created so readers on mobile devices can access these pages more easily, but the way I see it, these templates (along with certain "conventions" like "Don't decorate captains in articles of North American association football teams") exists for promoting North American exceptionalism and little else.
- @Cendric than cantonais:: Please explain. What you've said doesn't mean anything concrete to most of us, especially since football squads (soccer teams, in American English) are little-known in North America, so the examples you provide don't seem to illustrate anything about "North America[n] exceptionalism". — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:43, 21 March 2016 (UTC)
- Support enabling by default. It's an extremely useful, time-saving feature. I've been using for many months in multiple browsers and OSes with no problems. Turning it off is trivial, finding and turning it on is not. WP cannot remain exactly the same "built in 2005" site forever. We are losing readers because of our shite interface and utility, and this is great improvement to it. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:43, 21 March 2016 (UTC)
- Conditional support. Looking at the survey above in this discussion, I think this feature is great for previewing articles because many people said they like it (301 participants), but some said they don't (52 participants). So, we would want to balance the needs of the majority of supporters to the few people who say they disagree with it. Therefore, The hoverboards should give a brief explanation of what they're, so they won't keep readers and editors wondering "What is that little popup"; Facebook uses a similar method when introducing new features, and also, they should clearly explain how to opt out of using this feature and to turn it back on as they wish because it can get a little bothersome to some readers and editors alike, as per some commentors above. Sam.gov (talk) 18:48, 21 March 2016 (UTC)
- Great idea. For anons, I guess it could work on the cookie basis; any that accept the cookie, and don't want the hovers can save that preference, and not lose if if their IP address changes, at least in theory. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 21:55, 21 March 2016 (UTC)
- Yes, but not now. Hovercards needs some tweaks before being rolled out by default, but I strongly support it being rolled out by default eventually. {{Nihiltres |talk |edits}} 21:22, 21 March 2016 (UTC)
- Support, but with the option to opt out easily delineated on each popup. Hovercards isn't perfect, but maybe we can implement an opt-in option first, then we can roll it out by default after the bugs are fixed. epicgenius (talk) 13:59, 22 March 2016 (UTC)
- Oppose. There is no need to force this feature on the users who find this feature annoying (and it looks like the number of such users is noticeable). Also, I suspect that seemingly the main argument of the supporters - that otherwise those other anonymous readers will not be able to use this feature without registering - seems to be outweighed by the fact that such state of affairs would gently encourage such users to register, and, perhaps, to start editing as well. For examle, I have also registered to get a "registered-only" feature (justified alignment). --Martynas Patasius (talk) 22:03, 23 March 2016 (UTC)
- Oppose - If the feature always performed as well as the display in the example screenshot of this proposal, enabling them would be something to discuss.—Godsy(TALKCONT) 07:27, 24 March 2016 (UTC)
- Oppose – Not for every user's taste, or CPU. A rather gratuitous add-on feature, not a core necessity, should be off by default. SteveStrummer (talk) 01:47, 25 March 2016 (UTC)
- Oppose It's not just the number of users on each side but the minor additional value for those who like it, and the major distration for those who do not. DGG ( talk ) 04:27, 25 March 2016 (UTC)
- Oppose As far as I remember, it was enabled my default, then I went and disabled it. I find hovercards useful. You know what, I'm gonna try it right now and decide. --QEDK (T 📖 C) 06:48, 25 March 2016 (UTC)
- Why does it have to pull a picture and there's no infobox information, just the lede. Random hovers are an issue but they're an issue on every website with hovercards enabled. It's going to work just fine on most articles but on ones with linked ones, it will definitely be annoying. Sometimes, the preview text is absolutely useless and the picture isn't useful in most cases either (it'd be good for animals and plants but those are very limited uses). --QEDK (T 📖 C) 06:57, 25 March 2016 (UTC)
- In the name of God, enable by default. Frankly, hovercards increase the quality of Wikipedia in that they are useful for obtaining information quickly and easily. As has been stated above, anyone who dislikes hovercards has the option to disable them, and those who do find them useful will be grateful of their existence. While there are a few problems (such as the inclusion non-free images, etc.), I see no great cause of concern over their activation. If anything, we can enable them sometime in the future when all of the bugs have been worked out, but personally, I feel they're just fine as is. Colonel Wilhelm Klink (Complaints|Mistakes) 16:43, 25 March 2016 (UTC)
- Don't you dare mess with the preferences of existing registered users. As for IPs, oppose, at least until the bugs are ironed out. BethNaught (talk) 22:15, 25 March 2016 (UTC)
- Comment I think the primary question here is about IP's and NEW accounts. I agree with BethNaught that changing existing editor preferences should not be on the table. For IPs, enabling by default and making it very easy to turn off is being proposed to solve the issue of discoverability for a feature that the majority of readers appear to like (when it was auto-enabled in Greek and Catalan). Without enabling the feature, we don't have a great way of allowing users to try it. There is no user preference area (solvable, but not easily) and, even if there was, there is no good way we have identified to help users discover this feature without showing them. Someone above mentioned running a central notice banner to inform users that it is an option, but this raises other issues--when do you turn the banner off, for instance? Do we turn it on 1 day a month in perpetuity? I am very interested in hearing suggestions, but tend to feel that allowing organice discovery when a user mouses over a link and then providing a very easy way to disable is the way forward. It seems that an easy path to disablement is the biggest issue. Maybe a blocker for rollout would be developing a dialogue on that first hover that shows users how to turn it off? Just an idea. Jkatz (WMF) (talk) 00:18, 26 March 2016 (UTC)
- I really liked Stanning's alternative proposal earlier of showing a hovercard once, and with it a dialogue asking whether the reader would like to continue using the feature. If no response, we would assume no and disable it. I also think the idea of a reader preference area deserves some looking into—if not for Hovercards, then for future add-on features. Ultimately that's what enabling and disabling these kind of features boils down to: preference. Wikipedia has enabled by default a host of these add-ons now—VisualEditor, Media Viewer, Reference Tooltips—and while it is possible to disable each even without a registered account, it would be easier if there were a centralized location for readers (i.e. unregistered users) to switch these on and off. It could also be a place to put beta features like Hovercards, in order to expose them to our readership (the ones who really matter). Mz7 (talk) 18:31, 29 March 2016 (UTC)
- Oppose. Screen clutter which should be opt-in only.--Smerus (talk) 09:03, 26 March 2016 (UTC)
- Support WP:ILikeIt. As an editor I find it useful for quickly telling if the link is correct. It also makes Wikipedia look more professional. AIRcorn (talk) 02:01, 27 March 2016 (UTC)
- Support, I've been using Hovercards for some time and I love it. Really improves my reader experience. --SSneg (talk) 09:44, 27 March 2016 (UTC)
- Strong Support For once, let's think of the readers. I've been using it for a while and it's one thing I really miss when I'm reading on my phone or other computers. It solves a major problem: clicking on links in running prose. When I'm reading an article on a subject I don't know a lot about, I can hover over a blue link, read a brief blurb to try and get the gist of the term, and keep going without having to open a new tab or leave the page. It makes reading and understanding text easier. Enabling by default will introduce a number of people who don't even know this exists to the feature and if they don't like it they can easily opt out. For IPs, it not only makes it easier for them to read and understand articles, but it also enhances our user experience and spurs innovation.
- I'm not convinced by these opposes of "screen clutter" or that it will encourage users to register. It's only screen clutter if you hover. If you don't hover on links, it doesn't clutter your screen. I'd be willing to say most registered users don't even know about this feature, so the idea that an unregistered user would find out about it and be so amazed by the feature that they make an account is not something I find hard to believe. For its bugs it is actually really stable in practice and having it enabled by default will probably get those bugs fixed even faster. I strongly believe that this feature will drastically improve the experience of anonymous readers, even if some editors find it suspect. We are an encyclopedia first, and this is a well designed feature that easily, minimally, and creatively solves a big problem readers have. If that harms your editing workflow, then opt-out, but I don't see why we should be blocking a useful feature because editors don't want to talk the 30 seconds to opt-out of it. Wugapodes (talk) 14:11, 27 March 2016 (UTC)
- Strong support per what Wugapodes said Common: how many experienced editors don't have navigational popups turned on? over 44,000, its our most commonly used opt-in gadget. Our readers would greatly benefit from that simple little bit of help finding the content. I can't believe we are making "clutter" arguments. The readers that are using desktop (an increasingly shrinking portion), are used to this kind of design in almost every other website -- lets not take our own IDONTLIKEIT arguments, to assume they apply for our readers. Sadads (talk) 13:57, 28 March 2016 (UTC)
- Support, per Ruud and Wugapodes. I personally like Hovercards, even though I quickly turned it off in favor of nav popups, so I decided to read the oppose votes first. I didn't find any of them convincing. There's a clear way to opt out, so whatever annoyance might be experienced by people encountering it for the first time would be minimized. APerson (talk!) 13:14, 30 March 2016 (UTC)
- Oppose. In my opinion, this feature is interesting and I'm glad it exists but quickly Hovercards become annoying and stressful as you find yourself hoping your mouse doesn't land on any links. I also think it undermines people participating in the encyclopedia. People are less likely to edit and improve pages they never visited. This feature is flashy and sounds like a great idea, but in practice it would make Wikipedia like a man wearing too much jewelry. Overkill so let's keep it simple. Jason Quinn (talk) 15:27, 30 March 2016 (UTC)
- Oppose. I like the hovercards but making them default will create a cultural expectation that everyone is using them, which is a major faux pas with blind readers, mobile phone users, and people who just choose to disable javascript. Also, based on what Jason Quinn said above, I wonder if hovercards might account for the reduced page visits the WMF has observed? Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 15:46, 30 March 2016 (UTC)
- Oppose making them opt-out. Pop-ups are, indeed, fantastic, and i expect these Hoverthings are too; but they will be annoying (Pop-ups sometimes annoy me, and i've used them for years) and a distraction from the actual content on the page; there is bound to be an effect on performance, especially on those users who have poorer connexions and slower machines, and particularly if they are used without the described freezing resolved. In all honesty, and i don't believe this is an IDONTLIKEIT argument, i oppose making almost anything opt-out on the principle that simpler is better, and we should be making it as easy as possible for our users to access our content; cheers, LindsayHello 11:17, 2 April 2016 (UTC)
Accessibility
Please can someone point us to the accessibility impact assessment for hovercards, showing their effect on people with disabilities, and/ or those using assistive software? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:57, 28 March 2016 (UTC)
RFC: Corrections on Main Page?
The Main Page sometimes has factual errors (mainly on WP:DYK, also in other sections). At the moment, these get quietly corrected or removed, but no acknowledgment of this is being made. Similarly to what happens with e.g. newspapers (Correction (newspaper)), we could make a note of factual errors we featured on the Main Page in either the same spot (so a DYK error gets noted in the DYK section of the main page) or in a separate section on the Main Page. This should only be done for facts, not for grammatical errors, capitalization changes and the like. This was recently done a few times, but met with mixed reactions. How exactly this should be done is not really important, first we need to agree on whether this is wanted or not. Fram (talk) 10:42, 23 March 2016 (UTC)
(Note: this is not intended for ITN items which were correct at the time of posting but were outdated at some time: this is not an error but normal progression of events). Fram (talk) 10:46, 23 March 2016 (UTC)
Examples: A possible approach to such a correction, or this one (that one wasn't a Beatles recording, only Harrison was involved). (these were added after the first two comments below were made) Fram (talk) 14:09, 23 March 2016 (UTC)
- I think how we do things now is fine. Most of the items which come up for discussion at WP:ERRORS are ephemeral anyways, and most changes are minor differences of wording or updates of changing or fluid situations. --Jayron32 11:47, 23 March 2016 (UTC)
- The main problem with the main page currently is that the disclaimer is buried at the bottom in fine print. It should be made more prominent as it's our general position that that any of our content might be wrong. Publishing corrections should only be done when the error or issue is important as it is quite easy to nitpick details. For example, the blurb for yesterday's FA said, "The animals lived for at least 12 to 20 years..." This is erroneous because some of these creatures died young while at least one specimen was found to have reached age 27. But the exact range of lifespans of creatures that have been extinct for millions of years is not a big deal and argument about the best wording for our tentative knowledge of them is likely to be protracted. What might help is having WP:ERRORS turned into a noticeboard with the usual structure of topical sections, archives and the like. Currently WP:ERRORS is too emphemeral and this makes it quite poor at handling issues which would benefit from some continuity, history and discussion. Andrew D. (talk) 13:46, 23 March 2016 (UTC)
- One possible solution is that the error gets removed or corrected, but that a correction only gets posted at the next update (FA or DYK mainly) after a discussion at WP:ERROR. That could avoid corrections for every minor problem, or corrections to corrections, and so on. Fram (talk) 14:11, 23 March 2016 (UTC)
- Having the general disclaimer buried at the bottom in fine print doesn't mean that it doesn't get found. Just look at the amount of rubbish that gets posted to its talk page. Same thing happens with other links "buried at the bottom in fine print" like Wikipedia talk:About and Wikipedia talk:Contact us. --Redrose64 (talk) 21:23, 23 March 2016 (UTC)
- The general disclaimer page gets about 5000 hits per day. That's about the same as a mediocre DYK, which isn't much. Consider that this page appears not just at the foot of the main page but at the foot of every page. Hardly any of our readers are clicking on the link. One reason for that is that the link is blandly bureaucratic and boring. If, instead, every page said Wikipedia is not reliable!, it might get more attention. Andrew D. (talk) 21:54, 23 March 2016 (UTC)
- Having the general disclaimer buried at the bottom in fine print doesn't mean that it doesn't get found. Just look at the amount of rubbish that gets posted to its talk page. Same thing happens with other links "buried at the bottom in fine print" like Wikipedia talk:About and Wikipedia talk:Contact us. --Redrose64 (talk) 21:23, 23 March 2016 (UTC)
- One possible solution is that the error gets removed or corrected, but that a correction only gets posted at the next update (FA or DYK mainly) after a discussion at WP:ERROR. That could avoid corrections for every minor problem, or corrections to corrections, and so on. Fram (talk) 14:11, 23 March 2016 (UTC)
- Oppose We are a website, not a printed source. A newspaper cannot edit already sold papers. And we have five million articles where lots of errors are found and corrected. The main page gets a lot of views and hopefully has fewer errors than average articles but I still don't see good reason to single it out and point out already corrected errors unless they are directly harmful, and I don't recall cases of that on the main page. PrimeHunter (talk) 14:35, 23 March 2016 (UTC)
- The reason to single out the main page is that unlike other pages, it gets heavily scrutinized before anything is posted there and shouldn't contain any serious errors. It's not the part that anyone can edit, with all advantages and disadvantages that has, but the part that we (the community) choose explicitly to highlight, to showcase. That may of course not be enough for you to consider supporting this, and I don't intend to badger all opposes, but I just wanted to indicate why I do see good reasons to single it out. Fram (talk) 14:51, 23 March 2016 (UTC)
- Weak oppose, per PrimeHunter above. Rehman 14:46, 23 March 2016 (UTC)
- While I think reminding people that Wikipedia is full of errors is a good idea (there was something good about the time when the wiki was full of harmless vandalism of the "Kusma is gay! tell everyone!" variety, as that served as a reminder that Wikipedia is edited by random people and not always accurate), I don't like having extra policies for errors on the Main Page as opposed to errors in the content everywhere else. The main problem I see here is that it took more than two hours until the problem was corrected, which is embarrassingly long and probably something to point out whenever somebody opposes a good faith editor at WP:RFA. WP:ERRORS is one of the more urgent admin areas. —Kusma (t·c) 15:09, 23 March 2016 (UTC)
- Actually, more than 6 hours in that instance between reporting and correction. Getting errors off the main page (by correction or removal) is of course more important, and shouldn't wait until a correction has been written; it should be consecutive processes, with the error handling not dependent on the addition (or not) of a correction. Fram (talk) 15:14, 23 March 2016 (UTC)
- Oppose. Primarily because I don't see an actual point. Resolute 19:15, 23 March 2016 (UTC)
- Weak support I can see this helping the accuracy and transparency of Wikipedia. My main concern would be the implementation, but I'm open to a trial run to see whether there is any way of doing this. Jolly Ω Janner 19:49, 23 March 2016 (UTC)
- Oppose except where BLP issues are involved. For the most part, the readers who saw the error won't be likely to see the correction. עוד מישהו Od Mishehu 20:56, 23 March 2016 (UTC)
- Support A few years ago I would have agreed with the oppose arguments. However, it now seems to be standard practice on the web to indicate how a news story or other posting has been corrected, in the interest of fuller transparency. It is not a question of who might or might not see it, or what type of website we like to think we still are. It's a matter of principle; we may find ourselves behind the curve sooner than we think. Daniel Case (talk) 21:09, 23 March 2016 (UTC)
- Oppose it's not clear what errors qualify for main page "corrections". It's not clear how the demonstration of such errors fits into the main page design considering that errors can occur in every panel of the main page. There may be a case for a "Corrections" page which can be linked from the main page somewhere so we can confess our sins, but given today's little outburst, it's clear that "disclaimers" will be as erroneous as the errors they are attempting to disclaim. This is not path we need to tread, all articles in Wikipedia are subject to errors, after all. The Rambling Man (talk) 21:25, 23 March 2016 (UTC)
- Support I like this idea, and I agree with Daniel Case that this is a common practice that we should be adopting. Of course, my general opinion is that we put an enormous amount of volunteer effort into selecting and assembling content for main-page visitors who are mostly indifferent to it, and we'd be far better off coming up with alternative, more targeted processes of serving curated content to those likely to be interested in it. But given that we have what we have, I think we should be transparent about our errors and use the opportunity to highlight the wiki process. Opabinia regalis (talk) 21:55, 23 March 2016 (UTC)
- Oppose Errors can occur anywhere. We work on a basis of making corrections as we go. Hawkeye7 (talk) 22:03, 23 March 2016 (UTC)
- Oppose due to the nature of Wikipedia, errors are commonplace. We don't acknowledge previous errors on other articles, not even BLPs. The main page should not be an exception. SSTflyer 07:51, 24 March 2016 (UTC)
- Oppose - Once something is printed or published electronically by a reputable news organization, it isn't expected to change. Wikipedia articles on the other hand are fluid and change is an expectation.
By enshrining the errors within a certain version because it appeared prominently almostWe shouldn't give the impression that we are holding our articles to the publishing standards of organizations who employ correction (newspaper), which we cannot due to the nature of the project.Errors both big and small can exist, and unless we have a body of volunteer scrutinizers to check articles (which begs the question why not preemptively do it),We already reasonably scrutinize the text before it appears on the main page, so if there is an error it might not be discovered or brought to light until much later.In that case more than likely individuals won't check to see if it was present in the version that was linked on mage page (in the unlikely case they even know or remember it has been there) when it is corrected, and the "correction acknowledgment notice" would fail to have listed it(unless there was to be atime limit to catch errors?). Furthermore, consensus would be needed on which errors to report (along the lines of which items to include in the news section). Obviously errors like falsely stating someone was a suspect in a notable assassination attempt nature would be reportedif linked on the main page, but what about smaller factual errors. How long would an error within the text have to be live if it is corrected during the day to warrant a noticeit is linked on the main page?This proposal would probably increase the rate of complex non-factual information being purposely introduced to the pages slated to be displayed there (or planted long before that then nominated) by malevolent editors with the goal of "making the correction acknowledgment notice".Lastly, maintaining a "correction acknowledgment notice" along with the other processes I've described above adds more non-essential work for our volunteers, who could instead be improving encyclopedia articles. Interesting idea, I liked it before I thought to hard about it.—Godsy(TALKCONT) 08:38, 24 March 2016 (UTC)- The proposal is not for errors in the articles linked to from the main page, only for errors actually put on the main page (e.g. for DYK, only errors in the one-line hook would apply, not all errors elsewhere in these articles). All texts put on the main page are already vetted extensively by editors here (through the FA process or the DYK process), so your question about the preemptive vetting is besides the point. Fram (talk) 09:24, 24 March 2016 (UTC)
- Comment: many people compare the main page to other pages, where no corrections are indicated. There are of course a few major differences, including the lack of history on the main page (it is relatively easy to see when an article stated version X or version Y of the truth; it is much harder for most people to find when the main page said X or Y, as it exists of transcluded subpages with different names). Articles are pages "anyone can edit", with the inbuilt risk that they will contain errors. The Main Page is not a page anyone can edit, but a severely restricted and vetted one. This of course doesn't mean that one should support this proposal, but I don't think that only opposing this because we don't do this on articles, is really a sufficient argument ("we have references on all articles, we should have them on the main page as well" would be a comparable reasoning, which I think many of you would oppose). Fram (talk) 09:24, 24 March 2016 (UTC)
- Oppose, per WP:NOT#PAPER and WP:NOT#NEW. Newspapers publish retractions and paper book publishers include errate sheets because they can't correct the extant copies. That does not apply here; we simply issue a corrected "edition" instantly. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 11:18, 24 March 2016 (UTC)
- Comment it would be worth adding a "correction" notice to the talk page of DYKs, for instance, that have suffered major issues and still been on the main page, after all the "DYK" hook is usually added within a template to the article talkpage. It would be easily traceable to add a "correction" parameter to this, or simply add a "Correction" section to the talkpage. The Rambling Man (talk) 11:22, 24 March 2016 (UTC)
- Oppose. We already know where these errors are coming from, this will do nothing to address the underlying issues. Gamaliel (talk) 14:59, 24 March 2016 (UTC)
- Oppose. What concerns me mainly about this proposal is that it would essentially create what amounts to a "DYK shame file" on the front page which would give incentive to those users opposed to DYK to find fault with DYK hooks and/or the underlying articles in order to add hooks to the file. Disputes over content and processes occur all the time on Wikipedia, the front page is not the place for them. Gatoclass (talk) 16:38, 24 March 2016 (UTC)
- DYK is its own shame file sometimes already, this wouldn't change a lot about that. As has been said before, errors in the underlying articles have nothing to do with this proposal. This is about errors (not "finding faults with", but "finding factual errors in"). No idea why you add "disputes over processes", perhaps for the same reason you added "the underlying articles" to your oppose. Still, after your recent comments at WT:DYK, I'm not amazed about these inaccuracies, I just hope not to many uninvolved editors believe them. Fram (talk) 19:56, 24 March 2016 (UTC)
- So, you've never pulled a DYK hook because of issues with the article? It's hardly as if this were an unknown event, so yes, hooks and the underlying articles. With regard to "disputes over processes", what I'm saying is that the main page is not a place for pursuing them, which I fear is what would occur if this proposal were to be adopted. Gatoclass (talk) 08:43, 25 March 2016 (UTC)
- I can't recall pulling a DYK hook from the main page for issues with the article, no. But I may have done, if the article needed deletion as a hoax or if the hook segment in the article was a copyvio or some such problems. But it's a strawman argument anyway, as it doesn't address what I said or what this proposal is about. If a DYK would get pulled for copyvio problems, no correction would need to be put on the main page, and I didn't suggest this. And if a DYK would get pulled for being about a hoax article, the DYK hook would obviously be incorrect and a correction for such an egregious mistake wouldn't be a bad thing anyway. So no, feel free to repeat it as often as you like, but definitely not about the underlying articles. Fram (talk) 10:32, 25 March 2016 (UTC)
- Okay, have it your own way. But I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not. Gatoclass (talk) 11:05, 25 March 2016 (UTC)
- Funny, it is important enough to put on the Main Page that Game X was the first to require Controller Y, but when that information is incorrect, it is suddenly "incredibly trivial". Considering that the majority of DYK hooks is of comparable triviality, perhaps we should just get rid of it? That would free up time for quality control in all articles and remove lots of bureaucracy and problems. But I have the feeling that that is not what you had in mind when you wrote the above. Fram (talk) 11:36, 25 March 2016 (UTC)
- On the contrary, I have never denied that many DYK hooks deal with trivia, and I'm not bothered by it, because DYK is not about finding a bunch of portentous facts, but about demonstrating that Wikipedia is an ever-expanding knowledge base on the widest possible variety of topics. You, by contrast, like on the one hand to disparage DYK on the basis that it deals with trivia, but on the other apparently expect the community to have conniptions over the fact that a small percentage of the trivia featured might on occasion be erroneous. Gatoclass (talk) 12:34, 25 March 2016 (UTC)
- (on second thoughts, forget it. I'm done with replying to your wild accusations time and time again. People who follow DYK without seeing DYK as a goal in itself will know my real objections against it (which is not triviality), the amount of errors, and the amount of those I catch after they have been approved but before they hit the mainpage as well. Those things are more telling than whatever you may come up with next. Fram (talk) 13:12, 25 March 2016 (UTC) )
- On the contrary, I have never denied that many DYK hooks deal with trivia, and I'm not bothered by it, because DYK is not about finding a bunch of portentous facts, but about demonstrating that Wikipedia is an ever-expanding knowledge base on the widest possible variety of topics. You, by contrast, like on the one hand to disparage DYK on the basis that it deals with trivia, but on the other apparently expect the community to have conniptions over the fact that a small percentage of the trivia featured might on occasion be erroneous. Gatoclass (talk) 12:34, 25 March 2016 (UTC)
- Funny, it is important enough to put on the Main Page that Game X was the first to require Controller Y, but when that information is incorrect, it is suddenly "incredibly trivial". Considering that the majority of DYK hooks is of comparable triviality, perhaps we should just get rid of it? That would free up time for quality control in all articles and remove lots of bureaucracy and problems. But I have the feeling that that is not what you had in mind when you wrote the above. Fram (talk) 11:36, 25 March 2016 (UTC)
- Okay, have it your own way. But I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not. Gatoclass (talk) 11:05, 25 March 2016 (UTC)
- I can't recall pulling a DYK hook from the main page for issues with the article, no. But I may have done, if the article needed deletion as a hoax or if the hook segment in the article was a copyvio or some such problems. But it's a strawman argument anyway, as it doesn't address what I said or what this proposal is about. If a DYK would get pulled for copyvio problems, no correction would need to be put on the main page, and I didn't suggest this. And if a DYK would get pulled for being about a hoax article, the DYK hook would obviously be incorrect and a correction for such an egregious mistake wouldn't be a bad thing anyway. So no, feel free to repeat it as often as you like, but definitely not about the underlying articles. Fram (talk) 10:32, 25 March 2016 (UTC)
- So, you've never pulled a DYK hook because of issues with the article? It's hardly as if this were an unknown event, so yes, hooks and the underlying articles. With regard to "disputes over processes", what I'm saying is that the main page is not a place for pursuing them, which I fear is what would occur if this proposal were to be adopted. Gatoclass (talk) 08:43, 25 March 2016 (UTC)
- Oppose - Serves no purpose. We already have Wikipedia:Main Page/Errors. — Maile (talk) 18:32, 24 March 2016 (UTC)
- That page is for readers to contact us (editors) to correct a page. This proposal is for the reverse, to let the readers know that despite our vetting, we posted incorrect information on the main page. Which you are free to oppose, of course, but confusing things doesn't help. Fram (talk) 19:56, 24 March 2016 (UTC)
- Support assuming it's not ugly or intrusive. I think it'd be a service to readers to let them know when they have been accidentally misinformed. --Jakob (talk) aka Jakec 19:27, 24 March 2016 (UTC)
- Support; above all, Wikipedia is a source for information, and any incorrect information which is distributed by Wikipedia should be corrected. Because of the high traffic volume of the main page, a mistake there carries more weight than a mistake elsewhere, and should be treated thusly. Something along the lines of the first of Fram's two examples above appeals to me; a small notation under the day's DYK's is nonintrusive yet useful. Colonel Wilhelm Klink (Complaints|Mistakes) 21:41, 24 March 2016 (UTC)
- Support Noting that online editions of newspapers do include corrections. As the possible negative impact on living persons where incorrect contentious claims have been made are clearly significant, and as WP:BLP avers that we must avoid damage to living persons, any error which might improperly affect living persons should be corrected with the same visibility as was given the incorrect claim or information. For matters of "how old was the fossil" - such errata are of far less importance, but where specific living persons are concerned, I find the "but facts are of minor value" position to be wrong. Collect (talk) 23:25, 24 March 2016 (UTC)
- Oppose. My opinions on the main page's accuracy issues are fairly well known, and I'd seriously consider abolishing the MP altogether and replacing it with www.wikipedia.org given the amount of hassle it causes for dubious benefit. That said, I agree with every word of
I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not
above. ‑ Iridescent 11:29, 25 March 2016 (UTC)- Then please see my reply above to that statement. The DYK errors are just as incredibly trivial as the DYK hooks, so arguing that the corrections should not be displayed is basically an argument that the hook should not have been displayed in the first place. Which goes back to your first argument of course (which has considerable merit), but is hardly a reason to oppose posting corrections as long as we are stuck with DYK. Fram (talk) 11:39, 25 March 2016 (UTC)
- You know my opinion of DYK, which I consider an embarrassment to Wikipedia, but in practice it's kept as a recruiting tool ("if you write an article, we'll showcase it on the main page") and virtually nobody actually reads the things. (The MP gets about 15-20 million hits per day, and the DYK project considers it noteworthy if a DYK gets over 5000 hits.) Publishing "errata slips" would be a time-consuming and open-ended undertaking for minimal benefit, since in practice nobody cares. The BLP issue is something of a strawman, given that while there certainly have been libellous statements about living people made it onto the MP, I could probably count the instance since the MP was instituted in 2004 on the fingers of one hand; the typical MP error is more along the lines of "you say the Sikorsky S-51 helicopter was built for civilian use but they were actually used primarily by the military"; a rolling log of this kind of correction would be of no interest to anyone, and just add to the already cluttered main page. In the unlikely event of a genuinely serious error, a retraction could be published on the MP if deemed appropriate, but that is already the case, and I don't see what's gained by just adding to the clutter to make statements like "On 10 March, we posted that the Devanahalli pomelo is the world's largest citrus fruit. However, this statement is not verifiable in the sources provided." other than as a stick with which to beat the repeat offenders at DYK. (It could also offer a perverse incentive to introduce errors, by those trying to boost pageviews, since published corrections would mean the item appearing on the main page for a second time.) ‑ Iridescent 12:18, 25 March 2016 (UTC)
- Okay! Fram (talk) 12:21, 25 March 2016 (UTC)
- What I certainly would support is a three-strikes system at DYK, where any nominator who has three substantive "this hook is not true" complaints against them upheld is banned from DYK. I don't think I'm giving away any great secret in saying that a couple of editors are responsible for a disproportionate amount of the fabrications and mis-citations that get into DYK,* but AGF discourages people from calling them out on it because of the inevitable backlash from the regulars closing ranks. ‑ Iridescent 15:27, 25 March 2016 (UTC)
*Once as an exercise, I went through one of the worst offenders's articles line-by-line annotating every untrue statement, claim not supported by the source, use of inappropriate sources, improper synthesis and even a citation to a novel as if it were fact. This was an extreme case, but not extreme enough as to be unique. ‑ Iridescent 15:27, 25 March 2016 (UTC)
- What I certainly would support is a three-strikes system at DYK, where any nominator who has three substantive "this hook is not true" complaints against them upheld is banned from DYK. I don't think I'm giving away any great secret in saying that a couple of editors are responsible for a disproportionate amount of the fabrications and mis-citations that get into DYK,* but AGF discourages people from calling them out on it because of the inevitable backlash from the regulars closing ranks. ‑ Iridescent 15:27, 25 March 2016 (UTC)
- Okay! Fram (talk) 12:21, 25 March 2016 (UTC)
- You know my opinion of DYK, which I consider an embarrassment to Wikipedia, but in practice it's kept as a recruiting tool ("if you write an article, we'll showcase it on the main page") and virtually nobody actually reads the things. (The MP gets about 15-20 million hits per day, and the DYK project considers it noteworthy if a DYK gets over 5000 hits.) Publishing "errata slips" would be a time-consuming and open-ended undertaking for minimal benefit, since in practice nobody cares. The BLP issue is something of a strawman, given that while there certainly have been libellous statements about living people made it onto the MP, I could probably count the instance since the MP was instituted in 2004 on the fingers of one hand; the typical MP error is more along the lines of "you say the Sikorsky S-51 helicopter was built for civilian use but they were actually used primarily by the military"; a rolling log of this kind of correction would be of no interest to anyone, and just add to the already cluttered main page. In the unlikely event of a genuinely serious error, a retraction could be published on the MP if deemed appropriate, but that is already the case, and I don't see what's gained by just adding to the clutter to make statements like "On 10 March, we posted that the Devanahalli pomelo is the world's largest citrus fruit. However, this statement is not verifiable in the sources provided." other than as a stick with which to beat the repeat offenders at DYK. (It could also offer a perverse incentive to introduce errors, by those trying to boost pageviews, since published corrections would mean the item appearing on the main page for a second time.) ‑ Iridescent 12:18, 25 March 2016 (UTC)
- Then please see my reply above to that statement. The DYK errors are just as incredibly trivial as the DYK hooks, so arguing that the corrections should not be displayed is basically an argument that the hook should not have been displayed in the first place. Which goes back to your first argument of course (which has considerable merit), but is hardly a reason to oppose posting corrections as long as we are stuck with DYK. Fram (talk) 11:39, 25 March 2016 (UTC)
- Oppose per Primehunter. Most DYK errors are not egregious enough and do not receive enough complaints from people to warrant special notice on the main page, especially since they are quickly corrected. If for some reason it does, a special case could be made, but I find that situation unlikely. I would instead suggest that stronger fact-checking is done during the nomination process to prevent this situation from occurring in the first place. ZettaComposer (talk) 14:11, 25 March 2016 (UTC)
- Oppose although I get where Fram is coming from. Not only is running a corrections column going to take extra editor work as well as valuable real estate on the Main Page, it really advertises shameful inaccuracies instead of being transparent with the reader. I agree with Andrew D that the disclaimer need to be far more prominent. Instead, why don't we hand out one-day blocks of editors responsible for these errors making it to the Main Page? Like Iridescent's three strikes concept, the editor is banned from those processes (DYK, ITN, etc.) where they've proven incompetent. Let's cure the disease (inaccuracy causing reader unhapiness) rather than treat the symptom (mollifying readers thru Mea culpa). Chris Troutman (talk) 15:35, 27 March 2016 (UTC)
- Support. I think that if a statement appears on the Main Page but is determined to be incorrect, it would be appropriate to post a correction on the Main Page, in hopes that the truth will reach as many people as the false statement did. Blocking the editors responsible for the incorrect information may be an appropriate punishment, but it doesn't by itself promulgate the correction. --Metropolitan90 (talk) 05:34, 28 March 2016 (UTC)
- Blocking is not necessarily appropriate, because blocks are not for "punishment". Especially on a first offense, the editor responsible for the incorrect information was more than likely submitting it in good faith, and mistakes happen even among competent, good-faith contributors. The correct approach is to advise them to learn from the mistake and move on. If the editor repeatedly makes the mistake in spite of numerous warnings/advice in response, that's when a preventative block or a ban from the process should be considered. Mz7 (talk) 21:15, 2 April 2016 (UTC)
- Support If the Main Page is run like a newspaper, then why not have corrections as well? Obviously some people are reading the DYKs. If the facts are in error, then we should attempt to inform those readers of the error. I also would support either a three strike or block policy for those responsible. FuriouslySerene (talk) 14:09, 29 March 2016 (UTC)
Displaying pronunciatiin of a word in regional language
Hello Friends, I would like to suggest to Display pronunciation of the word searched by user in regional language, like in India, Regional language is Hindi or Marathi.
For Ex. consider a word Revoke so while displaying on wikipedia page as
Revoke ( रिवोक )
This will help reader to know the correct pronunciation of the word.— Preceding unsigned comment added by PGAwade (talk • contribs)
- There's too many languages to do that, and many local languages cannot accurately represent sounds in other languages. Many articles do feature the International Phonetic Alphabet pronunciation, which is meant to be language neutral (in other words, anyone who speaks any language who learns how to read the IPA can use it to pronounce any word). Ian.thomson (talk) 04:03, 24 March 2016 (UTC)
- Strongest possible oppose This is the ENGLISH Wikipedia. We should never, ever have text in languages other than English except for cases like the native names of proper nouns. Also, in your example, there's nothing at all that would make Hindi or Marathi special with regards to the term "revoke", so the only way we could fairly do that would be for every word to be accompanied by hundreds of languages' worth of pronunciations. Jackmcbarn (talk) 20:49, 28 March 2016 (UTC)
- User:PGAwade, may I suggest that this idea is far more appropriate for wiktionary? That said, I suggest that you learn IPA (IPA for English should help) and use those pronunciations where available. Oiyarbepsy (talk) 04:33, 29 March 2016 (UTC)
- Oppose, per Jack. The IPA for the standard English pronunciation should sufficeThere is already too much of English-as-an-official-2nd-language countries trying to turn the English Wikiedia into their Wikipedia. More effort should be spent by those nationals in developing and expanding their home-language Wikis (and believeme, living in the thick of it here in Asia, I know what I;m talking about). Kudpung กุดผึ้ง (talk) 11:23, 30 March 2016 (UTC)
"Research help" proposal
- Backgound
A pilot project has added this template (or something similar):
to 10,633 articles with a "References" section - based solely on discussions at two WikiProjects, initiated by User: Astinson (WMF) (really the respected user User:Sadads).
It is intended to add these to all articles.
The purpose is to solve a problem or problems. The problem should be stated in Wikipedia:Research_help/Proposal#What_are_we_trying_to_solve?, but there is no clear statement of a problem or problems.
The template links to a page which needs to be read to understand the likley effect. Among other things it makes categorical statements about biases, editors and Wikipedia article which could be contentious, and embeds a not-strictly-accurate video.
A number of editors (including me) are not happy with having this text linked to form the bodies of of some 10,633 articles, many dealing with important topics, without a VP approval.
There are many issues here, including WMF-community relations, believing projects WP:OWN the articles in their scope and cross-namespace links.
I would like to focus on one proposal however:
Proposal
The existing 10,633 article "pilot" be suspended by blanking the template, and no further templates added. When a proper VP proposal for a pilot has been made and passed, which should include community review of the template wording, the help page wording and the purposes behind it, the pilot may continue. If the proposal is not made, or does not pass, within a month from today, the templates will be removed. Meanwhile editors are free to remove the templates in the normal course of editing using editorial discretion.
Pings
|
---|
Those who commented on Wikipedia talk:Research help. Astinson (WMF) Dirk Beetstra Brigade Piron CFCF Dialectric Roger (Dodger67) Esquivalience Fram Green Hazard Hzh JFW Jytdog Help! Kendall-K1 Kerry KMJKWhite MichaelMaggs MilborneOne Moxy Navyvet2016 NiD.29 Ocaasi (WMF) Pgcudahy Rhododendrites Sadads Steelpillow WhatamIdoing Wugapodes Additional editors from TfD (possible duplicates) theWOLFchild Anotherclown BethNaught Bilorv CFCF clpo13 David Eppstein Dialectric Drmies Garion96 Geogene Hawkeye7 In actu (Guerillero) Izno Jytdog Kierzek KMJKWhite Tom (LT) Martynas Patasius MichaelMaggs Mitch Ames Navyvet2016 Necrothesp Nick Nyttend Ozzie10aaaa Peter (Southwood) RexxS Scolaire Teaktl17 Ed Yaush Yngvadottir Apols if anyone missed. |
All the best: Rich Farmbrough, 18:21, 24 March 2016 (UTC).
I dug up relevant pages I could find:
- WikiProject_Medicine discussion: Supported.
- WikiProject_Military_history discussion: Supported.
- Village Pump Technical: There was mention of a posting there, but I couldn't find it.
- Bot approval discussion:
- Approved. 10,000 pages maximum.
- any further scaling beyond that cap would require Community concensus (referring to Village pump)
- Template for discussion: Heated no consensus. Many 'keeps' were limited to a 1-month test.
- This project's Talk page: mostly complaints.
Alsee (talk) 13:06, 25 March 2016 (UTC)
Support (stop the "pilot" until consensus is reached)
- Not suitable placement, unclear motivation, target page needs work. Also breach of WMF-community protocol which needs reining in. All the best: Rich Farmbrough, 18:21, 24 March 2016 (UTC).
- Pause until we know what we have. GenQuest "Talk to Me" 03:22, 25 March 2016 (UTC)
- Pause at least and consider rolling back until there's been consensus considerably stronger than "well, I asked a few people and nobody actively disagreed". It's clear from Wikipedia:Research_help/Proposal#Who is affected? that the intent is to add this to every page on Wikipedia, but there's no obvious impact assessment I can see. On longer articles, it's likely to be lost in the general goop of navboxes, Commons links, portals and external links at the bottom of the page if not made even more obtrusive than it already is, but making it obtrusive enough to stand out to readers will make it an obnoxious and distracting presence on shorter stub articles. Even the actual proposal itself makes it clear that spamming this template isn't appropriate. I have no doubt of the good faith of those involved, but this looks like yet another case of someone at the WMF with a pet project assuming that everyone else is as enthusiastic for their idea as they are themselves, and before it goes any further it needs a discussion among the broader editor base as to whether the benefits of this outweigh the problems, and how to implement it if it does go ahead. ‑ Iridescent 11:06, 25 March 2016 (UTC)
- Pause and consider rolling back per Iridescent. In addition, I definitely don't support embedding this into content. Regardless of whether it's needed, this is not the right way to go about it. It should be presented as meta-content (it currently doesn't even use the
selfref
class or similar), it should be presented in the right place as meta-content relevant to the whole wiki (Main Page or sidebar spring to mind?), and I'd want confirmation before placing it in the references section, where I'd bet it's not read by the people who need it and annoying to the people that don't. {{Nihiltres |talk |edits}} 16:42, 25 March 2016 (UTC) - Stop the pilot and roll back. Self-referential meta-content should not appear in the text of articles and this wide-reaching change should have been brought forward for project-wide consensus rather than consulting just a few wiki-projects, who do not control the relevant articles. Also see my comment below about timelines. BethNaught (talk) 22:23, 25 March 2016 (UTC)
- Stop the pilot and roll back promptly. As per BethNaught, this kind of self-refereential content does not belong on article pages. The idea is clearly intended to help readers, but a better way must be found to do this. Do not wait another two weeks to roll this back, and certainly no longer. DES (talk) 09:32, 26 March 2016 (UTC)
- Strongly stop the pilot If I had known this had existed, I would have strongly objected. The fact that this project was done without the consensus of the community (WP:VP) undermines the project's ideals. Programming G E E K (mah page! // use words to communicate page) 11:37, 26 March 2016 (UTC)
- Support This and anything like it needs needs project wide consensus before implementation; and in this specific case, there needs to be wider discussion on the best method for implementation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 26 March 2016 (UTC)
- Strong support: Consensus represents both the concerns of editors as well as the wishes of the entire community. Although the WikiProjects asked were in no way small, they cannot speak for the entire community nor is the community devoid of objections to this project. Esquivalience t 02:35, 27 March 2016 (UTC)
- Support. Roll back until more widely discussed and piloted. JFW | T@lk 07:54, 27 March 2016 (UTC)
- Support. As I was saying in the discussion concerning the template, it is not just annoying, it is not just violating guidelines about self-references, it also links to the page that is misleading the readers (into thinking that Wikipedia is more reliable than it is) with various "Finally, Wikipedia's millions of readers catch and fix flaws when they find them." or "This works most of the time because many eyeballs make all bugs shallow," (still there in the current version - Special:Diff/711865882). Or, at least, it would be misleading them, if they were actually reading it, which isn't certain (hardly anyone has cited anything from that page in any of those discussions, and the ones who participate in them could be expected to be more motivated to read all that than an average reader) - but if no one reads that page, the template is still useless. And we already know much about this idea (most importantly - that it is not good), thus there isn't much to research, meaning that the further trial is unlikely to be useful. And if it is misleading, violating guidelines, annoying and useless, I'd say that the trial should be stopped. --Martynas Patasius (talk) 18:28, 27 March 2016 (UTC)
- Support as per User:Rich Farmbrough. Jason Quinn (talk) 15:44, 30 March 2016 (UTC)
Oppose (allow the "pilot" to continue ad lib)
- Continue Does it really hurt anything for a 30-day test. Give me a break people. The real question is should they remove them all after the trial is up. Oiyarbepsy (talk) 03:24, 25 March 2016 (UTC)
- continue just give it a chance--Ozzie10aaaa (talk) 23:47, 25 March 2016 (UTC)
- Continue for the next 9 days trial will end on April 7 anyway. I support in general improving articles and the way we communicate article content; part of this involves trying new things. Trying things inherently carries a component of risk (on wikipedia at least: mainly to the proposer of a trial's mental health and wellbeing). This was a small trial with local consensus that has a defined endpoint in 9 days. What a storm in a teacup.--Tom (LT) (talk) 17:12, 27 March 2016 (UTC)
- Oppose, forum shopping after Wikipedia:Templates_for_discussion/Log/2016_March_8#Template:Research_help with no notice to participants there (those pings did not work), plus only a couple days left anyway. Ed [talk] [majestic titan] 01:12, 3 April 2016 (UTC)
- Oppose per above, it's ending soon anyway, and could be possibly useful. I would prefer it if more consultation was done before implementing something like this, though. I am also concerned with the implementation of a result here by the person who proposed it. Ajraddatz (talk) 03:54, 3 April 2016 (UTC)
Neutral
- Neutral Were this a proposal, I would have opposed its implementation. I don't think this is the right way to go about solving the "problem" of helping people do research. But that's not what this discussion is, and I think we can cross that bridge when we get to it. This pilot has a hard stop on April 7th. After going 600 article over the pilot amount, the bot stopped adding them to pages. I don't particularly see a problem with leaving it on these pages for about 10 more days and then addressing whether we want to let it keep going. I don't want it to continue (which is why I'm not in oppose) but I see very little difference between the pause outcome and what's already occurring. By the time we develop consensus, it will likely be just a few days from the pause outcome and when it would have naturally ended anyway. I don't really feel comfortable in either support or oppose because of that, so here I stand. Wugapodes (talk) 18:59, 26 March 2016 (UTC)
- can I do the same? Can I? Can I?. I want to add a very nice test I thought of to a mere 10,000 of WP's pages for only one month. Can I? That is, although the intention looks good, it looks very bad. ANd no, Ignoring All Rules is not a good argument to add a poorly designed link to a disclaimer-like page. Anyway Wugapodes makes a good point. Why bother... Lets move on to discuss the big picture, and check if anyone says they will clean up after the deadline and then 'forget' to. - Nabla (talk) 21:26, 26 March 2016 (UTC)
Additional discussion
The Bot approval discussion should have bounced this to Village pump. It should have been foreseeable that controversy would arise over 10,000 "experimental" cross-namespace links (with an icon to boot) added to the Reference lists. The intentions are good, but this is way outside any commonly accepted norms. Any cross-namespace link in an article is typically revert-on-sight, and any content unrelated to the article it is in is also typically revert-on-sight.
It appears that this "pilot" is planned to end in a few days anyway, after which they planned to come to Village Pump anyway. It looks like this discussion is mostly moot, unless it gets a real fast Snow close. Even with a quick Snow close it would make little difference to the apparent end-date anyway. Alsee (talk) 13:31, 25 March 2016 (UTC)
- @Alsee: Could you point me to a specific end date? Also, I will say that pilots have a nasty habit of lingering longer than intended (cf Pending Changes trial) and that it could take an exceedingly long time for them to come here, given there are several steps in the given roadmap between the trial phase and the Village Pump phase. The roadmap is not at all clear. BethNaught (talk) 22:23, 25 March 2016 (UTC)
- Hi all. Thanks for bringing this up for discussion, we really appreciate the wide range of feedback we have been getting. We had been hoping to collect more data, so that we could reflect on a data-informed discussion (hence the pilot and limited discussion). We hadn't previously documented a specific removal date, because of the delays in the bot activity and variability in visibility created by the TFD (skewing both the feedback and pageviews). However, based on when the bot implemented, I plan to noinclude the template, on or before April 7 (or via concensus of course). I documented it with this edit. I will engage more in the discussion tomorrow. I look forward to any questions and discussion, Astinson (WMF) (talk) 01:44, 26 March 2016 (UTC)
- Thanx.
- Rich_Farmbrough, the noinclude on the template will blank the template as proposed, additions of the template have already hit the bot-approval cap, and the previously stated intent is a Village Pump proposal before proceeding any further. It seems the objectives of this proposal have been agreeably satisfied. How about withdrawing & boxing the unneeded support/oppose sections? We can leave this discussion section open. Alsee (talk) 04:09, 26 March 2016 (UTC)
- I think it's quite useful. I am also not very happy with the idea that this project has "snuck under the radar". I thought perhaps I was being a little cynical entertaining this idea, but I now see that the project was advised to come here back in November, by User: WhatamIdoing
- I think it's quite useful. I am also not very happy with the idea that this project has "snuck under the radar". I thought perhaps I was being a little cynical entertaining this idea, but I now see that the project was advised to come here back in November, by User: WhatamIdoing
- Hi all. Thanks for bringing this up for discussion, we really appreciate the wide range of feedback we have been getting. We had been hoping to collect more data, so that we could reflect on a data-informed discussion (hence the pilot and limited discussion). We hadn't previously documented a specific removal date, because of the delays in the bot activity and variability in visibility created by the TFD (skewing both the feedback and pageviews). However, based on when the bot implemented, I plan to noinclude the template, on or before April 7 (or via concensus of course). I documented it with this edit. I will engage more in the discussion tomorrow. I look forward to any questions and discussion, Astinson (WMF) (talk) 01:44, 26 March 2016 (UTC)
did you spam notices about this to the Village Pumps or anything like that? There was an objection last year (with a script that displayed the editors'/authors' names on the page) that was framed as being a procedural complaint about a LOCALCONSENSUS by a WikiProject. It would be desirable to have attention from non-participants, especially since WPMED doesn't OWN the articles
- to which User:Astinson (WMF) replied:
We were aware of that experience. We are operating under the assumption that this is not going to have many strong objections: every person we have shown this to has had no show-stopping objections (mostly positive tweaks, etc), we plan to do this a temporary pilot to see if there is evidence of its usefulness, and it will be a template that can be "noincluded" at a moments notice.
- There have been numerous objections, and the template has not been "noincluded" - except by me, and that was reverted.
- This is not a small thing, it is, arguably, damage to 10,633 articles.
- All the best: Rich Farmbrough, 05:41, 26 March 2016 (UTC).
- I was referring to the existing agreement "to noinclude the template, on or before April 7". I don't see what's really being added by piling on supports for what's going to happen anyway. I'm surprised there were no objections raised at MED or MILHIST and I think BOT-approval should have bumped this unusual edit to Pump, but I think we can take this as a good faith situation with an uncontested end to the pilot. Alsee (talk) 10:26, 26 March 2016 (UTC)
- If the pilot is going to end naturally, this poll is redundant and ought to be closed. Note that when it was started there was not a clear date, but now there is I agree with you. BethNaught (talk) 10:43, 26 March 2016 (UTC)
- "Damage" is a pretty strong word to use there, Rich. Ed [talk] [majestic titan] 01:14, 3 April 2016 (UTC)
- The pages are worse with the message displaying. They are therefore damaged. Deliberately making the encyclopaedia worse is something up with which I will not put.
- All the best: Rich Farmbrough, 01:34, 3 April 2016 (UTC).
- That's just your opinion, which is why I find it strange that you are closing this discussion. Ed [talk] [majestic titan] 01:46, 3 April 2016 (UTC)
- If not me, who? If not now, when? All the best: Rich Farmbrough, 02:00, 3 April 2016 (UTC).
- WP:AN has an entire section devoted to requests for closure... Ed [talk] [majestic titan] 02:37, 3 April 2016 (UTC)
- I was referring to the existing agreement "to noinclude the template, on or before April 7". I don't see what's really being added by piling on supports for what's going to happen anyway. I'm surprised there were no objections raised at MED or MILHIST and I think BOT-approval should have bumped this unusual edit to Pump, but I think we can take this as a good faith situation with an uncontested end to the pilot. Alsee (talk) 10:26, 26 March 2016 (UTC)
Proposal implemented
Per consensus. I see no value in leaving the message in articles any further. Sufficient data should already be collected. Per the proposal, the pilot can be resumed by gaining consensus here.
Do I feel like the bad guy? Yes. But I also felt like the bad guy leaving the message in 10,633 articles when there is consensus here to remove it, and many other objections have been voiced. Had my questions on to pilot talk page been answered, I might have lapsed into inaction for another few days.
All the best: Rich Farmbrough, 00:02, 3 April 2016 (UTC).
- I've reverted. You should really leave notices to previous participants, as many interested parties don't watch this page (note that your pings above did not work, probably because they weren't followed by a signature, but I can't be sure). That's probably why you don't have many !votes above. In addition, you should leave the closing of such a proposal to a neutral third party. Thanks. Ed [talk] [majestic titan] 01:11, 3 April 2016 (UTC)
- I have noincluded the template just as the WMF staffers said it could be if there was any objection.
- I therefore think it unreasonable for said WMF staffers to revert, especially since we have clear consensus.
- Nor is it concomitant with Wiki culture to filibuster, to get the "required" outcome.
- I have re-reverted. In doing this I am protecting the encyclopedia, there should be no reversion unless there is a compelling reason.
- All the best: Rich Farmbrough, 01:29, 3 April 2016 (UTC).
- This is not 'protecting the encyclopedia,' it's stifling innovation and ignoring that you improperly notified all of the previous participants in past discussions. See my comments above. Also, like in the TFD, I'm commenting here in my volunteer role only. You can see my disclaimer on my user page, my posts to Fram's talk page, and/or as I said at the TfD: I've been a Wikipedian and supporter of the Wiki Library for long before I or it joined the WMF. My edits and thoughts here are mine and mine alone; my personal views very frequently differ from the WMF's official lines. Ed [talk] [majestic titan] 01:44, 3 April 2016 (UTC)
- Nothing is being stifled here, except a poorly thought out implementation of what may be a good idea. The fact that there are no answers after many days to questions about this pilot suggest that it is not being seriously pursued or considered any more by those involved - except perhaps with the hope that it gets past the planned end date through the operation of WP:BURO.
- I too support the Wiki Library, that does not mean that I have to support every project that is shoved under its banner.
- As to which hat you are wearing, you were involved with the discussion started by User:Jytdog in relation to this project "my official capacity". I don't think you can convincingly switch hats in this circumstance, and I am certain that it is unwise to do so.
- All the best: Rich Farmbrough, 02:14, 3 April 2016 (UTC).
- First, that conveniently ignores my positions taken before that on WT:MILHIST and the TFD. No hat-switching back and forth. Second, while Jytdog's discussion started from the debates surrounding this trial, it quickly became a larger discussion about how the WMF interacts with the community. I said that in the discussion as well, but your truncated quote above doesn't exactly capture the actual sentiment of the sentence: "Going to jump in here in my official capacity, which I think(?) is the right one for this conversation." (emphasis mine)
- I take pains to note when I'm writing in a volunteer (untethered to the WMF) or an official (tethered to the WMF) capacity. I'm sure there are plenty of ways to discredit me as a volunteer and there will be a mistake at some point, but that isn't one of them and this isn't that time. Ed [talk] [majestic titan] 02:44, 3 April 2016 (UTC)
- This is not 'protecting the encyclopedia,' it's stifling innovation and ignoring that you improperly notified all of the previous participants in past discussions. See my comments above. Also, like in the TFD, I'm commenting here in my volunteer role only. You can see my disclaimer on my user page, my posts to Fram's talk page, and/or as I said at the TfD: I've been a Wikipedian and supporter of the Wiki Library for long before I or it joined the WMF. My edits and thoughts here are mine and mine alone; my personal views very frequently differ from the WMF's official lines. Ed [talk] [majestic titan] 01:44, 3 April 2016 (UTC)
- All the best: Rich Farmbrough, 01:29, 3 April 2016 (UTC).
Banter
I don't know how many people feel like me but I've always wanted Wikipedia to be a fun kind of place. We get work done, but let it not feel like drudge. So, I propose we make a page for banter where we can get together and do some shiz. I don't know how will other people will feel about this but hey, atleast I've spoken my mind. --QEDK (T 📖 C) 16:53, 27 March 2016 (UTC)
- Maybe Wikipedia:Village pump (banter) ? All the best: Rich Farmbrough, 22:06, 27 March 2016 (UTC).
- We had that many years ago. It was called Wikipedia:Esperanza. It was killed with pitchforks and torches for upsetting the local villagers. --Jayron32 02:09, 28 March 2016 (UTC)
- It seems to have dissolved into some useless bureaucracy that caused it to be brought down. I went through it and why not just make a coffee lounge kind of place? (If enough people support this proposal, I'll frame some rules and make one) --QEDK (T 📖 C) 14:26, 28 March 2016 (UTC)
- I think it could be fun to have a relaxed kind of place on here where it wouldn't be all about AfD fights, vandalism and other unpleasant aspects of the encyclopedia. I would support it. White Arabian Filly Neigh 21:53, 29 March 2016 (UTC)
- I've seen other online entities that had a "work" part and a "banter" part. The banter parts were so lightly used that a little banter remained in the "work" part, because if it were put in the banter part hardly anyone would see it. Jc3s5h (talk) 12:51, 30 March 2016 (UTC)
- I think this would be a good thing to have. We need a place to see our fellow editors as human beings and make links. In fact, it would help me no end in my NPP and newbie welcoming tasks if I knew some editors working in various areas. However, get ready for the shouts of wp:nothere :) Happy Squirrel (talk) 01:16, 31 March 2016 (UTC)
- I've seen other online entities that had a "work" part and a "banter" part. The banter parts were so lightly used that a little banter remained in the "work" part, because if it were put in the banter part hardly anyone would see it. Jc3s5h (talk) 12:51, 30 March 2016 (UTC)
- I think it could be fun to have a relaxed kind of place on here where it wouldn't be all about AfD fights, vandalism and other unpleasant aspects of the encyclopedia. I would support it. White Arabian Filly Neigh 21:53, 29 March 2016 (UTC)
- It seems to have dissolved into some useless bureaucracy that caused it to be brought down. I went through it and why not just make a coffee lounge kind of place? (If enough people support this proposal, I'll frame some rules and make one) --QEDK (T 📖 C) 14:26, 28 March 2016 (UTC)
- Wikipedia is not a social network. Such a page cannot be reconciled with our policies. RGloucester — ☎ 01:58, 31 March 2016 (UTC)
- Given that the goal of this banter page would be to increase collaboration by allowing less structured interraction, the end goal does focus on Wikipedia. I would tend to see this more as similar to meetups being organised on-wiki. From reading the policy you linked, I rather got the impression it was forbidding using Wikipedia as a place to conduct one's off wiki social life, not as forbidding social interractions with people we are contributing to Wikipedia with. Happy Squirrel (talk) 02:11, 31 March 2016 (UTC)
About {{Commons category}} , Commons category-inline}}, {{Wikisource}}, {{Wikisource-inline}}, {{Wikisource author}} and the like
Now that Wikidata often has info about a particular Wikipedia page's corresponding Wikimedia Commons category or Wikisource page or the like, is it really necessary to keep this kind of templates in the article? They have the same function! I've removed this kind of templates in these pages, however sometimes someone reverted my removals, so here I ask other Wikipedians' opinion.--RekishiEJ (talk) 03:35, 30 March 2016 (UTC)
- Keep them. IMHO it is really necessary to keep this kind of templates in articles and you should not remove them.
I think you're proposing that rather than have a direct link from an article to its corresponding Commons category (say), readers would have to find and click the "Wikidata item" link and look in Wikidata simply to find whether there's a Commons category, and if so, go to it?
Technically, that works, but Wikidata isn't user-friendly (nor intended to be); and anyway, it's surely much more friendly to have a link from a WP article to its Commons category, rather than make the reader go elsewhere simply to find out whether there is one!
With the increasing amount of linkage in Wikidata, it'd be good if these link boxes could be placed automatically, so that articles wouldn't have to contain templates such as {{Authority control}} or, indeed, Commons category}}, because the information would appear automatically. But I don't know whether such an enhancement is on the radar. — Stanning (talk) 11:48, 30 March 2016 (UTC)
- Keep, our sister projects are so intertwined with Wikipedia and its editors that more links, not less, should be the norm. All the images, for example, are now "off-site" in commons, so the lines are not only blurred but come together nicely. I've strongly advocated including a few sister-project links at the bottom of topic templates, for example, and hopefully more editors are coming around to that position as well. Randy Kryn 11:57, 30 March 2016 (UTC)
- I mean, now that these info on Wikidata are shown on the "In other projects" section, is it really necessary to keep the templates anymore? For example, readers of the Wikipedia article Dmitry Rogozin can access the corresponding English Wikiquote page simply by clicking the Wikiquote link shown on the IOP section, in my opinion {{Wikiquotes}} should be removed from the article.--RekishiEJ (talk) 12:38, 30 March 2016 (UTC)
- Keep - All templates are extremely helpful here and not only that but in the last 3/4 years of me being here I've never ever known about the "In other projects" section and that's because I obviously never pay attention to that area, So having these links makes it so much easier expecially for those who have no idea about the IOP thing, (BTW sorry but I've reverted you on the Dimitry article as you should really get consensus to remove them anyway), –Davey2010Talk 01:59, 2 April 2016 (UTC)
"Event coordinator" user group
I propose creating a new user group, entitled "event coordinator", which has the following rights;
(noratelimit)
- This allows users to create more than 6 accounts on a single IP in a 24-hour window. Currently, users are given the "account creator" flag, but this also gives access to override spoofing checks and the title blacklist, something event coordinators don't need.(ipblock-exempt)
- Many time events are held at libraries of universities, and often these are blocked. This would allow for them to create accounts for others, even though the IP is blocked.Add groups: Confirmed users
- Often a source of backlog at PERM, as editors start to get the needed editing experience at events but don't have the needed four days tenure.
This right would be given by sysops at WP:PERM either for short amounts of time or permanently to trusted and frequent event holders.
Thoughts? Kharkiv07 (T) 22:16, 31 March 2016 (UTC)
- If we are going to go this route, may want to be so bold as to also bundle in
Add groups: Confirmed users
. — xaosflux Talk 22:36, 31 March 2016 (UTC) - How about just assign them the 'account creator' and IPBE groups for the time? Ajraddatz (talk) 01:41, 1 April 2016 (UTC)
- They both contain needed and more powerful permissions, account creator has the ability to override spoof-checks and the title blacklist, and IPBE contains tor-overrides that CUs don't like handing out. It's also the ease of one flag instead of two, and per xaxosflux's suggestion the addition of the ability to add the confirm right is a plus. Kharkiv07 (T) 01:45, 1 April 2016 (UTC)
- I don't recall those "powerful" rights ever being abused by an event coordinator, but I could be wrong. Creating more bureaucracy with yet another niche user group doesn't seem ideal to me. Ajraddatz (talk) 01:53, 1 April 2016 (UTC)
- Please note, this is not adding IPBE 'group' but one of the nested rights, so tor-block would still apply. — xaosflux Talk 14:53, 1 April 2016 (UTC)
- They both contain needed and more powerful permissions, account creator has the ability to override spoof-checks and the title blacklist, and IPBE contains tor-overrides that CUs don't like handing out. It's also the ease of one flag instead of two, and per xaxosflux's suggestion the addition of the ability to add the confirm right is a plus. Kharkiv07 (T) 01:45, 1 April 2016 (UTC)
- Do we know the extent to which people with the account creator user right use/need the spoofing/blacklist overrides? Would it be easier to say those are admin rights only and reframe the existing account creator right as something closer to "event coordinator"? The benefit of doing so, to me, is that I think the blacklist and antispoofing measures are part of why there's a reluctance to issue the right for longer than a short period of time. I don't think it's regularly removed from experienced/trusted users, but for those who are, for example, involved in GLAM or education they may not be extremely experienced but would be good people to have that ability nonetheless (without having to request a permission in advance of each event/class they'll need it for). — Rhododendrites talk \\ 16:56, 2 April 2016 (UTC)
- Those rights are included for people involved with the WP:ACC process, and are probably useful to have in there, mainly for creating accounts with similar usernames to existing ones. It's a hard right to abuse; you need to explicitly check a box in order to override the blacklist and antispoof, so short of a severe lack of clue or bad intent it isn't something which would see routine damage. Like most things on-wiki, these actions can be very quickly corrected as well (blocking, renaming, etc.), and since there is no access to deleted or suppressed content the "potential for abuse" argument shouldn't be coming into play without a good reason. Ajraddatz (talk) 17:13, 2 April 2016 (UTC)