Wikipedia:Village pump (proposals)

 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.

« Archives, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Proposal: Enable Hovercards by default

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

• Considering the usual practices for closing discussions, there's only one possible result at the moment: no consensus at this time. After the first 7 votes, the opposes outnumber the supports by 29 to 10, with 2 more (Nihiltres, Sam.gov) that might be considered opposes, depending on implementation details. There are other factors than simply counting votes of course, none of which lean in the direction of the supporters. But simply boxing this up with a negative outcome might not even make the opposers happy in the long run. My guess is we'd just get a series of tweaked versions of this proposal, with annoyed voters on both sides ... or possibly the WMF will simply turn the feature on at some point before getting consensus for it on the English Wikipedia (and I don't need to point out that similar things have happened before, with mixed results). In the interest of avoiding the potential negative outcomes of a series of votes and moves and countermoves, I'm going to start a subsection immediately after the archived discussion and ask a few questions to see if we can find some common ground between supporters and opposers. If we can, and if the argument can be made that that common ground can be discovered in the archived discussion (with hindsight, if you're looking for it), then I'll consider changing my conclusion from a simple "no consensus at this time" to "no consensus, but the discussion suggests that consensus might be possible in a future discussion, with a few caveats". - Dank (push to talk) 18:18, 18 April 2016 (UTC)
  • In response to a question: I'm not ignoring the first 7 votes, I'm just saying that, in my experience with RfCs and similar discussions, the long-term trend is a better measure of how future discussions will go than early votes are, other things being equal. And of course, the result would have been no different, regardless. - Dank (push to talk) 00:11, 19 April 2016 (UTC)
  • Okay, there's no apparent movement towards a middle position, so I'll box up the last section as well. I'm sure this issue will resurface, and when it does, we'll have more data to look at, so it might be easier to deal with next time. - Dank (push to talk) 15:15, 20 April 2016 (UTC)

---

Screenshot of Hovercards in use

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

• Oppose per Cirt. --Luis150902 (talk | contribs) 18:18, 18 April 2016 (UTC)
• 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)

  Okay. --Izno (talk) 12:21, 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)

  Right, but they need to be designed for all readers, who may not be able to reload the page due to bandwidth, may not be able to reload the page due to technical inability... etc. --Izno (talk) 12:46, 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)

Ruud Someone below pointed out that the survey included opt-in en wikipedia users. I filtered those out and the results are here. It doesn't change much, but I did want to be precise as this was an oversight. I will update all the survey questions shortly. Jkatz (WMF) (talk) 20:36, 6 April 2016 (UTC)

Screenshot of survey results when filtering out En Wiki opt-in users

• 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)
  • It would be good to have data on the performance impact of hovercards. I expect javascript performance and client data speeds have improved significantly faster than the demands of a Wikipedia page load. - hahnchen 16:46, 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)

@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)

• 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)

  I'm somewhat confused by who you mean by "you people". --Yair rand (talk) 21:49, 17 March 2016 (UTC)

  @Yair rand: I'm referring to those that want to push this feature on everyone by default. Chris Troutman (talk) 23:04, 17 March 2016 (UTC)

  "You people" would probably consider themselves designers and engineers. - hahnchen 23:34, 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. –Davey2010^Talk 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 48,307,485 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)

• 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)

• 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)
  • Great idea. A clearly indicated opt out button would be useful. Sam.gov (talk) 19:08, 23 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^(TALK_CONT) 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, Lindsay^Hello 11:17, 2 April 2016 (UTC)
  • Actually, this is a proposal to enable Hovercards by default. So are you in fact supporting this proposal, LindsayH? epicgenius, presented by reddit.com/r/funny (talk) 15:32, 15 April 2016 (UTC)

  Not at all, Epicgenius. I'm sorry my meaning wasn't clear: I strongly oppose making these Hoverthings automatic, opt-out, as i do anything which distracts from the content, which it is apparent they do/will; cheers, Lindsay^Hello 15:42, 15 April 2016 (UTC)

  @LindsayH: So, you do not want them enabled by default. Now I see. Thanks. epicgenius, presented by reddit.com/r/funny (talk) 15:45, 15 April 2016 (UTC)

• Oppose being enabled by default - Hovercards are a radically different feel and function from the rest of Wikipedia. Not long ago "pop-up" was a dirty word on the Web (thanks, Tripods). We may be moving into a post-post-popup age, but they are nonetheless a loud feature that some may like, but for those who don't like them, it'll be a terrible first impression (in other words, people who like them might really like them, but for people who don't like them, they really don't like them). Yes, those who don't like them can simply opt-out .... and if it's not enabled by default those who do like them can simply opt-in (i.e. I don't see "you can just..." as a good argument here). I would want to see much better evidence of a broad positive impact and limited negative impact. That chart above, if I understand it correctly, is terribly misleading as-is. I'm sure others have pointed this out already, but the survey was not a random sample of users but a self-selected sample among those users who already have enabled it (and not those who enabled it then disabled it in horror). I should hope 75% of people who made a conscious choice to turn the feature on actually agree that it's a good one. — Rhododendrites ^talk \\ 20:57, 3 April 2016 (UTC)

Hi Rhododendrite This is a great catch, but only partially true. The survey in question went to a random sample of Greek and Catalan Wikipedia users during a period when hovercards were enabled by default to all users of those wikipedias. However, it also went to english users who were opted in. Going back into the survey results, I was able to generate a report that filters out the opt-in English users. Here is what it looks like--you will see that the numbers do not change significantly.

Screenshot of survey results when filtering out En Wiki opt-in users

I will add it above, as well. Jkatz (WMF) (talk) 20:30, 6 April 2016 (UTC)

@Jkatz (WMF): Does the WMF have the capability to conduct A/B testing on the English Wikipedia? There are all sorts of metrics that you can't measure, from a much wider audience, than just with just a user survey. - hahnchen 08:45, 10 April 2016 (UTC)

@Jkatz (WMF): Aha. Thanks for the clarification. Sorry, I didn't catch that. I do still have to stand by my position that I'd want to see more evidence (for the English Wikipedia) before it's enabled by default in any "permanent" capacity. Maybe a shorter period with a set end date for testing purposes? — Rhododendrites ^talk \\ 14:40, 10 April 2016 (UTC)

• Question. The discussion feels weighty to me, like it might benefit from a careful close. It's listed at WP:CENT, but it's not an RfC. Does this discussion need a close? Should the close wait till the 30-day point, as if it were an RfC, or would 21 days be enough if things continue to slow down? - Dank (push to talk) 22:19, 3 April 2016 (UTC)
  • Apologies, I was thinking about helping out with this one, but I can't, life has gotten a little crazy. - Dank (push to talk) 02:53, 9 April 2016 (UTC) Working on it. - Dank (push to talk) 17:05, 18 April 2016 (UTC)
• Comment: I see Hovercards as being primarily a reader's feature, and simply feel that this question is being asked of the wrong crowd. From a reader's perspective, this would appear to be a major change; we (here) might already know about it, and know about our preferences and this conversation, but to the vast majority of users, it would be a fairly big surprise. Perhaps if the foundation is considering getting involved with the development, and thus we're talking about the full scale introduction of (what will appear to most users to be) a new way of reading the world's most popular and complete online encyclopedia, it's the users they should be asking. I suggest that if the foundation wants to know if users want new features before developing and rolling them out, the foundation should post a site wide banner asking ALL readers to try it and decide for themselves, then click either I like this feature or I don't .... If the feedback is positive (enough) then the foundation has their call to arms - otherwise, it remains opt in. We here, are not the average user. fredgandt 23:38, 3 April 2016 (UTC)

  @Fred Gandt: A survey of readers/users was already conducted. See above. Are you suggesting running another one, perhaps with a simpler format? --Yair rand (talk) 23:58, 3 April 2016 (UTC)

Yes, much simpler and shorter. Show a banner stating that a new feature is being considered, with a Try it now button. If clicked, enable the Hovercards for the session and automatically disable the feature at the end of the session or if the user returns to the banner and clicks the now visible I don't like it button. If they return to the banner and click the I like it button during their session, provide registered users the option to permanently enable the beta feature, and thank the IPs. Metrics gathered, no surprises, and no particular effort required of the user (a few clicks). fredgandt 00:20, 4 April 2016 (UTC)

• Oppose I had popups enabled for some time and found it annoying to have the window blocking my view (I have a large tendency to close sites where I get a 'popup' with advertising or with a request to subscribe to their newsletter - I am there to read the article). Below there was a suggestion of 'holding shift while hovering' which makes sense to me (though I understand the concern that that would unclear to non-regular readers). --Dirk Beetstra ^{T C} 03:23, 7 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)

Their panels are opened and closed when you focus a link, so they are usable for users relying on keyboard navigation. Similarly for screenreaders, but you can't interact with them. The popups have aria annotations to declare them as tooltips (even though they are more like floating windows), but the link is not connected to the tooltip, preventing the screenreader from being able to do anything with them. That's probably fine in this particular case. It's probably more efficient for a screenreader user to directly navigate to a link, instead of trying to figure out what a popup like this does and how it should be controlled. It might possibly be improved in the future, but it is not degrading the experience. —TheDJ (talk • contribs) 15:56, 10 April 2016 (UTC)

Possible compromise: Require holding SHIFT to pop-up?

A [simple?] tweak that would mostly retain the functionality and allow it to be enabled by default without being intrusive to people who don't like it: require the shift key (or another key) to be held for the hovercards to appear (i.e. same as normal, but only when shift is held). Doable? Desirable? Apologies if this has been discussed and I didn't see it. — Rhododendrites ^talk \\ 21:19, 3 April 2016 (UTC)

I don't see what the point would be. Nobody would know that the feature was available. We don't exactly have a way of communicating with the average reader, and it wouldn't make sense to waste their time with this "Hold shift" information even if we did. --Yair rand (talk) 22:59, 3 April 2016 (UTC)

For someone who thinks Hovercards could be useful, the information wouldn't be a waste of time, but it's a fair point that we don't have great ways to communicate with readers. I suppose I was thinking more about newly registered users. Regardless, the zero other replies in this subsection says to me it's not as promising an idea as I thought :) — Rhododendrites ^talk \\ 14:45, 10 April 2016 (UTC)

Common ground?

See the archived discussion above. There are several places to look for common ground. Roughly speaking, some supporters assert that hovercards have to be a default feature for readers to discover that they exist. To repeat some suggestions already made above: aren't there in fact many ways that readers might discover hovercards, short of having instant popups every time a cursor is over a link for even a moment? What if the reader has to move the cursor to a link and leave it there a few seconds? (Eventually, a reader will trigger a hovercard, and then they can find out how to get the hovercards faster if they want them faster.) Couldn't something in the standard page design, or in an occasional banner, educate readers about hovercards? That doesn't mean we have to nag people to register if they want hovercards, of course; any number of simple actions (Shift + hover, hovering for a few seconds, etc.) could produce hovercards for readers who aren't logged in. I'm not lobbying for anything, of course, I just want to find out if this discussion has some possible result that both sides can live with, at least temporarily. - Dank (push to talk) 18:36, 18 April 2016 (UTC)

• hmm, I fear that such a discussion will turn into a "Dear devs, if you want to deploy this, built a leaning tower that does backflips and is indestructible"-situation. Why don't we just keep it simple:
  • Graduate it from Beta, preserving on/off settings for registered users
  • On by default it for newly registered users
  • Keep it disabled for non-registered users
  • Enable it by default for most other wiki's (unless they indicate a community consensus otherwise)

—TheDJ (talk • contribs) 19:20, 18 April 2016 (UTC)

At the moment our only two options would be "opt-in" or "opt-out". If left as an opt-in this feature is currently completely undiscoverable and requires—from the perspective of a reader without an account—a large number of Byzantine steps to enable (given that they somehow have the knowledge that this feature exists). If made into a opt-out then it may be too much of an obnoxious, in-your-face feature for some readers. This is somewhat of a false dichotomy, though. I think it would be best if the WMF would make a technological investment to also give readers without an account the possibility to customize their reading experience. I've made such a suggestion at mw:User Interaction Consultation/Preference menu for readers.

This proposal does not say how new features can be advertised to readers. Two common methods used by other websites are:

1. Display a bar at the bottom of the screen with the text "We recently introduced X to Wikipedia. Would you like to try it?", with a "Try it" and a "No, thanks" button.
2. Open the preference menu in the top-right corner of the screen, and highlight the toggle that enables the feature. Possibly with a short description.

—Ruud 19:33, 18 April 2016 (UTC)

A solution involving cookies, if effective, would take most of the heat out of this discussion (for those with cookies enabled), and several other discussions. - Dank (push to talk) 20:16, 18 April 2016 (UTC)

These notifications are on the table, but are they really better than simply showing a user and then removing it if they don't like it? Otherwise we have to show these notifications in perpetuity and it is hard to explain the feature without a demo. Jkatz (WMF) (talk) 23:58, 18 April 2016 (UTC)

I personally think that just showing them would be a perfectly acceptable approach, that's why I voted to make them opt-out above. Lots of other people seem to disagree with this and I do see their point to some extent. I don't think the "banner" approach it completely unworkable either. It could even include a small image of the feature in action, for example.

The really thorny issue would be if a new user signs up for an account a user without any preferences set comes along a few years down the road and she has several features waiting for her to "Try now" or say "No, thanks" to. But that's a problem that's still quite far ahead of us, and one that's probably solvable. —Ruud 00:21, 19 April 2016 (UTC)

Hi, Thanks for summarizing the results of the RFC and starting to move this forward Dank. From my end, I just wanted to update folks on 3 things:

1. FAQ: we are working on a hovercards FAQ that addresses some of the concerns mentioned (but certainly not all). Moushira is finalizing it and one of us will post here when it is live.
2. We are also working on some options for creating preferences for anon users. I do not think that this is a solution for discoverability, but it will go a long way in making it easier for anon users to toggle features on and off. Again, that will be posted here soon.
3. WMF's planned next steps. My current thoughts for how this plays out, is that while we are exploring common ground. The WMF rolls out hovercards on a wiki that is interested in adopting it (they exist). We run an AB test there to get fresh, more rigorous numbers (and a qualitative test to make sure we aren't destroying the experience for a minority of users). In parallel, we will start to work on improvements we have already identified: improvements to images (ability to override), preferences, and the ability to disable. The results of the initial, smaller rollouts might identify other tweaks we need to make. Jkatz (WMF) (talk) 23:58, 18 April 2016 (UTC)

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

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)

• 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)

It's actually a general content policy, I see no reason why not till now. But 5 voices are barely it. --QEDK (T ☕ C) 10:31, 4 April 2016 (UTC)

Support as log as it is just a room or two in which a few admins can act as moderators... nothing else is needed. Fritzmann2002 18:31, 7 April 2016 (UTC)

I like the idea, but the possibility of vandals doing whatever they want is just too great. ThePlatypusofDoom (talk) 21:00, 7 April 2016 (UTC)

I'm totally behind this! It would need some moderation of course, but I'm sure that can be sorted out. Commissaress (talk) 21:25, 7 April 2016 (UTC)

All but died on the vine in January 2015, here, albeit with a slightly different context/angle. Beware the scarlett letter P(erennial). ―Mandruss ☎ 21:50, 7 April 2016 (UTC)

Successful WikiProjects usually have some chatter going. You might find a large WikiProject in an area that interests you, and join in. Alternatively, some of this happens on a few users' talk pages. WhatamIdoing (talk) 05:29, 13 April 2016 (UTC)

I can see how meeting and greeting fellow Wikipedians could be useful, especially for newer editors, and along those lines would see a place for it in a back room of the teahouse.

For more established editors, an extension to userbox induced categorization facilitating editors' search for and interactions with Wikipedians with specific attributes could be handy, where rather than simply finding a list to individually pester, one could open open discussions with all of them on a dedicated banter symposium page.

Overall, I can see the encouragement to let one's guard down and blow off steam turning rapidly into an arena where everyone's guard is forced up, and folk get burned. It may seem an officious place at times, but considering how busy it is, the rules have kept the peace and order in a remarkably efficient way for years. fredgandt 02:55, 16 April 2016 (UTC)

I personally oppose this suggestion - Wikipedia is supposed to be a serious encyclopaedia, not a joke book. Vorbee (talk) 14:57, 23 April 2016 (UTC)

Introduce different colours for links to different things

Anyhow, I basically just wanted to suggest that different colours should be used for different things when links are used in articles. I will give an example.

For example, when you read an article about a person or a war or something similar, there might be a reference to a rebellion or something similar, now very often if you click on a link where it says "rebellion", is takes you to an article about said rebellion, but very often you also come to an article that explains what a rebellion is.

So basically I would just like to see (in the future), maybe links having different colours if it's an explanation of a certain term, compared to a link to something that is not a description of terminology, such as an event, person etc.

I know that if you hold your mouse cursor over a link it shows where it leads most of the time, though when you are on slow internet or in a public library or so, this might take a lot of time, also loading pages back and forth when you realize you are being explained what a rebellion or an apple is.

It's a small problem I know, I just think it would be helpful.— Preceding unsigned comment added by Chronicler87 (talk • contribs) 10:14, 8 April 2016‎

The manual of style for linking already strongly encourages articles to be written such that "the reader knows what to expect when clicking on a link", for this reason. It can be achieved by the structure of the sentence and the link alone - "Cao Qin led the rebellion against the Emperor" links to the general article about rebellions, and "Cao Qin led the rebellion against the Emperor" links to an article about that specific rebellion. --McGeddon (talk) 10:48, 14 April 2016 (UTC)

At the top of this page, there's a discussion about enabling hovercards by default which is quite relevant.

Whilst the manual of style dictums on link formation (noted by McGeddon above) provide guidance, the actual encyclopedia is massive and full of errors - which is of course where WikiGnomes come to the rescue; there's nothing that can't be fixed.

Some kind of automatic solution is at present practically impossible, and would require either powerful AI or a Semantic Web - neither of which is likely to rule the roost here any time soon. fredgandt 11:16, 14 April 2016 (UTC)

With all due respect, I would strongly oppose this suggestion. To have two colours - blue which is an existing wiki-link, red for an article that has yet to be created - is nice and easy. To have more colours would only confuse new editors. Evidence is that when I first began editing Wikipedia, some one did once ask why some links are blue and some red. Vorbee (talk) 20:56, 20 April 2016 (UTC)

Religious messages

I propose that people should not be allowed to use their Wikipedia user pages, signatures etc. to promote their religious beliefs. 81.152.70.247 (talk) 00:28, 9 April 2016 (UTC)

• Wikipedia:What Wikipedia is not#Wikipedia is not a soapbox - Says no advocacy.
• Wikipedia:User pages#What may I not have in my user pages? - Agrees.
• Wikipedia:Userboxes#Content restrictions - Agrees, but
  • Wikipedia:Userboxes#Life, personal status and situation - lists religious userboxes
    • User:UBX/Userboxes/Religion - like these.

I'd imagine this has been discussed many times before, and it's all very open to interpretation. I personally couldn't care less; each to their own  fredgandt 04:59, 9 April 2016 (UTC)

Personally, I have no problem with a user identifying his religious beliefs (or the lack thereof) on his user page with an infobox or otherwise. There is a difference between mere identification (which can, indeed, be useful in understanding where a user is coming from and it's the kind of revealed information about a person which helps to build community here) and advocacy or promotion, which I agree is inappropriate, though I think a good deal of tolerance should be exercised in regard to user pages. A couple of infoboxes, even if kind of fervant, should be tolerated; long rambling essays, proselytizations, or screeds should not. Raising it in a signature, however, might well be pushing the line, since a signature will be repeated again and again. On the other hand, I think that existing policies and guidelines, including those listed by Fred Gandt, above, are more than sufficient to deal with any situation which might come up and I'd be opposed to writing any new specific rules about the issue. If you have doubt about a particular user's usage, first take it up with them, then if you get no satisfaction take it to an administrator or to ANI. Regards, TransporterMan (TALK) 05:44, 9 April 2016 (UTC)

There is really only something to pick a fight over, and it would not surprise me to find more people promoting their atheist religious beliefs, and that they would have a lot hard time reining that in without feeling extremely suppressed. Mangoe (talk) 12:28, 9 April 2016 (UTC)

There are no "atheist religious beliefs". HTH. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:04, 11 April 2016 (UTC)

In addition to the hurdles Fred has already pointed out WP:CSD#U5 applies "where the owner has made few or no edits outside of user pages". Users need to be substantial contributors before they start writing about their imaginary friends or anything else "not closely related to Wikipedia's goals". Bazj (talk) 12:50, 9 April 2016 (UTC)

Don't care if someone espouses their beliefs, relgious or non-religious, on their user page. And actually it is a good way to vet bias in articles. Jaldous1 (talk) 16:06, 10 April 2016 (UTC)

Something Bazj points out (purposefully or not) is where policy and good manners will decide inappropriate posts of pretty much any kind.

"This user is [insert personal choice here]" is fine within reason, whereas "This user thinks [insert other's personal choices here] are deluded" or even "This user [insert thing that typifies a personal choice here] in order to save your retched souls" is definitely NOT okay.

In other words, stating simply that one is inclined a certain way is (within reason) fine, but stating that not being that way inclined is bad, or that being inclined another way is bad, or even stating that being a particular way is especially good, begins to smack of advocacy or derision, which is not acceptable. fredgandt 16:23, 10 April 2016 (UTC)

If a user starts to add major Jewish (or Muslim, or Catholic, or atheist) POV issues in articles, it would be very useful for the project if this user also happens to admit to being Jewish (or Muslim, or Catholic, or atheist) prominently on his/her userpage. עוד מישהו Od Mishehu 05:41, 11 April 2016 (UTC)

If a user starts to add any non-neutral POV we already have policies to deal with that. WP is about facts with sources not about opinions or biases, religious or otherwise. Saying we need to ask a user to divulge their religious views to ensure good editing is saying WP's key policies of WP:V, WP:RS, WP:NOR, and WP:AGF do not work. The day that becomes true I will quit editing and even quit reading WP. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 06:28, 11 April 2016 (UTC)

The OP's question was about promotion which would clearly be POV if it were in article space. In their own user space, not so clear. As Od Mishehu pointed out, disclosure is good. Even better to edit in such a way that nobody ever suspects you even have an opinion, and that the question of POV never arises.

If the disclosure crosses the line into proselytising or bearing witness, it's clearly "not closely related to Wikipedia's goals", and clearly flags up a topic on which the editor may be easily trolled (as Fred_Gandt called me on above). As the late, great Dave Allen used to sign off, "May your god go with you", Bazj (talk) 07:18, 11 April 2016 (UTC)

Obviously, there are red lines even in this context; certainly, though, any content which would fit into a normal-sized userbox in normal-sized text would be too short to be proselytising. עוד מישהו Od Mishehu 14:40, 11 April 2016 (UTC)

• Unless sharing sharing personal preferences of any type that aren't strictly related to encyclopedia editing is prohibited, which would basically force everyone to edit anonymously, expressing personal preferences of any type could fall under the first three bulletin points the IP mentions (if we interpret them in the manner the IP is).—Godsy^(TALK_CONT) 04:24, 12 April 2016 (UTC)

We only ask that editors be professional, not perfect. Set aside your personal biases to the best of your ability and only add content that can be appropriately sourced. That is all. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 05:00, 12 April 2016 (UTC)

@Koala Tea Of Mercy: My comment is mainly in response the notion users shouldn't be allowed to put userboxes (or just state it in general) stating their religion on their userpage (and signatures to a certain extent). Nothing to do with editing articles. To sum it up: Almost all preferences are allowed to be expressed (pedophilia is a notable exception). They are either all in or all out. We can't discriminate upon the expression of religious views by assuming expressing that particular preference is an attempt to proselytize, advocate, or an indication of more bias than any other association or veiw expression. Statements and expressions like rainbow flags, peace signs, Flying Spaghetti Monsters, and even nationality (notably those Canadians with their 🍁 signatures ) and sex would all have to be disallowed.—Godsy^(TALK_CONT) 06:45, 12 April 2016 (UTC)

This proposal is rather broad. As for signatures - I don't really have issue with someone adding a character to their signature unless it is specifically offensive; I'm opposed to adding POV messages to signatures though - they are meant to be identification points only. As for user pages - I'm fine with people self identifying their beliefs (e.g This user is a christian) because it also helps identify potential COI's -- but I'm opposed to using userpages for "promoting" of personal beliefs in general. — xaosflux ^Talk 18:34, 12 April 2016 (UTC)

Potentially outdated, but related: http://www.wikichecker.com/religion/ Ckoerner (talk) 18:34, 18 April 2016 (UTC)

Is not this already covered at Wikipedia: What Wikipedia is not under the section which states that Wikipedia is not a soapbox? This section does note that on some articles - such as those to do with politics (one could also argue on religion) it might be tempting to promote one's own viewpoint, but clarifies how Wikipedia at least aims to be neutral - ergo, this has already been covered.Vorbee (talk) 20:59, 22 April 2016 (UTC)

Implementing Help:Maintenance template removal

Note: the genesis for this started with Wikipedia:Village pump (miscellaneous)/Archive 51#Are notice tags demotivating?--Fuhghettaboutit (talk) 01:57, 10 April 2016 (UTC)

Hey all. For years we regularly get questions at various fora about maintenance template removal. (In fact, a few questions related to this issue were posted today (1, 2.) The questions we often receive show that:

• i) it is not obvious to many that maintenance templates are placed and removed manually. Many people assume there’s some mysterious automated threshold or A.I. program that governs removal;
• ii) some people seem put off from helping out in the first place—refrain from tackling the problem the template flags—because the process of template removal is neither obvious nor transparent;
• iii) because there’s nothing in the display of most templates to indicate to the reader that they can dive in to help, and no link to a page explaining the process (as proposed here), they assume it’s some job for an elite class of user (and so we lose the desperate help we need from the masses); and
• iv) people often do not grasp what needs to be done to address the issue flagged by the template, despite the links in them.

So, I’ve drafted Help:Maintenance template removal. The intent is that we add to the display of a variety of maintenance templates the following text, linked to this help page:

• Learn how and when to remove this template message.

I’ve spent a lot of time at this help page not just describing the ins and outs of the removal process, but a section addressing some some of our more important and high-use templates — explaining the issues involved, relevant guidelines and policies, and what needs to be done before removal.

If consensus is gained to add such a proposed link to maintenance templates, whether as currently drafted or as suggested after discussion, I will need some help from the more tech-savvy as to the proper way to incorporate the link into the templates. Right now my manner of adding it, as seen in the {{unreferenced}} example I used at the help page, does not play well with that template’s date parameter (“April 2016”), which should appear after the main text, not after the proposed link.--Fuhghettaboutit (talk) 01:57, 10 April 2016 (UTC)

Discussion (maintenance tag removal)

• Misunderstandings about the purpose of templates and the process of removing them seem to be fairly common among new editors. I would Support adding a notice like this to maintenance templates. It is possible that this could lead to some templates being removed prematurely, but I think making the process easier to understand is worth it. Howicus (Did I mess up?) 02:11, 10 April 2016 (UTC)
• Support. One thought: new editors who this is aimed at may not understand that the message they are seeing comes from a template. So might it be more meaningful to refer to "how and when to remove this message"? --Gronk Oz (talk) 02:36, 10 April 2016 (UTC)

  Hey Gronk Oz. How about "how and when to remove this template message"? I kind of like the idea that we're being precise and teaching what the "thing" is (a template), but I like your idea too. Plus, this mirrors the name of WP:TM.--Fuhghettaboutit (talk) 02:49, 10 April 2016 (UTC)

  Yep - that's perfect. --Gronk Oz (talk) 22:25, 10 April 2016 (UTC)

• Support A great idea. I would not object to minor wording changes. Cullen³²⁸ Let's discuss it 06:44, 10 April 2016 (UTC)
• Support Excellent idea. Templates are about 3rd dan for most new editors, and some more accessibly presented How-To would clearly be welcome.-- Elmidae (talk) 13:33, 10 April 2016 (UTC)
• I would definitely support this. This issue comes up over and over at the Teahouse. DES ^(talk) 15:14, 10 April 2016 (UTC)
• Support anything that helps new uses is welcome. I assume that it only apples to the box type templates and not the inline versions. Keith D (talk) 15:54, 10 April 2016 (UTC)

Hey Keith D. At present, yes, this is geared toward and would only apply to the box type. The templates for which I provided specific instructions at the help page are where I thought these would first be added.--Fuhghettaboutit (talk) 16:58, 10 April 2016 (UTC)

• Support. Needed and necessary. GenQuest ^{"Talk to Me"} 16:48, 10 April 2016 (UTC)
• Support per everybody. ―Mandruss ☎ 17:16, 10 April 2016 (UTC)
• Good idea. If anything, it's a way to help people realise they can edit Wikipedia. BethNaught (talk) 17:23, 10 April 2016 (UTC)
• Support. Excellent idea. --ColinFine (talk) 17:35, 10 April 2016 (UTC)
• Support - great idea. Thanks for working on this. Ajraddatz (talk) 17:42, 10 April 2016 (UTC)
• Support - this issue comes up a lot at the Teahouse, and this seems a good way to try to help new users understand the issue. Cordless Larry (talk) 17:44, 10 April 2016 (UTC)
• Support - and a hearty pat on the back for the effort. Comment - There's currently a RfC at {{Multiple issues}} (talk) about showing links to related talk page sections, for discussion of the issues raised, in the concise versions of maintenance templates. I would suggest that this proposed change and any that may arise from that discussion be borne in mind together. fredgandt 17:51, 10 April 2016 (UTC)
• Support — I think the tendency for most people who aren't experienced with Wikipedia's mechanisms is to view maintenance tags simply as red flags over particular articles' reliability, and not as actionable issues that can be resolved and then checked off. This change is a good idea that would perhaps put them to better use. —Nizolan ^(talk) 01:57, 11 April 2016 (UTC)
• Comment, good help page, maybe start with 1..3 cleanup templates to test/show your intended link feature. –Be..anyone (talk) 22:25, 11 April 2016 (UTC)
• Support-- I read the Help article and it was like a breath of fresh air. Thank you so much User:Fuhghettaboutit for this long overdue addition. Fritzmann2002 18:11, 13 April 2016 (UTC)
• Support - excellent work. JohnCD (talk) 19:10, 13 April 2016 (UTC)
• Support - Well thought out solution. Gmcbjames (talk) 00:12, 14 April 2016 (UTC)
• Support - A good solution to a real problem. The help page is good and very accessible. Happy Squirrel (talk) 04:54, 14 April 2016 (UTC)
• Support all efforts and any implementation approach to do this. We have a major problem with new editors believing that some anointed admin needs to decide even the most obvious of cases, so they add refs but leave {{unref}} at the top of the page for months afterwards. Seriously: it's occasionally awkward if we screw up a widely used template, but the fact is that this is a wiki, and if we don't like the first place/color/size/style/whatever, then we can change it later. Let's do this. WhatamIdoing (talk) 18:07, 14 April 2016 (UTC)
• Support - great idea, and the draft looks good. Long overdue! --SubSeven (talk) 06:00, 15 April 2016 (UTC)
• Support Staggeringly good idea. WaggersTALK 09:52, 15 April 2016 (UTC)
• Support, to pile on a bit. Excellent idea. APerson (talk!) 22:50, 16 April 2016 (UTC)
• Support a great idea. --Tom (LT) (talk) 00:40, 17 April 2016 (UTC)
• Support This is very good. My quibble is that the help page concentrates on new editors removing a template after they have addressed the issues, though in my experience this is not the only time someone should be looking to remove a template. I have seen templates languishing on articles years after the issue has been dealt with. Templates should be removed after the issues have been addressed, regardless of who addressed the issue or when. Sometimes the issue might have been resolved in pieces by several editors over a period of time, and nobody took final responsibility for the template. Sometimes a template is placed in error (or anger) so there is no amendment work to be done. I think it would be helpful if the guidance page addressed everyone, not just newbies. The advice on Template:POV is useful, and some of that could be incorporated. I might leave some comments on the help page talkpage. SilkTork ^{✔Tea time} 08:51, 18 April 2016 (UTC)

• Note: SilkTork already proposed at the talk page and then made excellent additions to address the matters raised above.--Fuhghettaboutit (talk) 15:46, 23 April 2016 (UTC)

• Support - no brainer really, why has it taken so long? Include various suggestions above too. Aoziwe (talk) 10:50, 23 April 2016 (UTC)

Implementation discussion (maintenance tag removal)

This section was originally posted to Wikipedia:Village pump (technical)#Template help and relocated here.

<introductory text removed as out of context here> What I need is help with the technical aspect of doing this – a standardized way to pass that link through to the templates. It should appear after all other content, after a line break. The way I've done it up to now (as seen in the examples I placed at the linked help page) is to just add the message after a break (<br />) to the fix= parameter these template all have. But the result is that the date parameter of the templates appears after the link:

 • Learn how and when to remove this template message. (April 2016)

So, what needs to be done in order to leave the date parameter where it belongs, after the main template content, and have the link appear after all of that content? Is there a way to keep it in the fix parameter but make the date not appear after it? If not, do we need a new parameter in Ambox to accomodate the link (which if I understand correctly is just a conduit for Module:Message box, so is there a change needed there?)? Thanks--Fuhghettaboutit (talk) 00:34, 14 April 2016 (UTC)

@Fuhghettaboutit: Would this be any better (I know it's not exactly what you want, but appears to be an improvement)?

Mdann52 (talk) 12:13, 14 April 2016 (UTC)

Thank for responding Mdann52. I really think it should be set off in the manner proposed. It's not part of the main text, and interrupts its flow.--Fuhghettaboutit (talk) 12:17, 14 April 2016 (UTC)

Please add {{multiple issues}} near the top of your test list, it should not trigger multiple links to the same help page. A WikiProject Templates exists or existed, maybe you find more support there. –Be..anyone 💩 12:58, 14 April 2016 (UTC)

The change would almost certainly have to go into Module:Message_box, probably an additional parameter that could be specified in template:ambox or whatever. Rwessel (talk) 05:48, 15 April 2016 (UTC)

Thanks to everyone thus far for participating. Since at this point it looks pretty good for implementation, I'm pinging the creator and main editor of Module:Message box.--Fuhghettaboutit (talk) 02:32, 17 April 2016 (UTC)

Related proposals at Meta

Editors interested in Maintenance tag issues may also want to read and contribute to two proposals in Meta:

• Maintenance_tags_follow-up
• A better interface re maintenance tags --S Philbrick(Talk) 00:22, 17 April 2016 (UTC)

Watson and next generation improvements to the standard Wikipedia search box

Although natural language use in search boxes is still a long way off, the recent press is full of announcements of IBM making massive investments into the use of WATSON software in the search boxes of the medical industry and various specialized business sectors. Is Wikipedia evaluating or talking about the possible use of WATSON software for improvements and enhancements to the standard Wikipedia search box currently in use at the top of the page. Fountains-of-Paris (talk) 15:28, 11 April 2016 (UTC)

You are suggesting using advanced artificial intelligence to a software development team that, despite millions spent of search, created a search box where searching for "a = b" returns "R.A.B.", "A-B", "(a,b)-tree", "A. B. Guthrie, Jr.", and "A/B testing". If, for whatever reason (I strongly suspect bad management, not technical incompetence) they cannot manage to provide basic functionality such as searching for a literal string, for FSM's sake don't ask them to partner with IBM to try to provide A.I.! --Guy Macon (talk) 01:37, 12 April 2016 (UTC)

You mean, just like google does and any other modern search engine. This is how search engines work these days, they ignore things like punctuation. If you want a 100% literal match, you need to use insource regexp searches. —TheDJ (talk • contribs) 16:07, 12 April 2016 (UTC)

• A point you probably have not considered is that WATSON is not just software, it is also highly proprietary hardware customized for high-speed AI algorithms. The software and the hardware are an inter-dependent system and one is useless without the other. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 05:08, 12 April 2016 (UTC)

• I believe that you are incorrect. Watson runs on SUSE Linux Enterprise Server with Apache Hadoop. Such systems are readily available, but the IBM hardware is presumably much faster. The real problem is that all of that expensive hardware answers one question by one user at a time. It would take a lot more computing power to handle all of the searches Wikipedia gets. --Guy Macon (talk) 05:50, 12 April 2016 (UTC)

• You are correct that WATSON uses SUSE Linux Enterprise Server and Apache Hadoop but these two software packages are only a fraction of the whole WATSON system. The core software is called DeepQA and that runs only on the proprietary POWER7 processors.

From our own article on WATSON (see Watson_(computer)#Current_and_future_applications) allow me to point out this: "IBM also intends to market the DeepQA software to large corporations, with a price in the millions of dollars, reflecting the $1 million needed to acquire a server that meets the minimum system requirement to operate Watson."

For a quick but detailed overview of the scope of the software and hardware used by the WATSON system take a glance at this pdf of a presentation made by IBM at one of the SHARE conferences. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 06:34, 12 April 2016 (UTC)

You mean the PDF that says "All of the hardware is available for sale at your friendly international purveyor of business machines"? Your claim that Watson is "highly proprietary hardware customized for high-speed AI algorithms" is factually incorrect. Call IBM, pay them three million dollars, and they will deliver a shiny new cluster of ninety IBM Power 750 servers and all the networking hardware needed to run Watson -- none of it custom. Then of course you need to buy the Watson software, which looks like it will run you a couple of million more. Or you can accept a slower response time and use fewer servers. --Guy Macon (talk) 13:47, 12 April 2016 (UTC)

The whole point is moot I think, since it is a proprietary system if I'm not mistaken, and we only use Free and open-source software for the core functionality of the website. —TheDJ (talk • contribs) 15:58, 12 April 2016 (UTC)

TensorFlow is open source. Praemonitus (talk) 21:31, 14 April 2016 (UTC)

@Praemonitus: If its free source then does that put it back on the map of what Wikipedia can take up as part of the evaluations of the next increment in the enhanced version of the Wikipedia search box? Fountains-of-Paris (talk) 14:45, 15 April 2016 (UTC)

The "distance" of capability between Watson and the current Wikipedia search box

@Guy Macon, TheDJ, and Koala Tea Of Mercy:The distance between Watson and the current Wikipedia search box was discussed here [1]. Basically the current conventional search box does a little bit more than a simple search look-up which simply fails if the search item is not found. This was slightly improved a month ago to a 3-character look-back algorithm to correct letters only at the very end of the search item. For example "David Bowtie" will be corrected to "David Bowie" because the correction is only done at the end; if you type in "Fostoevsky" you get a failed search error message and no correction to "Dostoevsky" is even attempted. There are super fast algorithms for single letter correction, but Wikipedia is still short of accomplishing even that level. If Watson in the search box is not even on the radar screen for the Wikipedia search box, then what should be the expectation for the next generation of the standard Wikipedia search box improvement? Fountains-of-Paris (talk) 14:54, 13 April 2016 (UTC)

You have to keep in mind that many AI problems are known to be NP-complete, i.e. we don't think we have efficient algorithms for them. This is part of why even Google pours tons of research into its search engine many years after it was first invented.--Jasper Deng (talk) 21:35, 14 April 2016 (UTC)

@Jasper Deng: Yes I think that's correct about some very hard problems. If I put the two extremes of search box effectiveness at Wikipedia between full natural language interface at one extreme and the simple find/fail approach the matching the search item placed in the Wikipedia search box, then my feeling is that Watson added capabilities would be at the half way point between the two extremes. What do you think should be the current expectations for an improved search box? Can the Watson level of Wikipedia search box performance be practical and implemented if the Watson source TensorFlow is open source? Fountains-of-Paris (talk) 14:45, 15 April 2016 (UTC)

@Fountains-of-Paris: First off, please stop conflating Watson with AI in general (TensorFlow is not part of Watson, for example).

Even with TensorFlow, this would still require substantial development (and server resources) on the foundation's side. @Jdforrester: may have comments on how feasible it is; I am not a developer for the foundation and can't speak for them.--Jasper Deng (talk) 20:54, 15 April 2016 (UTC)

@Jasper Deng: There is no preference on my part for using either Google's Tensorflow or IBM's WATSON. I first listed WATSON up above because of the large success and publicity of its "Jeopardy" quiz show. The current Wikipedia search box is currently non-AI in any appreciable way. It seems to follow the find-or-fail approach of simple look-ups of the search term. It does not even seem to incorporate the spelling correction software which Wikipedia currently uses for standard editing of its articles generally. Either Tensorflow or WATSON is fine if it gets the discussion started. At present when I type in "Fostoevsky" all Wikipedia gives is a fail error message, in place of a simple correction to "Dostoevsky" and a successful link to the page. Either Tensorflow or WATSON is fine for starting this discussion. Wikipedia should implement its very efficient word processor spelling correction software into the standard Wikipedia search box at the top of the page as quickly as possible since the software already exists in Wikipedia. Fountains-of-Paris (talk) 14:23, 16 April 2016 (UTC)

@Fountains-of-Paris: You appear to be wrong about the "three character lookback algorithm". For example, if you type "Dxstoevsky" or "Dstoevsky" it will suggest Dostoevsky without trouble, and it even does well with something like "Axtidisestablishmentarianism" or "Pnumonoultramicroscopicsilicovolcanoconiosis". I've read (but can't find the link again, although T125671 looks relevant) that your problem with "Fostoevsky" that you keep harping on is that it currently requires the first letter to be correct so as to limit the search space. Anomie⚔ 13:47, 17 April 2016 (UTC)

@Anomie: This is the discussion which includes the link I think you just referred to here [2]. When I copy your "Dxstoevsky" into the search box and search I then get a failed search message with no options listed. Same for your "Dstoevsky" misspelling, which again offers only to start a new article if you want to write one. However, when I type in something as bad as "Fostoevsky" then a Google search does give the corrected search results with useful options, as it should be expected to do. If the Google version of the search box is that much better than Wikipedia's version then possibly they can be approached by someone from Wikipedia or WMF to see if they could provide their search box to Wikipedia so that Wikipedia can dazzle users with a new "super" search box (that is, Google's search engine installed here at Wikipedia). In the general press there are reports that Google is friendly with and a sponsor of Wikipedia, so perhaps they are open to such a possible approach. Fountains-of-Paris (talk) 14:45, 18 April 2016 (UTC)

Hello, I was pointed over this way from the discovery-l mailing list. While I can't claim to know it all when it comes to how our search works, I did want to help provide a little more supporting information to the discussion. I’m writing this under the assumption that readers aren’t super-savvy with every technical components. For more savvy readers, this might be stuff you already know.

Our search back-end (the software that makes search work) is based upon Elastic (formerly known as Elasticsearch). Elastic is built upon Lucene (for indexing and search). A peer (of sorts) is SOLR, which is what Watson uses (meaning Watson also uses Lucene - everything is related!).

So in a way Elastic and SOLR are children of Lucene, which powered wiki search up to about 2014.

Elastic, like it’s other family members, is open-source, with a pretty robust ecosystem of plugins. It’s also a well-used solution, with many big web services using it for their search. You can check out their site for a fancy list of clients and what not. Using Elastic lets engineers (of which we have 4 dedicated to search) focus on integration with our wiki-specific needs. We also get the advantage of using an active project and benitifing from it’s developments.

Right now, we're using a pretty good chunk of what Elastic offers us. The completion suggester update and some work on popularity scoring are recent examples of work on increasing the power of search. We’re also looking at leveraging a language-detection library called TextCat (=^.^=) to provide search results in a desired language (given the input).

What makes Watson different is its focus on machine learning. This is, if you will accept my apologizes on the over-simplification, an extension of traditional search. While our current search ‘learns’ (like with popularity scoring, when new pages are added to the index, etc.) machine learning would allow search to use metadata to make associations that we humans can easily make, but computers can’t.

Of which, ORES is a great example of where the foundation is looking into machine learning (and where the Discovery team is listening to experiment and learn).

I guess this is all to say, “Search is complicated. We’ve got a solid stack to work on top of. We’re always eager for ideas and learning.” :)

I hope this provides a little insight on what we’re using, why, and how far we are down the path of improving search. I’m happy to help answer related questions and/or bug those with more knowledge.

Personal note: I worked in the data management team of a large healthcare provider before joining the foundation. We had a demo or two of Watson. It demos great. It's really expensive. :) CKoerner (WMF) (talk) 16:44, 18 April 2016 (UTC)

References

@Fountains-of-Paris: FWIW we initially tested the completion suggester allowing first character substitutions, but after load testing against our production search cluster had to scale it back to not checking changes in the first character. The per-request time spent in the search engine goes from 2-3ms for what we use now to 10-12ms when also allowing first character substitutions. We perform a few thousand of these queries every second and the limitation is strictly a performance issue. We unfortunatly do not have the option to throw a few million servers at the problem like google does. There is a request to expand the search cluster's processing capacity by ~66% in the FY16-17 budget so we may be able to revisit this after expanding the search cluster, but it depends on how much of that extra capacity ends up being available and how much is used by natural growth in usage. EBernhardson (WMF) (talk) 17:46, 22 April 2016 (UTC)

@EBernhardson (WMF): The issues you strongly represent here are also under discussion in the subsection directly below this one and are all important issues and benchmarks. The balance of how much of this assessment is shifted by hardware capacities being balanced by the strength of the search engine are of significance. In the subsection directly below the highlights were on the strength of the search engine software itself and its capacities, with possible discussion of enhancing with current Wikipedia search box using progress in Watson-like software applications, or, by emulating/implementing Google search engine capacities in the next generation Wikipedia search box. Some of the other editors and analysts at Wikipedia and WMF have started to indicate the practical limitations involved in such future development which I'll try to response to in direct order. If you have any data on the hardware capacity trade-off relationship to the relative strength of the search engine being used, then it would be interesting to see it or have it linked here. I do remember Sergei Brin in his often quoted interview from the 1990s telling people that the key transition for his development of the Google search engine was the emerging hardware capacity in his time back then "to download the full internet" in an accessible format. If you have some trade-off data on the hardware to software relationship then it would nice to have it linked here. Cheers. Fountains-of-Paris (talk) 15:45, 23 April 2016 (UTC)

Would a Google-Wikipedia search engine be a better option.

@CKoerner (WMF): CKoerner (WMF) has clarified that it is unlikely that a Watson-like Q & A in the standard Wikipedia search box can be expected (see section above) for financial reasons and otherwise. Although less flashy than the Watson-like Q & A features, are there any options to pursue by way of getting the Google search engine installed to enhance the current Wikipedia search box software? If Wikipedia is budgeting upwards of half-a-million dollars per year on improving the current Wikipedia search box (based of ELASTIC and possibly ORES), then does offering a partnership to Google make sense if they would be willing? Google has the best search engine available today and it would seem to make some sense to try to partner with them. Does a Google-Wikipedia search engine partnership make sense financially? Fountains-of-Paris (talk) 21:09, 18 April 2016 (UTC)

There's already a Google search available in .js, which I use and find rather good. DuncanHill (talk) 22:10, 18 April 2016 (UTC)

@DuncanHill: Would installing the Google search engine software into the current Wikipedia search box (that is, replacing/updating the current Wikipedia search engine in the upper right corner of the standard Wikipedia page) be a big improvement with no costs added? Fountains-of-Paris (talk) 16:45, 19 April 2016 (UTC)

I really couldn't give any comment on whether that would be a "no cost" improvement. As it is, I use the Wikipedia search box when I know, or am fairly sure of, the article title. I use the Google box when I don't know a likely title, or when I am searching for combinations of words etc. DuncanHill (talk) 16:50, 19 April 2016 (UTC)

Due to the foundation's principle of user privacy, third party services are usually out of the question for things like this.--Jasper Deng (talk) 22:03, 19 April 2016 (UTC)

@DuncanHill and Jasper Deng: This is the public announcement made by Wikipedia WMF about its generous relation to Google here: [3]. At present all of this is public and in the public domain. Google has made a grant in the seven digit range and a Wikipedia-Google partnership on using their search box engine, the best around, as an upgrade of the current Wikipedia search box engine would appear as being promising. Should the Google search engine be considered as a possibility to upgrade the current standard Wikipedia search box engine currently based on ELASTIC (possibly with or without ORES)? Would this also get the Watson-like AI research initiatives started on a stronger and enhanced footing? Fountains-of-Paris (talk) 14:37, 20 April 2016 (UTC)

@Fountains-of-Paris: Please re-read my statement. Third-party grants are very common and usually highly welcomed. But the use of third-party software is a different manner.--Jasper Deng (talk) 15:26, 20 April 2016 (UTC)

If you are aware that Google would be unsympathetic in advance regarding sharing their knowledge base and applications library then please let us know. Tensorflow and many other software apps are open source and publically available for anyone to use from Google. The highly welcome grants from Google to Wikipedia suggests that they might be more open to closer ties with Wikipedia which would be constructive. Should Wikipedia be interested or even open to the idea of enhancing the current standard Wikipedia search engine if Google would be willing to share their applications technology and their top level search engine technology? Fountains-of-Paris (talk) 16:08, 20 April 2016 (UTC)

It just doesn't work the way you want it to. The foundation pretty strongly prefers to have its code developed from scratch unless it's free and open-source. Therefore, it is theoretically possible for the foundation to use a TensorFlow-based solution, but as I explained above, it is not deemed to be technically feasible. --Jasper Deng (talk) 17:37, 20 April 2016 (UTC)

At the moment we were just told by Koerner that maintaining the Wikipedia search engine is a large effort involving the expense of at least 4 dedicated programmers at the WMF foundation. Estimate that at half-a-million dollars per year with incidentals added, and it sounds like a real bite into the annual expenses. At present I do no know if Google is even using TensorFlow in their own version of their search engine, or if the AI part is still in research and development for them. If you have some added insight here then great. The Google search engine is the best one out there and if Wikipedia can make it work here as well then so much the better for enhancing the standard Wikipedia search box. As I said before, the Wikipedia search box currently fails on "Fostoevsky" but the Google search box gets me straight to "Dostoevsky" no questions asked even when the same mistype of "Fostoevsky" is keyed-in. It sounds like a point in favor of trying to use the Google version of a better search engine at Wikipedia. Fountains-of-Paris (talk) 18:14, 20 April 2016 (UTC)

Again, no matter how good of an idea, the foundation is unlikely to do anything involving third-party non-free code, for privacy reasons.--Jasper Deng (talk) 20:08, 20 April 2016 (UTC)

I don't have the time right now to write a longer rationale here, but suffice to say that using more Google-based infrastructure (or any kind of third-party infrastructure) is not under consideration and likely won't be any time soon. Here are some of the reasons:

• Firstly, negotiating with Google and maintaining that relationship would take up significant staff time (which costs money), and then we'd likely need as many staff members as we have now to maintain the bridge between our systems anyway. It seems unlikely we'd save any money by doing this.
• Secondly, we'd lose a significant amount of control over where our search logs go, potentially compromising the privacy and safety of our users. This would be bad because search logs can contain highly personally identifying information and therefore are presently very closely guarded.
• Thirdly, by using Elasticsearch, an open source search backend, we're able to contribute back to the open source search community by upstreaming improvements to Elasticsearch.
• Fourthly, we have three dedicated search engineers, which only represents around 1% of our total staff. The Foundation's investment seems perfectly proportionate to me.
• Finally, as demonstrated by the recent launch of the completion suggester, which vastly reduced the number of queries that give zero results and increased user satisfaction with search, we are able to make our own progress on this without relying on third parties.

Hopefully that helps clarify the situation. --Dan Garry, Wikimedia Foundation (talk) 23:53, 21 April 2016 (UTC)

@Jasper Deng and Deskana (WMF): Thanks for both your comments. I have already made a preliminary response in the previous section regarding some of the trade-off questions concerning the strength of the search engine being used as compared to the strength of the hardware supporting the search engine technology being used. My reference was to the Sergei Brin comments in the 1990s where he indicated that the strength of the Google search engine was based on the then emerging technological ability to fully "download the internet" in an accessible format. This is the statement that needs to be tailored to the next level of inquiry for the next generation search engine design and implementation at Wikipedia. This would help determine the extent of your comments above on the practical limitations of using the model of the Google search engine for any future capacity objectives for the next generation Wikipedia search box engine. Could one you mention or indicate if the current capacities at Wikipedia and WMF are sufficient to do the equivalent of the Sergei Brin comment for Google in the context of Wikipedia; that is, can you "download the entirely of Wikipedia" as a basis for enhancing search box access performance in terms of preprocessing the direct database access addressing to articles, both properly spelled and improperly spelled, and then dynamically updating it on a daily or hourly (on-going) basis for all five million Wikipedia articles. I know the Wikipedia version is open source and I am asking the system design version of this question for purposes of the discussion here if one of you has a ready answer. Cheers. Fountains-of-Paris (talk) 16:10, 23 April 2016 (UTC)

A new section in CFD

I suggest a new section "CFRc" (Categories for recategorization). This process right now is not controlled. There is no forum for discussion, the category talk spaces are rarely visited, people have to make their edits or otherwise they would have to wait 6 months for a response.

There are easy cases where you don't need discussion, but what about the difficult ones? For example: Category:Singing is subcat to Category:Vocal music. Question: Would it not make more sense for it to be the other way around, as there can be singing without vocal music, but no vocal music without singing? If I would be bold and make this change according to my logic, I risk offending other people. But is is not something, I can propose in CFD in its current state. So I want to introduce a new section.

I imagine CFRc to be like the speedy rename section, you can simply nominate some categories, state your rationale and within two weeks you get a final decision or at least starting a discussion. The people at CFD are used to think about category problems, so they can easily judge all sort of cases. It would make recategorizing faster and a community effort.
Update 22 April The easiest way seems to be an additional template in CFD that says "restructure" or "recategorization" instead of "rename", "delete" etc.
CN1 (talk) 20:33, 17 April 2016 (UTC)

• Support the !forum. But specifically, beatboxing is vocal music without singing. There are others ^[blah]. fredgandt 23:51, 17 April 2016 (UTC)

• OK, so it is the other way as I thought. Singing is vocal music - the is-relationship puts the categorization beyond debate.
  

But would a circular categorization be appropriate in this case? Vocal music is ~95% singing, which is a "belongs-to-relationship".

That way three categories, which already are subcats to both, singing and vocal music, but only belong to the latter, can be removed from singing: a capella, barbershop music, vocal ensembles.

This topic is irrelevant, but it shows how this kind of discussion could look like. CN1 (talk) 15:13, 18 April 2016 (UTC)

• Oppose, we already have the talk pages of WikiProject Categories and (in this case) WikiProject Music for these kind of discussions. It doesn't make sense to scatter the discussions even further. Marcocapelle (talk) 05:13, 20 April 2016 (UTC)
  • @Marcocapelle: By the potential huge amount of such questions, the WikiProject talk spaces would need to be archived every month.
    

Besides, the questions in this problem are so strongly related to questions of renaming, deleting, merging and splitting, that I don't think there is a better place than CFD, it is just waiting for this section to be included.

CN1 (talk) 22:24, 21 April 2016 (UTC)

• I've tried raising such discussions at topic-related projects, e.g. about loops in the category hierarchy, often without much response. However, doing so plus posting a link at WT:CAT to the discussion, or vice-versa, is probably the best bet and sufficient. One existing alternative which I have used a few times is to have the discussion at CFD using a template which roughly matches what you want to do, e.g. Template:Cfs, and edit the proposal to say Restructure with a description of your proposed outcome. We could perhaps add an alternative template. – Fayenatic London 13:36, 20 April 2016 (UTC)
• We need to have such discussions, but it ought to be possible to do this within the present CFD structure (Categories for Discussion). I guess this involves manually adding a section to the page, possibly without tagging the categories (not sure about that part). Peterkingiron (talk) 15:53, 20 April 2016 (UTC)
  • I think we should always tag the category pages, to draw attention to the discussion. As a poor alternative there is already a notice template for use on category talk pages, but that only works for the few editors who may have the category on their watch list. – Fayenatic London 16:44, 21 April 2016 (UTC)
  • @Peterkingiron and Fayenatic london: This is what I want, but would there be some users who are assigned to watch after this section regularly like there are for the speedy rename section? Who would do that? If we can not find them, I may have to go the route Fayenatic suggested, posting a CFR and manually changing the word "renaming" to "restructuring" or "recategorising". Thing is: I've never seen a user so that - would that be a problem if I do such a uncommon thing? And if it is OK, can we not add a new template for this, so that other users are informed that they have this option? CN1 (talk) 22:16, 21 April 2016 (UTC)

RFC - Proposed: "Page mover" permission to be created

Please see Wikipedia talk:Page mover#RFC - Proposed: "Page mover" permission to be created to comment.

With thanks to everyone who provided input and insight, I would like to put forth a proposal to create the Wikipedia:Page mover permission. My suggestion is that page movers would receive

suppressredirect (The ability to move pages without leaving behind a redirect)

move-subpages (The ability to move subpages when moving their parent pages)

tboverride (The ability to override the title blacklist)

modified $wgRateLimits, allowing them to move pages more frequently than most users

This userright would be especially useful to editors who assist at Wikipedia:Requested moves. –xeno^talk 00:17, 19 April 2016 (UTC)

Proposal to make Draft:sandbox the default sandbox

Since both Markup editing and Visual Editing are possible in Draft:Sandbox, I propose that it replace Wikipedia:Sandbox (which can only be edited in Markup) as the default sandbox. WP:Sandbox is still useful to keep for those who specifically want to test out source code behaviour in the Wikipedia namespace, and for retaining its history. However, I think that Draft:Sandbox is more intuitive for new and inexperienced users, and the draft namespace also seems an appropriate prefix for a default sandbox.

What do people think? T.Shafee(Evo﹠Evo)^talk 23:08, 20 April 2016 (UTC)

It seems to have been taken care of. When you click on "edit page visually" you end up in the Draft:Sandbox. StarryGrandma (talk) 16:13, 23 April 2016 (UTC)

Auto-assessment

There exist nearly 700,000 articles currently in the category tree of Category:Unassessed-Class articles. Based on a sample I've looked at, it seems somewhere between 1/6 and 1/8 of these articles have been assessed, but some of the WikiProject templates on the talk page never had the {{{class}}} parameter filled in! This sort of task is perfect for a bot. I'm proposing that a bot run through all unassessed articles and fill in the {{{class}}} parameter using the already-filled-in {{{class}}} parameter from other WikiProject templates on the same page. If there's not a non-empty {{{class}}} parameter on the talk page, the article would be skipped. Some example edits: [4] [5] [6] [7]

This is a surprisingly simple task that seems unlikely to be controversial and potentially helps out hundreds of WikiProjects. I've already created the bot, but I'm seeking consensus that such a task is appropriate to run. Thoughts? ~ Rob^Talk 05:56, 21 April 2016 (UTC)

Discussion (Auto-assessment)

In theory, different WikiProjects are entitled to different set of criteria (in practice, the basic classes Stub–B are judged against the same criteria by all). Some other complications might arise:

1. What if existing classes disagree? In your third example, edit WikiProject Women's History gave the article Start, but WikiProject Discrimination ranked it as Stub-class. In your example edit, the result is to favor the lower ranking. Is this the intended behavior, why? Typically articles progress with time, and the lower rankings are based on older revisions (as was indeed the case with this article).
2. How will you treat non-standard classes (more of them here)? Say, if WikiProject Military history gives the article B+, but the WikiProjects with empty class parameters do not recognize that class neither in their assessment scheme nor in the way their template is coded.
3. Unassessed articles encourage editors to manually assess the article based on its current state. The bot, on the other hand, will inherently give articles assessments based on their past, and not current, status.

– Finnusertop (talk ⋅ contribs) 06:52, 21 April 2016 (UTC)

1. I currently have it set to use the lower class, but I could just as easily skip it. I've now set it to skip articles that have multiple standard classes set. If the article has a standard and non-standard class set (i.e. B and B+), then it will evaluate to the standard class (since it's very unlikely other templates will be using the non-standard one).
2. Any class other than FA, FL, A-C, GA, Start, and Stub are ignored.
3. I'm of the opinion some info is better than none. In reality, if an editor comes across an article with the situation I described, they'd probably plug in the old assessment value. Like always, editors can come by and update the classes. ~ Rob^Talk 11:31, 21 April 2016 (UTC)

Good answers, Rob. Regarding the third point, it would be great if the edit summary of the bot said that manual assessments are preferred. Many people watch articles and talk pages along them, and this bot could simultaneously serve as a reminder to conduct a fresh manual assessment. – Finnusertop (talk ⋅ contribs) 19:34, 21 April 2016 (UTC)

@Finnusertop: I can definitely do that. ~ Rob^Talk 20:32, 21 April 2016 (UTC)

@Finnusertop: The |auto= parameter was provided on many WikiProject banners for just that purpose, see WP:AUTOASSESS; if copying from another banner the bot would set |auto=inherit. Many WikiProject banners have had the feature removed in the last few years; some (like {{WikiProject Women}}) never had it; some (like {{WikiProject Women's sport}}} still have it. --Redrose64 (talk) 20:58, 21 April 2016 (UTC)

I think that every WikiPpoject that want auto-assessment has to state this individually. Otherwise, I do not see why we have class defined by each project separatelly. -- Magioladitis (talk) 16:52, 21 April 2016 (UTC)

We could also do it that way; place a mass-message on all WikiProject talk pages and allow either opt-in or opt-out. I'd greatly prefer opt-out, because of how many inactive WikiProjects there are on-site. ~ Rob^Talk 16:55, 21 April 2016 (UTC)

In case of inactive projects what's the reason to assess pages? Assessment is here to help wikiproject members. -- Magioladitis (talk) 17:13, 21 April 2016 (UTC)

Currently inactive projects don't usually stay inactive indefinitely, and inactivity at the WikiProject talk page doesn't mean that editors aren't using the assessment scale. ~ Rob^Talk 17:17, 21 April 2016 (UTC)

There will also be example of different classes. -- Magioladitis (talk) 18:51, 21 April 2016 (UTC)

Already mentioned by Finnusertop at 06:52, 21 April 2016. --Redrose64 (talk) 19:12, 21 April 2016 (UTC)

And fixed so those will be skipped. ~ Rob^Talk 19:24, 21 April 2016 (UTC)

@Xeno: if they want to comment on this. I used their script to autoassess in the past. -- Magioladitis (talk) 21:47, 21 April 2016 (UTC)

• I think Mag has a point in that unassessed articles can help focus the efforts and eyes of the members of said WikiProject. Probably best to go for opt-in so that only the projects interested in mass auto-assessment have their WP templates adjusted. –xeno^talk 00:50, 22 April 2016 (UTC)

I've tested my script on a sample, and it seems to work well. I'd like to avoid focusing on the technical issues here, since that's best handled in the BRFA process. Before we start talking details of the technical implementation, we need consensus for the task itself. ~ Rob^Talk 23:13, 21 April 2016 (UTC)

You can check User_talk:Xenobot_Mk_V/requests/archive (and older archives) for projects that wanted auto-assessment work in the past. –xeno^talk 00:54, 22 April 2016 (UTC)

I am involved in assessment for WP-Australia and support this task. --99of9 (talk) 23:35, 21 April 2016 (UTC)

• Seems like everyone agrees this would be beneficial as an opt-in task, so let's go with that. @Magioladitis and Xeno: How would you recommend notifying all projects of this possibility? I'm unaware of any mass-messaging service that will hit all WikiProjects currently, but I could do a one-time botrun that places a brief message on all project talk pages. I compiled a list of 1,194 WikiProjects/task forces from Category:Active WikiProjects, Category:Semi-active WikiProjects, and Category:Inactive WikiProjects, manually trimmed of the pages that are miscategorized. I'm not sure if it would be appropriate to use a semi-automated program to place a notice on all their pages or if a BRFA would be required for that many edits. Given the nature of the edits, I'd basically be a human bot if I was using a semi-auto program, just clicking away. This is on the line of what WP:BOTASSIST might apply to. ~ Rob^Talk 21:08, 22 April 2016 (UTC)

Proposal for changing Rights for whom can protect

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

---

In the current User Rights Group, only Administrators can change the protection level of different pages. However, as All Admins are not only 24/7, which made protecting pages from vandalism takes time to do. I am thinking if Wikipedia can extend rights for Extended Confirmed Users such that it can gain rights to change pages which are not fully protected (Full Protection), such that they can change the rights of some pages to prevent further vandalism by Unregistered, New Users? --1233thehongkonger (talk) 08:21, 21 April 2016 (UTC)

Oppose Extended Confirmed Users is an automatically assigned group after 30 days and 500 edits. There is no way some users should automatically get rights to prevent other users from editing a page. PrimeHunter (talk) 10:32, 21 April 2016 (UTC)

I do think we should have some user right for page semi-protection and un-semi-protection, but only one which is given out manually. עוד מישהו Od Mishehu 11:20, 21 April 2016 (UTC)

Oppose, anyone who can be trusted to correctly semiprotect pages should be allowed to block vandals or delete the page as appropriate. In other words, all of these people should be administrators. —Kusma (t·c) 11:53, 21 April 2016 (UTC)

• Oppose There's a reason that the adminship process is lengthy, and it's because the job is important and difficult. Letting thousands more people do it would hinder, not help. Joseph2302 (talk) 17:20, 21 April 2016 (UTC)
• Oppose Yes it can be a drag when one of the pain-in-the-kiester trolls gets going. We revert and report and revert again but any delay is not a reason to give editors who haven't been through a RFA some of the tools. The delay is part of life on WikiP and they all get blocked and/or pages get protected eventually. MarnetteD|Talk 19:18, 21 April 2016 (UTC)
• Oppose There are dozens of admins active at any given time. There are currently 851 who have the ability to protect articles, even at the periods of lowest activity, a few dozen are probably watching WP:RFPP, and most times of day there are hundreds. Admins are not overloaded. If you want to protect pages, use WP:RFA to ask for the admin bit yourself. --Jayron32 19:26, 21 April 2016 (UTC)
• You'll find some support for unbundling the sysop bit in general, but automatically giving the ability to protect pages wouldn't be a good idea. Ajraddatz (talk) 00:56, 22 April 2016 (UTC)
• Oppose per above. Suggest WP:SNOW closure. Even well thought through unbundling proposals rarely find consensus, so I doubt this one will find much support in its current form. Wugapodes (talk) 01:06, 22 April 2016 (UTC)

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

Indicate bot edits in page histories

Whilst we have indicators for both m and b edits in change (recent and watch) lists, the indicator for bot edits are omitted from histories and contributions.

I see no good reason to omit this information from histories, and simply propose that it should be included. fredgandt 16:13, 23 April 2016 (UTC)

To be very clear - are you proposing edits that have a bot flag included in the edit, or edits made by users in the bot group - these are not necessarily the same. — xaosflux ^Talk 21:30, 23 April 2016 (UTC)

Note: phab:T13181 is an old request "Mark bot edits in histories". phab:T18228 is a possible application if the data was there: "filter history of edits on bots (hidebots=1)". PrimeHunter (talk) 22:07, 23 April 2016 (UTC)

Erm, Imma gonna go with "flag" - final answer(?) Ok, I read all that somewhere once (or twice) xaosflux, but grey matter being what it is (squishy) it's mostly gone. bs where they should be.

phab T13181 - Brion: Schema changes, if appropriate, will be made when we've got a clear opportunity to plan for them. c.2007 -_-

Agreed PrimeHunter, it would potentially be very useful for filtering and simply nice to know when reviewing page histories by the by.

So, with phabs being old and tired, is this a road to nowhere or can they be prodded? fredgandt 22:32, 23 April 2016 (UTC)

Restricting access to user contributions

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

---

I do not agree with the current design whereby any stalker or nosy passer-by can examine any editor's entire edit history, and thereby build up a profile of that person. I propose that this facility be greatly curtailed. Administrators should continue to be able to see complete edit histories in order to investigate abuses. All editors should be able to see their own histories. It may also be desirable for recent edits, at least those of newly registered users, to be visible to all, so that ordinary (non-Admin) editors can find and revert strings of vandalism. However, the present unrestricted access to edit histories is neither needed nor desirable. 217.44.215.0 (talk) 17:17, 23 April 2016 (UTC)

Oppose and Snow close The only people this could benefit are serial vandals and their smelly socks. MarnetteD|Talk 17:21, 23 April 2016 (UTC)

What is "snow close"? 217.44.215.0 (talk) 17:24, 23 April 2016 (UTC)

"snow close" means, in this context, "this proposal does not stand a chance of being accepted". Something to do with rolling snowballs. Anyway. There are very many good reasons for keeping edit histories open to all - it's often useful to see what an editor has been up to and many eyes make all bugs shallow, which is to say, one cannot rely on the administrator caste to spot issues which arise out of non-admin examination of user histories. Bottom line is, wikipedia is a very transparent thing, and if that causes you problems w.r.t. your editing history, then you probably have a COI which means you should not be editing. --Tagishsimon (talk) 17:33, 23 April 2016 (UTC)

Re "snow close", I do not believe that one editor has the authority to make that judgement unilaterally. MarnetteD, please allow the discussion to take its course. As far as vandalism is concerned, I have made suggestions addressing that. How often do non-Admin (or non-Senior) editors go back through years of a user's edits looking for vandalism? 217.44.215.0 (talk) 17:37, 23 April 2016 (UTC)

We don't really do seniority around here. How often? Often, in my experience. I think you may have a misconception about admins. They have the keys to the mop-storeroom and, err, that's about it. They're not Batman. The whole place depends on ordinary users doing this sort of thing - looking for vandalism & COI, for instance. If an admin action is required, admins can be summoned (with their mop & bucket). Meanwhile MarnetteD isn;t particularly trying to close down the discussion, so much as advise - accurately - that it's not going to go anywhere. --Tagishsimon (talk) 17:42, 23 April 2016 (UTC)

May I suggest changing the wording in your proposal (section heading and lead) to clarify that you're referring to "User Contributions", please? fredgandt 17:43, 23 April 2016 (UTC)

This proposal does not have a snowball's chance in hell of passing, for both legal and practical reasons (attribution and the need for transparency). So I also second a snow close.--Jasper Deng (talk) 19:51, 23 April 2016 (UTC)

+ !vote to close this. fredgandt 21:25, 23 April 2016 (UTC)

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

Good lists

Why isn't there a good list designation, like there is a good article designation? Unless I'm missing something, a list goes from regular status to featured status, if it gets improved enough to make it. I think there should be some kind of intermediate status to show that a list is sourced, well written and encyclopedic, like an article, without it being quite to featured level. White Arabian Filly ^Neigh 21:00, 23 April 2016 (UTC)

@White Arabian Filly: Because there was no consensus at Wikipedia:Village pump (proposals)/Archive 123#Good Lists. The present situation, broadly speaking, is that most WikiProjects have List and Featured List but no levels in between; a few have Stub List (or SL) in addition; WP:MILHIST has CL, BL and AL, but not Good List (see WP:MHA#SCALE). --Redrose64 (talk) 22:24, 23 April 2016 (UTC)