Wikipedia:Village pump (proposals)/Archive 131

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211

About {{Commons category}} , {{Commons category-inline}}, {{Wikisource}}, {{Wikisource-inline}}, {{Wikisource author}} and the like

Now that Wikidata often has info about a particular Wikipedia page's corresponding Wikimedia Commons category or Wikisource page or the like, is it really necessary to keep this kind of templates in the article? They have the same function! I've removed this kind of templates in these pages, however sometimes someone reverted my removals, so here I ask other Wikipedians' opinion.--RekishiEJ (talk) 03:35, 30 March 2016 (UTC)

Keep them. IMHO it is really necessary to keep this kind of templates in articles and you should not remove them.
I think you're proposing that rather than have a direct link from an article to its corresponding Commons category (say), readers would have to find and click the "Wikidata item" link and look in Wikidata simply to find whether there's a Commons category, and if so, go to it?
Technically, that works, but Wikidata isn't user-friendly (nor intended to be); and anyway, it's surely much more friendly to have a link from a WP article to its Commons category, rather than make the reader go elsewhere simply to find out whether there is one!
With the increasing amount of linkage in Wikidata, it'd be good if these link boxes could be placed automatically, so that articles wouldn't have to contain templates such as {{Authority control}} or, indeed, {{Commons category}}, because the information would appear automatically. But I don't know whether such an enhancement is on the radar. — Stanning (talk) 11:48, 30 March 2016 (UTC)
  • Keep, our sister projects are so intertwined with Wikipedia and its editors that more links, not less, should be the norm. All the images, for example, are now "off-site" in commons, so the lines are not only blurred but come together nicely. I've strongly advocated including a few sister-project links at the bottom of topic templates, for example, and hopefully more editors are coming around to that position as well. Randy Kryn 11:57, 30 March 2016 (UTC)
    • I mean, now that these info on Wikidata are shown on the "In other projects" section, is it really necessary to keep the templates anymore? For example, readers of the Wikipedia article Dmitry Rogozin can access the corresponding English Wikiquote page simply by clicking the Wikiquote link shown on the IOP section, in my opinion {{Wikiquotes}} should be removed from the article.--RekishiEJ (talk) 12:38, 30 March 2016 (UTC)
  • Keep - All templates are extremely helpful here and not only that but in the last 3/4 years of me being here I've never ever known about the "In other projects" section and that's because I obviously never pay attention to that area, So having these links makes it so much easier expecially for those who have no idea about the IOP thing, (BTW sorry but I've reverted you on the Dimitry article as you should really get consensus to remove them anyway), –Davey2010Talk 01:59, 2 April 2016 (UTC)
    @Davey2010: "In other projects" has only existed outside of a Beta for a month or two. Before that, maybe another 6 months. So it is no wonder that "in the last 3/4 years of [you] being here" that you have not really known about them. --Izno (talk) 19:55, 3 April 2016 (UTC)
Ah well that would completely explain why I've never known in the 3/4 years ... cos it's never been there for that long! !, Other than checking a users contributions or to upload a file... I've never needed to use that bar so obviously don't pay sod all attention to it, Well I still believe the templates are better than the sidebar thing but that's just MHO. –Davey2010Talk 20:41, 3 April 2016 (UTC)
  • Keep. The template determines the display of the information – placement in the article, box at right, inline, individual or a list with others, the text for the link, and so on. The casual reader may well not expand and look through all the side links, indeed I also normally don't. In some cases the target name is not the best for the link text in a particular article, for example with Caroline Matilda of Great Britain, the corresponding commons category is commons:category:Queen Caroline Mathilde of Denmark: it is a matter of human judgement in each case whether the link text should be the target name, the article name, or something else. --Mirokado (talk) 21:00, 3 April 2016 (UTC)
  • Keep, though it should be clear that mandatory inclusion of these should not be done. They're good templates to advertise content on these sites, and most of the time are purposely included to highlight this. However, while we might categorize some free content with a topic, it might not always make sense to force a link to that in the body (but letting Wikidata handle that otherwise), especially if the other content is otherwise thin, like one or two pictures that already used in the article in question. --MASEM (t) 22:06, 3 April 2016 (UTC)
  • Keep in this article, the {{Commons category}} template is 19 pages from the "In other projects". Secondly, the side bar isn't part of the article. These are valid external links.
All the best: Rich Farmbrough, 13:06, 4 April 2016 (UTC).

One-month focus on 5-6 link disambiguation pages.

Every month we have a disambiguation link-fixing contest at Wikipedia:Disambiguation pages with links, with the winners receiving immortality by being recorded in the Disambiguator Hall of Fame (and the top three being eligible for a free t-shirt from Wikimedia). There are two ways to earn points in the contest - one is to fix links to the top 1,000 most-linked pages at the beginning of the month, and the other is to fix links on the "bonus list", which includes all disambiguation pages with four or fewer incoming links. Over the years that we have been working on this, we have steadily beaten down the average number of disambiguation links per page until we have now reached the point that many of the top 1,000 have only five links. In fact, as of now, there are fewer than 1,000 pages with more than 5 incoming links. If we can keep that number below 1,000 through the end of the month, then we will have bridged the gap between the main list and the bonus list, and every single disambiguation link in Wikipedia at the beginning of May will count for the contest. If we could get a few dozen Wikipedians to each knock out a few dozen disambiguation links to pages with 5 or 6 incoming links before the end of the month, I'm sure we would handily make this goal. Cheers! bd2412 T 15:04, 4 April 2016 (UTC)

Show full section hierarchy in edit summaries

When we edit a page section, the edit summary is automatically populated with /* The section name */ which is parsed to form a link to that section.

We can manually alter that value, and even add more /* Section links */ using the same syntax.

I'd like to see the full section hierarchy automatically added when we're editing inside a nest i.e. If we edit a level 3 section, the edit summary would be auto-populated with something like /* Level two section *//* Level three child of level two section */.

This would make edit summaries clearer to understand (and in many cases that clarity is practically essential), especially in our watchlist. fredgandt 17:58, 3 April 2016 (UTC)

It would add clarity, but it would become an issue of too much automatic text in the edit summary restricting space for manual comments. What about including the level 2 header by default, and then the smallest section actually edited? For example, /* Level two section *//* Level three / four / five child of level two section */? Ajraddatz (talk) 18:13, 3 April 2016 (UTC)
I agree; it eats into the real-estate. I felt the proposal would be more acceptable if the change isn't drastic. Utilising the system already in use, with a little tweak would be trivial in coding terms (on the backend), and remain familiar. Ideally however, I'd prefer to see a more grown up system which required no special text in the summary at all. But yeah, as long as the end result shows the root section and that the edit was performed on a child, I could get behind leaving out a few parents. fredgandt 18:49, 3 April 2016 (UTC)
I would tend to support it, as long as it doesn't eat into the maximum edit summary length - which it currently does. עוד מישהו Od Mishehu 20:58, 4 April 2016 (UTC)
I can't speak for them (of course), but I doubt the WMF would be open to a lightweight request to consider removing section link handling from being text based. I think something like that would require a massive majority !vote. So assuming we're stuck with a text based solution, all we might hope for is to remove section links from the 255 byte count per summary, and to be honest, I doubt they'd go for that without a fight. The thing is, whilst section links are text based, we can remove them if they're in the way, so any additional ones automatically added would be not much more bother than the ones we already get. fredgandt 00:17, 5 April 2016 (UTC)
The only objections to your suggestions that I see are technical matters: "removing section link handling from being text based" would require a rework of quite a bit of code to store the section links in some unspecified other manner, and "remove section links from the 255 byte count per summary" (while keeping the summary as a text-based field) would similarly require some major reworking since the byte count limit comes from the size of the database field in which the summary is stored rather than being some arbitrary number chosen for nontechnical reasons.
There is T6715 which is about simply raising the byte limit, which is probably your best bet for getting action here. I think it's currently stalled on "new DBA objects to the old plan, new ideas are proposed but no one is working on making those new ideas happen"; you should probably ask on the task if you want to find out more. BJorsch (WMF) (talk) 20:03, 6 April 2016 (UTC)

Move reason preview

It is possible to link to diffs (e.g. Special:Diff/12345678) and permanent links (e.g. Special:PermanentLink/12345678) in the move reason. In order to more easily check the links for errors, I propose a preview feature like the one for edit summaries. Iceblock (talk) 22:32, 5 April 2016 (UTC)

This calls for a change to the software - see Wikipedia:Bug reports and feature requests. As a workaround, click on any edit link, use the desired summary, and preview the edit; it should work the same way as the move reason. עוד מישהו Od Mishehu 11:26, 6 April 2016 (UTC)
It should be reasonably easy for someone to make a user script to do the preview using action=parse&prop=&summary=.... Anomie⚔ 20:08, 6 April 2016 (UTC)
On the side note, no task is hard for you, Anomie. --QEDK (T ☕ C) 14:27, 7 April 2016 (UTC)

Auto-hyphenating words for alignment in all articles?

I have seen long, lengthy words pushed from one sentence to another. Shall we have a system automatically detect syllables of every word and then break them to smooth alignments of every article? I was going to take this to "Idea lab", but this idea is as far as I go. --George Ho (talk) 19:23, 7 April 2016 (UTC)

On Firefox, Safari and IE 11 this is as easy as adding a hyphens: auto to the stylesheet. See e.g. User:Ruud Koot/vector.css. On Chrome this currently requires loading a rather large piece of Javascript. Automatic hyphenation will also screw up occasionally. Firefox's hyphenator also seems a bit too aggressive IMHO. —Ruud 20:00, 7 April 2016 (UTC)

Use of local forms of English

I see your policies recommend that local forms of English (Indian, South African and so on) should be used on topics specific to a particular country. I've just commented as follows in the Talk section of the article on the Indian film 'Om Shanti Om' (which is obviously specific to India): "As a non-user of Indian English, I can't help wondering what such a specifically Indian word as 'lathicharge' is doing in a Wikipedia article. At first I thought it was a misprint, then looked it up and discovered what a 'lathi' is. I suppose there's no reason not to use such terms in Wikipedia (any more than 'lakh' and 'crore', or that ugly euphemism 'eve-teasing'), but it doesn't make for easy reading, especially if (like many Wikipedia users) your native language isn't English in the first place. As for 'Shahrukh Khan is communal' (just after 'lathicharge'), I can again only assume it's Indian English, since it means nothing whatever to me as a native English-speaker - except a vague hint that the guy may be sexually promiscuous! By the same token, I wouldn't use the word 'bold' in its common Irish meaning ('naughty', 'cheeky') or the Australian word 'bogan' in the middle of a text for an international readership." I really think there comes a point where keeping to local forms of English gets confusing, as I think it is here. Of course, I can look up 'lathicharge' and find out the meaning (as I have done), but I still have no idea what 'is communal' is supposed to mean. Perhaps Manoj Kumar (who apparently used the expression) simply doesn't know English very well, or perhaps this was an over-literal translation from Hindi (or another Indian language). Anyway, my proposal is that the policy be amended (if only slightly) in the interests of international intelligibility.213.127.210.95 (talk) 16:06, 7 April 2016 (UTC)

MOS:COMMONALITY says to attempt to use common words. The reason many articles (especially the Indian topics) don't is because (I suspect) most editors interested in those articles are from India or speak Indian English natively. --Izno (talk) 16:13, 7 April 2016 (UTC)
Thanks for this prompt and helpful reply! I was going to add that when translating into English (which I do for a living) I now tend to avoid English words that can easily be misconstrued by non-native speakers of the language. Classic examples are 'eventually' and 'actually', whose direct equivalents in other languages ('éventuellement', 'actuellement' and so on) mean something quite different ('possibly' and 'currently'). I now try to replace these two words with 'ultimately', 'sooner or later', and 'in fact', 'really' (whose meanings are clear to all), unless I'm quite sure that my readers will be native speakers.213.127.210.95 (talk) 16:21, 7 April 2016 (UTC)
Even if there is a localised English template on an article, it should not be any issue to convert jargon only understood in that region to more internationally known words. The example of Australian unique words would need converting as most of them are colloquial or slang, and not appropriate for written use. If a unique term is needed, then it should be explained, the same as for other technical language used. Graeme Bartlett (talk) 07:04, 10 April 2016 (UTC)

Displaying pronunciation of a word in regional language

Hello Friends, I would like to suggest to Display pronunciation of the word searched by user in regional language, like in India, Regional language is Hindi or Marathi.

For Ex. consider a word Revoke so while displaying on wikipedia page as

Revoke ( रिवोक )

This will help reader to know the correct pronunciation of the word.— Preceding unsigned comment added by PGAwade (talk • contribs)

There's too many languages to do that, and many local languages cannot accurately represent sounds in other languages. Many articles do feature the International Phonetic Alphabet pronunciation, which is meant to be language neutral (in other words, anyone who speaks any language who learns how to read the IPA can use it to pronounce any word). Ian.thomson (talk) 04:03, 24 March 2016 (UTC)
  • Strongest possible oppose This is the ENGLISH Wikipedia. We should never, ever have text in languages other than English except for cases like the native names of proper nouns. Also, in your example, there's nothing at all that would make Hindi or Marathi special with regards to the term "revoke", so the only way we could fairly do that would be for every word to be accompanied by hundreds of languages' worth of pronunciations. Jackmcbarn (talk) 20:49, 28 March 2016 (UTC)
  • User:PGAwade, may I suggest that this idea is far more appropriate for wiktionary? That said, I suggest that you learn IPA (IPA for English should help) and use those pronunciations where available. Oiyarbepsy (talk) 04:33, 29 March 2016 (UTC)
  • Oppose, per Jack. The IPA for the standard English pronunciation should sufficeThere is already too much of English-as-an-official-2nd-language countries trying to turn the English Wikiedia into their Wikipedia. More effort should be spent by those nationals in developing and expanding their home-language Wikis (and believeme, living in the thick of it here in Asia, I know what I;m talking about). Kudpung กุดผึ้ง (talk) 11:23, 30 March 2016 (UTC)
  • Oppose Unless the word is from another language, or is a proper noun, no real need to do this. My feeling is that it would just slow down Wikipedia. ThePlatypusofDoom (talk) 23:24, 7 April 2016 (UTC)
  • Comment: Just what exactly the OP is proposing is highly ambiguous, and some of the above responses seem to have adopted different of the multiple possible interpretations. If the user simply wants a script that allows them to view a rough translation of a given word, utilizing manual selection I'd direct them towards [translate.google.com google translate]. If they want a script that translates and transcribes a term when places in our internal search engine, that would be a major project, though probably not infeasible in theory. If they want to have actual parentheticals which include a transcription of every term introduced for every language that could reasonably be concerned with the topic (of the article or term), that is obviously just not possible for a variety of reasons. Again, it's quite questionable what PGAwade is asking for here, but the least we can tell them is that, as a general rule, non-English content (especially in non-English scripts) is severely restricted to certain niche contexts on this project, as as a matter of longstanding community consensus as to pragmatics and the fact that this particular Wikipedia is meant to facilitate the sharing of information through English, insofar as article content is concerned. Snow let's rap 11:13, 11 April 2016 (UTC)

Problem a new article just by a small and big letter difference

Problem a new article just by a small and big letter difference. an article "Vettar River" is made two times in name of "Vettar river".--wiki tamil 100 11:43, 11 April 2016 (UTC)

@Wiki tamil 100: can you not just move the article to the right place (Vettar river) while leaving a redirect (as it appears a reasonably common typo). --Dirk Beetstra T C 11:49, 11 April 2016 (UTC)

RFC: Corrections on Main Page?

There is no consensus to issue corrections on the main page. (non-admin closure) ~ RobTalk 06:17, 18 May 2016 (UTC)

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

The Main Page sometimes has factual errors (mainly on WP:DYK, also in other sections). At the moment, these get quietly corrected or removed, but no acknowledgment of this is being made. Similarly to what happens with e.g. newspapers (Correction (newspaper)), we could make a note of factual errors we featured on the Main Page in either the same spot (so a DYK error gets noted in the DYK section of the main page) or in a separate section on the Main Page. This should only be done for facts, not for grammatical errors, capitalization changes and the like. This was recently done a few times, but met with mixed reactions. How exactly this should be done is not really important, first we need to agree on whether this is wanted or not. Fram (talk) 10:42, 23 March 2016 (UTC)

(Note: this is not intended for ITN items which were correct at the time of posting but were outdated at some time: this is not an error but normal progression of events). Fram (talk) 10:46, 23 March 2016 (UTC)

Examples: A possible approach to such a correction, or this one (that one wasn't a Beatles recording, only Harrison was involved). (these were added after the first two comments below were made) Fram (talk) 14:09, 23 March 2016 (UTC)

  • I think how we do things now is fine. Most of the items which come up for discussion at WP:ERRORS are ephemeral anyways, and most changes are minor differences of wording or updates of changing or fluid situations. --Jayron32 11:47, 23 March 2016 (UTC)
    • The proposal is not for those kind of changes, but for real errors. I'll add some recent examples above. Fram (talk) 14:09, 23 March 2016 (UTC)
  • The main problem with the main page currently is that the disclaimer is buried at the bottom in fine print. It should be made more prominent as it's our general position that that any of our content might be wrong. Publishing corrections should only be done when the error or issue is important as it is quite easy to nitpick details. For example, the blurb for yesterday's FA said, "The animals lived for at least 12 to 20 years..." This is erroneous because some of these creatures died young while at least one specimen was found to have reached age 27. But the exact range of lifespans of creatures that have been extinct for millions of years is not a big deal and argument about the best wording for our tentative knowledge of them is likely to be protracted. What might help is having WP:ERRORS turned into a noticeboard with the usual structure of topical sections, archives and the like. Currently WP:ERRORS is too emphemeral and this makes it quite poor at handling issues which would benefit from some continuity, history and discussion. Andrew D. (talk) 13:46, 23 March 2016 (UTC)
    One possible solution is that the error gets removed or corrected, but that a correction only gets posted at the next update (FA or DYK mainly) after a discussion at WP:ERROR. That could avoid corrections for every minor problem, or corrections to corrections, and so on. Fram (talk) 14:11, 23 March 2016 (UTC)
    Having the general disclaimer buried at the bottom in fine print doesn't mean that it doesn't get found. Just look at the amount of rubbish that gets posted to its talk page. Same thing happens with other links "buried at the bottom in fine print" like Wikipedia talk:About and Wikipedia talk:Contact us. --Redrose64 (talk) 21:23, 23 March 2016 (UTC)
    The general disclaimer page gets about 5000 hits per day. That's about the same as a mediocre DYK, which isn't much. Consider that this page appears not just at the foot of the main page but at the foot of every page. Hardly any of our readers are clicking on the link. One reason for that is that the link is blandly bureaucratic and boring. If, instead, every page said Wikipedia is not reliable!, it might get more attention. Andrew D. (talk) 21:54, 23 March 2016 (UTC)
  • Oppose We are a website, not a printed source. A newspaper cannot edit already sold papers. And we have five million articles where lots of errors are found and corrected. The main page gets a lot of views and hopefully has fewer errors than average articles but I still don't see good reason to single it out and point out already corrected errors unless they are directly harmful, and I don't recall cases of that on the main page. PrimeHunter (talk) 14:35, 23 March 2016 (UTC)
    • The reason to single out the main page is that unlike other pages, it gets heavily scrutinized before anything is posted there and shouldn't contain any serious errors. It's not the part that anyone can edit, with all advantages and disadvantages that has, but the part that we (the community) choose explicitly to highlight, to showcase. That may of course not be enough for you to consider supporting this, and I don't intend to badger all opposes, but I just wanted to indicate why I do see good reasons to single it out. Fram (talk) 14:51, 23 March 2016 (UTC)
  • Weak oppose, per PrimeHunter above. Rehman 14:46, 23 March 2016 (UTC)
  • While I think reminding people that Wikipedia is full of errors is a good idea (there was something good about the time when the wiki was full of harmless vandalism of the "Kusma is gay! tell everyone!" variety, as that served as a reminder that Wikipedia is edited by random people and not always accurate), I don't like having extra policies for errors on the Main Page as opposed to errors in the content everywhere else. The main problem I see here is that it took more than two hours until the problem was corrected, which is embarrassingly long and probably something to point out whenever somebody opposes a good faith editor at WP:RFA. WP:ERRORS is one of the more urgent admin areas. —Kusma (t·c) 15:09, 23 March 2016 (UTC)
    • Actually, more than 6 hours in that instance between reporting and correction. Getting errors off the main page (by correction or removal) is of course more important, and shouldn't wait until a correction has been written; it should be consecutive processes, with the error handling not dependent on the addition (or not) of a correction. Fram (talk) 15:14, 23 March 2016 (UTC)
  • Oppose. Primarily because I don't see an actual point. Resolute 19:15, 23 March 2016 (UTC)
  • Weak support I can see this helping the accuracy and transparency of Wikipedia. My main concern would be the implementation, but I'm open to a trial run to see whether there is any way of doing this. Jolly Ω Janner 19:49, 23 March 2016 (UTC)
  • Oppose except where BLP issues are involved. For the most part, the readers who saw the error won't be likely to see the correction. עוד מישהו Od Mishehu 20:56, 23 March 2016 (UTC)
  • Support A few years ago I would have agreed with the oppose arguments. However, it now seems to be standard practice on the web to indicate how a news story or other posting has been corrected, in the interest of fuller transparency. It is not a question of who might or might not see it, or what type of website we like to think we still are. It's a matter of principle; we may find ourselves behind the curve sooner than we think. Daniel Case (talk) 21:09, 23 March 2016 (UTC)
  • Oppose it's not clear what errors qualify for main page "corrections". It's not clear how the demonstration of such errors fits into the main page design considering that errors can occur in every panel of the main page. There may be a case for a "Corrections" page which can be linked from the main page somewhere so we can confess our sins, but given today's little outburst, it's clear that "disclaimers" will be as erroneous as the errors they are attempting to disclaim. This is not path we need to tread, all articles in Wikipedia are subject to errors, after all. The Rambling Man (talk) 21:25, 23 March 2016 (UTC)
  • Support I like this idea, and I agree with Daniel Case that this is a common practice that we should be adopting. Of course, my general opinion is that we put an enormous amount of volunteer effort into selecting and assembling content for main-page visitors who are mostly indifferent to it, and we'd be far better off coming up with alternative, more targeted processes of serving curated content to those likely to be interested in it. But given that we have what we have, I think we should be transparent about our errors and use the opportunity to highlight the wiki process. Opabinia regalis (talk) 21:55, 23 March 2016 (UTC)
  • Oppose Errors can occur anywhere. We work on a basis of making corrections as we go. Hawkeye7 (talk) 22:03, 23 March 2016 (UTC)
  • Oppose due to the nature of Wikipedia, errors are commonplace. We don't acknowledge previous errors on other articles, not even BLPs. The main page should not be an exception. SSTflyer 07:51, 24 March 2016 (UTC)
  • Oppose - Once something is printed or published electronically by a reputable news organization, it isn't expected to change. Wikipedia articles on the other hand are fluid and change is an expectation. By enshrining the errors within a certain version because it appeared prominently almost We shouldn't give the impression that we are holding our articles to the publishing standards of organizations who employ correction (newspaper), which we cannot due to the nature of the project. Errors both big and small can exist, and unless we have a body of volunteer scrutinizers to check articles (which begs the question why not preemptively do it), We already reasonably scrutinize the text before it appears on the main page, so if there is an error it might not be discovered or brought to light until much later. In that case more than likely individuals won't check to see if it was present in the version that was linked on mage page (in the unlikely case they even know or remember it has been there) when it is corrected, and the "correction acknowledgment notice" would fail to have listed it (unless there was to be a time limit to catch errors?). Furthermore, consensus would be needed on which errors to report (along the lines of which items to include in the news section). Obviously errors like falsely stating someone was a suspect in a notable assassination attempt nature would be reported if linked on the main page, but what about smaller factual errors. How long would an error within the text have to be live if it is corrected during the day to warrant a notice it is linked on the main page? This proposal would probably increase the rate of complex non-factual information being purposely introduced to the pages slated to be displayed there (or planted long before that then nominated) by malevolent editors with the goal of "making the correction acknowledgment notice". Lastly, maintaining a "correction acknowledgment notice" along with the other processes I've described above adds more non-essential work for our volunteers, who could instead be improving encyclopedia articles. Interesting idea, I liked it before I thought to hard about it.—Godsy(TALKCONT) 08:38, 24 March 2016 (UTC)
    • The proposal is not for errors in the articles linked to from the main page, only for errors actually put on the main page (e.g. for DYK, only errors in the one-line hook would apply, not all errors elsewhere in these articles). All texts put on the main page are already vetted extensively by editors here (through the FA process or the DYK process), so your question about the preemptive vetting is besides the point. Fram (talk) 09:24, 24 March 2016 (UTC)
      • I've amended my comment to reflect that, a good part of it still stands. Regards,—Godsy(TALKCONT) 13:23, 24 March 2016 (UTC)
  • Comment: many people compare the main page to other pages, where no corrections are indicated. There are of course a few major differences, including the lack of history on the main page (it is relatively easy to see when an article stated version X or version Y of the truth; it is much harder for most people to find when the main page said X or Y, as it exists of transcluded subpages with different names). Articles are pages "anyone can edit", with the inbuilt risk that they will contain errors. The Main Page is not a page anyone can edit, but a severely restricted and vetted one. This of course doesn't mean that one should support this proposal, but I don't think that only opposing this because we don't do this on articles, is really a sufficient argument ("we have references on all articles, we should have them on the main page as well" would be a comparable reasoning, which I think many of you would oppose). Fram (talk) 09:24, 24 March 2016 (UTC)
  • Oppose, per WP:NOT#PAPER and WP:NOT#NEW. Newspapers publish retractions and paper book publishers include errate sheets because they can't correct the extant copies. That does not apply here; we simply issue a corrected "edition" instantly.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:18, 24 March 2016 (UTC)
  • Comment it would be worth adding a "correction" notice to the talk page of DYKs, for instance, that have suffered major issues and still been on the main page, after all the "DYK" hook is usually added within a template to the article talkpage. It would be easily traceable to add a "correction" parameter to this, or simply add a "Correction" section to the talkpage. The Rambling Man (talk) 11:22, 24 March 2016 (UTC)
  • Oppose. We already know where these errors are coming from, this will do nothing to address the underlying issues. Gamaliel (talk) 14:59, 24 March 2016 (UTC)
  • Oppose. What concerns me mainly about this proposal is that it would essentially create what amounts to a "DYK shame file" on the front page which would give incentive to those users opposed to DYK to find fault with DYK hooks and/or the underlying articles in order to add hooks to the file. Disputes over content and processes occur all the time on Wikipedia, the front page is not the place for them. Gatoclass (talk) 16:38, 24 March 2016 (UTC)
    • DYK is its own shame file sometimes already, this wouldn't change a lot about that. As has been said before, errors in the underlying articles have nothing to do with this proposal. This is about errors (not "finding faults with", but "finding factual errors in"). No idea why you add "disputes over processes", perhaps for the same reason you added "the underlying articles" to your oppose. Still, after your recent comments at WT:DYK, I'm not amazed about these inaccuracies, I just hope not to many uninvolved editors believe them. Fram (talk) 19:56, 24 March 2016 (UTC)
So, you've never pulled a DYK hook because of issues with the article? It's hardly as if this were an unknown event, so yes, hooks and the underlying articles. With regard to "disputes over processes", what I'm saying is that the main page is not a place for pursuing them, which I fear is what would occur if this proposal were to be adopted. Gatoclass (talk) 08:43, 25 March 2016 (UTC)
I can't recall pulling a DYK hook from the main page for issues with the article, no. But I may have done, if the article needed deletion as a hoax or if the hook segment in the article was a copyvio or some such problems. But it's a strawman argument anyway, as it doesn't address what I said or what this proposal is about. If a DYK would get pulled for copyvio problems, no correction would need to be put on the main page, and I didn't suggest this. And if a DYK would get pulled for being about a hoax article, the DYK hook would obviously be incorrect and a correction for such an egregious mistake wouldn't be a bad thing anyway. So no, feel free to repeat it as often as you like, but definitely not about the underlying articles. Fram (talk) 10:32, 25 March 2016 (UTC)
Okay, have it your own way. But I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not. Gatoclass (talk) 11:05, 25 March 2016 (UTC)
Funny, it is important enough to put on the Main Page that Game X was the first to require Controller Y, but when that information is incorrect, it is suddenly "incredibly trivial". Considering that the majority of DYK hooks is of comparable triviality, perhaps we should just get rid of it? That would free up time for quality control in all articles and remove lots of bureaucracy and problems. But I have the feeling that that is not what you had in mind when you wrote the above. Fram (talk) 11:36, 25 March 2016 (UTC)
On the contrary, I have never denied that many DYK hooks deal with trivia, and I'm not bothered by it, because DYK is not about finding a bunch of portentous facts, but about demonstrating that Wikipedia is an ever-expanding knowledge base on the widest possible variety of topics. You, by contrast, like on the one hand to disparage DYK on the basis that it deals with trivia, but on the other apparently expect the community to have conniptions over the fact that a small percentage of the trivia featured might on occasion be erroneous. Gatoclass (talk) 12:34, 25 March 2016 (UTC)
(on second thoughts, forget it. I'm done with replying to your wild accusations time and time again. People who follow DYK without seeing DYK as a goal in itself will know my real objections against it (which is not triviality), the amount of errors, and the amount of those I catch after they have been approved but before they hit the mainpage as well. Those things are more telling than whatever you may come up with next. Fram (talk) 13:12, 25 March 2016 (UTC) )
  • Oppose - Serves no purpose. We already have Wikipedia:Main Page/Errors. — Maile (talk) 18:32, 24 March 2016 (UTC)
    • That page is for readers to contact us (editors) to correct a page. This proposal is for the reverse, to let the readers know that despite our vetting, we posted incorrect information on the main page. Which you are free to oppose, of course, but confusing things doesn't help. Fram (talk) 19:56, 24 March 2016 (UTC)
  • Support assuming it's not ugly or intrusive. I think it'd be a service to readers to let them know when they have been accidentally misinformed. --Jakob (talk) aka Jakec 19:27, 24 March 2016 (UTC)
  • Support; above all, Wikipedia is a source for information, and any incorrect information which is distributed by Wikipedia should be corrected. Because of the high traffic volume of the main page, a mistake there carries more weight than a mistake elsewhere, and should be treated thusly. Something along the lines of the first of Fram's two examples above appeals to me; a small notation under the day's DYK's is nonintrusive yet useful. Colonel Wilhelm Klink (Complaints|Mistakes) 21:41, 24 March 2016 (UTC)
  • Support Noting that online editions of newspapers do include corrections. As the possible negative impact on living persons where incorrect contentious claims have been made are clearly significant, and as WP:BLP avers that we must avoid damage to living persons, any error which might improperly affect living persons should be corrected with the same visibility as was given the incorrect claim or information. For matters of "how old was the fossil" - such errata are of far less importance, but where specific living persons are concerned, I find the "but facts are of minor value" position to be wrong. Collect (talk) 23:25, 24 March 2016 (UTC)
  • Oppose. My opinions on the main page's accuracy issues are fairly well known, and I'd seriously consider abolishing the MP altogether and replacing it with www.wikipedia.org given the amount of hassle it causes for dubious benefit. That said, I agree with every word of I still say the main page should not be used as a political football. And in any case, I think this proposal is completely impractical, would require a lot of discussion about procedure, would burden DYK with more bureaucracy, reducing the time spent on quality control itself and discouraging participation, and achieve very little, given that DYK hooks are only ever displayed for a few hours - removed hooks even fewer - and that most DYK errors are incredibly trivial, such as whether game controller x was first used in game y on platform z in 1999, or not above. ‑ Iridescent 11:29, 25 March 2016 (UTC)
    • Then please see my reply above to that statement. The DYK errors are just as incredibly trivial as the DYK hooks, so arguing that the corrections should not be displayed is basically an argument that the hook should not have been displayed in the first place. Which goes back to your first argument of course (which has considerable merit), but is hardly a reason to oppose posting corrections as long as we are stuck with DYK. Fram (talk) 11:39, 25 March 2016 (UTC)
  • Oppose per Primehunter. Most DYK errors are not egregious enough and do not receive enough complaints from people to warrant special notice on the main page, especially since they are quickly corrected. If for some reason it does, a special case could be made, but I find that situation unlikely. I would instead suggest that stronger fact-checking is done during the nomination process to prevent this situation from occurring in the first place. ZettaComposer (talk) 14:11, 25 March 2016 (UTC)
  • Oppose although I get where Fram is coming from. Not only is running a corrections column going to take extra editor work as well as valuable real estate on the Main Page, it really advertises shameful inaccuracies instead of being transparent with the reader. I agree with Andrew D that the disclaimer need to be far more prominent. Instead, why don't we hand out one-day blocks of editors responsible for these errors making it to the Main Page? Like Iridescent's three strikes concept, the editor is banned from those processes (DYK, ITN, etc.) where they've proven incompetent. Let's cure the disease (inaccuracy causing reader unhapiness) rather than treat the symptom (mollifying readers thru Mea culpa). Chris Troutman (talk) 15:35, 27 March 2016 (UTC)
  • Support. I think that if a statement appears on the Main Page but is determined to be incorrect, it would be appropriate to post a correction on the Main Page, in hopes that the truth will reach as many people as the false statement did. Blocking the editors responsible for the incorrect information may be an appropriate punishment, but it doesn't by itself promulgate the correction. --Metropolitan90 (talk) 05:34, 28 March 2016 (UTC)
Blocking is not necessarily appropriate, because blocks are not for "punishment". Especially on a first offense, the editor responsible for the incorrect information was more than likely submitting it in good faith, and mistakes happen even among competent, good-faith contributors. The correct approach is to advise them to learn from the mistake and move on. If the editor repeatedly makes the mistake in spite of numerous warnings/advice in response, that's when a preventative block or a ban from the process should be considered. Mz7 (talk) 21:15, 2 April 2016 (UTC)
  • Support If the Main Page is run like a newspaper, then why not have corrections as well? Obviously some people are reading the DYKs. If the facts are in error, then we should attempt to inform those readers of the error. I also would support either a three strike or block policy for those responsible. FuriouslySerene (talk) 14:09, 29 March 2016 (UTC)
  • Support Not only is pointing out mistakes important. Having corrections on the main pages seems like it can further Wikipedia's goals. One it emphases that all sources should be understood with critical thinking. Two it can be used to encourage new editors to help fact check. Wikipedia is building a information store to do that we need to engage with people that might be future editors. A DYK "editted" section seems like it could benefit us. PaleAqua (talk) 19:32, 3 April 2016 (UTC)
  • Support ... but we can do better. Fram said the reason to single out the main page is that "it gets heavily scrutinized before anything is posted there and shouldn't contain any serious errors". I disagree, firstly the reason is that the main page is different type of publication, more like a journal than an encyclopaedia. But more importantly it should get heavily scrutinised, but DYK, as both Fram and I have pointed out in the past (and unless things have changed) is often inaccurate. I would suggest we consider a pre-publication of the queues so that the DYKs get more eyes on them. (At the moment the queues are all empty... which is not a good situation.)
All the best: Rich Farmbrough, 12:05, 4 April 2016 (UTC).
  • Support It has become standard for on-line sources to acknowledge changes made. I'd go a step further and note any changes made, but what Fram has proposed is a fine start and maybe enough. Hobit (talk) 08:17, 6 April 2016 (UTC)
  • Create own page It would be best to have a special page, in a link at the bottom of the screen. It shouldn't be part of the actual encyclopedia. ThePlatypusofDoom (talk) 23:26, 7 April 2016 (UTC)
  • Oppose. I too appreciate Fram's motivation here, but this seems unwieldy and inconsistent with our encyclopedic model. The main page has little enough space as is, and is largely already monopolized by the news and media elements; little enough space is already given to navigation and other pragmatic uses in order to accommodate these features without adding one more section that seems to suit anything but an encyclopedia. As others have said above, mistakes occur all over the project every day, but our model is the correct mistakes and focus on revising content, not tracking historical errors for our readers.
Besides, I also agree with those who have pointed out that an ounce of prevention here would be worth a pound of cure; rather than creating a system to call out our mistakes, we should have more robust editorial/consensus processes for those elements of the main page, if people are truly convinced that errors there are of significant concern. Though I think talk of banning people for good-faith mistakes is excessive as well. How about we start with a certain proscribed amount of fact-checking and increasing the number of editors who must validate a given fact in DYK or ITN. I've never contributed more than incidental edits in those spaces, so I'm not sure if there are certain editors known for sloppiness and a gung-ho behaviour, but it might be worth discussing TBANs for them, but only under the most severe of circumstances where there is broad consensus that they exhibit a combination of incompetence and IDHT. Snow let's rap 04:01, 9 April 2016 (UTC)


Note: {{Did you know/Queue/{{Did you know/Queue/Next}}}} should display the next queue. I have added this to my talk page header. All the best: Rich Farmbrough, 12:13, 4 April 2016 (UTC).
  • Oppose - It seems redundant and unnecessary to make an additional note or create a new page for any corrections/errors. Because we can correct the information immediately, I see no reason to do anything further. Meatsgains (talk) 03:57, 9 April 2016 (UTC)
  • Support – It seems unconscionable to me to feed readers incorrect information and fail to take any proportional remedial action. Firstly: of course there is a difference between minor edits of the style commonly requested at Main Page/Errors and outright falsities. It should be assumed that correction notices are unnecessary for grammatical or stylistic subtleties, minor ambiguities and the like. The proposal already states that this would only apply to factual errors. As far as the idea of a "shame list" goes, people should be wary of introducing factual errors, and perhaps it will serve as an incentive to be thorough in editing. I don't consider an impersonal correction notice to be a "shame list" anyway, though; very few people check or care about the individual people behind the DYK hooks anyway. The "encyclopedia, not a newspaper" point is well-taken, but highlighting information on the main page is an editorial judgement and should be subject to similar standards of integrity to other forms of edited publishing. —Nizolan (talk) 01:17, 12 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.

Seeking opinion about edit-protected request

Template_talk:Autoblock#Template-protected_edit_request_on_14_April_2016. Comments here or there are welcome. Feel free to throw questions at me. --QEDK (T ☕ C) 15:12, 14 April 2016 (UTC)

No, comments here should not be welcome - please don't encourage people to go against WP:MULTI. --Redrose64 (talk) 15:58, 14 April 2016 (UTC)
My bad. I was expecting questions here about that actually but well. I will claim innocence with that "or". --QEDK (T ☕ C) 16:36, 14 April 2016 (UTC)

Automatically setting PC protection level for BLP's

Hello folks,

Our BLP policy states that "contentious material about living persons (or, in some cases, recently deceased) that is unsourced or poorly sourced – whether the material is negative, positive, neutral, or just questionable – should be removed immediately and without waiting for discussion." Having said this, it seems that anonymous editors frequently make changes to BLPs without citing properly. Since in most cases these changes are immediately visible to the public and could potentially lead to misinterpretation, I would like to suggest that all BLP article edits be subject to review by default, so any material that violates the violate the BLP rule could be removed without being visible to general users who don't really do editing but just reading.

Please let me know how you think about this proposal. Thank you!

Regards, <<< SOME GADGET GEEK >>> (talk) 02:24, 10 April 2016 (UTC)

Just to throw one practical concern out there, this seems like it would cause a massive backlog of edits awaiting review, something like a week or more. --Bongwarrior (talk) 02:30, 10 April 2016 (UTC)
Support Even though I agree with Bongwarrior, BLPs have become a major issue across Wikipedia and I have had to revert a countless amount of vandalism on BLP articles. — Music1201 talk 05:40, 10 April 2016 (UTC)
  • Strong Oppose I agree with Bongwarrior, the backlog would just be way too much. — Omni Flames (talk contribs) 07:12, 10 April 2016 (UTC)
  • Oppose because not all BLP's need this level of scrutiny. I know of quite a few BLP's that are hardly edited (not even vandalized).--Jasper Deng (talk) 07:18, 10 April 2016 (UTC)
  • There are presently 1,087,991 BLPs on Wikipedia (number dynamically updated). I doubt this would be feasible, though I agree with your concerns. BethNaught (talk) 07:19, 10 April 2016 (UTC)
    • Technically, I think that writing an adminbot to handle this would probably be practical; a one-time run on all non-protected BLPs, and real-time maintenance would probably work. It could certainly remove PC on any BLP when the category is removed by an account with over X months and Y edits when the protection reason includes any of specific words; and report any BLPs with PC when either the removal is done by a newer account or where the protection reason is anything different. It could also monitor any additions to CAT:LP and use a protection reason which uses one of these words. I think, though, that we have a different issue here - the backlog of pending changes. עוד מישהו Od Mishehu 04:49, 14 April 2016 (UTC)
    • To put it in perspective, that's approx. 15% of all articles.—Godsy(TALKCONT) 05:24, 14 April 2016 (UTC)
  • Per Jasper, basically. Not all BLPs need the extra layer of scrutiny. I do like PC in that it lets anyone still edit (I would certainly oppose any attempt to mass-protect articles), but I don't think this idea is practical or particularly needed. Ajraddatz (talk) 08:51, 10 April 2016 (UTC)
  • Oppose partly as per Bongwarrior and Jasper. Also i dislike PC protection in general, it takes away from the immediacy that is the Wiki experience, adn can confuse new editors. DES (talk) 15:10, 10 April 2016 (UTC)
  • Qualified Support I would point out that certain areas now have a more stringent rule than this (the 500 edit rule), and that the "backlog" of BLPs is exceedingly unlikely to reach even 2,000 edits, much less hundreds of thousands. In fact, many articles are not edited as often as once a year in the first place. So the "it would inconvenience us to require vetting of edits by IPs" is weak. Rather, it is the fact that some edits may cause actual harm to living persons which should govern our actions - if we have a tool to prevent harm, we would be remiss in dismissing it. Collect (talk) 14:55, 11 April 2016 (UTC)
  • Weak support I think the fact that vandalism to BLP-articles doesn't go "live" is slightly more positive than the problem of, admittedly, confused new editors. As for the workload....we just would have to see. Lectonar (talk) 15:10, 11 April 2016 (UTC)
  • Oppose - we need to keep PC down to an appropriate workload level; since BLP edits are too frequent, it will make the PC log be too backlogged all the time. עוד מישהו Od Mishehu 09:33, 12 April 2016 (UTC)
  • Oppose due to the surety of a backlog in this proposed process. There aren't enough WikiGnomes out there. GenQuest "Talk to Me" 00:12, 14 April 2016 (UTC)
  • Oppose - I've been known to check Special:PendingChanges and review pending changes from time to time. It isn't uncommon for some changes to remain un-reviewed for 12 hours or so. To apply this en masse to biographies of living people which haven't been shown to be problematic would be in violation of the regulations community consensus set for pending changes protection. Secondly, this would be way too many edits for our volunteer community here to reasonably review in a timely manner (on a side note: only approx. 8,000 users have currently have this right). The only pragmatic way to guard articles in this way would be to disallow un-registered and non-autoconfirmed users the ability to edit biographies of living people, though I wouldn't support that either, and I believe similar proposals have failed to gain consensus in the past.—Godsy(TALKCONT) 05:12, 14 April 2016 (UTC)
  • A more useful approach might be to sit down with a database query and make a list of the "1,000 most reverted BLPs", and consider just those. WhatamIdoing (talk) 18:09, 14 April 2016 (UTC)

Using the edit filter to enforce ArbCom or Community bans Reply

I have never understood why this does not already happen. The edit filter is the closest way to technically prevent editing on a certain topic.
Example: User XYZ was topic banned from editing restaurant related topics. An edit filter could be enabled to prevent user XYZ from editing articles with the "Restaurants" category. — Music1201 talk 05:37, 10 April 2016 (UTC)

But is the breaking of topic bans really a major problem? When it does happen, the user who breaks the ban is usually blocked very quickly by administrators. — Omni Flames (talk contribs) 05:45, 10 April 2016 (UTC)
I'm not sure how many users have topic bans, but we have a tough enough job maintaining the filters we already have. The number of filters/changes required would what, triple? The Category:Restaurants contains 22 direct subcategories, and would not contain all restaurant-related topics. The relevant categories to be checked would include things like Restaurateurs, Gastropubs in the United States, and Soup kitchens. The categories don't include templates, project pages, or talk pages. Additionally, most topic bans have several exceptions. These things add up to quite complex tests, which are also expensive in terms of the edit filter condition limit - a limit which disables the edit filter when there are too many matches. In my experience there is nothing better to pick up topic ban violations than other users editing in the same areas - edit filters are no match. -- zzuuzz (talk) 06:46, 10 April 2016 (UTC)
The problem is that I don't think there's a straightforward algorithm to tell if a user is violating a topic or interaction ban, and our edit filter system already can't handle this many more filters.--Jasper Deng (talk) 06:53, 10 April 2016 (UTC)
To expand on what Jasper Deng said, there is a restriction on how many filters there can be, because they are all applied while saving, and if there were too many of them then the save time would become noticeably longer. It's also very technically difficult to make a filter which would match every case for the topic ban, and so I think manual scrutiny is a better option for most cases. There would be ways to accomplish this through new extensions here, but probably the abusefilter isn't the best way. Ajraddatz (talk) 08:53, 10 April 2016 (UTC)
  • I would oppose this as per zzuuzz's and Jasper Deng's comments above. Edit filters must be applied to ewvery edit saved by every editor, and may not be too complex. many topic bans are quire complex and not really suited for algorithmic detection, even with a rather more powerful system than edit filters can support. I would hate to try to program such a filter. Consider how many topic bans include the words 'broadly construed'. DES (talk) 15:07, 10 April 2016 (UTC)
  • Any eidt filter we create must meet 2 basic criteria: They must have a reasonable number of hits (not too few, since that would make it a waste of resources; not too many, since that would probably show that the filter is catching too many false positives); and it must be quick enough to check for every edit. I doubt that there is much ArbCom enforcement that could be written into filters which meet both of these criteria. עוד מישהו Od Mishehu 09:36, 12 April 2016 (UTC)
  • Mwaagh, I think that this is in principle a good idea that I c/would support, it may only be a technical problem why we don't. But these filters can be reasonably fast: IF (user_name) EQUALS <restricted user> results in a false for almost every edit, and would not cost a lot of resources. Adding a "AND page_name IS ONE OF "list of pages" will add some processing time for the edits that do hit (but then, only for the restricted user .. and such an editor did not get restricted for nothing; it would need some paperwork to get the list done, which could always be expended when necessary), but in general this will not bring down Wikipedia. Then you add further specifications down the line if needed, or you leave it at this and let it just 'tag'. It only becomes a problem if the restriction is not too page and not too user specific ("no-one should edit these 2000 pages long list of pages more than 3 times in any stretch of 7 days"). If the filter is tag only, it becomes a quick checklist, and if it is specific enough it can be restricted as well.
  • I think that the real question is, why does the WMF not either allocate more processing power to the edit filters to both speed them up ánd so the community has the possibility to write more edit filters, or have the development team write 'clones' of the abusefilter for commonly used tasks and which can then run much faster by design: a check enforced by code (only apply this when user = <username>) or only apply this when user-right = unconfirmed-checkbox) is always faster than a check of an interpreted code (interpret "if user = <username>" or "NOT user-right = confirmed", fill in the variables and then get the result) - and there are many filters that start with these checks that we now don't write just because overall it is too slow at the moment, and the suggested filters are among them. --Dirk Beetstra T C 10:57, 12 April 2016 (UTC)
  • I oppose of this, if a sanctioned editor can't follow the terms of their restriction the door is right over there. — xaosflux Talk 12:14, 12 April 2016 (UTC)
    • That is true regardless if you use an edit filter to block the edits / detect possibly conflicting edits or not (in the end, this just gives you an easy to access on-wiki record), so I am not sure what you oppose here. --Dirk Beetstra T C 13:03, 12 April 2016 (UTC)
      • To clarify, managing the edit filter is a careful balancing act of scalability of the tool, and administrative overhead of the filters - managing comprehensive lists of user to page/category mappings is setting us up for a management nightmare - we already have enough headache when short-term filters have to be built for individual vandals. — xaosflux Talk 18:29, 12 April 2016 (UTC)
        • I see that point, but that goes both ways. The current bans are an administrative nightmare as well. Sneaky editors could circumvent bans, and many editors are not aware that a certain editor is banned from certain topics, and edits may go through because of that. It needs quite a number of editors to keep an eye on the edits of a banned editor to see if they are editing in violation of said ban (and you see that happening, some editors turning into a form of WikiPolice, and just a couple of the editors become the judge of the appropriateness of the edits by the banned editor). --Dirk Beetstra T C 08:06, 13 April 2016 (UTC)
  • If the edit filter system were optimized to the point that we could have 1000s of filter with no discernible impact on performance, then sure we could apply per user and per page filters. Right now the limits placed on the filter system (in part due to design issues that could be improved) mean that we need to prioritize its use for filters that are likely to get significant hits and avoid filters that are so specialized that they will rarely be triggered. Dragons flight (talk) 13:21, 12 April 2016 (UTC)
    Even if we had much more powerful hardware and software, Dragons flight, even if we could apply the full power of, say, IBM's "Watson" to each and every edit separately, correctly determining which edits do and which do not fall within a complex topic ban is not a trivial task for an algorithmic system. And a filter that gets it right more often than not but has a significant error rate might be worse than useless - we might trust the filter more than we should, leading to worse outcomes. Until we can run edits though HAL9000 or some other truly intelligent system, I don't think this is a task to approach with a program. DES (talk) 18:24, 12 April 2016 (UTC)
    I'm imagining that an Arbcom directive gets implemented as a filter simply saying that X person is not allowed to edit articles A, B, and C. Human(s) would have to decide on the list of which articles are covered, but the filter itself would be easy to implement. To the extent that the targeted list ends up being incomplete / incorrect, one would have to allow for additional articles be added or removed from the list, again subject to human review. However, we already have edge cases and discussion about interpretation of various Arbcom restrictions. All of this HAL9000 stuff is a red herring in my mind. We don't need an edit filter that can decide which articles involve "Neoclassical Romanticism" (or whatever the prohibition de jour happens to be). We simply need humans that are willing to discuss what the prohibitions ultimately mean and try to spell it out in concrete terms. (Of course if humans aren't willing to do that, then such filters will probably never be created.) Dragons flight (talk) 18:46, 12 April 2016 (UTC)
    But in practice I have yet to see a topic ban defined in terms of an explicit list of articles. It is always of the form "Editor:Example may not edit articles connected with Neoclassical Romanticism, broadly construed". Sanctioning admins are supposed to employ judgement in assessing any given edit as to whether it violates the terms of the ban. In some cases things are broader: "Editor:Example may not make any edits on the subject of Neoclassical Romanticism, broadly construed, in any any article at all". Here it is the subject of the edit, not the subject of the article, that is the criterion, and human judgement at the edit-by-edit level is even more obviously required. This flexibility is by design, to avoid the subject of the ban gaming the system, and to afford the sanctioning party some leeway when what seems to be a technical violation doesn't fit the reasons for the TBAN. If the cost of programmatic enforcement is that an explicit list of affected articles must be compiled in advance, i don't think most people will see it as an improvement. And in the absence of such a list, separating violations from legit edits is a hard problem. I honestly don't think current AI is up to making that distinction with sufficient accuracy to serve this purpose at this time. DES (talk) 22:14, 12 April 2016 (UTC)
    When I use edit filters, I generally do that to detect editors. I have a block-evading editor with reasonably signature edits using one or two ranges, or mainly targetting specific pages, and I write a filter on that. Does that filter catch everything? No, it catches maybe 90% (and people find a way around). Does that make the filter useless? No. If the editor trips the filter once, I know to check the other edits as well. Is my filter finished? No, I regularly have to add pages, signature edits, etc. Do I have to now consider that if my filter is not tripped that I can assume the editor is not there? No, but instead of checking every day the whole range, I check once every week. The filter is saving me work.
    The same would be true here. Some bans are plain clear: 'stay away from subject X'. Hence, there are no edits that are not a violation of TBAN, every single edit is. The instruction is clear, stay away. That is very easy to catch in a blocking filter, an expandable list of pages not to touch. If the ban is not that black and white, then indeed the edits may not be blockable, but then the filter goes to tag-only and people will check the hits to the filter (if it has a visible tag, even other editors may do that work for you, bringing down the workload). And there will be bans that are not suitable for this at all, and nothing will change, you will have to do everything by hand. A sneaky banned editor may be able to do edits under the radar, but with the help of filters, that radar has a much finer maze to detect. --Dirk Beetstra T C 07:56, 13 April 2016 (UTC)
    It should be noted that I think the filter does not use short-circuit evaluation (I think it's a long-requested feature though), which would negate the benefit of checking the username first in an and expression (as would be required by the filter).--Jasper Deng (talk) 21:21, 14 April 2016 (UTC)

Related Pages extension

WP:Related_Pages_extension/RfC isn't quite a "proposal" at the moment, but it could become one and it needs more people to comment. The WMF built an extension to add machine-generated "See Also" style links at the bottom of all articles. They are asking for our view on it, and how we might want it improved. It is currently available in the Beta Features section of preferences, and they may offer it for default-activation on wikis that want it. Alsee (talk) 11:35, 15 April 2016 (UTC)

IEG proposal for learning from article revision histories

I'd like to announce an IEG proposal I am working on titled "Learning from article revision histories". The goal of the project is to help editors see how the editing process unfolds over time by visualizing revision histories as trees of edits. In particular, the project evaluates the effectiveness of the BOLD, revert, discuss cycle by modeling article growth as an evolutionary system. The intended outcome is to provide a way to highlight effective editing both at the level of the individual edit and as an editorial team.

This proposal has benefited greatly from community feedback since its inception, and now integrates more closely with the ongoing work by the WMF in this area. If you have a chance to give me your feedback on the project as an editor, a software engineer, or a researcher, I would be appreciative and the project would surely benefit. -- Evoapps (talk) 15:38, 16 April 2016 (UTC)

Proposal to globally ban WayneRay from Wikimedia

Per Wikimedia's Global bans policy, this is a notice to a community in which WayneRay participated in that there's a proposal to globally ban his account from all of Wikimedia. Members of the community are welcome in participate in the discussion. --

— Cirt (talk) 19:12, 18 April 2016 (UTC)

@Cirt:The best place to make this announcement would probably be at WP:AN, where we discuss local bans. עוד מישהו Od Mishehu 02:55, 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. –xenotalk 00:17, 19 April 2016 (UTC)

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. –Davey2010Talk 22:50, 17 March 2016 (UTC)
  • Oppose. This would reduce article traffic, and interferes with the reading of text when readers unintentionally hover their cursor on a wikilink. Personally, I find this feature annoying. sst✈ 02:03, 18 March 2016 (UTC)
    • How would it reduce article traffic? Hovercards are very simple to understand, and users can still just click on the link to open the article in a new page, there's no difference in behaviour there. If you feel that by serving up the lead to readers in a hovercard, that the reader will not then read the rest of the article, you are saving time and resources needed to serve a new page. - hahnchen 23:43, 18 March 2016 (UTC)
  • Comment – I can see the use for this, but I can also see how it can become really annoying. What we really need is a solution that would make it much easier for readers (that is, non-editors) to notice these add-ons and enable them voluntarily. Something like a prominent "reading preferences" menu at the top of the page, next to "Create account", that all of our users could have to personalize their reading experience. If there is widespread support for a particular add-on from this setup, a discussion of whether to enable by default would be more successful. Mz7 (talk) 05:03, 18 March 2016 (UTC)
    @Mz7: How would you define "widespread support"? (Currently there are 46,071 registered users who enabled this beta. A survey among anonymous users found that over three quarters found this useful, one in eighth disliked it.) —Ruud 09:56, 18 March 2016 (UTC)
    @Ruud: Careful with statistics! Those 46,071 are less than 0.2% of the 47,293,353 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(TALKCONT) 07:27, 24 March 2016 (UTC)
  • Oppose – Not for every user's taste, or CPU. A rather gratuitous add-on feature, not a core necessity, should be off by default. SteveStrummer (talk) 01:47, 25 March 2016 (UTC)
  • Oppose It's not just the number of users on each side but the minor additional value for those who like it, and the major distration for those who do not. DGG ( talk ) 04:27, 25 March 2016 (UTC)
  • Oppose As far as I remember, it was enabled my default, then I went and disabled it. I find hovercards useful. You know what, I'm gonna try it right now and decide. --QEDK (T 📖 C) 06:48, 25 March 2016 (UTC)
    Why does it have to pull a picture and there's no infobox information, just the lede. Random hovers are an issue but they're an issue on every website with hovercards enabled. It's going to work just fine on most articles but on ones with linked ones, it will definitely be annoying. Sometimes, the preview text is absolutely useless and the picture isn't useful in most cases either (it'd be good for animals and plants but those are very limited uses). --QEDK (T 📖 C) 06:57, 25 March 2016 (UTC)
  • In the name of God, enable by default. Frankly, hovercards increase the quality of Wikipedia in that they are useful for obtaining information quickly and easily. As has been stated above, anyone who dislikes hovercards has the option to disable them, and those who do find them useful will be grateful of their existence. While there are a few problems (such as the inclusion non-free images, etc.), I see no great cause of concern over their activation. If anything, we can enable them sometime in the future when all of the bugs have been worked out, but personally, I feel they're just fine as is. Colonel Wilhelm Klink (Complaints|Mistakes) 16:43, 25 March 2016 (UTC)
  • Don't you dare mess with the preferences of existing registered users. As for IPs, oppose, at least until the bugs are ironed out. BethNaught (talk) 22:15, 25 March 2016 (UTC)
  • Comment I think the primary question here is about IP's and NEW accounts. I agree with BethNaught that changing existing editor preferences should not be on the table. For IPs, enabling by default and making it very easy to turn off is being proposed to solve the issue of discoverability for a feature that the majority of readers appear to like (when it was auto-enabled in Greek and Catalan). Without enabling the feature, we don't have a great way of allowing users to try it. There is no user preference area (solvable, but not easily) and, even if there was, there is no good way we have identified to help users discover this feature without showing them. Someone above mentioned running a central notice banner to inform users that it is an option, but this raises other issues--when do you turn the banner off, for instance? Do we turn it on 1 day a month in perpetuity? I am very interested in hearing suggestions, but tend to feel that allowing organice discovery when a user mouses over a link and then providing a very easy way to disable is the way forward. It seems that an easy path to disablement is the biggest issue. Maybe a blocker for rollout would be developing a dialogue on that first hover that shows users how to turn it off? Just an idea. Jkatz (WMF) (talk) 00:18, 26 March 2016 (UTC)
I really liked Stanning's alternative proposal earlier of showing a hovercard once, and with it a dialogue asking whether the reader would like to continue using the feature. If no response, we would assume no and disable it. I also think the idea of a reader preference area deserves some looking into—if not for Hovercards, then for future add-on features. Ultimately that's what enabling and disabling these kind of features boils down to: preference. Wikipedia has enabled by default a host of these add-ons now—VisualEditor, Media Viewer, Reference Tooltips—and while it is possible to disable each even without a registered account, it would be easier if there were a centralized location for readers (i.e. unregistered users) to switch these on and off. It could also be a place to put beta features like Hovercards, in order to expose them to our readership (the ones who really matter). Mz7 (talk) 18:31, 29 March 2016 (UTC)
  • Oppose. Screen clutter which should be opt-in only.--Smerus (talk) 09:03, 26 March 2016 (UTC)
  • Support WP:ILikeIt. As an editor I find it useful for quickly telling if the link is correct. It also makes Wikipedia look more professional. AIRcorn (talk) 02:01, 27 March 2016 (UTC)
  • Support, I've been using Hovercards for some time and I love it. Really improves my reader experience. --SSneg (talk) 09:44, 27 March 2016 (UTC)
  • Strong Support For once, let's think of the readers. I've been using it for a while and it's one thing I really miss when I'm reading on my phone or other computers. It solves a major problem: clicking on links in running prose. When I'm reading an article on a subject I don't know a lot about, I can hover over a blue link, read a brief blurb to try and get the gist of the term, and keep going without having to open a new tab or leave the page. It makes reading and understanding text easier. Enabling by default will introduce a number of people who don't even know this exists to the feature and if they don't like it they can easily opt out. For IPs, it not only makes it easier for them to read and understand articles, but it also enhances our user experience and spurs innovation.
    • I'm not convinced by these opposes of "screen clutter" or that it will encourage users to register. It's only screen clutter if you hover. If you don't hover on links, it doesn't clutter your screen. I'd be willing to say most registered users don't even know about this feature, so the idea that an unregistered user would find out about it and be so amazed by the feature that they make an account is not something I find hard to believe. For its bugs it is actually really stable in practice and having it enabled by default will probably get those bugs fixed even faster. I strongly believe that this feature will drastically improve the experience of anonymous readers, even if some editors find it suspect. We are an encyclopedia first, and this is a well designed feature that easily, minimally, and creatively solves a big problem readers have. If that harms your editing workflow, then opt-out, but I don't see why we should be blocking a useful feature because editors don't want to talk the 30 seconds to opt-out of it. Wugapodes (talk) 14:11, 27 March 2016 (UTC)
  • Strong support per what Wugapodes said Common: how many experienced editors don't have navigational popups turned on? over 44,000, its our most commonly used opt-in gadget. Our readers would greatly benefit from that simple little bit of help finding the content. I can't believe we are making "clutter" arguments. The readers that are using desktop (an increasingly shrinking portion), are used to this kind of design in almost every other website -- lets not take our own IDONTLIKEIT arguments, to assume they apply for our readers. Sadads (talk) 13:57, 28 March 2016 (UTC)
  • Support, per Ruud and Wugapodes. I personally like Hovercards, even though I quickly turned it off in favor of nav popups, so I decided to read the oppose votes first. I didn't find any of them convincing. There's a clear way to opt out, so whatever annoyance might be experienced by people encountering it for the first time would be minimized. APerson (talk!) 13:14, 30 March 2016 (UTC)
  • Oppose. In my opinion, this feature is interesting and I'm glad it exists but quickly Hovercards become annoying and stressful as you find yourself hoping your mouse doesn't land on any links. I also think it undermines people participating in the encyclopedia. People are less likely to edit and improve pages they never visited. This feature is flashy and sounds like a great idea, but in practice it would make Wikipedia like a man wearing too much jewelry. Overkill so let's keep it simple. Jason Quinn (talk) 15:27, 30 March 2016 (UTC)
  • Oppose. I like the hovercards but making them default will create a cultural expectation that everyone is using them, which is a major faux pas with blind readers, mobile phone users, and people who just choose to disable javascript. Also, based on what Jason Quinn said above, I wonder if hovercards might account for the reduced page visits the WMF has observed? Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 15:46, 30 March 2016 (UTC)
  • Oppose making them opt-out. Pop-ups are, indeed, fantastic, and i expect these Hoverthings are too; but they will be annoying (Pop-ups sometimes annoy me, and i've used them for years) and a distraction from the actual content on the page; there is bound to be an effect on performance, especially on those users who have poorer connexions and slower machines, and particularly if they are used without the described freezing resolved. In all honesty, and i don't believe this is an IDONTLIKEIT argument, i oppose making almost anything opt-out on the principle that simpler is better, and we should be making it as easy as possible for our users to access our content; cheers, LindsayHello 11:17, 2 April 2016 (UTC)
    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, LindsayHello 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.

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)

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)

Proposal for changing Rights for whom can protect

There is no consensus to allow non-administrators to protect pages. Closed as per WP:SNOW. (non-admin closure) ~ RobTalk 02:20, 22 April 2016 (UTC)

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

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 861 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.

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)

Restricting access to user contributions

In order to maintain constant attribution on our content license and core values, each edit must be attributable to an editor - this proposal would goes against this core principal. Closed as per WP:SNOW. — xaosflux Talk 21:29, 23 April 2016 (UTC)

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

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)

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)

Watchlist: pages that have changed

To indicate a change since last visit in items on a watchist, the tiny green dots are not as immediately distinguishable from the tiny blue dots as would be yellow or amber dots. Would it not be better to use yellow or amber dots? Or else to use bolding, as in the Wikipedias in (all?) other languages? Theodoxa (talk) 20:36, 26 April 2016 (UTC)

@Theodoxa: Bold is already available as an option, in Preferences->Gadgets. The image for updates can also be customized; Wikipedia:Customizing watchlists has instructions on how to change to a green star, but I'd think an amber dot could also be created. —C.Fred (talk) 20:47, 26 April 2016 (UTC)
Thank you. I have opted for the bolding. The other customizing you mention might require too much effort from someone unaccustomed to making such changes. Theodoxa (talk) 20:57, 26 April 2016 (UTC)
This isn't really a VPR matter but WP:VPT; in fact, it has come up there before - see Wikipedia:Village pump (technical)/Archive 113#Green bullets in watchlists. --Redrose64 (talk) 23:01, 26 April 2016 (UTC)

So, it's done....

Before butchering the VP/Banter page, read on.

  • Before you cite the Esperanza case, can we trial the thing at least considering 5 or so of us at VPR were actually interested.
  • Before you cite NOTASOCIALNETWORK, having light-hearted chit-chat is often conducive to collaboration (I mean a certain number believe so). How about a trial?

--QEDK (T ☕ C) 15:25, 27 April 2016 (UTC)

Because why not. --QEDK (T ☕ C) 03:52, 28 April 2016 (UTC)

Wikipedia:Water cooler

We all work hard at this workplace. Shouldn't Wikipedia:Water cooler exist? Anna Frodesiak (talk) 11:05, 27 April 2016 (UTC)

Yes, but only as a redirect to WP:Village pump, not a separate page set. Each project has its own name for what is basically the same thing - try for instance m:Meta:Village pump. One of them - I forget which - does have a page named Project:Water cooler. --Redrose64 (talk) 11:52, 27 April 2016 (UTC)
Page set? I'm talking about a single page. Anna Frodesiak (talk) 11:57, 27 April 2016 (UTC)
And village pump is so serious. It's all business. I'm talking about a place where you could share a joke or two, ask how things are going in your area. Maybe it could lead to good things. Anna Frodesiak (talk) 12:02, 27 April 2016 (UTC)
Unfortunately for this proposal, Wikipedia is not a social networking service. This type of effort has been attempted in the past, with less than ideal results. See Wikipedia:Esperanza for further details. --Allen3 talk 12:30, 27 April 2016 (UTC)
Jeepers! I think you're right. This looks awful. Okay. It was just a thought. We have IRC channels that fill this need. Somebody please hat helmet this idea. :) Anna Frodesiak (talk) 12:35, 27 April 2016 (UTC)
I remember now, it's Wikinews. --Redrose64 (talk) 22:11, 27 April 2016 (UTC)
It's also a chat room on one of the StackExchange sites, I believe. --QEDK (T ☕ C) 03:59, 28 April 2016 (UTC)

Template:Philippine name

I would like to propose two more variants of Philippine name: the first one is for natural children where the Filipino has no middle name, but has the maternal family name as the surname; and the second one is for married women where the marital name will be added at the end of hatnote. 203.215.120.138 (talk) 12:16, 28 April 2016 (UTC)

Existing discussion is already at Template talk:Philippine name, please comment on that page. — xaosflux Talk 17:38, 28 April 2016 (UTC)

Incest in Cherry (comics)

Some time ago asked that the category "Incest in fiction" in the article "Cherry (comics)" as reference numbers put where the protagonist had sex with his mother. My request has been ignored.— Preceding unsigned comment added by 201.255.93.146 (talk • contribs)

Are you referring to the overly vague post from a week ago at Talk:Cherry_(comics)#Inces, that does not mention categories nor explicitly recommend adding them? Ian.thomson (talk) 08:18, 24 April 2016 (UTC)

Yes. — Preceding unsigned comment added by 201.255.122.150 (talk) 22:06, 26 April 2016 (UTC)

In that case, you did not at all ask for any categories to be added anywhere, much less the specific category you mention here. Instead, you left a cryptic message that no one could have acted upon until you posted here, actually stating what you meant. Anyway, I don't think it would be useful or warranted to add that category where the article does not mention anything about the stroyline from one issue of a comic with numerous issues.--Fuhghettaboutit (talk) 22:50, 28 April 2016 (UTC)

Banter

I don't know how many people feel like me but I've always wanted Wikipedia to be a fun kind of place. We get work done, but let it not feel like drudge. So, I propose we make a page for banter where we can get together and do some shiz. I don't know how will other people will feel about this but hey, atleast I've spoken my mind. --QEDK (T 📖 C) 16:53, 27 March 2016 (UTC)

Maybe Wikipedia:Village pump (banter) ? All the best: Rich Farmbrough, 22:06, 27 March 2016 (UTC).
We had that many years ago. It was called Wikipedia:Esperanza. It was killed with pitchforks and torches for upsetting the local villagers. --Jayron32 02:09, 28 March 2016 (UTC)
It seems to have dissolved into some useless bureaucracy that caused it to be brought down. I went through it and why not just make a coffee lounge kind of place? (If enough people support this proposal, I'll frame some rules and make one) --QEDK (T 📖 C) 14:26, 28 March 2016 (UTC)
I think it could be fun to have a relaxed kind of place on here where it wouldn't be all about AfD fights, vandalism and other unpleasant aspects of the encyclopedia. I would support it. White Arabian Filly Neigh 21:53, 29 March 2016 (UTC)
I've seen other online entities that had a "work" part and a "banter" part. The banter parts were so lightly used that a little banter remained in the "work" part, because if it were put in the banter part hardly anyone would see it. Jc3s5h (talk) 12:51, 30 March 2016 (UTC)
I think this would be a good thing to have. We need a place to see our fellow editors as human beings and make links. In fact, it would help me no end in my NPP and newbie welcoming tasks if I knew some editors working in various areas. However, get ready for the shouts of wp:nothere :) Happy Squirrel (talk) 01:16, 31 March 2016 (UTC)
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)
What does a suggestion like QEDK's have to do with a social network ? Can we please add a WP:NOTAFUCKINGSTERILEOPERATINGROOMEITHER ???? —TheDJ (talk • contribs) 17:38, 28 April 2016 (UTC)
Indeed, any serious endeavour requires a serious approach. To do anything else is to invite mockery, and furthermore, to distract editors from the mission of this project. As soon as editors start turning this project into a social game where one's goal is to acquire social relations or social status, that will result in a nothing more than a social club, and a social club is not compatible with the serious task set before us. RGloucester — ☎ 17:43, 28 April 2016 (UTC)
It's scary how some people think every social thing is a game not to be taken serious and dismissed up front with a wiki shortcut. It's like erecting a 6 meter high wall every single time someone mentions "mexico" or "palenstine". It's too easy, oversimplified and misguided response. To pretend we have no social aspects is to bury your head in the sand. We have social aspects and the 4th pillar even affirms this (even though we seem to ignore it most of the time). Userboxes, decorated user pages, FA and GA badges, barnstars and decorated signatures also all have social aspects, that we are have accepted. To talk to someone on his talk page instead of on a forum is a social choice. To pretend that we are not social is thus a fallacy, and replying to every single thing, that potentially has a social aspect to it, with a NOTSOCIAL link is even more so a fallacy. The world is not that simple. We are not Facebook indeed, we are not Twitter, we are Wikipedia, a collaboratively written encyclopedia by people who thus form a social network. Just not the Internet age one. —TheDJ (talk • contribs) 18:10, 28 April 2016 (UTC)
A social club is exactly what has built the encyclopedia. All of those discussions through which policies are made, admins are elected, naughty contributors are banned, edit wars are resolved, newbies are helped, and collaboration on articles occurs, are all elements of the social aspect of Wikipedia and are key to the functioning of this project. Many editors will also tell you that the only reason they stayed involved was because of the opportunity for interaction with their peers, through talk pages and IRC. Humans are social creatures, and we need to have that potential for interaction for this site to continue. However, because of this prevailing desire to not be a social network (and by this I think people mean not be Facebook), this side of the project has been seriously neglected and has not evolved since 2001. That's a problem. General comment, no preference for or against the proposal as I wouldn't use it. Ajraddatz (talk) 18:28, 28 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)

Well, it did last a few hours without getting MfD-ed. Maybe for once, the community should be less stuck up and try to give a go at new things. If the name is a problem it can be changed but I see no reason to oppose the concept (yet). --QEDK (T ☕ C) 05:31, 28 April 2016 (UTC)
Since I am part of this community, and it was just referred to as stuck up, I take umbrage. Perhaps this is an indication of why editors should maintain a professional distance on community talk pages. fredgandt 17:25, 28 April 2016 (UTC)
That comment made me wince, too. I'm not sure what I think of the Banter page, yet (obviously should've been an RfC first, but beyond that I don't know). It's really disappointing, however, that discussions about new ways to foster community so often lead to supporters of the idea attacking the community for not supporting their particular method of fostering community. — Rhododendrites talk \\ 19:38, 29 April 2016 (UTC)

Destubbing articles

I was thinking that it might be healthy for wikipedia if we proposed some destubbing contests for a number of countries, including those of the UK to improve general standards and make them more consistent. Get people destubbing articles and try to make it fun. I'm testing out an idea by area of Wales at Wikipedia:WikiProject Wales/Awaken the Dragon/Stub Obliteration/The Preserved County Challenge this week. So if anybody would like to get involved with helping destub a few articles and see how things go this would be warmly appreciated. You don't have to be a contestant in the overall contest, but anybody who can independently help destub a few articles is very welcome. Potentially something like this could eventually eliminate a good number of our stubs for all countries and topics.♦ Dr. Blofeld 12:33, 25 April 2016 (UTC)

Such a competition has been organized a few times before: Wikipedia:Stub Contest. – Finnusertop (talk ⋅ contribs) 16:40, 25 April 2016 (UTC)
We've had success at WP:VG with simple cleanup drives, at least one of which I think was triaging and acting on our stubs (either deciding they're perma-stubs and merging as appropriate or actively getting some up to a higher quality level). --Izno (talk) 17:34, 25 April 2016 (UTC)
We should probably do something like this every so often - the stubs are currently around 38.5% of all articles around here (2,334,600 articles out of 6,815,651). עוד מישהו Od Mishehu 16:12, 26 April 2016 (UTC)
A scan (it took a while, you can check my results at this link) says that there are 318,714 tagged stubs which are in Category:Living people; this would be about 41.6% of the 765,091 articles in that category. I strongly suspect, although I didn't actually check it out, that many of these are simply AA7 cases that got missed by our New Page Patrollers. עוד מישהו Od Mishehu 20:30, 26 April 2016 (UTC)
I know there's a good deal of stubs on athletes. WP:NSPORTS is fairly inclusive, so theoretically any athlete that has played a single professional game usually qualifies. There are 7,000 stubs for WP:NFL, 14,000 for WP:TENNIS, 8,000 at WP:BASKETBALL, etc. When all's said and done, wouldn't be surprised to find 100,000 perma-stubs from athletes. They likely do meet GNG, but sources are hard to come by to expand them because sports news decays very quickly. It's hard to find articles on an athlete that played a single season and was a middling player from the 1950s. ~ RobTalk 12:24, 27 April 2016 (UTC)
It's hard to fine online sources for that. The solution may be to find people to volunteer to check out a book or something from a library or something and flesh out a hundred or so stubs based on a source. I find it's easier to work off a topic than it is for a single article sometimes. Perhaps those projects should make a contest against each other on a percentage basis or something. -- Ricky81682 (talk) 02:18, 30 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: [1] [2] [3] [4]

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? ~ RobTalk 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. ~ RobTalk 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. ~ RobTalk 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)
Would it be useful to have a category that tracked articles with conflicting (standard) assessments? Especially if this could be sorted by WikiProject it would allow for members to quickly check articles and if necessary update their projects assessment if it is the out-dated one. Jamesmcmahon0 (talk) 10:02, 15 June 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. ~ RobTalk 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. ~ RobTalk 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. ~ RobTalk 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. –xenotalk 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. ~ RobTalk 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. –xenotalk 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. ~ RobTalk 21:08, 22 April 2016 (UTC)
  • What's the point of having a separate "class=" parameter if all the WikiProjects are supposed to share the same class assessment? On the French Wikipedia {{WikiProjectBannerShell}} is used to generate a unified "quality" for the article as a whole. However, many WikiProjects do not share the same class structure. A problem is that "page type" is mixed into "quality class". First, PageType should be separated from quality class. A list is a page type, it doesn't indicate the quality of the page. Article/List/Redirect/Template/Project/Portal/etc should be set in a "pagetype" parameter instead of the class. This can be shared between wikiprojects with no conflicts in assessments, the only conflicts would be some wikiprojects recognize various pagetypes and others just use NA. Quality classes are also not shared across wikiprojects, with some having A-class and some not, etc. If we can have a unified page quality, then individual wikiproject quality assessments should be solely about the quality of the infornation in the project's purview. Also, having WPBS accept quality settings (and merging {{Vital article}} into WPBS) will allow setting quality assessments for articles without memberships in Wikiprojects (they are unbannered, and perhaps no wikiproject covers the topic area). -- 70.51.46.195 (talk) 05:04, 24 April 2016 (UTC)
    I don't necessarily disagree with a new system of assessment, but I'm working within the bounds of the current system. I doubt there's going to be significant support for changing the system since it's worked well enough so far, but you're welcome to try proposing it in an appropriate venue. As a side note, I'm going to remove "A" from the classes that this bot will auto-assess, because some projects don't use the A class. ~ RobTalk 05:16, 24 April 2016 (UTC)
    Many projects do have their own assessment system. The military history project for one is heavily complicated for their own purposes. I'd say first making a message on each project's talk page and see who bites. Collect all the supporting projects and then you can automate those together. For example if the NFL project supports it and the biographies one as well, you can also make sure that the biographies on NFL pages includes the sports parameter rather than doing it in rounds. Else, propose a bot that does this as a running project. A number of projects don't even use the extended class system which in particular doesn't expose them to draftspace pages (draftspace is a bigger area now than ever) which are basically the new pre-stub pages. -- Ricky81682 (talk) 02:31, 30 April 2016 (UTC)
    When you say "many projects", can you give examples other than MILHIST (which is different in several ways, not just assessment criteria) and Help Project (which doesn't classify pages in mainspace but those in Help: space). Other than those two, I don't know of any that have a |class= parameter but which don't respect the basics of Wikipedia:Version 1.0 Editorial Team/Assessment#Quality scale for pages in mainspace, perhaps with a small number of omissions (A-class being commonly omitted) or additions (Disambig, Redirect). For pages outside mainspace, it's a different matter, but other than Help project, those aren't subjective judgments - a non-redirected template might be template-class on one project and NA-class on another, but there is no way that it can be anything other than those two. --Redrose64 (talk) 08:32, 30 April 2016 (UTC)

Religious messages

CLOSED
No consensus shown to change the status quo through this overly-broad proposal. It is noted that users are given a freer hand on their pages than those in the article space. Self Identification of any kind is not limited by Wikipedia policy. Limits are already in place to control over-enthusiastic proselytizing. Non-Administrative closure – GenQuest "Talk to Me" 11:52, 30 April 2016 (UTC)

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

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)

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(TALKCONT) 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(TALKCONT) 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)

I think this is a slightly different situation, as it relates to user pages and signatures, rather than article content. Cordless Larry (talk) 18:29, 24 April 2016 (UTC)
WP:NOTCENSORED. That said, I've seen users whose only edits were to make pretty userpages about themselves and their personal beliefs and preferences (religious and otherwise) and those need to go per WP:NOTWEBHOST. PCHS-NJROTC (Messages) Jesus Christ loves you! 03:53, 25 April 2016 (UTC)
I think at the end of the day, it all comes down to whether the user is a net positive. If the user encourages other editors to read the Bible on the userpage (even all over their userpage in an obnoxious way) but creates dozens of Good Articles, are we going to demand they take it down and drive them off the site? No. The negative of religious expression on the user page is clearly outweighed by the good the editor is doing. This is not to say content creators (or other productive editors) can't be the subject of scrutiny, but we have to pick and choose our battles. Obnoxious religious expression is obnoxious, but it's a very small negative for the encyclopedia as a whole. It's not worth driving away good editors. ~ RobTalk 04:05, 25 April 2016 (UTC)
  • What why is everyone slapping this puddle of chunky sals-- Oh, that's not salsa. I'm seeing a pretty clear consensus that this is already covered by WP:NOTSOAPBOX and other pages, but that those pages do not apply to a user simply stating that they hold (or reject) certain beliefs (whether they be religious, political, philosophical, aesthetic, or whatever), particularly if those beliefs are not leading to any sort of disruption. The only real discussion I'm seeing here is nitpicking, and I'm aware that someone could find something to nitpick over how I expressed the consensus, but that was the general direction I see that it's already gone. Time to close and move on? Ian.thomson (talk) 04:19, 25 April 2016 (UTC)
  • Baseless. Identifying yourself as something doesn't mean you're spreading it and/or have a COI with the subject. --QEDK (T ☕ C) 05:33, 28 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.

The disambiguation gap has been bridged!

The Wikipedia:Disambiguation pages with links/May 2016 competition is underway, but this month is special. Normally, we have two sets of lists from which points can be scored for the competition - the main list containing the top 1,000 most linked disambiguation pages, and the bonus list containing disambiguation pages with four or fewer incoming links. Historically, there has been a gap between these, with the main list having pages with at list six or seven or eight incoming links. However, thanks to the heroic efforts of our disambiguators, we have for the first time ever managed to bridge the gap. That means that as of the start of May 2016, every single disambiguation link in Wikipedia counts for the contest. Go forth and disambiguate! bd2412 T 02:40, 1 May 2016 (UTC)

Revive WP:ABUSE, but completely revamp how it does business.

In recent years, the old Wikipedia:Abuse response project has gone inactive, and there doesn't seem to be anything going for notifying ISPs, schools, employers, etc anymore. This is despite the existence, and continued use of, templates like {{WHOIS}} and {{Shared IP}} which mention the possibility of abuse reports being sent (and with some templates still even linking to the inactive abuse response project). My proposal is that we either revive WP:ABUSE or create an entirely new project to create template messages which admins and vandal fighters can use to send to ISPs, contact information can be documented for ISPs, schools, etc (we already have this, which I would incorporate into the project), and users could document success stories. This is 'not a proposal to bring back the concept of people submitting cases to the abuse response project, but rather a proposal that we either revive the old project, or create an entirely new one, for the purpose of making it easier for administrators and vandal fighters to contact ISPs and organizations themselves. Thoughts? PCHS-NJROTC (Messages) Jesus Christ loves you! 01:08, 25 April 2016 (UTC)

Screaming into the void before didn't produce satisfactory results, why do you think that will change? More to the point: The project died mostly because ISPs and other organizations basically ignored any and all requests for remediation, so why do you think that will be better if we revive the project? --Jayron32 01:20, 25 April 2016 (UTC)
Before we try to restart getting ISPs and schools to take action about their vandals, I think that we need to try to answer a question that is difficult to know the answer to. Why are ISPs and schools so unwilling to deal with vandals (and other Internet scum) who use their address blocks in ways that are detrimental to Wikipedia? In the case of ISPs, I can see several reasons. First, nothing in an ISP's Terms of Service with its customer prohibits the customer from violating Terms of Service with an unaffiliated web site, such as Wikipedia. Second, there isn't a financial incentive for the ISP to throw off bill-paying users. Maybe a Wikipedia editor who works for an ISP can provide insight. As to schools, I don't have as good an answer. However, I don't think that we will be able to motivate ISPs to work with us until we identify business reasons for them to work with us. Robert McClenon (talk) 01:42, 25 April 2016 (UTC)
Correct me if I'm wrong, but don't most ISPs and the like require abuse reports to come from an official (i.e. @<company>.<tld>) email address? —Jeremy v^_^v Bori! 02:40, 25 April 2016 (UTC)
People think ISPs don't respond to abuse reports. That simply isn't true; I've submitted hundreds of them, some related to WP, others not. If you search the internet, you can find people chattering in forums and other websites about being contacted about abuse issues (mostly virus activity and copyright infringement; probably a good 95% of the abuse reports they receive relate to that, and they get tons of them). As for the AUP issue, a lit of AUPs prohibit activity that hinders other subscribers' use of the service. Especially when we start talking rangeblocks, that certainly applies here. The reality is, WP:ABUSE was a failure for dealing with ISPs because its way of doing things was incompatible with the ISPs' way of doing things. WP:ABUSE required 5 blocks on an IP before they would act. On my experience monitoring my home router's firewall log, virus infected Time Warner Cable IP addresses will stop trying my port 445 after I've sent exactly three reports to [email protected], and I never receive a personal response unless I submit it wrong (or if the person at RR Abuse Control is retarded and thinks I submitted it wrong). ISPs will almost surely send a warning to the subscriber as the first action they take, if they take action. My guess is someone who has repeatedly ignored our warnings and been blocked 5 times will similarily wipe their ass on a warning from their ISP, unless it's a kid and the warning goes to the parents. With WP:ABUSE, contactors would often send one report and close the case as "actioned" afterward, and it didn't help that IPs with such a history of abuse were bound to get tagged with an extended block as WP:ABUSE is trying to work the case. In contrast, I've sent many abuse reports relating to Wikipedia and Conservapedia, both within and outside of WP:ABUSE and had good results. Jack Stevens with Embarq was good about calling subscribers on the phone about vandalism issues. I've had Comcast say over the phone they would take action. AT&T took action against User:Mmbabies after I contacted the Better Business Bureau (and he went away for roughly a year). I received a personal response via email from Cox Communications thanking me and asking me to contact them again if the problems were to persist. I saw persistant pom-pom type vandalism (clearly the same person) from a Department of Homeland Security IP registered through Sprint cease when I contacted Sprint. Karajou at Conservapedia shared an email with me where he received a personal response from Bell Canada. JANET in the UK always responds well to abuse reports. I've had good experiences dealing with schools and universites as well. Dealing with schools is a bit of a different animal. If you just contact what is listed at ARIN, you are wasting your time as that is probably out of date. I normally go to the school website, and if I don't call them on the phone (which is actually what is best), I send an email to either the technology department or a school administrator (like a principal). If anyone is interested, I could email you copies of some of the interactions I've had over the years. PCHS-NJROTC (Messages) Jesus Christ loves you! 02:54, 25 April 2016 (UTC)
Something else I forgot to add is that a couple of times I saw threads at RationalWiki's Saloon Bar about prople getting their internet service suspended for vandalizing Conservapedia. The one that sticks out in my mind I highly suspect was using AT&T Mobility, based on the timing of the reports. It took two reports to achieve that. PCHS-NJROTC (Messages) Jesus Christ loves you! 02:57, 25 April 2016 (UTC)
@Jeske, throughtout my experience, I can remember one high school which said they wouldn't do anything unless the WMF contacted them. That's okay, in that instance it was literally a cheerleader posting about how she was the captain of the cheer squad, so I enailed her coach about her making the team look bad. I know, a little harsh, when I was 18 I was merciless about it though and her coach said she would talk to her about it. I don't think I would go to that extreme if the same thing hapoened today though. PCHS-NJROTC (Messages) Jesus Christ loves you! 03:12, 25 April 2016 (UTC)
For those of you doubting the effectiveness of abuse reports. PCHS-NJROTC (Messages) Jesus Christ loves you! 01:23, 28 April 2016 (UTC)
Given the increased problems with harassment on and off-wiki nowadays, I see this as ripe for massive abuse. The only party that I think would have legitimate support (if it did do something) would be ARBCOM since only they would have the actual long-term evidence (and can examine on and off-wiki) and the long-term perspective on the worst of the worst characters. Otherwise, I can't imagine how this will work unless people are prepared for the absolute and real risk of being blocked themselves for OUTING and harassment violations if they get the wrong person. -- Ricky81682 (talk) 02:22, 30 April 2016 (UTC)
Huh? How does abuse reporting have anything to do with WP:OUTING? One contacts the abuse department for an IP address and forwards the logs, it's not like we're naming suspects (and I long since quit contacting cheer coaches, etc about issues, just IT departments and abuse departments). PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 06:03, 30 April 2016 (UTC)

I actually think this would be a good idea, as I got a question about it, and wasn't really sure what it even was...If we say no to WP:ABUSE here, then I think it makes sense to remove the abuse section from the templates that include it. TJH2018talk 21:20, 1 May 2016 (UTC)

I don't see any reason not to do this. No one is making anyone file abuse reports under my proposal, and for those against sending them, any "who denny" desiring to send one can do it without even being a member here because we have the logs out in the open. In fact, I've heard of organizations doing it when vandals post something disparaging about their organzation. I'm just looking to make it a little easier for those who do want to submit them. Besides, it sending abuse reports might at some point save us the headache of dealing with WP:Long term abuse by stopping someone in their tracks early. PCHS-NJROTC (Messages)Growing tired of the bullshit day by day. 05:26, 2 May 2016 (UTC)

Save page -> Publish

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.

Tracked in Phabricator
Task T131132

Apparently the default text on the button label is about to change from "Save page" to "Publish". I don't think this has been discussed locally yet, so what do people think? Some of the reasons for changing this are articulated on the phabricator link. — Martin (MSGJ · talk) 21:16, 2 May 2016 (UTC)

Already under discussion at Wikipedia:Village pump (technical)#Change of "Save page" button to "Publish". --Redrose64 (talk) 23:17, 2 May 2016 (UTC)
Seems reasonable to me for the reasons laid out there - people don't always realise that 'Save' means 'Show to the world right now'. Sam Walton (talk) 23:21, 2 May 2016 (UTC)
Per WP:MULTI please can we avoid split discussions? --Redrose64 (talk) 23:43, 2 May 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.

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)
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 [5]. 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 [6]. 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!)[1].
So in a way Elastic and SOLR are children of Lucene, which powered wiki search up to about 2014.[2]
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. [3]
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.[4] [5] 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

  1. ^ https://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/doc/retrieve-rank/configure.shtml
  2. ^ https://blog.wikimedia.org/2014/01/06/wikimedia-moving-to-elasticsearch/
  3. ^ Like this: http://opensourceconnections.com/blog/2015/10/16/bm25-the-next-generation-of-lucene-relevation/
  4. ^ https://blog.wikimedia.org/2016/03/17/completion-suggester-find-what-you-need/
  5. ^ https://lists.wikimedia.org/pipermail/discovery/2016-March/000901.html
@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: [7]. 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)
We have an open source Q and A machine here [8] Doc James (talk · contribs · email) 09:24, 24 April 2016 (UTC)
In Q and A machines generally, both the Siri and Jarvis approaches to AI have had a mixed review. The link you provide for a similar Q and A machine takes over 30 seconds to respond to its own sample question ("Who wrote Ender's Game?") on a high speed internet line. That would be well over the under 1 second response time Wikipedia normally expects from its standard search box performance. Should the next generation to the standard Wikipedia search box move towards the Brin model of the Google search engine which is the industry leader and which is under one second in response time? Fountains-of-Paris (talk) 15:34, 25 April 2016 (UTC)

@Fountains-of-Paris: Thanks for the question. To be honest, I'm unclear what you're really asking me here. You're using a lot of buzzwords and jargon in somewhat meaningless ways. Your response to me also has almost nothing to do with what I wrote, so I think we might be talking past each other. Anyway, I will try to answer your question. It's a red herring to ask if we can "download the entirety of Wikipedia" when, obviously, we already have access to the servers upon which the content Wikipedia is stored, and search indices built from that content. But, yes, there are dumps of the content that exist and can be downloaded; you can read more about that at Wikipedia:Database download. That has very little to do with search, however. --Dan Garry, Wikimedia Foundation (talk) 18:15, 27 April 2016 (UTC)

@Deskana (WMF): Yes that reply by Brin on the Charlie Rose interview show I think was him trying to "dumb-down" the language for general discernment in a broad audience. The way Brin describes the Google search engine more accurately is when he speaks of it being based upon and operating on the approach of providing a list of backlinks ranked by importance. His further comparison is that other search engines (like Lucene with or without Elastic) are inferior because they do not contain crawling and parsing, and other reasons. The question for the next generation Wikipedia search box is whether it should continue on a development plan using approaches (Lucene, Elastic) which are inferior to the Google-model search engine, or, if it is better to take the Google-model search engine approach, the industry's best search engine, as the model for future development of an improved and enhanced Wikipedia search box in the next generation. By the standards of Google, Wikipedia's 5 million articles are a tiny sample of the backlists ranked by importance which they use for the world wide web. The question is: Should Wikipedia begin to change over to developing a new Google-like search engine, which would be modelled on the best one out there, custom written and adapted for the 5 million plus articles at Wikipedia for the benefit of the next generation of Wikipedia readers and users? Fountains-of-Paris (talk) 16:10, 28 April 2016 (UTC)
@Fountains-of-Paris: I'm reading that, based on an interview where Google's co-founder said that he thinks Google's approach is superior to Elasticsearch, you think my team should should switch all of our infrastructure away from Elasticsearch, and instead build something totally from scratch. If so, no, that's not going to happen, for the reasons I explained above. I'm sorry, but this will be my last reply here; I don't have the time to devote to a back-and-forth on this. --Dan Garry, Wikimedia Foundation (talk) 16:35, 28 April 2016 (UTC)

Statistics for page counts and breakdown of the source of the page counts

Page count statistics are stored and available for all Wikipedia articles for the cumulative number of page hits per day on one of the tabs readily accessible on the edit history page. Does anyone know if these page count statistics are broken down anywhere as to the source of where the page request is coming from? What part of the the cumulative page count at Wikipedia comes from searching and linking from the Yahoo engine, as opposed to the Google engine, as opposed to the Wikipedia search box engine, how many are from desktop, how many are from mobile, etc? Which percentage of page counts for individual Wikipedia articles come from which sources whether from inside Wikipedia or from outside Wikipedia? Fountains-of-Paris (talk) 15:34, 4 May 2016 (UTC)

Election-year prophylactic on coatracking, shoehorning, and the like.

The current discussion at Wikipedia:Articles for deletion/Clinton donors in the Panama Papers is a reminder that even if the BLP articles on the candidates will be closely monitored, an enterprising campaign partisan can still easily attack their candidate of choice through the creation of a new article. What's next, List of shady people seen hanging around Donald Trump properties? List of Bernie Sanders donors who distribute foods containing dihydrogen monoxide? I believe that we need some measure in place to screen the creation of new articles separate from the candidate bios and purporting to describe things relating to the candidate. This might include some means of flagging new articles containing Clinton, Trump, Cruz, Sanders, Kasich, Hillary, Bernie, or Donald in the title to double-check before releasing into mainspace, and some means of holding articles specifically relating to the candidate for at least some glancing review. bd2412 T 23:52, 1 May 2016 (UTC)

That article was deleted. Looks like existing structures are working just fine to stop the problem. Nothing looks broken to me. --Jayron32 01:28, 2 May 2016 (UTC)
Yes, it was - after several days, and the participation of 20-something editors in a discussion about whether it was appropriate to have such an article. The problem might not have been discovered as quickly, but for the boldness of the editor who decided to add a link to this article from the subject's heavily watched main article. We could have saved that time and effort. bd2412 T 11:23, 2 May 2016 (UTC)
Not really. There exists no equitable mechanism to force people to not create articles we arbitrarily decide we don't want them to create. Wishing such a mechanism could exist doesn't make it exist. --Jayron32 16:31, 4 May 2016 (UTC)

Instruct administrators to notify the Communications Committee when placing blocks on /16 ranges

As I understand, if an administrator places a block on a single IP address belonging to the United States Navy, (s)he is greeted with a scary message that they are performing a sensitive action and that they need to notify the communications committee. If blocking one IP can potentially cause PR or political complications, it seems blocking major ISPs, entire U.S. States' government or educational networks (I've personally seen this with North Carolina, Washington, and Utah), or entire countries' government or educational networks can cause similar PR issues. I'm thinking it would be wise to put a notice on the block page stating something like "You are potentially blocking millions of individuals for an extended period of time, a potentially sensitive action. Please notify the Communications Committee immediately," when an admin is placing an extended block on a /16 range (six months or longer). The message shouldn't be designed to intimidate the admin, but just as a friendly notification that his/her action needs to be brought to their attention. Thoughts? PCHS-NJROTC (Messages)Schoolblocks are like gun-control, they only stop good faith contributors. 02:14, 12 May 2016 (UTC)

It's not really like that; we see this message when blocking IP's MediaWiki:Blockiptext. You can suggest changes on MediaWiki talk:Blockiptext. — xaosflux Talk 02:49, 12 May 2016 (UTC)
See also Wikipedia:Blocking_IP_addresses#Sensitive_IP_addresses - and yup the tables are not synced - not on purpose just noone has gotten around to updating the message. — xaosflux Talk 02:53, 12 May 2016 (UTC)
What I'm proposing is that we treat extended /16 blocks as sensitive actions. There doesn't seem to be any consensus to restrict them, but there's no denying that really, really long /16 blocks affecting millions of users could draw attention from the press, especially some of these ones on entire states' government or educational networks (where politicians are ultimately responsible for these ranges' activities). PCHS-NJROTC (Messages)Schoolblocks are like gun-control, they only stop good faith contributors. 03:20, 12 May 2016 (UTC)
Where else have you discussed the proposal that blocking IP ranges should be significantly more restricted than occurs now? Has there been much support? Should a signature contain a slogan that advocates a non-consensus position (or indeed, any position)? Johnuniq (talk) 07:43, 12 May 2016 (UTC)
Yes, seeing the message in your signature, [[User:|PCHS-NJROTC|PCHS-NJROTC]], which does indeed does not seem to be backed-up with any real-life data (show me school-IPs with long blocks where there are a significant number of edits from good faith contributors), does not make me take the concerns in the opening of this thread significantly serious. If an IP only vandalises it gets blocked, if a range is shown to only vandalise, it gets blocked - and depending on the situation, that may be lengthy. If someone (the press..) were to complain to Wikipedia about that block, they'd better understand that apparently the school board does not have a lot of control about their students (or the ISP over their/a customer(s)) when individuals are using the computer through their IPs, as by far the majority of their students (customers) apparently only edit to vandalise. Take out the culprits as IP-address-owner and put an effort in avoiding that happening again, tell Wikipedia and the IP(-range) will be unblocked to see if it really helped (we can always block again if it does persist ...). Or do you suggest that we leave vandals be and not block at all. After all, the editors on Wikipedia are just here for an extended game of whack-a-mole.
As such, I see no need - admins who use the blocking tool know that blocking a /16 is a sensitive action, and they know that blocking an IP for years is a sensitive action, and something that is not done lightly. --Dirk Beetstra T C 10:51, 12 May 2016 (UTC)

Articles needing updates

Hello, everybody. I just to bring up some issues with a number of articles. WikiProject France: 2016 in France has an event that takes place in February as predicted and scheduled even though its currently May. In addition, there are 7,270+ articles related to France that have not been assessed yet. WikiProject Ukraine: 2015 in Ukraine needs to have the April, May and June sections filled in and more sections added. For 2016 in Ukraine, the section events appears twice and it needs a talk page. WikiProject China: the Heilongjiang leaders and Jilin leaders templates are incomplete. Please add in names of People's Congress Chairmen and CPPCC Committee Chairmen for regional leaders templates of China that do not have them. The article Politics of Jilin needs to be updated with a full list for CPPCC Committee Chairmen. In addition, we have 5,440 articles related to China that have not been assessed. Anyone who is an expert in these fields, please come forward. Thank you. Zee money (talk) 19:47, 12 May 2016 (UTC)

@Zee money:, Hi Zee money, I have created a talkpage for 2016 in Ukraine and removed the duplicate header deemed as "Events". While I'm not an expert in most of these subjects, these were quick housekeeping edits that were easy for me to perform w/o any extended knowledge. Regarding the numerous articles that need to be assessed however, Village pump is probably not the best place to express your concerns for these articles. Addressing these issues on the project talkpages would probably be your best bet for a more timely and appropriate response. Good luck. Sunekit (talk) 03:18, 13 May 2016 (UTC)

Implementing Help:Maintenance template removal

Responding to a request for closure at WP:ANRFC. Obviously, there is consensus for this change. I'm leaving the implementation section open in case there's any remaining issues to be worked out there. (non-admin closure) ~ RobTalk 06:14, 18 May 2016 (UTC)

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

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:

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. Cullen328 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)
  • Support as discussed above. Doc James (talk · contribs · email) 09:29, 24 April 2016 (UTC)
  • Hold on please Fuhghettaboutit. I would support a link to a page describing how and when to remove a particular maintenance template, but how useful is a generic page like Help:Maintenance template removal? You could at least link to a section or anchor of that page, which deals with the particular template. Ideally there would be separate guidance for each maintenance template. — Martin (MSGJ · talk) 12:03, 26 April 2016 (UTC)
  • Martin, I feel such a disconnect between what you’re saying and this proposal’s purpose, the bases I gave for the why of it all, and how ungeneric and tailored the help page is for that purpose. “How useful is this” non-"generic" page? Extremely? Surpassingly? Pick your synonym. The constant notion that some elite class will fix the issue is dispelled. People will get that they can contribute and be bold. They will stop thinking templates are automatically removed (which we know is a persistent and common misunderstanding). With the clarity of removal explained, they will be more likely to act in the first place, maybe even enticing some bright people to first edit Wikipedia when seeing that, yes, they really can dive in to fix the problem. And the page is geared to teaching the information necessary to deal with any maintenance template, regardless of whether it’s one of the nine for which specific guidance is provided (the nine were chosen because they are so common). People can read. If they’re there as to one of those templates, and they’re the type of person who is likely to actually help, then they're much more likely in my experience to be the type of person to actually read the page – which is not overwhelmingly long – and to see the specific template guidance section. And for those who arrive there from a template which is addressed in the specific template guidance section, they should still be reading the content higher on the page, because it’s information is more important. Though I did provide anchors for the specific template section, I think it would actually be less helpful to have the link go to that section, thereby making it less likely people will read the page.--Fuhghettaboutit (talk) 01:55, 27 April 2016 (UTC)
  • Support. Great idea, may encourage editing and helps reveal more of Wikipedia under the hood to readers. The help pagr is good. Fences&Windows 17:28, 29 April 2016 (UTC)
  • Support per everybody. Comment Templates, especially PoV/unreffed/Peacock/etc. are often removed by the PoV editor who is convinced there isn't an issue, would it be worth strengthening the 'when not to remove' advice so that editors are specifically instructed to NOT remove if an/other editor/s objects. I note it says 'seek concensus', but could this be strengthened? Pincrete (talk) 22:22, 5 May 2016 (UTC)
  • Comment POV works both ways and header tags are completely nonspecific as to where the problem lies. (We don't have ESP and professional editors use a red pen.) Subjective (PoV/unreffed/Peacock/etc. header) tags, should include the similar guidance as contained in Template:COI.

Like the other neutrality-related tags, if you place this tag, you should promptly start a discussion on the article's talk page to explain what is non-neutral about the article. If you do not start this discussion, then any editor is justified in removing the tag without warning.

Additionally, WP:STEWARDSHIP is a concern here, when some editor drives by (often using an interface, with canned edit summaries), without the courtesy of using a section or inline tag, and doesn't start a talk page discussion, there is no indication that the tagging editor has any advanced knowledge about the article subject. Removing tags from disinterested editors should be trivial and the act of the interested editors moving them to the suspected sections should be considered a receptive courtesy.
Finally, because the problem is often with the editor and not the article, and COI tags are both accusatory of the editor and the article content, sustaining contested COI tags should required that the moving editor take the issue to COIN. (Similar to a WP:PROD) In many cases, the defects in the writing are marginal and the proper tag is Template:Connected contributor if that determination is made. 009o9Disclosure(Talk) 05:47, 13 May 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.

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)
The module was updated by Mr. Stradivarius to add the link when | removalnotice = yes is placed. Multiple issues was tested so that it would only place the link but once. I've added it to the nine templates specifically addressed at the help page, and will wait a fair amount of time before adding it anywhere else. Thanks all.--Fuhghettaboutit (talk) 11:56, 26 April 2016 (UTC)
Comment from an NPP and hopeful template editor: I feel like the proposed modification was poorly implemented from a design standpoint. I feel like it is unbalanced and expands templates more than necessary. {{More footnotes}} is now five lines long when blp=yes. I hate to complain and then not have a solution, but I personally feel like it needs to be integrated into the body better. -©2016 Compassionate727(Talk)(Contributions) 17:29, 26 April 2016 (UTC)
I came here to voice the same thing; the line-fed left-aligned bulleted list of only one list element is unbalanced and adds an unnecessary amount of whitespace (grayspace?) to the tag. How about putting the link in parenthesis after the tagging date parenthesis, and make it italic and lowercase to match the date? – voidxor 20:43, 26 April 2016 (UTC)
I think it's better on its own line, though having it in is what's important; having it appear after the date paramater would not be my choice but would still be fine. Certainly though, there is significant whitespace before it that would be best removed; snug it up as much as possible (and also if possible, maybe the space after can be reduced as well?) Unfortunately, I do not have the technical ability to help. Any tech people out there?--Fuhghettaboutit (talk) 01:22, 27 April 2016 (UTC)
I asked and received assistance from Mr. Stradivarius. It is now on the same line as the date.--Fuhghettaboutit (talk) 12:19, 27 April 2016 (UTC)
It looks good there (in my opinion, anyway). Thank you! – voidxor 20:26, 4 May 2016 (UTC)

Related proposals at Meta

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

OGG and MIDI

I understand the many benefits of midi files, but because wikipedia values accessibility, I propose that these midi files include their ogg conversion for simpler playback and wider support. Houdinipeter (talk) 16:37, 14 May 2016 (UTC)

FYI, the ticket to improve support for Midi is phab:T20852. It's been open for a while, but it's actually rather easy to fix. We just need to find the time to do so. Any assistance with development in this area would be hugely appreciated. —TheDJ (talk • contribs) 09:40, 19 May 2016 (UTC)

Harmonising a bunch of article titles

This concerns eight articles:

Currently we have eight articles about impeachments that actually happened (Impeachment process of Richard Nixon is different, since he resigned before being impeached), but there are three different title formats: "impeachment and RESULT of PERSON", "impeachment of PERSON", and "impeachment process against PERSON". I'm basically proposing that we pick one of these three (preferably "impeachment of PERSON", with "impeachment and RESULT of PERSON" as second choice) as the standard and move the other two to match it. Please indicate which one you support, or explain why you think the current setup is better than having a single standard. Nyttend (talk) 01:22, 13 May 2016 (UTC)

First choice - status quo. Second choice - all should be named "Impeachment of..." Impeachment means "Indictment of a public official" All of these people were indicted, so it is completely correct to say they were impeached. That later in the process they were either acquitted or convicted is not something that needs mentioning in the title. My first choice is still "status quo" because a foolish consistency is worse than being inconsistent. --Jayron32 01:31, 13 May 2016 (UTC)
I don't understand why you say that it would be a foolish consistency to adopt a single format for these eight. If I understand the article rightly, Emerson's attacking the idea of seeming consistency when situations are really inconsistent; here, there's no significant difference among these articles' titles, and articles need not express themselves nor resist institutional authority. Nyttend (talk) 01:40, 13 May 2016 (UTC)

In an analogy with the titles "Trial of ...", none of them is as "Trial and conviction of ..." or "Trial and acquittal of ..." or "Trial process of ...". So, considering the meaning of impeach, seems reasonable the title "Impeachment of ...". It could be create an infobox also?
PauloMSimoes (talk) 03:39, 13 May 2016 (UTC)

  • "Impeachment of foo" seems like it would be preferable as the most concise name. Unless there is any reason that any of these articles shouldn't be simply called "impeachment of...", I would support moving them there... Caeciliusinhorto (talk) 08:29, 13 May 2016 (UTC)
  • Impeachment of - unless there is a specific reason to make an exception in a specific case (as the OP pointed out, Nixon is such a case, since he was never impeached), all titles should use the same pattern. I would also like to point out that the lead for the Nixon article refers to the Johnson and Clinton cases - both using the text "impeachment of". עוד מישהו Od Mishehu 11:55, 15 May 2016 (UTC)
  • I haven't gone through all of these, but note that "impeachment" has different meanings in different countries. In the US, "impeachment" means the formal beginning of the process regardless of result, but in many (probably most) countries it refers to the actual removal from office (so what happened to Clinton, for instance, would be called "attempted impeachment"). ‑ Iridescent 18:33, 16 May 2016 (UTC)
    • What happened to Clinton is, in the location where it happened, called impeachment. Same is true with Johnson (same place, same outcome). Not sure about Brazil (the only other article on the list not using "impeachment of"). עוד מישהו Od Mishehu 04:30, 17 May 2016 (UTC)
      • Sure, but Rousseff is not in the US. In the US "impeachment" is the commencement of formal proceedings and thus "Clinton was impeached" is accurate, but in Brazil "impeachment" is the actual removal so it wouldn't be accurate to describe her as "impeached" unless and until she's formally removed from office rather than just suspended. (The BBC has a good plain-English graphic of the Brazilian constitutional process.) ‑ Iridescent 07:40, 17 May 2016 (UTC)
I agree generally with Iridescent. Even in the US president system, there is an important difference between adopting 'articles of impeachment' and those articles being successfully tried, so that one is successfully impeached. Even in America, it retains that older sense in an important legal and practical way. Alanscottwalker (talk) 09:55, 19 May 2016 (UTC)



Name Kritsell Laura Ariana Loza Born 26 july Tottenham, London, England

Discussion on appearance of preferences for logged out users at MediaWiki

After the proposal here to enable hovercards by default did not find consensus here, a proposal on how users should be able to opt-out of it was raised as MediaWiki. There has been limited discussion there and so your input would be appreciated. Here is a link to the discussion at MediaWiki. Wugapodes [thɔk] [kantʃɻɪbz] 20:12, 19 May 2016 (UTC)

Colorize text in the editor

With all of the effort being put into the WYSIWYG editor (can't recall its name off the top of my head), it occurs to me that all the text in the editor is black text on white background. What we may wish to consider is making different parts of the code representative (and maybe personally configureable) colors for each "type" of item in the edit window. Internal links could be blue, external links a different shade of blue, non-existing internal links red, templates another color, citations ... you get the idea, I hope. This is already possible in many text editors when writing programming language code, and since this is another form of that, it will make it easier for the human eye to parse the text among the different kinds of things that are within the text itself. Hires an editor (talk) 00:13, 20 May 2016 (UTC)

you may want to try the "WikEd" gadget. peace - קיפודנחש (aka kipod) (talk) 03:00, 20 May 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_131&oldid=1142560991"