Jump to content

Wikipedia:Village pump (proposals)/Archive 134

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, 212, 213, 214, 215

media credential

I have a vague recollection of seeing a discussion of media credentials somewhere, but my search for "media credentials" didn't seem to turn up anything relevant.

I'd like to revisit the subject but they would be helpful to review some of the background so if anyone recalls reading about this and knows how to find it I hope they can point it out.

The general issue is that it would be helpful if media were willing to request media credentials for Wikipedia editors. I think the position is that Wikipedia editors are expected to be "laypeople" not "professional journalists" and therefore should not be given the stature of a professional. I understand that position. However, in the case of sporting events, decent photographs require either a good vantage point, or a good lens or both. Some venues restrict the quality of camera equipment allowed by "fans"; the use of decent photographic equipment is only permitted by those with media credentials. It would be nice if we could find some way of arranging for such credentials.

I found one individual who claims to a been granted media credentials and I have a query into that person to understand more about the circumstances. It won't surprise me if some venues will grant media credentials simply by asking and explaining your connection to Wikimedia, but in the specific case I'm interested in, the venue wants a written request on letterhead, so I'm interested in determining whether that's a reasonable request to push Wikimedia to grant or if there is another option.--S Philbrick(Talk) 13:55, 6 August 2016 (UTC)

What do you propose we would do differently for users with "media credentials"? KSFTC 22:37, 9 August 2016 (UTC)
Someone at Wikinews would probably know more about this subject. WhatamIdoing (talk) 17:07, 10 August 2016 (UTC)
It is an interesting thought- having something equivalent to a press card to flash to custodians of protected sites, or just to cross the police line at festivals would be useful. Two recent examples were the wish to join other 'accepted locals' at bull-running events and Toro-piscine in Sommières. Bulls are bloody dangerous so rightfully the police were keeping tourists out but the locals and me appear blasé but are hyper cautious- I missed some good shots. The second was more cultural in a historic monument and archaelogical site managed by knowledgeable volunteers. The public were let into the best bits, in batches, twice a day on an guide-led tour. Neither conducive to the type of photography we need. I failed to explain, in my third language what Wikipedia was, what I was and why I should be made an exception and given the access I needed.
So what do I want- (this is a first stab)
An A6 sized card, with a nice large logo, saying who I am, passport number, and a set paragraph;" This is #NAME, who has been a contributing photographer to Wikimedia commons since #DATE. He has contributed #NUMBER of photos, under the username #USENAME. Please assist him today." We then can have some promotional blurb, and lawyers disclaimers. And finish with, "to verify his credentials an email may be sent to photographerscredentialsoffice@wikimedia.dot or online at http:#wikimedia.dot/acreditedphotograhers."
This could be issued in the form of a template, stored in a User/subpage, and when it is issued, the name appended to the webpage list.
Just a thought to be worked on. ClemRutter (talk) 08:07, 12 August 2016 (UTC)
  • I can't really comment on how Wikipedia would go about issuing credentials, but as someone who works in the press I can say the credential itself can only get you so far. In many cases, you need to work with the entity before hand to ensure you get the desired level of access. So simply showing a press pass might not be enough. Calidum ¤ 02:35, 13 August 2016 (UTC)
Thanks for commenting. Round our way its called the 'Gift of the gab'! It's an introductory tool, how one uses it is up to the individual-- and often it will fail, but it would increase the chance of success. ClemRutter (talk) 18:17, 14 August 2016 (UTC)
  • This is often one of the benefits of joining a chapter. The chapters are legal entities and have been known to hand out 'credential' like cards etc to members if they can show the need for them. They are often also well positioned to write certificates of event attendance and similar stuff (often requested by employers if you take an unpaid leave for an event for instance). —TheDJ (talk • contribs) 09:44, 15 August 2016 (UTC)

Give rollbackers the ability to delete pages with just one edit / edits by just one user

Closed per WP:SNOW. —MartinZ02 (talk) 16:27, 15 August 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.

Moved from Wikipedia:Village pump (technical) § Give rollbackers the ability to delete pages with just one edit / edits by just one user
 – ―Mandruss ☎ 22:18, 14 August 2016 (UTC)

Page creation vandals should be combatable by rollbackers. I think the same rollback button should be available in these cases, with a different action (deletion) performed upon clicking. Thoughts? Samsara 18:45, 14 August 2016 (UTC)

It is not possible for non-admins to delete pages. Unbundling this right is a perennial proposal. — foxj 18:51, 14 August 2016 (UTC)
If we can please avoid having "why it can't be done" type posts. I know for a fact that it CAN be implemented the way I propose, it is simply a matter of whether the community thinks it is a good idea, which is why I'm posting here. Samsara 19:12, 14 August 2016 (UTC)
I'm informing you politely that this is something the community have rejected many, many times (and seemingly will do again here). — foxj 19:56, 14 August 2016 (UTC)
  • Oppose The perennial proposal aspect of things aside, what's to stop vandals making two edits initially? I agree the unbundling of the tools is bound to happen at some point, but in this form they'd just find a way around it. We'd be back to rollbackers only being able to rollback edits -- samtar talk or stalk 19:16, 14 August 2016 (UTC)
    • what's to stop vandals making two edits initially? Version B of the proposal deals with that in allowing deletion if there is only one editor. Additionally, a recency threshold could be set to avoid use on old pages; limiting the right to (a) particular namespace(s) is another option. I've no doubt that admins at least would welcome having the extra button available to them. Samsara 19:32, 14 August 2016 (UTC)
  • Oppose If we want to start this again fine. But the community has repeatedly rejected this for numerous reasons. The deletion of pages should be left to admins. Not only that, but rollbacker is given out like candy here. To give all those people the ability to delete pages would be madness. Also, that is not what they were approved for. So to do this would require an audit of every rollbacker to ensure that they meet the new standards that are set. And there would be new, higher, standards since the deletion of pages is not something the community takes lightly. --Majora (talk) 19:18, 14 August 2016 (UTC)
    • Yes, but a proposal like this, separate from Rollback, and combined with the ability to delete redirects (esp. redirects with trivial page histories), is actually worth discussing. Or it actually would be, if people around here would stop living in the past long enough to stop driving this place into the ground... --IJBall (contribs • talk) 05:06, 15 August 2016 (UTC)
  • Addendum: As a side effect of the proposal, ideally admins should get a rollback button to remedy page creation in the simple scenario of a page consisting of just one edit, or, (let's call this version B of the proposal) where the page has only one editor. Samsara 19:20, 14 August 2016 (UTC)
  • Oppose. There are too many people with rollback permission that I don't think should be able to delete pages. Deli nk (talk) 19:35, 14 August 2016 (UTC)
    • Proposed is the permitted deletion of a particular, uncontroversial subset (to be further defined, for instance, in terms of recency, history, namespace) of pages to combat page creation vandalism. Samsara 19:38, 14 August 2016 (UTC)
I understand that. To be clear, there are too many people with rollback permission that I don't think should be able to delete ANY pages. Deli nk (talk) 19:40, 14 August 2016 (UTC)
  • Oppose Deletions of anything with content (controversial) should be left to duly appointed admins. (See WP:PAGEMOVER for an example of a technically uncontroversial page deletion.)--☾Loriendrew☽ ☏(ring-ring) 19:55, 14 August 2016 (UTC)
    • Maybe I'm missing something, but that last bit feels like apples and oranges to me. The pagemover right would not directly overlap with the newly proposed mechanism as far as I can see. Samsara 20:24, 14 August 2016 (UTC)
  • Oppose - Too risky. Better we should allow non-admins to temporarily block the vandal. By temporarily I mean 31 hours or less. ←Baseball Bugs What's up, Doc? carrots→ 19:58, 14 August 2016 (UTC)
  • Regarding bad blood over rollbackers: In reply to those who don't trust (other?) rollbackers - if your fears are well-founded, I think if anything, this right will be an opportunity for the bad 'backers to out themselves and be removed from the roster. The action would obviously be logged, just as is the case for the vast majority of actions right now. Wikipedia hasn't blown up before, and it won't blow up this time, either - one way or the other! Samsara 20:06, 14 August 2016 (UTC)
  • Though this jumping-to-polls is a bit of an odd precedent, I also oppose this. Unbundling the admin tools is consistently and repeatedly rejected by the community; asking over and over again is just wasting everyone's time. The risks involved with granting deletion rights to those who have the rollback ability, which is generally granted on a whim to whomever asks nicely for it, are really too great. Twinkle exists to tag pages for deletion, so this is really a solution in search of a problem. — foxj 20:09, 14 August 2016 (UTC)
    • Since politeness is so important to you, perhaps you would grant that I have never made a similar proposal before, nor been part of any group that has a habit of making such proposals, thank you. I will also note that you have not provided evidence that this particular proposal has been made before. Samsara 20:20, 14 August 2016 (UTC)
    • That's weak. Time changes – the "Admin/RfA model" for this place isn't just in the process of "failing": it has already has failed. (And no phantom "RfA reform" is ever going to fix it.) But people would rather bury their heads in the sand, and whine about "perennial proposals", rather than looking objectively at the lot of them to figure out which of them can be "reworked" into something like a workable proposal. --IJBall (contribs • talk) 05:06, 15 August 2016 (UTC)
  • Oppose If somebody is creating lots of inappropriate pages, post at WP:AN. Admins already have the "Nuke" option, at the top this says "This tool allows for mass deletions of pages recently added by a given user or an IP address. Input the username or IP address to get a list of pages to delete, or leave blank for all users." --Redrose64 (talk) 20:25, 14 August 2016 (UTC)
    • Thanks for the hint, never noticed that up there. I imagine there could be situations where more fine-grained control is needed, but the existing implementation is a good first-responder option. Samsara 20:43, 14 August 2016 (UTC)
  • Oppose. You're proposing that a non-admin be able to use the rollback right to delete pages in limited circumstances, but you say nothing about mistakes. What if you click a rollback link and delete the page by mistake? Your proposal leaves no room for undeletion, and enabling someone to do something without enabling them to self-revert is pretty much always a bad idea. And finally, giving non-admins access to Special:Undelete would be a horrid idea and has been vetoed by WMF. So basically, unless you can fix an erroneous deletion, you shouldn't have the ability to delete pages in the first place. Much better to resolve admin backlogs by nominating and supporting additional qualified candidates at RFA; if they're trustworthy enough to be deleting pages under any circumstances, they should be admins. Nyttend (talk) 22:06, 14 August 2016 (UTC)
    • People really seem to love opposing. Okay, so they'd need a self-undo, which, now that you mention it, should probably be a wiki-wide special mechanism anyway. Samsara 22:23, 14 August 2016 (UTC)
      • As far as I know, ever since bureaucrats were given the ability to desysop people (for many years, they could make people admins, but they couldn't remove the right), there's been no user right that can't be self-undone. With rollback, it's simple: click rollback on your own edit, or do an ordinary revert to restore the edit just before yours. We admins can undo bad deletions: just go to Special:Undelete and click the normal undeletion buttons. Nyttend (talk) 22:34, 14 August 2016 (UTC)
        • The point is this: there is no general undo mechanism that undoes whatever action you want to undo. For instance, with page undeletion, you have to go through an extra dialogue; with unprotection, you only have "change protection", so you have to retrace your steps on any of those. It would be a significant interface improvement to be able to simply undo exactly what you just did, rather than having to reverse your entire motion. I believe it's the case that the db currently does not remember prior states for things other than edits, so that's probably why it hasn't been implemented. However, it would be neat to get this implemented across the board and manifested in developer guidelines. Samsara 23:56, 14 August 2016 (UTC)
    • I'm with Nyttend on this. If you mess up and have to take it to an admin, that just adds another layer of complication. If you can undelete what you deleted, you can fix your own mistake. ←Baseball Bugs What's up, Doc? carrots→ 22:49, 14 August 2016 (UTC)
  • Oppose. I'm sorry to pile on, as it seems like it's starting to snow as it is, but this proposal would completely undermine the CSD process. Let's say a rollbacker is patrolling new pages, and comes across a page they feel should be deleted. For pure vandalism or an attack page, that's fine; but what's to stop a rollbacker from saying "Well, from what I can tell, this page meets WP:CSD#A7; instead of tagging it, I'll just delete it myself." This possibility removes the built-in safety net of CSD; as things are now, an administrator, an editor whose judgment has been weighed by and is trusted by the community, must review a CSD request from a non-admin. With this proposal, someone who does not necessarily have this level of judgment has the ability to circumvent this process and take power into their own hands. We could say to rollbackers, "only delete pages that meet A3 or G10", but I don't have the level of trust in all of the 5,584 non-admin rollbackers to be comfortable giving them all a delete button. Perhaps the page was not eligible for A7; a sound page has been deleted, and an admin has to come in and explain the problem to the rollbacker. Yes, the page can be undeleted, but that's not the only problem; the page creator (possibly a newbie), who did not have a chance to contest the deletion, is disheartened, and leaves Wikipedia. That's a lost contributor, which is far more difficult to replace than a lost page. While I would suggest having one rollbacker tag a page for another rollbacker to delete, this would mean that at least two people would have edited the page (creator + tagger), thus nullifying the process, as an admin would end up having to delete the page with multiple editors. This means that the deletion decision would come to one person, making one call. Admins can be trusted to make the correct call; I'm not sure any given rollbacker can. And, as always, there's the WMF's stipulation that any editor being given deletion rights be vetted by the community, which would essentially create an RFA-like process which all current and future rollbackers must be put through. Again, I'm sorry to come in here and rip this idea to shreds, but deletion is perhaps one of the most serious decisions that can be made on Wikipedia. I wouldn't trust it to anyone less than an admin. Colonel Wilhelm Klink (Complaints|Mistakes) 23:48, 14 August 2016 (UTC)
    • Like I've said before, if the concern is not trusting rollbackers, then this is a perfect way to allow untrustworthy rollbackers to out themselves. Samsara 00:22, 15 August 2016 (UTC)
      • Yes, but at what cost? It only takes one bad experience to chase someone away for good. That's an editor lost due to someone's carelessness, so I still take issue to it. I would not, however, necessarily be against deletion rights being granted to rollbackers who specifically request them at a venue not unlike WP:PERM/R. This would keep (most of) the bad apples out of the bunch, and would ensure that only those who can be trusted with performing deletions be given the right (though, ideally, community consensus should still be gauged before handing out deletion tools). What I object to is the idea of all rollbackers being granted deletion rights. Colonel Wilhelm Klink (Complaints|Mistakes) 00:55, 15 August 2016 (UTC)
  1. Oppose - a misused rollback can easily be fixed by anyone by a simple revert; a mistaken deletion can only be fixed by an admin. עוד מישהו Od Mishehu 02:55, 15 August 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.
Withdrawn by proposer. Colonel Wilhelm Klink (Complaints|Mistakes) 21:50, 16 August 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 have put up a new feature request at Phabricator and would like to get some community feedback on the idea.

FEATURE DESCRIPTION

When dealing with certain long discussions and/or complex section edits it is helpful to isolate (filter) the history of edits within a specific section. What I propose is that an optional (see below what I mean by this) link be placed on each section header (just after the current Section-Edit link). This would invoke a History page that is filtered as follows:

  1. any edit that references the given section in the <span.autocomment> text, and
  2. any edit that was the entire page (and so might include the targeted section).

As for what I mean by optional, my thought is it could be

  1. a user configurable setting ( [_] Show Section History link ) under Preferences, and/or
  2. a __NOSECTIONHISTORY__ magic word option similar to __NOEDITSECTION__.
Other than this filtering of which edits to list, the History page would act exactly the same as it does now.
— phabricator:T142911

Thoughts? Comments? Questions? Critcisms? Praise? Donations? Gifts? -- Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 01:37, 16 August 2016 (UTC)

Difficult to do in a performant way, and thus unlikely to happen. You need something like Flow in order for this to be performant. Might be doable as a user script, but you would have to find an author for it. —TheDJ (talk • contribs) 08:25, 16 August 2016 (UTC)
And quite simple for a vandal who wants to byposs the system o place a false section header claim in the summary. עוד מישהו Od Mishehu 10:34, 16 August 2016 (UTC)
The devs will almost certainly reject it, probably saying "we provided Flow to do exactly that, and English Wikipedia refuses to sanction its use". I for one do not want Flow here, so we're forced to write things like JavaScript gadgets ourselves. --Redrose64 (talk) 18:02, 16 August 2016 (UTC)
Od Mishehu This is just a suggestion for a tool, and like all tools it will not work correctly if someone games the system. That does not diminish the value of the tool in most cases for helping to sift thru the irrelevant edits when trying to find how a particular section was developed or to follow the progress of a given thread on a busy discussion page. If we allowed how people might abuse special tools to determine what we build we would have none at all. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 18:06, 16 August 2016 (UTC)

WITHDRAWN -- I just realized a major problem with this idea and until that can be addressed even I do not want to see this tool developed. The problem is that if, as I said in the Phab ticket, "the History page would act exactly the same as it does now" then all Hell would break loose because a multi-diff undo would incorporate other edits in other sections that are not showing in the list.
That would be bad, Very Bad! Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 18:11, 16 August 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.

Semi-Protection on large and/or GA/FA pages

WP:SNOW close; not only is this near-universally opposed, but ditching "anyone can edit" would be a fundamental change to Wikipedia's basic principles which would need WMF authority (which would not be forthcoming, given that they vetoed WP:ACTRIAL). ‑ Iridescent 19:16, 17 August 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.

One thing I've noticed is that not many vandals go for small, rarely edited pages, they have a tendency to go for big pages, or else GA or FA pages, based purely on my past experiences, most vandals are IP's, so adding semi-protection to large (the size that constitutes large would have to decided if it was added.) or else a blanket semi-protection for all GA or FA articles. Iazyges (talk) 22:07, 15 August 2016 (UTC)

... During the 18 hours D.B. was on the front page, there were 229 edits, an average of just under 13 edits per hour.
Of these, 56 were acts of vandalism—such as deleting valuable contents, inserting curses or insults, or inexplicably, expressing a like for pie. Humans reverted the vandals 38 times, and anti-vandal robots 17 times, the latter effecting a complete repair in six seconds average. ...
The really good news is that 118 edits were made to improve the article during this time, 26 edits by 19 distinct anonymous editors, and 92 edits by 61 different registered editors. One of these was a robot adding links to the corresponding article on the Spanish and Swedish Wikipedias.... —EncMstr (talk) 06:39, 16 August 2016 (UTC)
  • Oppose - these pages are probably watched by more users - for the same reason that vandals attack them. I would also like to point out that we have some edit filters which protect them fro certain types of vandalism. עוד מישהו Od Mishehu 10:37, 16 August 2016 (UTC)
  • Oppose: We don't preemtively protect pages because policy probhits that including GA/FA articles. KGirlTrucker81 talk what I'm been doing 14:36, 17 August 2016 (UTC)
  • Comment: Do we have any statistics to validate this assertion? I would suspect that vandalism tends to occur on frequently visited pages, rather than higher quality ones. Perhaps a metric comparing the rate of identified vandalism vs. frequency of page visits would help identify pages that are in need of stronger protection. Praemonitus (talk) 18:53, 17 August 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.

Notification of proposal to make Help:Hidden text a guideline

The RfC is at Help talk:Hidden text #RfC on status of this page. --RexxS (talk) 14:29, 18 August 2016 (UTC)

World geograph

(Moved here from Jimbo's talk page). Something Smallbones reminded me of. A few years back I was keen on scaling Geograph Britain and Ireland to worldwide. Those not familiar with it browse the site. It's been of tremendous value to rural localities in the UK, but in the US we're often missing photographs of rural localities, and in the developing world. I can't remember who showed an interest originally but at one point I believe we were close to forming an agreement with Geograph and them merging into Wikimedia and Wikimedia running it in conjunction with the wiki commons. I think it's worth revisting, primarily because so many rural places lack photographs in US and Africa etc. Especially as the developing world comes online, I think we need something which encourages people to photograph where they live and upload photographs. There's something about the grid square and "completing" a picture that I like. It shows the uneveness of current photograph coverage and which areas need the most work. Potentially you could also organize grant requests for people to travel to off the track places to photograph each village and fill in the picture, particularly Africa. I am aware that google and a few others often use maps with photographs accumulated, but I think it's time Wikimedia ran a similar sister project geared towards photographing the planet geographically by area. Photographs are also an important way to provide information, worth 1000 words as they say. I was wondering if there would be any support here to make it worthwhile proposing a new sister project. Some sort of system in which you can map out the existing photographs we have in the commons, identify areas where we're missing photographs and encourage people from all wikis to upload photos to fill in the grid. As with geograph, that sort of system encourages more photographs to be created and for people to think geographically. It would need some sort of interface which spans the languages and in which people can upload photos and they directly go into the wiki commons automatically, but will also work on the global grid. It might be worth recontacting Geograph and proposing a merger and scaling of this again. Anybody interested?♦ Dr. Blofeld 16:20, 19 August 2016 (UTC)

I just addressed this on your user page before seeing this. I'll copy it here.
I would be up for a similar Geograph-type project in the US, in fact already doing something sort of similar. See List of municipalities in Pennsylvania which is/was an informal project to get pix of the 2561 municipalities in PA. After about 3 years we're up to about 2165. Now PA is about half the area (and 20% of the population) of the United Kingdom, 46,055 sq mi (119,283 km2) so it's pretty clear even getting 1 per sq. mile would be a challenge. There are similar but even less formal projects for New Jersey and Ohio. If you have any idea how to organize it more formally, without expecting UK type results, let me know. Smallbones(smalltalk) 19:01, 19 August 2016 (UTC)

File:Barbra Streisand - 1966.jpg

Is this transferable to Commons anytime soon? Torfilm (talk) 22:47, 12 August 2016 (UTC)

Once someone has conclusively proven that a) no copyright renewals happened, b) the file was disseminated to the public in 1966 and c) the original copies didn't include a copyright notice and none was added during the "grace period" in which no-notice works can still have copyright claimed on them. Jo-Jo Eumerus (talk, contributions) 08:10, 13 August 2016 (UTC)
Yeah, but it seems that they stopped checking those pictures. Torfilm (talk) 10:16, 20 August 2016 (UTC)

Change to diffs

I would like to suggest that the deleted text in a diff be shown in some other color than yellow; I suggest red. I edit wikipedia on several different displays and OSs, and small bits of yellow, such as a deleted ".", are very hard to read on all of them. Peter Flass (talk) 23:23, 24 August 2016 (UTC)

A global change will be unlikely to go through, they spent ages arguing on the colours leading up to the present situation, and much of the current colour scheme has web accessibility in mind. If you don't like the present scheme, there are two things that you can do - one is to write some custom CSS to change the colours, the other is to go to Preferences → Gadgets, and enable "Display diffs with the old yellow-and-green colors and design". Personally, I did both. --Redrose64 (talk) 23:57, 24 August 2016 (UTC)
Thanks, looks better. Peter Flass (talk) 01:24, 25 August 2016 (UTC)

Right to click "Mark this page as patrolled" shouldn't be given to every auto-confirmed user

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Proposer has asked for this RfC to be withdrawn in order to collaborate with the prposal already being prepared. The proposal will be relaunched and those who have already commented will be informed. --Kudpung กุดผึ้ง (talk) 05:13, 27 August 2016 (UTC)

Proposal:

  • Option A- Every extended confirmed user will automatically get page patrol right.
  • Option B- It should be given as a right in WP:PERM according to the AFD stats of the user.
  • Option C- Every editor who has at least two rights among Autopatrolled, File mover, Page mover, Pending changes reviewer, Rollback, Template editor will automatically get page patrol right. — Marvellous Spider-Man 04:09, 26 August 2016 (UTC) — continues after insertion below
  • Option D 'New Page Reviewer' right at least 90 days /500 uncntested mainspace edits which will lock all non authorised users out of the use of the WP:Page Curation . On the principle of user right groups that require a certain recommended threshold of experience, the right would be accorded by admin discretion at WP:PERM, much in he same way as Reviewer, and Rolbacker.
Patrollers who have effected 200 uncontested patrolls during 2016 and who have a clean block log will be grandfathered into the right. The existing NPP userbox will be deprecated and users will be notified by newsletter (in preparation) that they can reappky.This should bring it in line at least with the requirement for the far less important and less critical process of WP:AfC.
It is at NPP where all the 1,500 or so new pages that arrive every day get rightly and wrongly tagged for deletion, and rightly and wrongly passed for inclusion. It's also the place where first-time article creators get bitten, and regular, competent users get harassed by incompetent patrollers. All that is really required is for NP Reviewer candidates to have read and fully understood the tutorials at WP:NPP and WP:Page Curation, and the policies and guidelines at WP:DELETION. Admins will have the discretion to revoke the right if a reviewers performance proves to be below a reasonable standard.
WMF developers are already investigating the technicalities of installing the right. Kudpung กุดผึ้ง (talk) 03:04, 27 August 2016 (UTC)

Auto-confirmed user can use Twinkle and page curation tool to nominate an article for deletion. Marvellous Spider-Man 04:09, 26 August 2016 (UTC)

Option C is probably technically impossible, as you are technically able to do something if and only if you have at least one permission which is allowed to do it. I think Option A is best here. עוד מישהו Od Mishehu 06:31, 26 August 2016 (UTC)
Has there been a problem with large numbers of pages being marked as patrolled when they should instead have been speedy deleted? --Tryptofish (talk) 21:17, 26 August 2016 (UTC)
Kudpung - you may be interested in this. — xaosflux Talk 02:31, 27 August 2016 (UTC)
No, I strongly disagree with this proposal. We need more new page patrollers, introducing more requirements for them will most certainly not help with backlogs. Omni Flames (talk) 02:53, 27 August 2016 (UTC)
And Omni Flames, will you take on the work of patrolling the patrolers? Be warned, it's a full-time job - NPP is a mess because like most maintenance tasks, it's largely being being done by new and inexperienced users, and because it's a mess the experienced users are giving up until some controls are introduced. That's where the backlog comes from. Perhaps you should read WT:NPP. Kudpung กุดผึ้ง (talk) 03:45, 27 August 2016 (UTC)
  • @Marvellous Spider-Man: There are already ongoing efforts to establish such a right with active communication with the WMF, as well as a reformed system of new page review. Past attempts of making major changes to NPP without cooperation with the ones that can actually implement such changes have failed despite a solid community consensus. Any proposal that proposes a major change to NPP will disrupt these efforts. In addition, such a major change should have a well-written, at least one page RfC that states the proposal clearly, and possibly a trial period. — Esquivalience (talk) 03:59, 27 August 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.

Defining Commons as a source for imports

Occasionally, at FFD we encounter situations where license templates which exist on Wikimedia Commons are not available here, leading to license issues, e.g Wikipedia:Files for discussion/2016 June 24#File:Kirkby and hudson sheet music 01.jpg. This could easily be remedied by importing the Commons templates (Commons, as a file dedicated site, has a lot more sophisticated free content tags than we, and such templates occasionally have enough edits that attribution via the history is necessary) - except that Special:Import does not have an option for importing from Commons. I'd like to ask whether Commons should be added to the list of wikis that imports can be made from. Jo-Jo Eumerus (talk, contributions) 18:26, 22 August 2016 (UTC)

Jo-Jo Eumerus do you have a few examples of pages that would be candidates for import from commons? Sometimes templates have interdependence - so they can be tricky to just import. In general, you can just prove attribute for a template on the template talk and/or in the edit summary when creating the page. — xaosflux Talk 02:39, 27 August 2016 (UTC)
commons:Template:Licensed-PD-Art/layout, for example. There may be others as well. Jo-Jo Eumerus (talk, contributions) 10:17, 27 August 2016 (UTC)

Proposal: New Page Reviewer user right

It is proposed to ensure that New Page Patrollers be suitably experienced for patrolling new pages. This user right would bring new page patrolls inline with the requirements for the reviewers at Articles for creation, and the systems for according minor user rights such as rollbacker, template editor, page mover, etc. (see: Requests for permissions). The discussion is taking place at: New pages patrol/RfC for patroller right. --Kudpung กุดผึ้ง (talk) 06:19, 28 August 2016 (UTC)

Right now, when you set off the abuse filter, your edit summary is followed by

(Tag: [title of the tag])

For example, this edit, in which an IP address removed {{db-club|help=off}}, has a message consisting of:

tag-list-wrapper: 1, tag-removal_of_speedy_deletion_templates)

To find the filter that got triggered, you have to check Special:AbuseLog for the user/IP or for the page in question. Would it be possible (and if so, practical?) to have the message include a link to the filter itself? Yes, some filters are hidden, but this wouldn't be a security vulnerability as far as I can tell: even when I'm logged out, I can see the filter number (in this case, filter 29), and I'm just asking for the tag to include the same link to the tag that we already get in the filter log. Nyttend (talk) 23:51, 27 August 2016 (UTC)

Do the (edit) links on Special:Tags do what you are asking for? MediaWiki:tag-removal of speedy deletion templates is editable and as you can see from other tags links work there from the diff. Jo-Jo Eumerus (talk, contributions) 08:16, 28 August 2016 (UTC)
It helps, but I was actually hoping for a link to the filter itself that would be following the edit summary. For example, in this one, "Tags: Removal...templates (29)". I know that we could add it individually to each one, but that would take a good deal of effort; it would be easier if there were some magic word or other MediaWiki setting allowing us automatically to introduce it to all of the tag messages. Nyttend (talk) 11:50, 28 August 2016 (UTC)
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
The community has clearly formed a consensus to deprecate the parameters in the manner proposed. It is also agreed that when deprecating the parameters, we must first convert their existing instances into a form acceptable by |coordinates= before removing their functionality from the templates – in other words, for now, we will discourage use of the parameters but continue to support them in the template. As a result, it is likely that the deprecation process will take some time and volunteer effort to carry out. Jonesey95's suggestion to create a page with instructions for how to help with the process is worth considering. Mz7 (talk) 04:37, 25 August 2016 (UTC)

Should the named coordinates-related infobox parameters (|latd= et al.) be deprecated in favor of |coordinates={{Coord}}? ―Mandruss ☎ 02:31, 12 August 2016 (UTC)

Precursor discussion: Wikipedia:Village pump (miscellaneous)/Archive 53#Category:Pages using deprecated coordinates format

BACKGROUND:

Many infobox templates support a |coordinates= parameter where you can code a transclusion of {{Coord}}. Many of those infoboxes also support a set of individual named parameters, each corresponding to one of {{Coord}}'s positional parameters (plus one corresponding to |display=). Such an infobox typically has around 10 related parameters such as |latd=, |longEW=, |coordinates_region=, and |coordinates_display=.

Creating the individual named parameters was seen as the only way to provide latitude and longitude to {{Location map}} while coding those values only once. Since the named parameters work with or without the presence of a {{Location map}}, the doc for some infoboxes attempts to discourage the use of |coordinates={{Coord}}, while most/all infoboxes still support it as an option when {{Location map}} is not used. An example is Template:Infobox building#Map and coordinates.

There has been an attempt to deprecate |coordinates= without public discussion and consensus. During the debate of that situation, it came to light that infoboxes could pass coordinates from |coordinates={{Coord}} to {{Location map}}. This would eliminate the need for the individual named parameters, and would be the superior solution.

PROPOSED:

Deprecate the individual named infobox parameters. Modify Module:Coordinates and the infoboxes so as to pass latitude and longitude to {{Location map}}. The technical details have already been worked out; see the above-linked precursor discussion.

BENEFITS:

  • All coordinates-related data concisely in one place, on one line. Individual elements can't get moved around and separated. Easier to see if an element is missing, and very difficult to duplicate one.
  • Learn one parameter name, not ~10.
  • {{Coord}} would be used for all coordinates-related data in any article, whether it has an infobox with {{Location map}}, an infobox without {{Location map}}, or no infobox.
  • No additional learning for editors who are familiar with {{Coord}} but have never worked with coordinates in articles that use {{Location map}}.
  • There is some inconsistency in the support for the individual parameters. For example, some infoboxes use |coordinates_region=, others |iso_region=. Some infoboxes do not support {{Coord}}'s |display= value and/or dim:. Et cetera. This adds complexity, decreasing ease-of-use, and this proposal eliminates that confusion by deprecating those parameters. ―Mandruss ☎ 02:31, 12 August 2016 (UTC)

RfC survey: Deprecate named parameters

  • Support as proposer. Decreased complexity, increased ease-of-use, same end result. If you are not already familiar with how all this works, and you find it difficult to understand—I rest my case. ―Mandruss ☎ 02:31, 12 August 2016 (UTC)
  • Support as a very good idea. Work a few years ago replaced about ten {{coord}}-like templates with coord. This proposal further reduces the complexity of placing latitude/longitude in articles and promotes keeping it up to date. —EncMstr (talk) 04:11, 12 August 2016 (UTC)
  • Support because {{coord}} provides a consistent set of parameters, not all of which are supported by individual infoboxes' group of |coordinates_...= parameters. -- Michael Bednarek (talk) 05:02, 12 August 2016 (UTC)
  • Support because of reduced complexity and the ease of use. —Codename Lisa (talk) 07:24, 12 August 2016 (UTC)
  • Support the coordinates in infoboxes are often confusing and hard to update. So a more simple system (at least face value) is preferable above a complex system. The Banner talk 07:29, 12 August 2016 (UTC)
  • Support Yes! Please! Some of the existing IB fields are a mess and anything that will improve that situation – such as this proposal – is welcome. GenQuest "Talk to Me" 18:50, 12 August 2016 (UTC)
  • Support; easier/simpler to have one parameter for coordinates (with a possible slight performance reduction) instead of ten or eleven. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 04:32, 13 August 2016 (UTC)
  • Support: Keeping the complexity as low as possible is beneficial to new editors, and really ought to be the principal factor governing a decision. FWIW, there is more likely to be a performance reduction through the wiki-text parser having to scan ten parameters than by a Lua module unpacking one parameter internally. Either way, any performance difference is likely to be completely insignificant . --RexxS (talk) 09:48, 13 August 2016 (UTC)
  • Support: Simplifies infobox templates and provides a single, easy way to get coordinates into an article and to work with pushpin maps. It also reduces potential duplication of coordinates in articles. – Jonesey95 (talk) 11:36, 13 August 2016 (UTC)
  • Support per above arguments, and to add to the consensus for a change which'll affect many thousands of articles. --Tagishsimon (talk) 12:53, 13 August 2016 (UTC)
  • support, more compact. Frietjes (talk) 13:51, 13 August 2016 (UTC)
  • Support per Jonesey95. — TransporterMan (TALK) 19:40, 13 August 2016 (UTC)
  • Support self-evident improvement S a g a C i t y (talk) 20:20, 13 August 2016 (UTC)
  • Support - Yes, please. This should simplify things greatly. Kaldari (talk) 20:44, 13 August 2016 (UTC)
  • Support. Eminently reasonable. Infoboxes are a clunky mess; anything that simplifies them is great. Regards, James (talk/contribs)
  • Support per others. Nothing else to add. Omni Flames (talk) 10:28, 14 August 2016 (UTC)
  • Oppose. At the moment, {{Infobox NRHP}} supports a coordinates parameter, but I don't remember the last time I saw it in use; every usage of this infobox that I can remember uses |lat_degrees= and similar parameters for the remaining coordinates. {{Infobox settlement}}, with nearly half a million transclusions, also uses individual parameters. Do we really want to break some of these heavily used templates? Perhaps you're just suggesting that we change the coding so that these parameters' internal workings will change without requiring edits to every infobox that's currently using |latd= — if so, I have no objection. Nyttend (talk) 22:42, 14 August 2016 (UTC)
    The term deprecate means discourage use but continue to support for the time being, with an eye towards non-support in the distant future. I didn't work out the technical details—that was done by Jc86035—nor do I understand them, but I assume Jc86035 understands deprecation and is not going to break anything. ―Mandruss ☎ 22:50, 14 August 2016 (UTC)
    When a "deprecate?" discussion is closed as successful, it's normal to see the deprecated code removed as soon as possible. If your assumption is correct, I have no opposition, but if that's the way things happen, it will be the first time I can remember in which we continue to support the deprecated coding for one minute more than what's required to change everything. Nyttend (talk) 23:22, 14 August 2016 (UTC)
    "As soon as possible" can be interpreted as "as soon as possible without breaking anything". Yes, it would be desirable to remove the support that soon, since the issue is not completely "put to bed" until that's done. But that could take 3 months or ten years, depending on how much time editors are willing to devote to converting infobox transclusions. Presumably we'll use a tracking category to track that progress; when the category is empty, the support can safely be removed. The main thing is to get all of the infobox documentation modified quickly, lest uninformed editors create more cases that need conversion. ―Mandruss ☎ 23:36, 14 August 2016 (UTC)
  • Support I like the {{coords}} way better and if it can become universal it simplifies things a lot, especially for users learning stuff (as all the documentation will eventually be contained in one place) rather than semi-duplicated 1000x. Jason Quinn (talk) 20:04, 15 August 2016 (UTC)
  • Support Uniformity will make it easier for all editors working on geography-related articles (and other articles too, I guess). Calliopejen1 (talk) 20:45, 15 August 2016 (UTC)
  • Support. Sometimes allowing two different ways to do things shows flexibility -- some people like to do it this way, some that way, and fine. But I've always found the extra fields in this case to be confusing clutter. So the negative outweighs the positive IMO, so away with it. Herostratus (talk) 00:59, 16 August 2016 (UTC)
  • Support Leaner is better. Afernand74 (talk) 18:51, 17 August 2016 (UTC)
  • Support, a no-brainer if can be integrated into Location map template. Renata (talk) 21:43, 18 August 2016 (UTC)

RfC discussion: Deprecate named parameters

  • Comment: If you want even more simplicity, there's a function, getCoords, in Module:WikidataIB that fetches the coordinates for the article's subject from Wikidata and passes them through {{Coord}} for display in an infobox. The local editor doesn't even have to supply the coordinates. For example, using {{#invoke:WikidataIB |getCoords |name=coordinates |fetchwikidata=ALL }} in Lincoln Memorial will give you 38°53′21″N 77°03′01″W / 38.88928°N 77.05014°W / 38.88928; -77.05014. Fuller information is in the module documentation. The code in the module could easily be used to supply the coordinates to {{Location map}} as well. Not all infoboxes will want to draw their information from Wikidata, of course, but it's worth assuming that some will do that when considering making changes either to template code or to parameter usage. --RexxS (talk) 18:26, 12 August 2016 (UTC)
    • @RexxS: Mandruss dislikes this approach, as many Wikidata coordinates have incorrect resolution (apparently 12 dp), which isn't exactly ideal. {{Location map}} already does this automatically anyway if it isn't fed coordinates. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 04:38, 13 August 2016 (UTC)
      • I just don't want to make the issue any larger than necessary. If the Wikidata question is independent from the one addressed by this proposal, and it appears to be, I'd prefer to keep it separate. Too often these things grow in scope until there is no discernible consensus on anything. ―Mandruss ☎ 05:04, 13 August 2016 (UTC)
        • Wikidata coordinates have a resolution of up to 12 decimal places in both latitude and longitude, and a precision that can be set as required. If you don't set the precision, it certainly is less than ideal, but that's no different from any other set of coordinates. Lincoln Memorial, for example, has 6 dp. What application can there possibly be that requires more flexibility than that? I'm pleased that {{Location map}} is already Wikidata-aware, but doesn't that raise the question of why would we need to feed it coordinates from {{Coord}}? For those who think that making sure that changes to parameter usage retain Wikidata compatibility is irrelevant, surely they are free to ignore these comments? --RexxS (talk) 08:38, 13 August 2016 (UTC)
  • @Mandruss: I've added functionality to the module's sandbox which allows
    • injection of coordinate parameters (helpful for adding things like type:country in {{Infobox country}}; or perhaps adding region:XX based on |country= like {{Infobox station}} currently does); and
    • finding other parameters of a {{Coord}} transclusion (e.g. {{#invoke:Coordinates| coord2text | {{Coord|51|27|N|0|03|E|region:GB-GRE}} | region }} → GB-GRE).
  • Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 08:49, 13 August 2016 (UTC)
  • Comment: There will most certainly be unexpected and interesting unintended consequences if we deprecate these parameters and convert infoboxes to the new standard. We should make sure that we have a Help page, linked from the "deprecated coordinates parameters in infoboxes" category page, where discussion can unearth and document the best way to convert infoboxes and their associated pushpin maps to the new standard. – Jonesey95 (talk) 11:40, 13 August 2016 (UTC)
  • Comment (moved to Wikipedia:Village pump (idea lab)/Archive 21#Adding restrictions on maintenance and tracking category creation.) Jason Quinn (talk) 06:39, 16 August 2016 (UTC)
@Jason Quinn: That tangential and independent topic would likely get more participation (more thorough consideration) and a clearer consensus if handled separately. ―Mandruss ☎ 21:07, 15 August 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.

NOTE: Implementation coordination and tracking is at: Help:Coordinates in infoboxes. ―Mandruss ☎ 15:07, 29 August 2016 (UTC)

Wikipedia:The 10,000 Challenge

Hi there. I've started a new initiative, the Wikipedia:The 10,000 Challenge. It's a long term goal to bring about 10,000 article improvements to the UK and Ireland. Through two contests involving just six or seven weeks of editing so far we've produced over 1500 improvements. Long term if we have more people chipping it and adding articles they've edited independently as well from all areas of the UK then reaching that target is all possible. I think it would be an amazing achievement to see 10,000 article improvements by editors chipping in with whatever area of the British Isles or subject that they work on. If you support this and think you might want to contribute towards this long term please sign up in the Contributors section. No obligations, just post work on anything you feel like whenever you want, though try to avoid basic stubs if possible as we're trying to reduce the overall stub count and improve general comprehension and quality. Thanks.♦ Dr. Blofeld 13:58, 30 August 2016 (UTC)

Castles Challenge

Hello. Let me announce a new writing contest in September. It's a contest about castles of Armenia and Spain. You have the complete information here on meta. Thanks! --Millars (talk) 16:57, 30 August 2016 (UTC)

Current season template for competition TV shows

I ran this by the IRC channel, they suggested I bring it here. You know how sports teams have a link in their infobox linking to the team's current season? (See Tampa Bay Rays as an example.) Well I think competition TV shows should have the same treatment as the current season information is extremely relevant to that article as well. This is opposed to what we do now, which is a hatnote. (See America's Got Talent.) Sure, it gets the job done, but it's not as prominent. Thoughts? TrueCRaysball | #RaysUp 01:26, 1 September 2016 (UTC)

Add selected anniversaries to mobile view

I'm an OTRS volunteer responding to VRTS ticket # 2016082610016837, in which a reader pointed out that the "On this day" section is available in the desktop view of the main page, but not the mobile view of the main page.

In looking at Wikpedia's main page on my phone, I have to admit it's kind of sparse, and could use an additional section or two. Perhaps a cookie-based configuration could be used to allow users to configure what they want to see?

As an interim fix, I created the page Wikipedia:Selected anniversaries/today to provide a single page view to this section. ~Amatulić (talk) 20:48, 30 August 2016 (UTC)

My impression is that the main page is too decorated to work well in mobile view. Jo-Jo Eumerus (talk, contributions) 21:00, 30 August 2016 (UTC)
For sure, but we could put a bit in the mobile site - I know that before I got into editing, all I looked at on the main page was "In the news" and "On this day". I think we could introduce at least one of these onto mobile without too much clutter. —  crh 23  (Talk) 19:21, 31 August 2016 (UTC)
The mobile home page looks absolutely terrible, with the main problem being that it's far too sparse. The addition of OTD (and maybe one day DYK) would be a welcome improvement. Colonel Wilhelm Klink (Complaints|Mistakes) 01:32, 1 September 2016 (UTC)

Purge attack or possibly libelous usernames?

Was wondering if this is feasible, though I know this won't be without its consequences like record-keeping or references. For instance, persistent and prolific trolls whose names I will not mention are known for creating sockpuppets which either disparage, attack or outright threaten users whom they crossed paths with. I had an impersonator account's username renamed due to this as I don't want to be associated with whatever childish act the said troll has done lately. Blake Gripling (talk) 11:18, 22 August 2016 (UTC)

Personally, when someone makes a username that attacks me, I see it as a recognition of my effectiveness, but of course, it is understandable if you want it gone. Revision deletion provides the capability to hide the username making an edit, and can even hide usernames in other logs. We are generally reluctant to hide the username when it is not grossly offensive, as doing so reduces administrator accountability to the community. That said, if someone is harassing you with the contents of the usernames they are creating, it would qualify for revision deletion WP:RD3, and a private request to an administrator you know would probably work. You could also submit it as an oversight request, while I don't think it would end up qualifying to actually be oversighted (Same as revdel, but admins can't see it either), they could also perform the revision deletions, and you get the additional level of confidentiality that comes when your dealing with an oversighter. Monty845 11:41, 22 August 2016 (UTC)
What if it's a credible death threat, or if he/she is implying to plan some form of real-world harrassment, e.g. swatting or a related prank? Blake Gripling (talk) 11:50, 22 August 2016 (UTC)
In the past I have reported libelous usernames to Oversight and they have been suppressed. Not going into details, obviously, but they were along the lines of <Established user><sex crime>. Death threats and threats of violence should be immediately reported to emergency@wikimedia.org and also to Oversight or admins for RevDel if appropriate. BethNaught (talk) 11:55, 22 August 2016 (UTC)
I could see those as a waste of database space, but seeing how that could be used as evidence against the said troll, having a (discreetly stored) record of it would be handy. Blake Gripling (talk) 11:58, 22 August 2016 (UTC)
May want to bump it to Oversight anyway - meta:Oversight policy#Use does indicate that oversight can be used on attack usernames, probably because there is no way to block and hide an user other than Oversight. See also phab:T23097, a task requesting that to be rectified. Jo-Jo Eumerus (talk, contributions) 11:59, 22 August 2016 (UTC)
Just more on that front. Stewards can perform something called a "global hide" which erases the user from all logs and oversights their edits. It also erases their username from CentralAuth. It is quite useful in cases such as described by the OP. I've asked for it in a few cases so far in my wikilife. If you believe a username requires such an action you can always ping a steward on IRC. There is usually one available 24 hours a day. You can reach them at #wikimedia-stewards connect Please be aware of the WP:IRCHELP disclaimer which is relevant to all IRC channels. Particularly the part about IP address. --Majora (talk) 23:40, 22 August 2016 (UTC)
You can also always email stewards through m:Special:Contact/stewards if you'd prefer to not go on IRC. Email queries are usually answered quite quickly. For usernames which affect only one project, you can also request help from the local oversighters through the link provided above. -- Ajraddatz (talk) 18:42, 23 August 2016 (UTC)

One other theoretical possibility: Have the username changed; then have an admin hide the entry where it happened. Back when our local 'crats were handling it, I would occasionally send them an email to change such an offensive username (and if they didn't hide the rename, I could go back and do so as an admin). Per meta:Steward requests/Username changes#Private requests, this can be done from this page - and ask them to hide it, too. עוד מישהו Od Mishehu 13:43, 26 August 2016 (UTC)

That would work, especially for those names attacking a particular group, creed or organisation. We certainly do not want to let them to sow any discord here, and any such accounts would only add up to the controversy. Blake Gripling (talk) 06:36, 1 September 2016 (UTC)

Regularise spacing between paragraphs on talk pages

Rather than wait for a solution that might never materialise, I'd like to see us do something about a perennial problem on talk pages.

It is obvious at present that the spacing between paragraphs in an unindented post is different from that between "paragraphs" in an indented post.

You only have to look here.
And here to see what I mean.

Editors get into the bad habit of leaving a space between successive indented posts to improve the readbility of the thread.

Unfortunately, as anyone who reads WP:LISTGAP knows, that causes problems for screen readers.
Many of them will tell the listener that a nested set of description lists has been closed and a new nested set of description lists has been opened.

That's not ideal, so we need the ability to let pseudo-paragraphs in indented posts stand out a little more, while not closing the nested lits for a screen reader. Let's say we want them to stand out to the same extent as normal unindented paragraphs do. I tried the following in Special:MyPage/common.css:

  • .ns-talk .mw-body-content dd {margin-top:0.4em; margin-bottom:0.4em;}

Now I see each paragraph on talk pages with the same spacing whether it's indented or not. That works well to my eyes - after just a couple of minutes the talk pages now look "natural" - so much so that I didn't feel the need to tinker further by adding extra space between each person's post (just increase the margin-top for .ns-talk .mw-body-content dl). If this were considered a useful improvement I'd propose it at Mediawiki talk:Common.css, but as it's so far-reaching, I thought it would be better to get opinions from a wider audience first.

What do others feel? Would this be a sensible improvement for both regular readers and those using screen readers? --RexxS (talk) 18:37, 1 September 2016 (UTC)

I usually stuff an explicit <p>...</p> in the beginning if I feel the need for space (which has the benefit for allowing multiple paragraphs [correctly] rather than multiple list items). --Izno (talk) 19:08, 1 September 2016 (UTC)
Good! Something is needed because having no vertical space can be very confusing, and I have had my indents "corrected" by people who don't realize that indents are supposed to indicate the point being addressed. I also use the <p> trick and it is very useful, but not many know about it or want to do it, and like many, I don't bother closing the tag which probably upsets purists. Johnuniq (talk) 23:37, 1 September 2016 (UTC)
This is a great idea! I don't think there are any significant improvements that should be made to this proposal; it'll probably be ready for an RfC if a few more editors comment. Enterprisey (talk!) 20:23, 4 September 2016 (UTC)
I also explicitly use <p>...</p> markup and have been hoping others would pick it up, but they don't. If other things could be done, in the background, to clean up the listgaps problem, that would be great. Really, we shouldn't be using description lists for this stuff at all; it's an abuse of the element, but it would be hard to work around at this point, other than by having MW rendered different output (pure CSS indentation) when : markup is used in talk namespaces.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:26, 5 September 2016 (UTC)

WP help articles

I made my first edit one week ago. After a couple of tiny edits I undertook the task of rewriting an article that had languished unloved for five years, this gave me some experience of WP help articles. They are comprehensive, general, detailed, referenced, linked, and useless. I have spent nine hours over the past three days attempting to find out how to do one simple task, I feel I know less than three days ago, and had a serious urge to throw my computer out the window, or maybe hang myself. In desperation I looked on YouTube, the first video was three minute and appeared to be narrated by a 14 year old female, it was excellent. The narration went something like this "Hi guys, this is simple, just click here, click here .... you are done! Oh, and by the way, have you called your mother recently. Well now you have time to do that." This young lady did not explain anything, she just showed how to do it.

WP help articles are produced just like any other WP article. People who really know their stuff can not help improving on them, it is just that these improvements are no help at all. It is somewhat ironic that WP help articles violate one of the WP rules, the no how-to rule, so they should not be on WP.

Consider establishing a sister project. The "How to do things on Wikipedia wiki". This wiki should violate a number of WP norms Articles should not be comprehensive, general, detailed, referenced, linked. The standard for articles is that each article should be a simple, direct how-to of just one task. People do not learn from generalities. They learn one simple task, expand the range of that task then move to general principles. The rule for editing should be "do not edit this article to make it more comprehensive, general, detailed, referenced, linked, instead think of ways to make it more simple, less general, less comprehensive, less referenced, less linked. Consider splitting the article into several articles, each of which is even more simple." At the end of each article would be the sole link "Like to learn more? Click here".

When I want to find something on WP, I do not search on WP. I use Google then select the most likely WP article that Google throws up.

I have donated money to Wikipedia for some years, because for me it has always been my most trusted source of impartial information on a huge range of topics. I trust what I read on WP above any other source, so I think the rules governing WP are just great, they should just not apply to help articles. It is a wonderful project, with a huge number of dedicated people and I would like to be one of these people. Please help me to be one of these people.

Foucault (talk) 15:46, 1 September 2016 (UTC)

Foucault, first off welcome to Wikipedia! I hope you decide to stay and continue to contribute. Have you tried checking out the Wikipedia:Help_desk and the Wikipedia:Teahouse? Both of these places, especially the latter, are ideal for new editors to ask questions about Wikipedia and receive more easily understood answers geared towards their greener experience, as opposed to the general help documents which are written towards a larger range of experience with regards to audience. RegistryKey(RegEdit) 08:36, 3 September 2016 (UTC)
PatrickFoucault, there is currently a project to make videos explaining various Wikipedia tasks at meta:Grants:IEG/Motivational and educational video to introduce Wikimedia; it doesn't seem to be making progress, although the project participants have produced a large page of scripts they plan to use for the videos. Enterprisey (talk!) 20:22, 4 September 2016 (UTC)
PatrickFoucault Thanks for your magnificent post. A sense of humour is needed to understand some of the help articles- but you are not alone- welcome aboard- do post to my talk page if I can be of any help. ClemRutter (talk) 14:25, 5 September 2016 (UTC)

New Search Engine

Section heading trimmed; was "If Google can offer to write and provide a new Search Engine for Wikipedia for free, should Wikipedia take it?"

The costs for Wikipedia to invest in the maintenance and development of its own proprietary search box engine based on the availability of related open source code for general development of search boxes in the software industry has been discussed in a long thread here [1] last Spring as costing hundreds of thousands of dollars per year to Wikipedia, using up numerous hours of analyst/programmer time at the Wikipedia foundation, and still being less effective/efficient than the Google search engine, which is the industry standard for the world's best search engine. If Google can offer to write and provide a new next-generation search engine to Wikipedia free of charge and at no cost, then should Wikipedia consider taking up the offer. News reports from recent months have shown that Google has partnered on several occasions with industry leaders to incorporate its search engine gratis, for free, when requested to do so, and Wikipedia has much to gain from a better, next-generation search engine from the recognized industry leader in search technology world-wide. Should Wikipedia consider accepting a new next-generation search engine to replace the current/dated Search box engine being used at Wikipedia if it is provided free and at no cost to Wikipedia? Fountains-of-Paris (talk) 17:33, 29 August 2016 (UTC)

What would such a Google tool provide that is not already available with Google search site:wiki.riteme.site your search term here? —EncMstr (talk) 17:44, 29 August 2016 (UTC)
@EncMstr: The current Wikipedia search box fails on numerous search box parameters when there are very trivial misspellings, which by comparison the Google search box engine "corrects" immediately and gives the correct links for immediately. All the current Wikipedia search box does, in such cases of trivial misspelling, is generally to tell you that a misspelled page does not exist and then offers to you, again and again, the opportunity to create a new page for your misspelling. The Google search engine is the industry gold standard and would get you to the article which you are trying to get to more efficiently and faster. Fountains-of-Paris (talk) 18:04, 29 August 2016 (UTC)
@Fountains-of-Paris: Please try the URL I gave: It is a Google search constrained to the English Wikipedia.
Does that not provide every benefit you mention with none of the downside? Except some extra typing. —EncMstr (talk) 18:24, 29 August 2016 (UTC)
Yes, its there to click and I did click it. Are you suggesting that it be installed in the upper right hand location of the standard Wikipedia work screen in place of the current version of the Wikipedia search box engine as something which you consider superior to the current version of the Wikipedia search box? (That is different from the option I have presented above). Fountains-of-Paris (talk) 18:45, 29 August 2016 (UTC)
"industry standard for the world's best search engine." is a laughable claim. Just because it's the most widely used, does not make it the best. In addition, dependence on a single entity leads to potential points of failure, not to mention the various drawbacks already suggested both here and in the referenced discussion. Centerone (talk) 20:22, 29 August 2016 (UTC)
@Centerone: The drawbacks speaking against Wikipedia spending hundred of thousands of dollars per year on its own open-source search engine must be obvious given budgetary pressures on Wikipedia. And if you know of anyone who has a better general search engine than Google then let us know. Google is the best at it without any effective competitors. By far, their search engine is significantly better than the open-source one Wikipedia uses for its search box at present, by a significant gap. Fountains-of-Paris (talk) 20:29, 29 August 2016 (UTC)
Dan Garry from the Wikimedia Foundation already responded to and squashed your economic argument in your original discussion where he said: "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." Personally I used to like AlltheWeb it offered more accurate results than Google did. However, the issue was one of popularity. Eyeballs and critical mass counts. Economics count. Marketing counts. Management counts. You can have the best search engine and database in the world, but if people don't know about it, or don't use it, it doesn't matter if you have the better mousetrap. Just because Google is currently the most popular, it doesn't mean it's the best. This is especially an issue if you just choose to give up and accept the borg. How are we ever going to have something better if we just capitulate to defeat? Centerone (talk) 17:17, 30 August 2016 (UTC)
@Centerone: Nothing at all was "squashed" by Dan Garry other than the start-from-scratch option for WMF to do the code development by itself which is entirely different. As a matter of fact most all at WMF participating in that discussion accepted that the Google search engine was the industry leader. At that time it was not placed on the table as to Wikipedia being able to get a new next-generation search engine gratis, for free, from Google which only entered the press this last summer several months after the original discussion linked above. Dan said that the start-from-scratch option for building a new next-generation search engine was much too labor intensive to launch, however, getting one gratis from Google is a new and completely novel option. It would be given to Wikipedia gratis and at no cost if there is a consensus among editors to accept such a new, next generation search engine from the industry leader which is the Google search engine. Fountains-of-Paris (talk) 17:30, 30 August 2016 (UTC)
Google have a reputation for storing user's past searches. Would a Wiki-specific engine retain information about users' searches (both logged-in editors and ordinary readers)? If yes then we shouldn't touch it with the proverbial bargepole. Martin of Sheffield (talk) 22:29, 29 August 2016 (UTC)
@Martin of Sheffield: That's important to bring up and Google has given a working solution for this. The first option is that they offer to fully exclude the storage option if requested to do so at the start. They are also willing to install the new search engine with a full option for individual editors to select whether they want the past searches stored or if they prefer them to never be stored, completely up to the individual editor, and similar to "cookies" being either enabled or disabled from various other websites on the web. It could be left completely up to individual editors to select whether they want to store or not to store. Fountains-of-Paris (talk) 14:58, 30 August 2016 (UTC)

It's not just editors though. Would ordinary readers have the same options? One could easily imagine someone researching a medical problem at lunchtime, and then getting "appropriate" adverts all over their browsing during office work. Martin of Sheffield (talk) 15:15, 30 August 2016 (UTC)

This discussion is pointless unless and until the WMF give any indication that they'd seriously consider it, since a decision of this nature would need to be taken at board level. While this may well save the WMF money in immediate costs, formal collaboration with one of the world's most loathed companies would cause an immediate and permanent drop in donor funds as well as the resignation of large swathes of the editor base, so I find it vanishingly unlikely that the WMF would entertain the notion for an instant. "Anyone can edit" is one of Wikipedia/Wikimedia's core values, and I very much doubt Google is going to put the source code for the algorithms on which their business depends into the public domain. Bear in mind that we don't even allow mp4 and wmv video because they make use of proprietary technology, and handing control of our search function over to a multinational corporation would be orders of magnitude more contentious; if it didn't lead to the kind of editor exodus, content forking and gradual eclipse of the initial project by the free-content alternative which happened at Wikitravel, I'd be surprised. ‑ Iridescent 15:20, 30 August 2016 (UTC)
@Iridescent: That's well stated, and previous editors at WMF have indicated that they would recognize that Google is an industry leader in the field of search engines in the link which I provided above from several months ago here[2]. The community of editors here on the Village Pump can make suggestions to WMF if there is consensus among Wikipedia editors that large cost savings to WMF and a new next-generation search engine provided gratis, for free, would be useful and an advantage to Wikipedia editors. Fountains-of-Paris (talk) 15:35, 30 August 2016 (UTC)
Google/Alphabet is not a company known for its public spirit, and won't do anything unless they can see a potential profit in it. If they're not harvesting either search data or user information (which would have to be a pre-requisite of any agreement), not getting a "brought to you by Google" advert on the search box or any other Google/Alphabet branding on Wikipedia (which will certainly never happen), and not permitted to show adverts in the search results (ditto) what possible reason would they have for doing this, especially given that (a) we've just kicked someone off the board primarily owing to his association with Google, and (b) a stand-alone Wikipedia search function directly competes with Google's core business? ‑ Iridescent 16:00, 30 August 2016 (UTC)
@Iridescent: Google is an established benefactor of Wikipedia, for which Wikipedia is and ought to be quite grateful (I can provide the link if you need it since it is in the long tread I previously provided above). During the summer, Google has accepted requests from FORTUNE 500 firms requesting that Google install working versions of their search engine on their computer and mobile products which Google has agreed to do and has provided (for example, Samsung, etc). As Google is already a benefactor of Wikipedia, this is all in the favor of Wikipedia getting a new next-generation search engine gratis and for free if there is a consensus to receive it among the editors at Wikipedia. Fountains-of-Paris (talk) 16:10, 30 August 2016 (UTC)
Iridcescent pointed this out, but you didn't seem to notice: gratis is not the same as free. Google might give us something free as in beer, but unless they gave us something free as in freedom, it's off the table. When Google agrees to release its search algorithm and software under a free and open license, do let us know. BethNaught (talk) 17:55, 30 August 2016 (UTC)
@BethNaught: The comment is that Google has offered other Fortune 500 firms to develop and install their search engine without cost as part of their corporate outreach. Since Google is a benefactor of Wikipedia, which is grateful for this philanthropy, it makes every kind of sense to accept a generous offer for a new next-generation search engine. If its good enough for Samsung to accept, which is a rival to Google for investors capital, then with so much more readiness can Wikipedia accept a generous and gracious new next-generation search engine from Google gratis, for free, for the benefit of Wikipedia's many editors. Fountains-of-Paris (talk) 18:06, 30 August 2016 (UTC)

I will say this one more time: Wikimedia is about free knowledge: free not just as in cost, but free as in freedom. That means that to the greatest extent possible Wikimedia uses free software. We have a free software search engine. We are not going to replace it with a non-free (as in freedom, whatever the monetary cost) search engine. That is an absolute blocker. If you will refuse to hear that, there is no point in either you or I continuing this discussion. BethNaught (talk) 18:11, 30 August 2016 (UTC)

Your edit appears to refer to open-source software in an indirect manner although you do not call it that. There is generally very little that is "free" about open source software which often requires extensive labor intensive programmer/analyst support to first get working and then to constantly maintain. If your edit is referring to Wikipedia as only using open-source software then this is clearly off the mark since Wikipedia editors are dependent on a large number on non-open source software systems for their day-to-day editing such as JSTOR and various off-line Word Processors which editors use for creating new articles off-line and then importing them back to Wikipedia. In the most friendly way possible, if you do not know the technical difference of what you refer to as "free" software and open-source software then just ask any one of your edit friends at Wikipedia. Open-source software is not free, and it is often labor intensive to support as evidenced by the hundreds of thousands of dollars Wikipedia spends annually, every year, to support the use of open-source software for maintaining its version of its regular search engine. A offer for a new next-generation search engine from Google for use at Wikipedia would be a terrific advantage for Wikipedia which would save Wikipedia hundreds of thousands of dollars each year which Wikipedia currently spends on maintaining "open-source" software for its regular search engine. Fountains-of-Paris (talk) 18:26, 30 August 2016 (UTC)

As the person who rewrote our search capabilities a few years back, I want to state that your assessment of how we do search is wildly off the mark. We do not spend hundreds of thousands of dollars maintaining our search engine software...it largely works off the shelf from Elasticsearch with just some config tweaks and a plugin we wrote :) Where the labor (and money) goes into is the MediaWiki extension middleware: the components required to plug a search engine into MediaWiki and make it behave in a way that our readers and editors expect and find useful. This would be the same case even if we got a replacement for Elasticsearch that was provided by Google. Now: could Google's search engine do a better job at relevance and so forth than we get out of Elastic? Probably! But to state that Google could provide something that drops in and saves us a tons of money on engineering resources is just incorrect and greatly misunderstands how the MediaWiki ecosystem works. Rather than trying to start what is basically a non-starter proposal, a much better use of everyone's time would be to find ways we can improve our relevancy and hopefully contribute those improvements back upstream to Elasticsearch itself. A final note: when we say that Wikipedia as only using open-source software we don't refer to the editors' choice of browsers or text editors or things like that: it's referring to the stack of technology we use to run the sites. The guiding principles cover this, specifically "As an organization, we strive to use open source tools over proprietary ones, although we use proprietary or closed tools (such as software, operating systems, etc.) where there is currently no open-source tool that will effectively meet our needs." Currently, to the best of my knowledge, the only parts of our stack that are closed source are server BIOSes/mgmt consoles and the operating system(s) on our network gear. This is important, because as that same section points out, we want people to be able to fork us without relying on secret sauce that others cannot have. ^demon[omg plz] 03:44, 31 August 2016 (UTC)
Thank you for that clarification and reassurance. Martin of Sheffield (talk) 08:44, 31 August 2016 (UTC)
Shameless plug - if folks are interested in helping improve wiki search results, please take a look at a grading tool the search team developed called Discernatron. You can judge how relevant a set of results are and help inform the team on how to improve our results. CKoerner (WMF) (talk) 13:56, 31 August 2016 (UTC)
@^demon: The assessment of cost incurred by WMF is based on WMF management indicating that 4 programmers/analysts are currently assigned to oversee and maintain the current search engine at Wikipedia with another manager assigned administrative duties to organize this effort. These 5 programmers/analysts/managers which along with administrative costs added on top means that WMF is paying about five hundred thousand dollars per year, every year to maintain its current "open-source" search engine. This was all covered in the thread I linked above and is a huge yearly expense to WMF paid year after year by Wikipedia discussed on the thread here [3]. Getting a new next-generation search engine from Google given to Wikipedia gratis, for free, represents a huge savings every year for Wikipedia. The Google search engine is the gold standard of the industry and would very significantly enhance search engine performance for everyone at Wikipedia and for Wikipedia's users. Using Wikipedia's current "open-source" search engine simply because its open-source misses all the advantages that getting a new next-generation search engine from the industry leaders at Google given gratis, for free, would offer. This appears to be a winning option for all at Wikipedia and a very large scale saving in Wikipedia's annual expenses to maintain its own less efficient search engine currently in operation. Going with the industry leaders at Google and a new next-generation search engine seems a strong and effective option for future improvement and enhancement of Wikipedia. Fountains-of-Paris (talk) 14:49, 31 August 2016 (UTC)
I'm not saying we don't have those costs, I'm saying they're not spent how you think they are and Google donating to us would not make those costs magically go away. I also explained why things need to be free as both speech and beer (and not just beer). Either you're not understanding what's being said or you're choosing to ignore it because you're trying to belabor a point. I shall not engage on this further. ^demon[omg plz] 15:42, 31 August 2016 (UTC)
There's no reason for you to comment if you're not following it. Use of open-source software just because its open-source and superficially "freely" available to download does not mean that it is the best product out there, or that it is the best choice for Wikipedia's future development and improvement. Google has the best search engine in the industry and as a benefactor to Wikipedia they can make a version of their search engine tailored to the needs of Wikipedia's editors and readers. The open-source search engine currently in use at Wikipedia is not the best choice out there: its merely adequate with many defects. Google does have the best choice out there and can make available a new next-generation search engine for Wikipedia at no cost, gratis, and for free to Wikipedia. Why would anyone defend the use of less efficient search engines of any kind when a better version of a new next-generation search engine can enhance and improve editing at Wikipedia. It is a better choice than continuing to use open-source products which are merely adequate and which incur large overhead costs to Wikipedia in order to maintain. Go with the best version of the search engine available from Google since it can be available gratis, for free, for Wikipedia's numerous editors and readers. Fountains-of-Paris (talk) 15:57, 31 August 2016 (UTC)

Section break for advantages of a new next-generation search engine for Wikipedia

Please go to the main page, and click the word "free" in "free encyclopedia". A free encyclopedia, as a free cultural work with exclusively copylefted and public domain content and using only free/libre/open source software, is our goal. Your proposal, even if it would save money or make the search better (which as explained above, it wouldn't), would not contribute to this goal. --Yair rand (talk) 17:14, 31 August 2016 (UTC)

@Yair rand: Thanks for your comment which brings up the important issue of Wikipedia's very strong commitment to free access to its encyclopedia conten. The introduction of a new next-generation search engine from Google given to Wikipedia gratis, and for free, is independent from anything that would impede access to the free encyclopedia content in any way and it would only enhance that access and make it much better. It is apples and oranges to claim that access to all the free encyclopedia content at Wikipedia would in any way be compromised or impeded by the use of the internal application which enhances access to all of that free encyclopedia content at Wikipedia. As already covered above, many editors at Wikipedia use non-open-source software such as JSTOR and various Word Processors off-line in order to write and research articles written for use at Wikipedia. The availability of new next generation search engine from Google written for Wikipedia would be of large benefit to enhance further the improved access to the free encyclopedia content of Wikipedia which in large measure is and should remain Wikipedia's claim to its mass popularity. Information like air wants to be free. The availability of a new next generation search engine for Wikipedia developed gratis, and for free, would be a large advantage to enhancing access to Wikipedia's free encyclopedia of knowledge. Fountains-of-Paris (talk) 18:53, 31 August 2016 (UTC)
Wikipedia editors using closed-source software is irrelevant. Please read Wikipedia:Free encyclopedia. Free means "that people are not forced to use proprietary software in order to read, modify, and redistribute it as they see fit." --Yair rand (talk) 21:36, 31 August 2016 (UTC)
No one is forcing you to use JSTOR or forcing you to use proprietary Word Processors at your home desktop in order to write articles which are then imported into Wikipedia by hundreds and hundreds of editors who use those proprietary products. Your point simply is apples and oranges and has nothing to doing with the free access to the content of the Wikipedia open source encyclopedia. A new next generation Search engine for Wikipedia given to Wikipedia gratis, and for free, would only make access to the free encyclopedia content that much more improved and enhanced. Even more, the savings of five hundred thousand dollars in annual software support expenses on a year by year basis makes this option for Wikipedia. Wikipedia extends great effort in asking for donations of 5 and 10 dollars, and here is an opportunity to effectively gain five hundred thousand dollars per year in Wikipedia savings if a free Google search engine is installed to improve the currently outdated version of the search engine still in use today. Five hundred thousand dollars per year added to Wikipedia's pocketbook year-after-year. Fountains-of-Paris (talk) 14:54, 1 September 2016 (UTC)
As the WMF have already told you, this is not going to happen, since it would be a gross breach of Wikipedia's founding principles. Let it go. ‑ Iridescent 15:49, 6 September 2016 (UTC)
Yep. You said we could go to the WMF if there was a consensus here in favor. There is indeed a consensus here—a consensus against. You keep repeating "gratis, for free", but that's not what we mean by free. We mean free as in speech, not free as in beer. Google is not going to open source their search engine code (or, for that matter, let anyone within a mile of it without signing 15 NDAs). It would be a waste of resources to even try for that, since it's never going to happen. Our resources are best put toward making the free (as in speech) alternatives as good as they can be. And those search technologies are open source, so if you'd like to help in developing them, you can, and I'm sure your efforts would be most welcome. Your time would be better spent on that than continuing to try to push this. Seraphimblade Talk to me 16:18, 6 September 2016 (UTC)

User Pages

My proposal is a simple one, that for ease of pinging, or any other way of notifying a person, you would be able to tell immediately in the preview (or after posting if you dont preview.) If you have in fact tagged a person. To get to my proposal, basically my proposal is to request that people either make a user page, regardless of content, just have it exist, or else as can be seen in User:Nev1, make the user page a redirect to your talk page. Thank you. Iazyges (talk) 04:49, 6 September 2016 (UTC)

@Iazyges: You may be interested this from Tech News: 2016-36. You will be able to get a notification when you successfully send out a mention to someone or be told if they did not get a notification. This will be opt-in. (phab:T144181, phab:T143101) — JJMC89 (T·C) 04:58, 6 September 2016 (UTC)
@JJMC89: Well, I suppose my proposal is more of an aesthetically pleasing one alone then. Iazyges (talk 05:01, 6 September 2016 (UTC)
User:Iazyges: For a notification to work, it is not necessary for a user page to exist, merely that it be linked to - even if that is a redlink. --Redrose64 (talk) 11:03, 6 September 2016 (UTC)
User:Redrose64, I understand this, I stated the ease of pinging as being for the one pinging. Iazyges (talk) 11:46, 6 September 2016 (UTC)
I did not get you. What kind of ease are you talking about here? Writing [[User:Example]] will remain same whether His user page exists or not. The only diff will be of a blue and red link which doesn't matter as both send Pings! Do you want the removal of red links ? I don't think that will be liked by one who will be forced to create a user page just for the sake that a red link doesn't appear. VarunFEB2003 12:57, 6 September 2016 (UTC)
@VarunFEB2003: Yes, that is what I would like, it is convenient, and aesthetically pleasing, and requires minimal effort to create the page, even if it's blank. Iazyges (talk) 22:00, 6 September 2016 (UTC)

@Iazyges: I don't think that will be liked by one who will be forced to create a user page just for the sake that a red link doesn't appear. Moreover it might become a bit bitty when forcing new users to create user pages, eventually they might leave! VarunFEB2003 06:01, 7 September 2016 (UTC)

@VarunFEB2003: We could use a bot to just make a blank page for everyone who doesn't have one (Although the lag would be monumental) or just have people click two buttons. Iazyges (talk) 06:03, 7 September 2016 (UTC)
@Iazyges: The thing is that there are a number of long term, constructive editors who never create a user page. That doesn't stop them from being excellent editors. Here is a good example. I don't think they would like being forced to have a user page, and the bottom line is that we're not going to change that just because one user doesn't think it looks pretty. Omni Flames (talk) 07:44, 7 September 2016 (UTC)
I see no need to force User pages to exist. Regarding knowing whether you have successfully pinged someone, I was recently discussing this with Devs on Phabricator. The current situation is:
  1. The WMF is currently working on an opt-in which will add an item to your notification list whenever you ping someone. In my opinion this has very limited value. Either you have to check your Notification panel after every message-with-a-ping, or you occasionally check the Notification panel and there's no way to realistically remember every ping that was supposed be sent but wasn't.
  2. There is a Phabricator request to show pings when you get the "page saved" message. However the way the software is set up the ping-information isn't available until about 1/3 of a second after page save, and they don't want to delay the "page saved" message. I asked if they could send the "page saved" message, keep the connection open, and send the ping information ~1/3 of a second later when it's available. They said that was an interesting possibility. However I don't think they are actively working on it.
  3. I also asked about the possibility of showing ping information on page-preview. As I recall, the answer was "maybe" and that it was an interesting idea. But again, it doesn't seem like this is something they are actively working on.
We could try run an RFC asking for action on this, but probably the easiest and most reliable way to get this done would be to submit it during the 2016_Community_Wishlist_Survey in November. Alsee (talk) 10:12, 7 September 2016 (UTC)

Current season template for competition TV shows (retry)

I tried getting input on this last week, but no one commented and it got archived. You know how sports teams have a link in their infobox linking to the team's current season? (See Tampa Bay Rays as an example.) Well I think competition TV shows should have the same treatment as the current season information is extremely relevant to that article as well. This is opposed to what we do now, which is a hatnote. (See America's Got Talent.) Sure, it gets the job done, but it's not as prominent. Thoughts? TrueCRaysball | #RaysUp 08:00, 8 September 2016 (UTC)

You are more likely to get better feedback at WT:TV. — JJMC89 (T·C) 15:32, 8 September 2016 (UTC)

Readers contributions

Hello everyone, in case you have not yet seen it, there is a page dedicated to discussing ideas for products, where readers can make contributions that are valuable to the mission and helpful to our editors. Please check and share your comments. Thanks!--Melamrawy (WMF) (talk) 17:16, 8 September 2016 (UTC)

CheckUser and Oversight appointments 2016: Announcement

The Arbitration Committee has resolved to perform a round of Checkuser and Oversight appointments. The arbitrators overseeing this will be DeltaQuad and Opabinia regalis. This year, the usernames of all applicants will be shared with the Functionaries team, and they will be requested to assist in the vetting process.

The Committee is bound by a Wikimedia Foundation policy that only those editors who have passed an RfA or equivalent process may be appointed, therefore only administrators may be considered. The Committee encourages interested administrators to apply, and invites holders of one tool to apply for the other.

The timeline shall be as follows:

  • 9th September: Request for candidates to apply.
  • 23:59 UTC, 20th September: Candidate submissions close, vetting begins.
  • 21st September: The Arbitration Committee and current Functionaries will vet the candidates.
  • 23rd September: Vetting ends, successful candidates contacted by the 26th September.
  • 26th September: Candidates published on-wiki, community feedback invited.
  • 23:59 UTC, 8th October: Community comments end.
  • By 19th October: Appointed candidates announced

For the Arbitration Committee, -- Amanda (aka DQ) 06:00, 9 September 2016 (UTC)

Discuss this

WMF Survey on the future of Flow

The WMF is running a survey regarding Flow, which they hope to eventually install instead of Talk pages. The notice and survey link are at Wikipedia_talk:Flow#Flow_survey_released. Any discussion should probably be centralized over there. Alsee (talk) 20:23, 8 September 2016 (UTC)

There is at the moment no plan to install Flow instead of the current system of talk pages. The current work is to support communities which are using Flow as a user-to-user discussion system (i.e. on volunteers talk pages). The official announcement for that survey has more details. Trizek (WMF) (talk) 15:35, 9 September 2016 (UTC)

Extended confirmed users

I propose that the extended confirmed user access level only be given through WP:PERM, and not be automatically granted to anyone who has 30 days tenure and at least 500 edits. This means that admins will be able to decide who does and who doesn't get the extended confirmed user access level; the advantage being that admins will be able to stop socks, vandals, and other disruptive editors from being granted extended confirmed user rights. —MartinZ02 (talk) 13:57, 27 August 2016 (UTC)

I wish there was a way to "remove" autogranted user-rights like extended and autoconfirmed. blocking shouldn't be the only recourse. But that said, I do like that such things are auto-granted. We just should be able to remove them too. How about if the devs add something which allows an admin to flag an account to not receive autogranted user-rights? This would limit registered accounts to the base "User", and require someone to thenceforth eith to manually add the user-rights, or to remove the flag (similar to unblocking). - jc37 14:30, 27 August 2016 (UTC)
@Jc37: Extended confirmed can be removed by admims at Special:UserRights. Community consensus for revoking is another thing. — JJMC89 (T·C) 22:35, 27 August 2016 (UTC)
If a vandal manages to do 500 edits and lasts thirty days then them having extended confirmed permission is the least of our worries, and won't stop us blocking them. When we find accounts that are breaching the sock puppetry policy we block them, but short of using check user (and no we aren't going to checkuser all accounts after 500 edits) there isn't much that could be done about that at wp:Perm. So the only bit of your proposal we could try to enact is some way of not giving the right to editors who are believed to be disruptive but not sufficiently disruptive to be blocked. Aside from the timesink that would be (and no we don't have the spare admins to take on such work), a bit like RFA except for hundreds of editors, I can't see us easily agreeing such a criteria and if we did we'd then have the RFA problem - loads of qualified candidates who aren't volunteering to run the gauntlet. Better by far for such a minor userright that we issue it automatically. ϢereSpielChequers 20:16, 27 August 2016 (UTC)
I'm afraid to say that I don't think this is a good idea. If a vandal actually goes to the trouble of making 500 edits and is a user for at least 30 days, then there will be little problem blocking said vandal; it's not like it is a simple task to get a new account to 500 edits and wait 30 days. Dustin (talk) 23:53, 3 September 2016 (UTC)
It's actually easier then you think; you can just edit your user‐page 500 times and wait 30 days. —MartinZ02 (talk) 19:28, 4 September 2016 (UTC)
Say a user decided to do something like that; if a new user just did then undid the same edit on his/her userpage, then he/she would look suspicious. The edits would appear on Special:RecentChanges, and someone would probably notice at some point. If said user decided to instead make less conspicuous userpage edits, then it would take longer, and it'd still be suspicious that a user is making hundreds of userpage edits without editing articles. The way things currently are, it's already pretty futile for a vandal to waste a huge amount of time making hundreds of edits with multiple accounts. If the user actually did all that userpage stuff then decided to start being disruptive on a page requiring editors to be extended-confirmed, it'd become obvious what the user was up to pretty quickly and a block would be handed out. Dustin (talk) 19:49, 4 September 2016 (UTC)
The problem is that the user would be blocked after doing something disruptive. However, if everyone has to go through WP:PERM to get extended confirmed rights, we can force disruptive editors to contribute to Wikipedia if they want to disrupt extended confirmed pages. —MartinZ02 (talk) 20:47, 4 September 2016 (UTC)
I can see a lot of problems resulting from making people undergo non-automated scrutiny for extended autoconfirmed. I expect requirements creep and a lot of participation from would-be article owners. On the other hand, removal of the status seems like a good option for responding to low-level disruption, and especially for gaming the automated process. I recall when 500/30 was new, a few people were topic banned for gaming it with useless minor edits. Rhoark (talk) 15:42, 9 September 2016 (UTC)

Proposal for a confidential COI mailing list

I want to thank everyone who contributed to this discussion. It is very clear that the consensus is against this proposal. Nonetheless, I think that the discussion has been very useful, in that it clarified the current views of the community about several related issues. There is a clear consensus that, except in extraordinary circumstances, determination of COI editing should be based upon the characteristics of the edits, and not upon the possible identity or biases of the editor making those edits. There continues to be a clear consensus against editors investigating one another. And there is a clear consensus against private evaluation of COI-related conduct, as opposed to open discussion on-site. --Tryptofish (talk) 00:33, 12 September 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.

Should the proposal at Wikipedia:COI List be enacted? --Tryptofish (talk) 21:20, 16 August 2016 (UTC)

Support

  1. Support as proposer. If one looks at WT:Harassment, it is clear that the community has divided views about how to reconcile the importance of protecting private information about users, according to the WP:Outing policy, with the importance of protecting articles from material that violates the WP:COI guideline and the terms of use on undisclosed paid editing. Editors need to be able to present evidence without being criticized for making accusations without evidence, while also not violating the harassment policy. This proposal grew out of the discussion here, and is a way to reconcile those needs without creating new bureaucracy, by using existing Functionaries. --Tryptofish (talk) 21:20, 16 August 2016 (UTC)
    I've been thinking about the concerns among some editors about how this would create some sort of sooooper secrit process. It's worth looking at the existing policy at WP:Outing, the last paragraph, the paragraph that begins: Nothing in this policy prohibits the emailing of personal information about editors to individual administrators, functionaries, or arbitrators.... As things stand right now, anyone can email any kind of accusation to an individual administrator chosen to be sympathetic, and that administrator can go right ahead and block the accused user on the basis of the private email. The blocked user does not get to find out what the accusation was, and there is no other review before the block. That's expressly permitted right now, if an administrator believes that there is a serious COI problem. Isn't the proposal here better than that? --Tryptofish (talk) 17:54, 17 August 2016 (UTC)
    Improper blocks, including abusive blocks, are reviewable at ANI. The lack of formal review of allegations of improper blocking is a concern, but it is not as serious as a group of admins soliciting personal information with an implied promise to act on that information. An individual receiving private information is better than a group receiving private information, because improper use of private information can be pinned on the individual, but not on the group. --SmokeyJoe (talk) 04:06, 26 August 2016 (UTC)
    I realize that there is no way this proposal is going to pass, but I would like to correct you that the proposal does not allow sending such material to admins who are not functionaries, and in fact expressly prohibits it. And it also specifies that users should not be blocked as a result of an email, but instead, the normal on-site processes should be followed. --Tryptofish (talk) 21:23, 26 August 2016 (UTC)
    Never thought that. The difficult question is "what is a functionary?" Wikipedia:Functionaries is not very tight. This proposal was to solicit personal information sent to them, with unclear limits on the downstream controls on information supplied. It begs to be leaked with plausible deniability by each individual. --SmokeyJoe (talk) 02:13, 27 August 2016 (UTC)
    Thanks for clarifying that. When you referred to "a group of admins", I thought that was what you meant. --Tryptofish (talk) 20:39, 27 August 2016 (UTC)
    It was mis-phrased, it should have been written without of admins, now struck. It does remind me again of workplace grievance procedures. Typically, the information, the identities of people involved, in the initial stages, everything is confidential. The way to achieve this, the *only* way in my opinion, is to have one grievance officer meet the complainant and receive the initial information, and for that grievance officer to guarantee confidentiality and discretion. There is no "Grievance Officer email distribution list". Indeed, even the process for meeting the grievance officer is anonymous and without records. If the grievance is found to have merit, the trained and empowered grievance officer then does what is required in making further enquiries and representations. I suggest that this sort of model is the only way to deal with solicitation of personal information. --SmokeyJoe (talk) 00:47, 29 August 2016 (UTC)
    Thanks. I really do appreciate this discussion. Even though I doubt that the proposal will pass, I think that the discussion has been very useful in clarifying what the community does not want. --Tryptofish (talk) 15:29, 29 August 2016 (UTC)
  2. Support My experience in dealing with these situations both as an admin. and as an arb has shown me that there is a real need for this. Most COI situations do not actually require this, but some do. There is no current way of handling the situation properly on-wiki; people attempting to have often inadvertently or in their enthusiasm run afoul of our rules about outing and similar policies. The only other potential resource at present is arb com, and as is evident from previous discussions, the majority of arbs do not want to deal with this problem. There are however a few arbs and other functionaries who are willing to deal with it. They are already authorized by the foundation and the community to deal with private information, and are accustomed to handling it properly. The only question is whether the available &willing functionaries are sufficient to handle the expected work: I think they probably are, because most COI problems are so obvious that no confidential information is required. This list will in such cases simply serve as a way of telling people that it is acceptable to go ahead on the basis of obvious content and behavior, but even this is helpful in giving them a safe place to send information and thus preventing them from violating policy. In those cases where private information is needed, the people on the list will be able to deal with it. If it should prove inadequate, we will find this out and be better able to suggest other solutions; if it is unnecessary,we will find this out also. Unless we try,we will not know. DGG ( talk ) 22:30, 16 August 2016 (UTC)
    If there is a need for this, apparently by your words only in a small fraction of cases, let the Arbs take responsibility. The functionaries email distribution (Wikipedia:COI_List#Membership) is, to the community of editors, an uncontrolled membership, inclusive of a number of ex officio members, and in not subject to community scrutiny. The proposal is to invite submissions of private information from editors about other editors, and that is a dangerous thing. --SmokeyJoe (talk) 04:06, 26 August 2016 (UTC)
    My understanding is that ArbCom does not want to do this. As for membership being uncontrolled, it is ArbCom that determines functionary status, and members have to be in good standing. --Tryptofish (talk) 21:23, 26 August 2016 (UTC)
  3. Support This suggestion would seem to both respect the privacy of users while also allowing the investigation of these conflicts of interest. If CoI editors were perfectly forthright about their activities we wouldn't have this problem. If we don't properly control CoI editors Wikipedia will become more slanted than it already is. Chris Troutman (talk) 22:52, 16 August 2016 (UTC)
  4. Support - I had my qualms, but after discussion with Tryptofish I do think this can square the circle between our extreme (but I do understand why they're necessary, I've been on the sharp end of the vicious nutcases who make them necessary) outing policies and trying to keep the wiki from being drowned in spam. A list where we can flag actual blatantly advertising self-revealing spammers without doing so on wiki is just the ticket - David Gerard (talk) 00:06, 17 August 2016 (UTC)
    The discussion with me is at WT:COI List. --Tryptofish (talk) 00:15, 17 August 2016 (UTC)
    Blatantly advertising users/spammers can be identified by the nature of the content submitted, warned, and blocked, all without any need of inquiry into their identity. COI only becomes relevant when reasonable editors could differ as to whether content is actually biased, thus the need to prove bias through identity and affiliations. DavidLeighEllis (talk) 00:11, 17 August 2016 (UTC)
    I'm talking about (to be amazingly hypothetical!) people who write bad articles with puffed-up press-release sourcing that they defend ridiculously, then if you happened to search on their Wikipedia username you'd discover their personal site where they literally advertise Wikipedia content marketing as something you should hire them for (though sadly, without a helpful list of clients). As things stand, it's a violation of the outing policies to say "smoking gun, no wonder his work is so relentlessly terrible with perfect formatting, ban this spammy bounder and delete his work like Carthage". So I do think we need a list for if this totally hypothetical circumstance were ever to, say, pop up in my editing - David Gerard (talk) 00:21, 17 August 2016 (UTC)
    Yes, and I think it's worth emphasizing that undisclosed paid editors can be both prolific writers and terribly insistent in their self-defense. It's not like telling good-faith editors to just undo spammy content on the merits will be practicable in the long-term. I asked in the discussion section below about deprecating WP:COIN, but seriously, that is neither practical nor desirable. --Tryptofish (talk) 00:29, 17 August 2016 (UTC)

Oppose

  1. Preliminary stance; I have concerns that the benefit in knowing that someone has a conflict of interest vs. not knowing it is not high enough to justify this system, with all the associated procedures. Jo-Jo Eumerus (talk, contributions) 21:37, 16 August 2016 (UTC)
    While I stand by my rationale for opposing the proposal, I'd like to disagree with the complaints about lack of transparency; the existing policies about privacy and the like (such as WP:OUTING) more or less demand that certain kinds of evidence be handled in a private manner. Maybe some keen person can find a way to reconcile both aims but I am dubious. Also, the proposed system is only tasked with giving out indicators (such as  Likely) and warnings, not with enacting any sanctions, so unless the scope of the proposal is broadened Star Chambers will not arise. Jo-Jo Eumerus (talk, contributions) 07:34, 24 August 2016 (UTC)
  2. The last thing Wikipedia needs is yet another clique of self-appointed Power Users; being able to see users' conflicts of interest is a feature, not a bug. For those rare occasions where sooper-sekrit rulings are actually unavoidable, this is why we have arbs, checkusers and oversighters who have to at least be vetted in some way as to whether the community trusts them to handle sensitive information, and can have that privilege withdrawn if they misuse it. Adding a hierarchical structure within the existing functionary system is not going to end well; there aren't enough functionaries to make it necessary (those who aren't interested in a topic just ignore the emails on that topic), and explicitly splitting off "outsiders" and "insiders" within the structure is a recipe for dysfunction. It's hard enough getting the arbs and CUs to cooperate rather than looking down on each other. ‑ Iridescent 22:01, 16 August 2016 (UTC)
    Please look more carefully: the proposal does not create such a new group! --Tryptofish (talk) 22:02, 16 August 2016 (UTC)
    Note I was expanding my comment as Tryptofish replied; the version to which he's replying is here. And yes, it does create a new group of superusers from within the existing functionaries, unless I'm seriously misreading it. ‑ Iridescent 22:06, 16 August 2016 (UTC)
    I do think you are misreading it to some extent. Nobody gains some new privilege that they do not already have. And you incorrectly describe things like people who ignore emails. --Tryptofish (talk) 22:11, 16 August 2016 (UTC)
  3. We don't need any more secret Star Chamber proceedings. DavidLeighEllis (talk) 23:15, 16 August 2016 (UTC)
    Look, I really mean this: There is nothing remotely like that being proposed here. The mailing list would not even make a determination that a COI exists! It would simply verify that there is or is not evidence that would make a COI "likely", and then all subsequent determinations would be made on-Wiki, by the existing procedures. --Tryptofish (talk) 23:19, 16 August 2016 (UTC)
    That is why the proposal is essentially like a Star Chamber, since determination of guilt, likely COI, is made using secret evidence off-wiki. Only the punishment phase of the proceedings would be public. The only way to refute a judgment of likely COI would be to fully disclose one's real life identity, marriage or other long term romantic relationships, employer, and group affiliations in some verifiable way. However, this isn't an option for many editors, who are editing under pseudonyms to avoid the depredations of trolls. DavidLeighEllis (talk) 23:33, 16 August 2016 (UTC)
    Aside from the fact that there is an appeal process (in which one does not publicly disclose any of those things), you need to ask yourself how someone accused of COI defends themselves now, without self-outing. The proposal actually makes it easier for the accused to avoid being outed. Inaccurate emotional terms like star chamber are really unhelpful here. --Tryptofish (talk) 23:39, 16 August 2016 (UTC)
    And you are wrong (as I already said above) when you say that the mailing list would make a determination of guilt. That is not what is being proposed. And "punishment" is more hyperbole. If editors want to oppose the proposal that is actually being made, that's appropriate, but editors should not make up a fictitious proposal to oppose. --Tryptofish (talk) 23:44, 16 August 2016 (UTC)
    Actually, I stated that "determination of guilt, likely COI, is made using secret evidence off-wiki". That is the essence of the proposal being made, isn't it? Then the judgments of guilt by the functionaries who received the secret evidence get posted on-wiki without substantiation. And it is possible to defend against a public COI accusation using current procedures without self-outing, simply by critiquing the sufficiency of the evidence posted. Use of secret evidence, presented even to the accused in only redacted form, should be reserved for the editors elected to the job, that is, Arbcom. DavidLeighEllis (talk) 00:00, 17 August 2016 (UTC)
    I've been thinking hard about that, and I might agree if this were going to lead to a decision to block or ban someone. But it would at most lead to reverting someone's edits and/or deleting some pages they created, along with maybe placing some templates about COI on talk pages (unless the user then edit warred to undo all that, etc.). Oversighters and Checkusers are not elected, but they are vetted by the community and appointed by the elected Arbs, for the specific purpose of being able to exercise good judgment with confidential information. And a user who feels unfairly treated does have the ability to appeal to ArbCom. --Tryptofish (talk) 01:09, 17 August 2016 (UTC)
    The alternative is the present situation, where we block based on guesswork. Of course, we don't usually say "coi" in the block, but "creating inappropriate pages" or "using WP for advertising" or "advertising-only account" or one of the various equivalents. I'll use guesswork (known more formally as "behavioral evidence", but guesswork is what it really amounts to, but I'd rather know what I'm doing. It's similar to spi, where wee may decide to block despite the checkuser results, but at least we have them much of the time. DGG ( talk ) 01:19, 17 August 2016 (UTC)
    Present evidence on-wiki and you will be blocked for WP:OUTING. Present evidence off-wiki and the community will object to secret trials. The logical solution is to mark WP:COI as "historical" as it is unenforceable in the present environment. Shock Brigade Harvester Boris (talk) 00:44, 17 August 2016 (UTC)
  4. Oppose as inconsistent with present community standards. For now, the community's view is that WP:OUTING trumps all else. Something like this will fly only after COI does major damage to en.wp's credibility. Shock Brigade Harvester Boris (talk) 23:47, 16 August 2016 (UTC)
  5. Oppose per Iridescent. 23:57, 16 August 2016 (UTC)Ealdgyth - Talk
  6. Oppose on several grounds. First, this is a solution in search of a problem: when is it necessary to prove that someone has a COI, using personal information in order to evaluate their edits? Second: I can believe that there might be a vanishingly small number of cases (two or three a year) where the edits are borderline and knowing whether you're dealing with a clever PR guy or good-faith editor who's not used to our 'house style' might swing the balance of an AfD or a sanctions proposal; that would be the only possible use for this list, and the existing functionaries' list could already handle that. Third: it encourages people to focus on digging up dirt on people, on how they make their living, and on "catching" evil-doers, when we should be encouraging people to evaluate the edits themselves. Fourth and finally: it doesn't address the elephant in the room, which is what we do once we've "caught" a paid editor. HJ Mitchell | Penny for your thoughts? 11:45, 17 August 2016 (UTC)
  7. Oppose COI should be handled transparently not behind closed doors. Only in death does duty end (talk) 15:08, 17 August 2016 (UTC)
  8. Oppose. Transparency is, in my view, a core value of the movement. What needs to be fixed here is editors' over-stringent interpretation of OUTING, not the creation of more secret bureaucracy. Regards, James (talk/contribs) 21:37, 17 August 2016 (UTC)
    I wish I knew a way to fix "editors' over-stringent interpretation of OUTING", but I suspect that we will end up going in the direction of making it more stringent, not less. There are just as many editors who oppose "over-stringent" interpretation of COI, maybe more. --Tryptofish (talk) 23:51, 17 August 2016 (UTC)
  9. Oppose If we had a clearer idea of of what the problem actually is, and what action should be taken, then such a procedure would more sense. Place me with the editors who oppose "over-stringent" interpretation of COI. It seems to be an allegation that gets tossed about, and defence is difficult. The last thing we want to do is encourage COI vigilantes. Hawkeye7 (talk) 01:06, 18 August 2016 (UTC)
    I appreciate your saying that right after the comment before. It really gets to the problem the community has right now: we have editors who say OUTING is too stringent, and we have editors who say COI is too stringent. It seems to me that a big part of "what the problem actually is" is the conflict between those two views. I thought that a better way to present COI evidence privately would allow editors who particularly care about COI to present evidence without violating OUTING, and would allow editors who particularly care about OUTING to be satisfied that such evidence would be handled securely. Instead, I'm getting the feeling that nobody likes it, and it will just end up leading to stasis. --Tryptofish (talk) 18:25, 18 August 2016 (UTC)
  10. Oppose - Drama box for anonymous denunciations of wikienemies. Guaranteed to be an ongoing source of conflict and distraction. Carrite (talk) 04:25, 20 August 2016 (UTC)
  11. Oppose Arguments make sense to me, e.g. HJ Mitchell, Hawkeye. Samsara 10:40, 23 August 2016 (UTC)
  12. Oppose As someone who's spent a fair amount of time working COI problems at WP:COIN, I haven't seen the need for this. Dealing with COI is about 80% article repair and 20% user behavior control. Sometimes we have COI problems that have to be sent to AN/I or sockpuppet investigations, but most of the time, it's sufficient to clean up the article and issue some warnings. Editors who stubbornly try to re-insert promotional material eventually get blocked for edit warring. In the two worst COI cases with which I've been involved, one with an offer of $10,000 to "fix" the article" and another which resulted in litigation, this proposal would not have helped. John Nagle (talk) 06:23, 24 August 2016 (UTC)
  13. Oppose per Only in death. The proposal seems a corbeau process in the making. Should be an open & verifiable process. Cabayi (talk) 07:17, 24 August 2016 (UTC)
  14. Oppose. I think HJ Mitchell sums it up best. Kudpung กุดผึ้ง (talk) 08:09, 24 August 2016 (UTC)
  15. Oppose creation of a star chamber email forum. The downsides of that outweigh COI editing. --SmokeyJoe (talk) 08:18, 24 August 2016 (UTC)
  16. Oppose - Harry sums it up well. The number of instances where the knowledge of private information is actually useful is tiny compared to what I envision the amount of traffic such a list would see. ​—DoRD (talk)​ 13:24, 24 August 2016 (UTC)
  17. Oppose per HJ Mitchell. It simply is not necessary to know whether someone is being paid or not - if the edits are good they should stay, if the edits are bad they should not. Thryduulf (talk) 10:30, 25 August 2016 (UTC)
  18. Oppose per HJ Mitchell]], et al. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:18, 25 August 2016 (UTC)
  19. Oppose per SmokeyJoe, DavidLeighEllis, and Jo-Jo Eumerus. There are systems already in place for this if the situation is great enough to demand it. We don't want to make it too easy for good-faith editors to be outed. Lastly, we have a good COIN board, or at least we did until Jytdog got topic-banned from it (yes, that is a not-so-subtle dig at that highly detrimental [in my opinion] decision). Softlavender (talk) 09:26, 26 August 2016 (UTC)
  20. Oppose - If a user creates undesirable content, fix the content and warn the user. If they do it repeatedly, block or ban them. Off-wiki detective quests to hunt down users with conflicts of interest are extraneous to our purpose, and the potential for abuse and drama would seem to outweigh any benefit.- MrX 16:28, 3 September 2016 (UTC)
  21. Wrong solution to a real problem. We don't need more unaccountable mailing lists. We do need sanity restored at WT:HARASS, tied to clear legal and ethics concepts like reasonable expectation of privacy, public figure, and many others. There is no privacy problem is noting that Company XYZ offered to pay people, in public, to write a WP article about them, one with problems was written by JimBobChickenButt22, and then the freelancing site shows a Chicken22Jimmy marking the job "done". No personally identifiable information is revealed. If someone going by XYZounds on WP writes an article on Chumpo Industries, and the ChumpoIndustries.com's "About Us" page tell us their CCO's name is "Xerxes Youill Zounds", we have a duty to act on that. Arguably there is no problem noting that there was an RfC on how to spell "alumin[i]um" again, that 50 "new users" showed up to vote for the long spelling as professional chemists, and that earlier the same day there was a public post to the International Chemists Poop-chute web-board asking people to come stack the vote, even if some real names happen to be used by some people on that mailing list. Truly excessive concerns over privacy make it effectively impossible to police WP:MEAT, WP:SOCK, WP:COI, organized WP:POV-pushing, even WP:HARASS itself (in relation to off-WP harassment between editors). Especially as WP becomes one of the most-used information sources in the world, the pressure to manipulate its content in biased ways is only going to climb and climb.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:41, 5 September 2016 (UTC)

Discussion

I'd like to pose a question to editors who oppose this proposal: would you also like to deprecate WP:COIN and mark it as historical? --Tryptofish (talk) 22:13, 16 August 2016 (UTC)

No. COIN is useful, and if only functionaries could deal with COI users, there'd be many more problems with COI users on Wikipedia. ThePlatypusofDoom (talk) 23:43, 16 August 2016 (UTC)
I agree with you that COIN is useful. But functionaries would not be "dealing" with COI users. The decision about what, if anything, to do would still take place at COIN, the decision being made by the community. But what happens at COIN now? If you accuse an editor but say you cannot post private information because of the outing policy, the accused will say you are making a WP:NPA violation, because you are making an accusation without evidence. And if you post the evidence, you end up with an oversight block. It's a lose-lose situation. Under this proposal, COIN would be working with just as much information as COIN gets now, but with greater confidence about evidence that cannot be posted at COIN. --Tryptofish (talk) 23:53, 16 August 2016 (UTC)
That would probably be a good idea. (We should also delete the WP:NOBIGDEAL section of WP:ADMIN and the WP:BLOCKNOTPUNITIVE section of the blocking policy, but I digress.) Shock Brigade Harvester Boris (talk) 23:47, 16 August 2016 (UTC)
OK, that's an honest answer! --Tryptofish (talk) 23:53, 16 August 2016 (UTC)
But as a hypothetical, for as long as COIN continues to exist, are we really better off without the proposal here? Should COIN operate without evidence, or should we just stop caring about COI? --Tryptofish (talk) 23:56, 16 August 2016 (UTC)

Still thinking about this, but are they required to be identified to WMF? Of course all current arb/CU/OS are, but it's not clear whether some of the other subscribers are, like ex-arbs. --Rschen7754 00:09, 17 August 2016 (UTC)

I'm not sure, but I assume ex-arbs did so when they became arbs, and ex-arbs who are no longer in "good standing" would be excluded here. --Tryptofish (talk) 00:12, 17 August 2016 (UTC)
No, it doesn't work like that; everyone who was previously identified was "de-identified" on 1 Jan 2016 unless they signed this document. Those (like me) who refused to sign were summarily ejected; compare then and now. ‑ Iridescent 00:40, 17 August 2016 (UTC)
So does that mean that current members of the Functionaries mailing list are now all "identified"? If so, that solves the concern that Rschen7754 raised. --Tryptofish (talk) 00:48, 17 August 2016 (UTC)
Since I've already commented at some length on earlier versions of this proposal, I'll keep my mouth shut on the substance for now. But to put this part to bed: yes, everyone currently subscribed to the functionaries list has signed the new confidentiality agreements, which superseded the old identification process. Opabinia regalis (talk) 00:51, 17 August 2016 (UTC)
(edit conflict) As far as I know, yes. There are probably some WMF staff and ex-WMF staff who are still on the mailing lists and aren't formally identified, but I wouldn't consider them an issue since by definition Legal knows where to find them if need be. (Whisper it quietly, but "identification" is virtually meaningless in the Wikipedia context. I could amend the name on a scan of a passport to have whatever name and photo I like in about three minutes; sure it won't fool the experts, but it doesn't need to, it only needs to fool whichever intern is checking the documents. The whole "identified user" thing is more about giving the WMF protection in the case of a breach—"well, we did our best to stop infiltrators getting in"—than about actual information security; those with long memories will recall when a Poetsock managed to wangle Checkuser status.) ‑ Iridescent 01:00, 17 August 2016 (UTC)
Subscriber list here, which appears to be up to date. Who is this Jimbo guy, is he identified...? ;) Actually there's no more intern-document-checking; you just have to sign the form. Many people here are far more aware of what the WMF is up to than I am, but I assume that decision had to do with recognizing the futility of the old process. Opabinia regalis (talk) 01:44, 17 August 2016 (UTC)
You could consider a general proposal along these lines that doesn't make an issue of COI per se, but that it may invoke COI as a possible explanation of why the editor is behaving in the way it has done, and what remedy may be appropriate. A COI editor who shows the same problem behavior as a non-COI editor is likely to respond differently to feedback and sanctions.
One can also consider having encrypted ArbCom cases such that everyone can add evidence (via email to the clerk) but only ArbCom can read the evidence. ArbCom may give selected persons the private key so that they can fully participate in the case. The accused editor can then also be given the private key at a later stage to respond to all the accusations. This is better than just using email, because you then don't have a structured way of laying out the evidence and arguing for the accusations and proposals. This then makes it difficult for the accused to respond later. Count Iblis (talk) 20:13, 4 September 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.

Which should be the main sandbox

Issue

WP:Sandbox can't be edited with visual editor (a ridiculous limitation for the main testing page). Trying to use VE on WP:sandbox just causes it to error, which would be confusing for new users.

Proposal

Draft:sandbox be made the main sandbox, since it's far more versatile. Pages suggesting that users test something out should point to Draft:sandbox. Examples:

What do people reckon? T.Shafee(Evo&Evo)talk 03:59, 12 September 2016 (UTC)

(Just wanted to flag that User:Sandbox has been used, and referenced to, as the main visual editor sandbox for years now . --Elitre (WMF) (talk) 16:48, 12 September 2016 (UTC))
A good point Elitre. I think that on balance, Draftspace is a more logical location than Userspace for the default sandbox. The Userspace version also gives a notification about editing user pages when you first edit it, which I think is confusing to new editors. T.Shafee(Evo&Evo)talk 06:17, 14 September 2016 (UTC)
I guess you're right. My intent though was just leaving a note so that links could be updated if the situation changes and I forget about this thread ;) --Elitre (WMF) (talk) 07:15, 14 September 2016 (UTC)

Input on Full Evaluation of WP:Research Help Pilot

The Wikipedia Library has now posted a report on its spring pilot test of a Research Help portal. As the report outlines, our target audience of readers and new editors generally reacted more positively to the pilot than experienced editors, who raised important critiques for discussion. The report provides more details on the results and some proposed next steps for the project. Your input is welcome on the report talk page. Astinson (WMF) (talk) 14:43, 14 September 2016 (UTC)

Global date and time format in preferences and some other suggestions

Currently, choosing a date/time format in your preferences doesn't affect everything as signatures, for example, still have the date coming before the month even though this is the current option I have selected in my preferences: "10:00, September 13, 2016." The only thing it seems to affect is the format of the date heading on your watch list. In signatures, it results in "10:00, 13 September 2016, Friday."

So my suggestion is that choosing a date/time format should affect everything. My other suggestion is that there should be an option to choose between 12-hour format—with no leading zeros—and 24-hour format. I prefer the former. Finally, switch the positions of the day and time.

The final result or an example of what I prefer looks like this:

  • Tuesday, September 13, 2016, 10:00 AM
  • Tuesday, September 13, 2016, 9:00 PM

Although, of course, in the example above, "Tuesday" would be replaced with "Today." (And same type of deal for "Yesterday.")

Amaury (talk | contribs) 17:00, 13 September 2016 (UTC)

@Amaury: There is a gadget which will reformat timestamps in signatures (it's "(U) Change UTC-based times and dates, such as those used in signatures, to be relative to local time (documentation)"). But as regards getting the date/time format in your preferences to affect dates in wikitext outside of signatures, this was once done, but the feature was removed in 2008 or early 2009. --Redrose64 (talk) 18:48, 13 September 2016 (UTC)
@Redrose64: Do you know why that was removed?... Just curious. --IJBall (contribs • talk) 19:26, 13 September 2016 (UTC)
@Redrose64: Sorry for getting back to you late, but that worked great, so thanks a lot! Really! And that results in, using Izno's signature, "September 13, 2016, last Tuesday (2 days ago), 12:41 pm (UTC−7)." I would still prefer either "Tuesday, September 13, 2016 (2 days ago), 12:41 PM (UTC−7)" or just "Tuesday, September 13, 2016, 12:41 PM (UTC−7)." But I'm probably asking for too much, unless there is some way, haha! However, I could simply modify my JS to only show "September 13, 2016, 12:41 pm (UTC−7)," and that would be even closer to what I prefer, minus likely not being able capitalize the AM/PM.
Also, sadly the editor is not affected (and it doesn't use your selected time zone), but I can live with that, LOL! Amaury (talk | contribs) 18:56, 15 September 2016 (UTC)
Inconsistent date formatting in articles--we had auto options for logged in editors but not for anons and so we would have a mix of date formats in the article wikitext displayed to anons (which a logged in user would not recognize as an issue). Review Wikipedia:Date formatting and linking poll. --Izno (talk) 19:39, 13 September 2016 (UTC)
This google search might just be a better way to review. --Izno (talk) 19:41, 13 September 2016 (UTC)
The editor is intentionally not affected: the editor is supposed to show exactly what the underlying code is, without any munging at all. --Redrose64 (talk) 19:14, 15 September 2016 (UTC)

In November 2015 we already decided to convert Google and Internet Archive links, but I want to explain why it makes sense to do this conversion for every website offering HTTPS; that being apart from the obvious reason of HTTPS being more secure.

  1. External links from Wikipedia (HTTPS-only) carry no referral information in the HTTP header when "leaving a secure protocol" (not by accident, but per RFC 2616 §15.1.3), i.e. from HTTPS→HTTP. That means these sites do not know where they are being linked from. But a lot of websites consider this important information, so it would be good practice if we change our external links (see, for example, this recent request by Newspapers.com).
  2. Nowadays, a lot of websites have HTTPS-redirects (just like Wikipedia). For instance, http://twitter.com redirects to https://twitter.com instantaneously (others include Facebook, SoundCloud, or Yahoo and all its services like Flickr or Rivals). But we still have plenty of HTTP links to those websites and plenty of others who are HTTPS-by-default (check Special:LinkSearch). These external links not only break the HTTP referer (see #1), but are also slower because HTTPS→HTTP→HTTPS (Wikipedia→Redirect→Destination) obviously takes more time than HTTPS→HTTPS.

Therefore, I propose that we steadily convert these links. In some cases this has been done already or is in progress (GreenC bot and my bot are taking care of Internet Archive links), but there is plenty more to do. I wanted to find out if this has support in the community. --bender235 (talk) 15:24, 15 September 2016 (UTC)

Activate Visual Editor on talk pages on English Wikipedia

I propose that Visual Editor is enabled on talk pages on English Wikipedia alongside Source Editor. This would remove the need of new editors to have to learn how to use Source Editor to interact with the rest of the community. It would also allow people from outside the Wikimedia movement more easily communicate with us e.g writing a question about donating images on a Wikiproject talk page. It seems very odd that there is a higher technical barrier to entry for talking to each other than adding information to articles.

Currently VE is being used in discussions on Wikimedia projects successfully including this one about copyright strategy started by WMF.

Would it be possible have this activated on one or a few Wikiprojects as a trial to identify any issues?

Thanks

--John Cummings (talk) 13:09, 2 September 2016 (UTC)

I'd say it should be enabled in all namespaces. It's now good enough that even as a dedicated source code editor, even I find uses for it -- mainly, table editing and pasting rich text. But when I try to use it, say, in the Wikipedia: namespace, I have to figure out why I can't. It's a needless annoyance. I think we all agree that VE was initially pushed prematurely, but it's a lot better now...and having available sometimes, but unavailable others, is far from ideal -- for both newbies and experienced editors. -Pete (talk) 23:46, 3 September 2016 (UTC)
I'll just comment to say that the WMF is very against it. The logic is seriously warped. The answer is "No, because Flow". Or, to fill in the missing details on that, "No, because we want to exterminate Talk pages completely, we want to force everyone to use Flow, and we view enabling VE on Talk as some sort of alternative or threat to the Flow agenda". Link: MW:Flow#If you are not working on Flow, will the visual editor be enabled on talk pages? Alsee (talk) 11:24, 4 September 2016 (UTC)
Thanks for the link, Alsee. I wish I could keep up with the status of Flow, it seems to be ever-shifting. That FAQ item was added in August 2016, so I suppose it is authoritative. Even though discussion technology has been under active discussion since at least 2010 or so, for some reason this is all on hold until June 2017. Discouraging. Thank you for the link. -Pete (talk) 19:16, 4 September 2016 (UTC)
@Jdforrester: This really does not stand a chance of happening. The VE team are dead against it see for example the closed WONT-FIX task T53154 "VisualEditor: Provide a tool to insert a talk signature in namespaces that need it".--Salix alba (talk): 19:19, 4 September 2016 (UTC)
@Salix alba: that task was completed and you can add a signature in VE, you can find insert signature under the insert menu in VE. --John Cummings (talk) 20:46, 4 September 2016 (UTC)
That does seem weird. I detest VE, but I understand why people like it, and the tool should not be forbidden to them on talk pages for no apparent reason, as long as the sigs issue noted above really is fixed.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:22, 5 September 2016 (UTC) Reconsidered.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:47, 5 September 2016 (UTC)

I just went to that Visual Editor user guide on Mediawiki[4], and tried to edit it in VE. After a long wait, it opened, more or less. Many images are not shown but given as text ([[File:VisualEditor and so on). (mind you, that page looks rather shitty in reading mode already, the section with "Once you have entered or selected the link, you complete the linking" isn't completely visible on my already widescreen small font machine...). If even that page isn't editable correctly in VE, I still see no reason to roll it out any further on enwiki (considering also the ongoing creation of many "nowiki" errors in the main namespace by VE edits). Fram (talk) 11:35, 5 September 2016 (UTC)

Oh, if it's still doing the incorrect nowiki thing, then, no. It is not ready for prime-time yet. I thought it only barfed that stuff up when used inside Flow.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:47, 5 September 2016 (UTC)
That page contains <translate> tags which aren't supported in VE. ed g2s • talk 03:50, 6 September 2016 (UTC)
@Doc James:, what tweaks do you think are needed? --John Cummings (talk) 20:24, 6 September 2016 (UTC)
It should be turn on able as a beta feature immediately so that long term editors and other can try it out. The signature issue was mentioned above. Doc James (talk · contribs · email) 20:28, 6 September 2016 (UTC)
Ok, thanks Doc James, what's the next step to implement VE on talk pages as a beta feature? John Cummings (talk) 20:58, 6 September 2016 (UTC)
How about we have a RfC and than present the result of that RfC to the WMF? That could gain some traction. Doc James (talk · contribs · email) 21:00, 6 September 2016 (UTC)

Thanks Doc James — Preceding unsigned comment added by John Cummings (talk • contribs) 11:30, 7 September 2016 (UTC)

So, my above experience was apparently invalid because they made VE available on a site where most pages contain translate tags, which mess up VE... Speaks volumes about both VE and the WMF, but nothing new there. So instead I tried to edit my user page there, which doesn't have such tags[5]. I go to the end of my text, press enter (cursor to new line), press enter again (cursor to one line lower down? No, cursor goes back up one line, to the end of my text!).

So I enabled VE here (very temporarily), and tried to have a conversation with myself on my user page (which still looks different in VE than it does in reality, fail again). At least I don't get the problems described above, but when I type 

Hi
:Hello
::Heya

I get Hi<blockquote>Hello</blockquote><blockquote>:Heya</blockquote> as the result. Which is useless.

I checked the linked page at Meta, [6], and very, very few edits there are made using VE, none in response to others, probably because that doesn't work in VE. If you can't even (easily, intuitively) reply to someone using VE, then why would you enable VE on talk pages? For the very rare cases where you really think VE offers a benefit (say, creating a table), you can always create the table in VE in your sandbox and then copy the wikicode to a talk page. Setting up a VE which is clearly unsuited for standard talk page editing just so a few exceptional cases can be made easier seems counterproductive. Fram (talk) 12:16, 7 September 2016 (UTC)

I think this fits with why JDF is so against VE for talk page. Talk pages were never in the design brief for VE so features like doing multi-level indentation haven't been worked out fully. Adding them takes time away from doing what they are supposed to be doing. --Salix alba (talk): 17:33, 7 September 2016 (UTC)
Well, also remember that the usage of : is a total abuse of the visual effect of a technical feature that should never have been in the first place, but is an accident of history that we can no longer correct. That means that for VE to distinguish between the visual effect for Talk page discussions and the technically correct usage pattern is really hard, since the difference is basically arbitrary. —TheDJ (talk • contribs) 09:25, 9 September 2016 (UTC)
You mean that Parsoid has to do that. VisualEditor 'thinks' in HTML, not wikitext. This means that it sees <dd> (instead of :), and it can't create that kind of list (yet. I have asked for this feature to be prioritized, partly because I use that in my own editing, but my request has been declined so far. I do not expect that feature to be seriously considered again until early 2017).
I appreciate the sentiments coming from John Cummings and others. However, I'm not hopeful that the proposal would be accepted. Firstly, it is impossible to enable it for specific pages only, so it would have to be for a full namespace. The most plausible "test" namespace would be Wikipedia: namespace, which is mostly AFDs and non-discussion pages. However, so long as WP:ANI exists in the Wikipedia: namespace, I do not believe that it will be enabled even there on this wiki. Secondly, the product manager has declined every single similar request from other wikis. So while you're free to make the proposal, I don't think it would be worth your time at this point. You might consider this subject again after the latest version of the wikitext editor has been deployed (i.e., no longer a Beta Feature [if you're interested in trying it as a Beta Feature, then check your prefs in about a month]). Whatamidoing (WMF) (talk) 22:30, 10 September 2016 (UTC)

Thanks for the information Whatamidoing (WMF), can I ask a couple of questions to understand the situation better? I have never done a proposal before like this:

  1. Who would do the accepting or now accepting of this proposal? I'm confused about if it would be a community decision or one made by a specific person at WMF or something else.
  2. Would it be technically possible to turn on VE on talk pages as a beta feature either on en.wiki or any other Wikimedia projects e.g Meta?
  3. I'm only suggesting this because the current system is not ideal and I understood that Flow was not being developed any more, is this the case? I don't want to propose something if there is another solution coming that will be widely implemented.

Thanks again

John Cummings (talk) 10:42, 13 September 2016 (UTC)

@John Cummings:, The primary problem is that VE does not (and will not be made to) match the mis-use of :::'s (which create a definition list) that we've historically mis-used for multiple indents (as discussed above), and as such it will never be suitable for editing multi-indent discussions. For #3, major development of Flow is currently paused, whilst the Collaboration team works on wrapping up Notifications work, and progresses on mw:Edit Review Improvements, but they do hope to look at this area (structured discussion) again after the ongoing work is done. HTH. Quiddity (WMF) (talk) 20:35, 14 September 2016 (UTC)
  1. John Cummings, proposals for config changes have to be "physically" implemented by WMF staff, and of course they're not going to implement something that they disagree with. In this case, it'd have to be accepted by the product manager for mw:Extension:VisualEditor.
  2. It's technically possible to turn the visual editor on at any MediaWiki site (including all Wikimedia sites) in any normal namespace (e.g., not "Special:").
  3. I agree that the current system isn't ideal. Flow is currently in active use at a few wikis, including mw:, where it's been the default for all (new) talk pages for a long time (old pages stick with their old format unless individually changed). However, I wouldn't expect Flow to be made available here at the English Wikipedia for a long time (=years). Whatamidoing (WMF) (talk) 17:37, 19 September 2016 (UTC)

Update icons for some templates

WP:SNOW Consensus against these new icons.

Almost all responses noted reduced readability as a primary concern, and this is especially an accessibility issue for those with poor vision.

Editors who did not raise readability concerns nonetheless found the current icons satisfactory, and saw no rationale to replace them. Alsee (talk) 19:35, 20 September 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.

This year is Wikipedia's 15th anniversary, and it is time for update icons of some templates, because some icons are outdated, which created in 2007. These new icons are created in 2013. Here are my proposals (for example):

Old New

and more. I think these icons will replaced in all languages Wikipedia. So I would like to discuss this, thanks.--Shwangtianyuan Talk Here 05:57, 14 September 2016 (UTC)

Support - The two examples you put up are clear improvements, and the CommonsEmblems_icons set in general is a good unified style for these sorts of icons. T.Shafee(Evo&Evo)talk 06:15, 14 September 2016 (UTC)
Comment - whilst retaining the coloured circular border, are you a) able to make the whole icon take up more space within its canvas and b) make the meaning-bearing central sections black and more easily distinguished? T.Shafee(Evo&Evo)talk 23:44, 14 September 2016 (UTC)
Oppose for now. You are killing off a lot of contrast and 'readability' of those icons. Just take a step back and squint a bit. Now consider how many people have some level of a vision problem. —TheDJ (talk • contribs) 06:25, 14 September 2016 (UTC)
Well its a good idea to change your icons and stuff from time time.[why?] On the other hand those particular examples shrink the meaning-bearing elements too much IMO. Herostratus (talk) 13:28, 14 September 2016 (UTC)
Question Do we have a Manual of Style for svg icons? I would like to read it and contribute to the talk page. ClemRutter (talk) 14:46, 14 September 2016 (UTC)
Oppose The new icons are two orange circles with an indeterminate squiggle inside. The old icons looked like a pair of scales and a book. Why change clear symbols to meaningless circles? Martin of Sheffield (talk) 15:29, 14 September 2016 (UTC)
Maybe, but not with that style - agree with TheDJ here - bad readability - not just "step back" but think scaled down like on a mobile browser as well. — xaosflux Talk 21:05, 14 September 2016 (UTC)
Oppose per The DJ. There is a serous degradation of readability in the proposed new icons. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:27, 15 September 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.

restrict editcontentmodel permission

A new WMF change is planning to grant access to (editcontentmodel) as used by Special:ChangeContentModel to all (auto)confirmed users. Some of the technical information is located in phab:T85847. Outside of Special:MassMessage there is little use case for this ability currently on the English Wikipedia and I propose that for enwiki we restrict this access to sysops (already assigned) and Mass Message Senders (who could make use of it to use Special:CreateMassMessageList). This utility can be used break articles from being able to be read or reverted by anonymous users, and is not currently easily reverted. Please comment below. — xaosflux Talk 02:01, 8 September 2016 (UTC)

  • Support This could have unintentional consequences if used by those not familiar with how different content models should be used. It can also be used for disruption. It can be added to other user groups at a later point if the need arises. — JJMC89 (T·C) 02:47, 8 September 2016 (UTC)
  • Let's just wait and see what the practical consequences are, before we restrict it. Restricting something later on should be easy enough. —TheDJ (talk • contribs) 08:21, 8 September 2016 (UTC)
    This is already available to sysops, the practical consequence is easy: most users will be able to take a working article and break it, See this page for an example: test2wiki:Law2. Apparently this is being done to support something about Flow, which we have strongly rejected on enwiki. — xaosflux Talk 11:33, 8 September 2016 (UTC)
    Well, that's not true at all. "most users" isn't true, because most users actually aren't autoconfirmed. In any case, any user can "break" an article by changing it's content. In this case, they can break it in a different way. It's not being done to support Flow, Flow already bypassed this. Legoktm (talk) 21:50, 8 September 2016 (UTC)
    @Xaosflux: While 'take a working article and break it' might be true, that goes for most things we do. The only question which to me is relevant, is wether dealing with that breakage is 'expensive' enough in labor to warrant protecting it more than page moves, and to have other people running around doing the work that an auto confirmed user might have been able to do on his own. And since we haven't tried this, we can't say anything about it yet. So, I would opt to gather that experience, before deciding it needs the protection that people seem to think is required. While I support some of your original concerns, I think that with the fixes made by Lego and Bawolff, will sufficiently address the problems to at least experiment with a wider access to this option. —TheDJ (talk • contribs) 11:00, 9 September 2016 (UTC)
  • Strong support to limit to sysops and mass message senders (for now). The possibility of "Content model change vandalism" per the apparent result at test2wiki:Law2 (and warring?!) could be disasterous, especially if folks are unaware that this would be a new area that needs patrolling. Side note: there are times when (user) script writers require a content model change when a page is not created with a js/css extension, but could be trusted with the permission. — Andy W. (talk · ctb) 16:01, 8 September 2016 (UTC)
    Update/clarify: If undo/rollback reverts contentmodel changes, some of my personal concerns are resolved. I still think a contentmodel change on an article will throw many experienced editors off, and there'll be plenty of folks who wouldn't realize an undo (or an edit of a previous revision?) would solve the issue. I'd be willing to support a rollout of (editcontentmodel) to a user group that has some semblance of maintenance or patrolling, like reviewer or rollbacker. I sincerely hope that contentmodel changes don't become a new form of disruption. Also, I hope a non-admin cannot change the content model of User:Andy M. Wang/common.css and move it to their userspace. — Andy W. (talk · ctb) 01:56, 9 September 2016 (UTC) added 02:10, 9 September 2016 (UTC)
    Thanks for updating. No, non-admins will not be able to do that. To be able to change the content model of a page, you first need to be able to edit it. In this case, non-admins are not able to edit your CSS or JS, so they would not be able to change the content model. Legoktm (talk) 03:28, 9 September 2016 (UTC)
  • Question. For those of us just coming into this discussion, could someone provide a link to where the idea of "contentmodel" is explained? Maybe point WP:Contentmodel at it? As Andy W. notes, it's something that is apparently new and might need to be understood (or at least known-about/knowable-about) by lots of editors. DMacks (talk) 16:11, 8 September 2016 (UTC)
    @DMacks: Most of the content model help is at mediawiki.org to avoid fragmentation of information, I think. (See Help:Content model) — Andy W. (talk · ctb) 16:14, 8 September 2016 (UTC)
    @DMacks and Andy M. Wang: Not new, but rarely encountered; even admins aren't fully knowledgeable (as in, how many of us have ever needed to do this?). There was a thread at VPT a few months ago (see Wikipedia:Village pump (technical)/Archive 147#MW Error message when undoing "content model" change) where somebody had managed to accidentally change the content model of a page, and had difficulty changing it back. This was the first time that I'd heard of the feature. --Redrose64 (talk) 23:02, 8 September 2016 (UTC)
    @Redrose64: Thanks. I had thought that the undo or rollback button did nothing to change the content model, and that had to be a separate mechanical action. To clarify, I don't think anyone's ever needed to monitor Special:Log/contentmodel before; I've maybe glanced at the log twice, maybe thrice tops. Suppose some editor changes Michael Phelps from wikitext to JSON. I thought there would be no working undo or rollback button since a text revert makes the page incompatible with JSON format (hence a need to monitor that log). If undo/rollback reverts text and contentmodel changes, that alleviates some of my concerns. — Andy W. (talk · ctb) 01:58, 9 September 2016 (UTC)
  • Strong support We shouldn't be giving out freely a tool which makes hard-to-revert vandalism easy and which has very little use. MMS holders should get it per Xaosflux. If it would be useful for some script developers, we can think of making a separate user group, but now we need to quickly get it out of the hands of our more enterprising vandals. I hope this can SNOW so the change doesn't get deployed here at all. BethNaught (talk) 17:05, 8 September 2016 (UTC)
    It would be helpful if you could elaborate on how this vandalism would be "hard-to-revert"? Legoktm (talk) 21:50, 8 September 2016 (UTC)
    According to your comments phab:T145044#2618347 and phab:T75490#1416463, edits changing the content model cannot be undone fully (i.e. changing the content model back) without visiting a special page and doing so manually. This is hard because a) the undoing is labour-intensive and slow b) the patroller has to know about it in the first place c) the process is not apparently compatible with common anti-vandal tools like Huggle and Twinkle. If as you state, the ability to do a complete revert in the standard way will not be soon forthcoming, the ability to change content models should not be widely given out. Autoconfirmed socks are not hard to obtain for a keen vandal, such as the Nikita troll who recently forced the implementation of ECP on many music articles. BethNaught (talk) 22:09, 8 September 2016 (UTC)
    Hmm, I think those comments might be a bit misleading out of context. In any case, thank you for explaining, I appreciate it. Those are discussing *undo* specifically. Actions like rollback will properly revert content model changes, meaning that tools like Huggle and Twinkle will work just fine. Does that resolve your concerns? Or do you see undo working as a requirement for granting to autoconfirmed users? Legoktm (talk) 22:25, 8 September 2016 (UTC)
    Long-term I consider the issue with undo a serious bug. Undoing a revision should undo all the associated changes. However, with regard to the upcoming deployment, if I were convinced that anti-vandalism tools would work I would be more sympathetic to TheDJ's wait-and-see approach. However I'm not convinced Twinkle will work. As far as I understand it, Twinkle works by taking the content of the old revision and posting it into a new edit, not by invoking MediaWiki rollback -- in fact, that's then point, to have rollback without rollback rights. So the automatic content model revert included in MediaWiki rollback wouldn't be invoked. Arguably Twinkle needs updating here, but it is a problem that needs resolving. BethNaught (talk) 22:55, 8 September 2016 (UTC)
    You're right :) Well, kind of. It uses the API's undo functionality apparently, not normal rollback. Bawolff and I are working on fixing that and will have it fixed by Monday when we planned to roll this out. Legoktm (talk) 23:20, 8 September 2016 (UTC)
    @BethNaught: There is a parallel, it's existed for years - and it's well-known too. Consider a (confirmed) user - let's call them Example - who goes to a page, makes a text change, moves the page to another title, and makes another text change. Let's assume that none of these actions was constructive, and the best thing to do is to put the article back to how it was before Example touched it. If you look at the page history, there will be three entries for that user, and all three have an "undo" link, yet the middle one, if clicked, will throw this message (in red). I believe that if Twinkle is used on that sequence of three actions, it will satisfactorily undo the two text changes, but not the page move. Moreover, true WP:ROLLBACK (not the Twinkle rollback) will also not revert the page move. --Redrose64 (talk) 08:34, 9 September 2016 (UTC)

Wow, I'm rather disappointed in how Xaosflux started and framed this discussion. This isn't a "WMF" change. I'm pushing this forward in my free/limited volunteer time. I've already asked how this could be used to break articles in a way that isn't undoable. And after responding to concerns at phab:T85847, no one has provided me with any specifics, which I'd really like to hear. Legoktm (talk) 21:50, 8 September 2016 (UTC)

Legoktm First let me apologies for my misundersanding on the source of this change. I've striken the WMF portion in the lead. While this is not "undoable" it does allow a registered user to break from the point of view of readers in a way that an unregistered user can not fix. It allows users to break an article for readers that is difficult to reverse (at least currently). You can not "undo" or "revert", you can not even load the last working version and hit save. Revert links to not appear on pages after content model changes? where is the revert? Try to force it get: 
Grabbing data of the earlier revision: [V9HoewpAID4AADqduzMAAAED] Exception Caught: Bad content model: expected javascript but got wikitext.
. For the English Wikipedia at least, I can't think of any good reasons that the article namespace should have js, JSON, MML formats presented to readers at all - please, please let me know what I am missing here and why this is needed? — xaosflux Talk 22:42, 8 September 2016 (UTC)
Thanks. I don't buy the argument of unregistered changes not being able to fix this. How is it different from an autoconfirmed user vandalizing a semi-protected page and blanking it? The reason it's throwing an exception is because we haven't deployed the fix for the bug your reported yesterday. Legoktm (talk) 23:03, 8 September 2016 (UTC)
That error above is not from "undo" it was from trying to do a twinkle rollback. Can any admin help demonstrate by changing User:Xaosflux/Test2 to js? — xaosflux Talk 23:37, 8 September 2016 (UTC)
Twinkle rollback uses "undo" via the API. Anyways, I converted the page. Legoktm (talk) 03:25, 9 September 2016 (UTC)

Update: Thanks to all your feedback and some work by user:bawolff, undo will now also undo content model changes. This also means tools like Twinkle rollback will work as well (Huggle uses normall rollback IIRC, so it would have already worked). You can test these changes on the Beta Cluster in a few minutes (you only need to create an account there to change content models), they won't work here yet. Legoktm (talk) 03:35, 9 September 2016 (UTC)

  • Not sure if needed - but if changing a content model by way of the rollback function - it bypasses the change in the content model change log. — xaosflux Talk 03:36, 9 September 2016 (UTC)
    I noticed that as well, and fixed it :) Legoktm (talk) 04:54, 9 September 2016 (UTC)
    @Legoktm and Xaosflux: I did some tests as "Andy M. Wang" and "Andymw2" at the Beta cluster. It looks like I can change another editor's subpage to CSS and prevent myself from editing it / undoing it. It also appears that for a page I can currently edit, I cannot select an old revision of a page whose content model differs from the current and try to edit that. I'm afraid that behavior might break Twinkle's revert-to-revision when the select revision's contentmodel is different. To revert to a revision, it looks like a manual change is needed. The reason this is problematic regardless is when a user changes a page like 2016 Summer Olympics to CSS, and makes a second edit. Users without rollback who are not aware of Special:ChangeContentModel (that's surely almost all) might try to select a revision prior to the contentmodel change, but cannot edit it due to the restriction. I'm waiting to be autoconfirmed so I can test what happens when I move a CSS to another user's subpage — Andy W. (talk · ctb) 06:18, 9 September 2016 (UTC)
    To summarize the scenario: suppose User A made the last good revision to Foo. User B changes the content model to CSS. User C edits the page. Then I believe an autoconfirmed User D should be able to select User A's revision and edit that, or use Twinkle's revert to revision by User A. — Andy W. (talk · ctb) 06:34, 9 September 2016 (UTC)
  • Support. It appears that the only use case here is massmessage, and we don't allow autoconfirmed users to utilize the page to send massmessage spamblasts. That is already a restricted-rights function for admins[7] (and presumably any massmessage-usergroup). Having an admin create the page is rare and trivial. Alsee (talk) 09:12, 9 September 2016 (UTC)
    Note, to aid any users that want to build up a mass message list, we have built empty shells for them to use (see Wikipedia_talk:Mass_message_senders#Mass-mail_subscription_list_shells). — xaosflux Talk 11:36, 9 September 2016 (UTC)
    Alsee, massmessage is certainly not the only use case. Changing the content model of a page is useful to anyone who works with JSON or JS pages on a regular basis, which covers all user script developers and anyone who works with the meta:Meta:FormWizard gadget, which is used on a bunch of WikiProject pages. (See, for example, WP:WikiProject Women in Red.) Enterprisey (talk!) 16:33, 10 September 2016 (UTC)

I'm not clear on what the security implications are of changing, for example, a mainspace article to a Javascript content type. Would this enable anyone to create a mainspace page with arbitrary Javascript that would run in readers' browsers? isaacl (talk) 00:22, 10 September 2016 (UTC)

@Isaacl: The page you browse could be a css or js, but is not in the list of things to be run in readers' browsers, so there's no major concern. (There's an order to which CSS (and JS) gets loaded by the browser. I think some of that is detailed here. As far as I know, at the enwiki local level, there are some site-wise css/js, but most of what the user customizes would be at Special:MyPage/common.css, (and Special:MyPage/common.js), and depending on skin, a vector.css/js or monobook.css/js etc. I don't think it's possible to create a .css or .js and maliciously move it to another user's specific css/js title to get run, so that's not a concern either.)
But that also being said, there really shouldn't be any legitimate reason anyone changes a mainspace page to a CSS or JS other than a miscreation at a bad title. — Andy W. (talk · ctb) 01:42, 10 September 2016 (UTC)
  • Support per all above me. This is useful for massmessage-senders and other trusted users for a very specific type of work. Others won't need it and there's romm for potential disruption. So I agree this should be restricted to MM senders and sysops. MarcoAurelio (talk) 10:46, 10 September 2016 (UTC)
    MarcoAurelio, which "other trusted users" were you talking about? Changing the content model of a page is useful to anyone who works with JSON or JS pages on a regular basis, which covers all user script developers and anyone who works with the meta:Meta:FormWizard gadget, which is used on a bunch of WikiProject pages. (See, for example, WP:WikiProject Women in Red.) Enterprisey (talk!) 16:36, 10 September 2016 (UTC)
    Can you help explain what is the workflow where one would change the content type of a page? I would appreciate learning more about this topic. isaacl (talk)
    I'll give an example where I had to pester an admin. xaosflux and I were working on the Navigation Popups gadget, and he had the bright idea of making a template-style sandbox where we could test a beta version of the gadget, so he made it and immediately changed the content model to JavaScript. I missed this second change, so when I made a sandbox myself myself, I was initially confused and had to pester xaosflux until he changed the content model of it. If I had the permission, I could have done it myself. At the moment, whenever I want a new gadget sandbox, I have to go get an admin to do it. Heck, come to think of it, I don't think we'd see much community opposition if we were going to add it to something like template editor. Enterprisey (talk!) 04:17, 11 September 2016 (UTC)
  • Oppose. I see no benefit of restricting it. I've had to pester admins when I do need the content model of a page to be changed (which is when I've been working with gadget sandboxes). Enterprisey (talk!) 16:27, 10 September 2016 (UTC)
  • Repeating what I said at phabricator:T85847#2626070: We should empower users to be bold. :-) I favor as liberal permissions as possible in nearly all cases as I think that's the wiki way. In the case of editing a content model, it should not be any more disruptive than moving/renaming a page. --MZMcBride (talk) 20:47, 10 September 2016 (UTC)

Hi BethNaught and xaosflux. Thanks for participating in this discussion. Other than the undo issue, which I think everyone agrees should be fixed (thanks Lego and Bawolff for doing that!), are there problems you foresee with more users having this user right? --MZMcBride (talk) 20:52, 10 September 2016 (UTC)

I was thinking I should have started this discussion along the lines of "Which user level should we add this permission to" - and with undo working I think I'd be good with adding this to extenedconfirmed. — xaosflux Talk 21:58, 10 September 2016 (UTC)
Extendedconfirmed seems like an OK level to put it at, but TBH I'd prefer to get rid of that not extend use of it myself. To avoid policy creep I'd say keep it as-is at autoconfirmed. -- Ajraddatz (talk) 22:33, 10 September 2016 (UTC)
As much as I'm personally unenthusiastic about it, extendedconfirmed seems to be what the community thinks is an acceptably high bar for a lot of things, and for that reason, if we can't get consensus for autoconfirmed, extendedconfirmed seems to be a good place to put this right. Enterprisey (talk!) 04:13, 11 September 2016 (UTC)
xaosflux, also, as I've realized from the above discussion, I think it would be worth it to restart this RfC with your proposed question. We've only had nine firm !votes so far, and everyone in the discussion (as far as I can see) already keeps an eye on this page. Enterprisey (talk!) 04:19, 11 September 2016 (UTC)
T145344
@MZMcBride and Xaosflux: Yes, sorry to interrupt, but may I please get an answer about how User D fixes this scenario:
  • User A writes the last good revision to page "Foo".
  • User B maliciously changes the content model of "Foo" from wikitext to CSS.
  • User C edits the page in good faith.
  • User D would like to revert to User A's revision without knowledge of Special:ChangeContentModel. (as not required by the undo/rollback cases tested so far)
I think the answer is neither undo nor rollback nor Twinkle's revert-to-revision nor "manual edit previous revision" (which I believe is not possible today), i.e. not possible. Thanks, — Andy W. (talk · ctb) 06:13, 11 September 2016 (UTC)
I suspect they get lost test2wiki:Law3 has a 3 edit combo if you want to look. — xaosflux Talk 14:11, 11 September 2016 (UTC)
If the only mitigation is Special:ChangeContentModel, I believe this is a usability bug then, mostly because users are very much unaware of that special page, and don't know how to reverse a content model change when undo and rollback are not available. — Andy W. (talk · ctb) 19:17, 11 September 2016 (UTC)
Sorry, I forgot to respond here. I filed phab:T145316 for this and have a patch pending. Thank you for testing :) Legoktm (talk) 20:46, 11 September 2016 (UTC)
Hi Legoktm, sorry, the scenario I'm describing above is for a generic mainspace page "Foo" in which it becomes impossible to undo/revert for anyone, including sysops. Let me know if I need to clarify — Andy W. (talk · ctb) 20:53, 11 September 2016 (UTC)
Yeah, I read too fast and then just edit conflicted with you. I thought it was about your comment earlier that you can lock yourself out of editing a user's subpage if you convert it to CSS or JS. Back to this scenario. Why would User C edit the page if they observe that the layout was messed up by the last commit? Wouldn't they try to undo B's edit first before making their good faith edit?
For discoverability...I suppose we could add a change tag that indicates the edit changed the content model of the page, which would then link to documentation about changing content models? Legoktm (talk) 20:58, 11 September 2016 (UTC)
Legoktm Sorry for not having a phab acct at this time I'm assuming User C could be relatively new, doesn't know about undo, and edits a high-traffic mainspace page (perhaps 2016 Summer Olympics) in good faith (or even in bad) after User B. If such an edit happens, rollback would no longer reverse a contentmodel change. Is support for a revert-to-revision (edit previous revision) out of scope? If it is, I think content model changes are still more disruptive than moves. Perhaps a tag could work...? My impression is that we're supporting undo/rollback to ensure most folks can reverse bad content model changes, and a mitigation for this seemed to fit the bill. — Andy W. (talk · ctb) 21:09, 11 September 2016 (UTC)
Created phab:T145344 — Andy W. (talk · ctb) 22:32, 11 September 2016 (UTC)
I'm not OK with adding this to extendedconfirmed. That's massive scope creep. Now that improved revert capabilities have been added, and the situation is (per Redrose) not too dissimilar to page moving, I would be OK with a trial run added to autoconfirmed (and confirmed, don't forget about that), but with a speedy restriction along the lines of the original proposal here in case of any abuse. BethNaught (talk) 16:30, 11 September 2016 (UTC)

Update #2: This won't be going out today (Monday), it'll be Thursday at the earliest, I will post here once plans finalize and also email wikitech-ambassadors. Legoktm (talk) 10:21, 12 September 2016 (UTC)

  • Oppose It doesn't allow any damage that regular editing can't already cause, and it can be fixed as easily as regular vandalism. Jackmcbarn (talk) 02:50, 17 September 2016 (UTC)
  • I think this discussion has helped spawn a lot of the issues that are being addressed in phab:T85847, if they all get resolved (basically making these type of changes easy to undo by most anyone) and empowering other tools (like the Abuse Filter) my overall opposition to expansion will be much diminished. As far as protecting articles, are there any current use cases where an existing article should ever have its content model changed? An edit filter to prevent that for the mainspace could be deployed. — xaosflux Talk 12:45, 17 September 2016 (UTC)
    The filter can be extended possibly to mainspace and Module, perhaps? It looks like there's one for Module with a similar purpose. — Andy W. (talk · ctb) 00:43, 21 September 2016 (UTC)

Wikipedia has to come out against Trump

Pulling the plug on this. I see no supports and a long list of oppose votes with very strong comments. Even the OP seems to realize this is going nowhere. Not questioning good faith, but if there has been a more obvious case of WP:Dead on arrival in the last month or so, I can't recall. Not a fan of the whole trout thing but I will admit this tempted me. (Yes I am WP:INVOLVED- sue me or revert me if you really think this deserves further debate.) (non-admin closure) -Ad Orientem (talk) 20:44, 21 September 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.

--- Fine, fine, fine, I get the point you're not for this. P.S. my guess is that the original article that ticked Trump is actually this one. Kudos to Scientific American for respecting the people. Wnt (talk) 17:15, 21 September 2016 (UTC)

I am appalled to read that Donald Trump has now sunk to suggesting banning information about how to make bombs:

"But how do you allow magazines to be sold -- these are magazines that tell you, from step one, go to the store and buy such-and-such, right? ... Those people should be arrested because they are inciting violence, OK. They are making violence possible. They should be arrested immediately. They have websites that tell how to make bombs, how to make all sorts of things that are totally destructive, and you know where they are coming from, and yet we don't want to touch them because of freedom of speech."

This comes on the heels of his earlier hopes to "open up the libel laws" [8] even beyond the already appalling status quo that has allowed the destruction of an entire suite of publications at Gawker over one truthful publication.

Now I am not saying that Wikipedia should endorse Clinton or something like that, no. But it is time for it to stand up and say that by golly, how are we supposed to write an article like 2016 New York and New Jersey bombings without saying that the terrorist(s) got pressure cookers and lengths of pipe and filled them with tannerite and black powder? He seems to be envisioning a world where people - or at least, certain races of people - aren't allowed to know shit, I mean, where even saying the phrase "pressure cooker bomb" would be cause for somebody to get sent to jail because he might "incite" violence by "making it possible" for someone to do something.

It is contrary to the scholarly duties of Wikipedia, and it is just plain offensive to common sense. If we lose every liberty and become a herd of scared individuals afraid even to collaborate on an encyclopedia, what difference does it make if the government wins or the terrorists win? There will be no law but violence, no justice but death. Wnt (talk) 17:14, 19 September 2016 (UTC)

I didn't realize Wikipedia hosted bomb making articles. The fact is if Wikipedia comes out against one candidate you implicitly endorse the other and I don't think that's a good position to put Wikipedia in. Sure, oppose any policy or law that undermines Wikipedia's goals, but play the ball not the man. Betty Logan (talk) 17:20, 19 September 2016 (UTC)
WP:SOAPBOX and per Betty, no, I don't think we have to much less that we should. I can understand our single soapboxing moment (SOPA), but that had distinct implications for how the Internet and thusly Wikipedia works. --Izno (talk) 17:21, 19 September 2016 (UTC)
Did you mean WMF? I thought WMF was already allowed to take political positions. Wikipedia, per se, is nothing but a bunch of editors, and opinion of Trump is not a matter for community consensus. We may not be apolitical, but we should behave as if we are. Can you clarify? ―Mandruss ☎ 17:26, 19 September 2016 (UTC)
You are aware that 95% of the world isn't the United States, right? We already have the servers in Amsterdam; in the unlikely event that a situation ever arose in which the WMF felt it could no longer operate in the US, relocating would just be a case of re-registering the office elsewhere. Assuming you mean Wikipedia itself taking a political standpoint, that you happen to dislike a particular candidate in an election is certainly not grounds for jettisoning the first and most fundamental of the WMF's founding principles, nor would Wikipedia last more than a few weeks if we did. ‑ Iridescent 17:43, 19 September 2016 (UTC)

I see it would be hard to justify a site-wide black-out or even banner based on a few comments by someone who changes his spoken views every few months anyway. But what about an open letter or some kind of group protest? Wnt (talk) 18:13, 19 September 2016 (UTC)

My reply still applies. Like we don't have enough to bitterly battle about, we should battle over this? Take the recent Trump photo war. Multiply by about 100. ―Mandruss ☎ 18:17, 19 September 2016 (UTC)
As someone who supported both the blackout of the Italian and the English Wikipedia, I don't think we're anywhere near a comparable situation at this moment. So far we're looking at a knee-jerk reaction of a presidential candidate, not ready-made bill that is about to be passed by Congress. Even if Trump wins the election, I doubt he will ever be in a position to put his ideas into law (remember who's the legislative power in the US). When this day comes, we'll have a look at it again. --bender235 (talk) 19:35, 19 September 2016 (UTC)--bender235 (talk) 19:35, 19 September 2016 (UTC)
I'm astounded to see anything but 100% rejection of this proposal. Wikipedia is an encyclopedia, not a political activist organization. The editing population couldn't be more politically diverse, but we are to determine the political leanings of a plural majority and present that as "the Wikipedia position" on Donald Trump? I don't fucking think so. And that goes for any political issue. ―Mandruss ☎ 20:09, 19 September 2016 (UTC)
This isn't a place fo politics so no to this proposal. Please see WP:NOT Gary "Roach" Sanderson (talk) 20:18, 19 September 2016 (UTC)

Also in depth the policy has something, and it is doing it see What Wikipedia is not#Democracy Gary "Roach" Sanderson (talk) 20:22, 19 September 2016 (UTC)

  • As far as WMF doing anything, that's a nonstarter. 501(c)(3) organizations can, to a limited degree, discuss political issues (like the SOPA bit), but they are strictly and absolutely forbidden from endorsing (or "disendorsing") specific candidates. They'd lose their tax exemption. As far as editors doing it? Well, let's do as we always do. That is, keep the article accurate and neutral, and let the facts speak for themselves. With Trump...let's just say I think those facts shout pretty loudly indeed. We don't need to editorialize. Seraphimblade Talk to me 20:26, 19 September 2016 (UTC)
Works for me, and I stand corrected as to WMF. ―Mandruss ☎ 20:49, 19 September 2016 (UTC)
You ask..."how are we supposed to write an article like 2016 New York and New Jersey bombings without saying...?" We can say that the bombs were home made without giving the recipe. Actually, that's probably äll a general encyĉlopedia needs. Britmax (talk) 11:16, 21 September 2016 (UTC)
@Britmax: This very case illustrates how damaging that approach would be. A homeless guy wanted a backpack, grabbed the abandoned backpack, and recognized the pressure cooker bomb for what it was. [9] If ordinary people weren't allowed to know what a pressure cooker bomb is, and just had some genericized notion of "homemade bomb" resembling something out of a Bugs Bunny cartoon, he might well have simply left the bomb behind without telling anyone, or at least, set it off taking out himself and nearby people while curiously fiddling at it trying to figure out what it was.
Wikipedia must never be reenvisioned as a "general encyclopedia", in the sense of, containing only such information as is needed to entertain some dilettantes without serving the needs of the serious researcher or even the honestly interested reader. Wnt (talk) 15:09, 21 September 2016 (UTC)
  • Strong Oppose - Urge SNOW Close This proposal is shocking and contrary to both the letter and spirit of the WP:PILLARS. It is also incompatible with the longstanding tradition of avoiding any form of political editorializing. Anything even remotely along the lines of political endorsements or editorializing would inflict incalculable and possibly irreparable damage on the reputation of the project. For the record, I can't stand any of the candidates for President and I loathe Donald Trump. But if (purely for the sake of discussion) this proposal were adopted, I would immediately retire from Wikipedia and have nothing further to do with it. -Ad Orientem (talk) 15:31, 21 September 2016 (UTC)
Agreed. GenQuest "Talk to Me" 15:35, 21 September 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.

Wells Fargo Checking account scandal

I know this isn't technically the place to propose new articles, but I was very surprised to find that WP hadn't worked up an article on the Wells Fargo checking account scandal. I am having trouble finding the article or has this not made it to article creation yet? NickCT (talk) 17:03, 20 September 2016 (UTC)

WP:SOFIXIT. There is no mandatory "article creation" process. There's a process called "You want the article, just go make one". It's how approximately 100% of all Wikipedia articles got made in the first place. --Jayron32 17:40, 20 September 2016 (UTC)
@Jayron32: - Well I just might do that....! Honestly I was just here for a gut check. Does seem odd that this hasn't produced an article, no? Seems like a pretty major scandal. The notability seems obvious. NickCT (talk) 18:32, 20 September 2016 (UTC)
Nothing is obvious to people who haven't thought of it yet. Everything is obvious if you have. Obviousness is only a measure of the mental state of the singular person, not of the world outside of your mind. In other words, I have no idea why you have found it obvious, or why others have not. That's neither here nor there, it makes no difference at all why the article does not exist. If you have reliable sources, create the article. If you don't have reliable sources, don't. That's all there is to it. --Jayron32 19:08, 20 September 2016 (UTC)
@Jayron32: - re "Obviousness is only a measure of the mental state of the singular person, not of the world outside of your mind." - Well I think you just won the Zen Words of Wisdom prize. Thanks for the input. NickCT (talk) 13:04, 21 September 2016 (UTC)
I understand you wanted to make a compliment (or was it irony?). If this were true Zen, we would have no Captain Obvious. I would rather say that "obvious" is a subjective judgement which may or may not be commonly accepted, like in that joke about a mathematician presenting ("This formula is obvious." ... Fifteen minutes of hard thought later... "Yes, this is obvious indeed.")
As for the question itself, I am tempted to utter something Zenful about due diligence: "Confucius say: One and the same thing has many names, but only one is the True Name. A master of True Names never forks".
@NickCT:Wells Fargo#Consumer Financial Protection Bureau fines - The True Name thereof is not obvious yet. Staszek Lem (talk) 19:32, 21 September 2016 (UTC)
@Staszek Lem: - I'm not sure it was meant to be a complement or ironic. Just an observation about the philisophical nature of the comment.
I saw that subsection. Strikes me that the scandal is of a size that merits more than a subsection. Agree that name is non-obvious. NickCT (talk) 13:38, 22 September 2016 (UTC)
"name is non-obvious" - that's the point. Some scandals have buzznames, which can be searchable terms. Otherwise IMO no reason to crease a separate page before it grows out of a subsection naturally, per Wikipedia:Summary style. Obviously it does not strike you (or me or others) hard enough to WP:SOFIXIT, e.g., by a simple cut-and-paste... Staszek Lem (talk) 16:21, 22 September 2016 (UTC)

The future of New Page Patrol and Articles for Creation

Following 5 years of unstructured discussion, a dedicated venue has been created for combined discussion about NPP & AfC where a work group is also being composed to develop the necessary changes. It is not an RfC, it is a call for genuinely interested users who have significant experience in these areas to join a truly proactive work group. There is some reading to be done before signing up. See: Wikipedia:The future of NPP and AfC. --Kudpung กุดผึ้ง (talk) 11:22, 24 September 2016 (UTC)

Note about "Historical Lenses"

Not completely sure where to put this but there should be a template that explains that History is a living thing, in that the various ways it is interpreted can change over time...I don't know if "historical lens" is a thing or not, but the idea is that people see history through their own view points, and this should be explained somewhere and all articles related to history should have a link to this explanation. I don't mean it as a disclaimer, but more as a means of being open about POV in its various forms, and that the reader may be unaware of. Hires an editor (talk) 23:42, 20 September 2016 (UTC)

This is not going to happen, since virtually every article on Wikipedia is "related to history" in some way. Why we don't do this is already covered by our FAQ—Wikipedia does not aim and never has aimed to be objectively true, but to give due weight to all significant views of any given topic. If new sources are published which refute or challenge a claim made in a Wikipedia article, we rewrite the article to include them as appropriate. ‑ Iridescent 09:49, 21 September 2016 (UTC)
Hires an editor - I think this is a valid concern, and the article Historical criticism in Category:Literary_criticism seems to be close to what you mean, or perhaps Historical method suits. This is one of those areas google explains better than WP -- a google for historical lense would give you many academic resources such as "Eight Critical Lenses through Which Readers Can View Texts" or [ http://iheartenglish.pbworks.com/w/page/8809918/Historical%20Lens "Historical lens"]. Showing a Historical lens as the context of the time, and New Historicism as the context the reader works in.
I do think WP generally does poorly on historical material or acknowledging that viewpoints change over time, partly as a structural bias of WP, partly as a bias of modern over 'old', and partly from the convenience or volume effect in big data. But I'm not seeing how a template would help so will offer a couple alternatives you might look at.
  • Articles - in particular, I see that Evidence and Interpretation lack mentions of historians practices and values. They point at the scientific and legal, and there are individual articles for Evidence-based practice (medicine, Legal evidence, Evidence (law) so ... perhaps you could add linkages there for Historical evidence. (And just to note - truth, fact, and evidence can be distinguished...especially in context of an election year ;-) )
  • Projects - the Wikipedia:WikiProject_Council/Directory/History_and_society#History_and_society seems a good way to help, as both highlighting some articles for handling as Historical, and in general methods for better dealing with them
  • Essay - develop a WP:ESSAY to provide information and suggested approaches. An essay isn't a guideline or a policy but it does serve as a place to find some prior and independent guidance when article questions come up. The Wikipedia:Essay_directory has many that are good (and many that are poor), but they're at least available as independent, substantial, and relevant material. You might write up something and list it in Category:Wikipedia_guidance_essays.
  • Find existing items - you might look among existing items that are mentioned in TALK for history articles -- things like such as WP:RECENT, WP:NOT, WP:LISTPEOPLE, WP:SOLDIER, WP:SYNTH for example. Not sure if you'd want to make this a private list of note for history discussions, or a category of history policies or things to mention in your essay ....
Hope this helped. Cheers Markbassett (talk) 20:46, 25 September 2016 (UTC)

Make certain warning templates visible on mobile

Note: This thread has been moved back to live discussion to request a belated, formal closure. --McGeddon (talk) 17:19, 24 February 2017 (UTC)

Proposal: make protection of example pages consistent

I am going to open a community discussion about our various example pages, with the goal of making the content consistent and identifying whether any should be listed as potential merged/delete targets. My list so far is is below; please let me know if I missed any.

As a start, I would like to propose that all of the pages in the list below and all associated subpages be protected with 30/500 extended confirmed protection indefinite semiprotection and full move protection. Right now the protection is all over the map; most are unprotected, some are semiprotected, and one subpage of a semiprotected page (User:Example/Lipsum) is fully protected. These are high-visibility pages, are often vandalized, and there should be no reason for a new editor to change them. --Guy Macon (talk) 18:50, 3 October 2016 (UTC)

List of top-level example pages:

(Feel free to add to the above list --Guy Macon (talk) 18:50, 3 October 2016 (UTC))

Should we apply indefinite semiprotection and full move protection to example pages?

(Changed from "Should we apply 30/500 extended confirmed protection to example pages?" per compelling argument below.)

Comment: At present, User:Example is under indefinite semiprotection and full move protection. That seems about right. It is hard to get too excited about the others, but perhaps someone can give a convincing reason for protection. Extended confirmed protection is still controversial and it doesn't seem to be the best choice here. EdJohnston (talk) 02:33, 6 October 2016 (UTC)

  • If you look at the rationale given for WP:PREEMPTIVE, it clearly applies to articles, which indeed anyone should be able to edit. There is zero reason a brand-new editor should be mucking around with example pages, templates, etc. While the pages have only attracted a few non-autoconfirmed vandals over the years,[10][11][12] the main reason I think they should be semiprotected is because so many pages -- including high-visibility policy pages and noticeboard discussions -- link to them[13][14][15] that they are high visibility. --Guy Macon (talk) 15:50, 6 October 2016 (UTC)
    Well, if they don't get much vandalism, I don't see a reason to protect them. Also, I've seen problems in the past with unwarranted non-article protections causing pages to fall out of date, so I am concerned such a thing may happen there as well. So oppose. Jo-Jo Eumerus (talk, contributions) 19:04, 6 October 2016 (UTC)

A bot to replace curly quotation marks?

Hey, I'm not too sure about this being significant enough, so I'd like to get consensus first. Would it be good if I set up a bot which replaced curly quotation marks (“”) with standard quotation marks ("") per the MoS, then use AWB to do it? If that isn't significant enough, could I make it put in this template which informs users that there are curly quotes that need to be replaced instead? PhilrocMy contribs 13:00, 7 October 2016 (UTC)

Consider reviewing the discussion at WT:MOS#Measures in support of MOS:CURLY. --Izno (talk) 13:03, 7 October 2016 (UTC)

Proposals to create new "all" BLP tracking categories being held up

I have put in requests here, here, and here for template edits to populate useful new tracking categories. Without greater attention, a single editor has been able to completely derail the requests. Please weigh in here! —swpbT 19:28, 6 October 2016 (UTC)

Beuller? —swpbT 16:33, 7 October 2016 (UTC)

List of redirects

Perhaps for any article, under tools (on the left sidebar) there should be a "list of redirects" that list what redirects there, while what links here can suffice for smaller or less used articles, some articles have thousands of things that link to them, and having a dedicated list for redirects could help. Iazyges Consermonor Opus meum 04:57, 9 October 2016 (UTC)

@Iazyges: You've already got it. Click "What links here", then above the list you should see a line "External tools: Show redirects only". Click that link. --Redrose64 (talk) 09:14, 9 October 2016 (UTC)

Pending Changes bot

Would it be feasible to make a bot that would monitor Pending Changes articles and automatically report them to WP:RFPP when a certain ratio of an article's recent edits are reversions of pending changes? This came up in this discussion, where a page sat with pending for about two years an from the looks of it, almost every edit for the past 200 or so have been reversions of pending changes.

Doesn't seems terribly important what the initial ratio is as long as it errs on the low side. If 100% are protected by admins the standard can be adjusted to reduce false negatives until there is a noticeable effect. TimothyJosephWood 21:18, 6 October 2016 (UTC)

It should probably be feasable; the place where you would need to discuss this would probably be at Wikipedia:Bot requests. עוד מישהו Od Mishehu 04:46, 7 October 2016 (UTC)
OTOH, this would be the better venue to try to establish consensus for such a bot. Anomie⚔ 22:12, 9 October 2016 (UTC)

Wikipedian Effectiveness Training

Does community health at Wikipedia concern you? Do you belief communication between Wikipedians can be improved? I started a grant proposal to develop and deliver a Wikipedian Effectiveness Training. Feel free to endorse or comment the proposal at Grants:Project/Wikipedian Effectiveness Training. Ad Huikeshoven (talk) 17:51, 10 October 2016 (UTC)

I want to ask a question.

how can i display

  • confirmed by password
    • Indicates that the local account was merged because the user specified a valid password for it.

on Special:CentralAuth on 'method'???--주발사 (talk) 12:59, 10 October 2016 (UTC)

This is not the right venue for this question - ever since WP:SUL was rolled out this is not really applicable to the English Wikipedia anymore. If you have general questions about CentralAuth for other projects you can read more here mw:Extension:CentralAuth. — xaosflux Talk 01:43, 11 October 2016 (UTC)

Rate Limit for All Users

Per the obvious vandalbot contributions of Special:Contributions/Knowledgekid666, why hasn't en.wiki placed a rate limit on all users, whether IP all the way through admin? To me, that would make sense. --MuZemike 02:52, 9 October 2016 (UTC)

That would, IMO, be a major overreaction. Yes these things may happen sometimes but I think the people on this site, the community as it were, need to find a threshold of risk they are willing to accept for this sort of thing. It's a public and open site for the most part so I think we need to accept that occasionally, in that type of environment, these things will happen. When they do, we deal with them accordingly, not limit otherwise trustworthy users just in case and limit the amount of improvements are done in Wikipedia. That, to me, would be far worse and would have far greater impact than simply blocking and reverting the edits of the occasional vandal. Mr. Nosferatu (talk) 03:11, 9 October 2016 (UTC)
No need to rate restrict everyone to get rid of this, just remove (or limit) Twinkle's ability to do global unlinking. I've seen other vandals using Twinkle to do this exact same thing, and in my opinion it's just too dangerous a feature to have unrestricted. Meters (talk) 03:31, 9 October 2016 (UTC)
I regularly edit pages in groups of 64 open tabs (things like replacing "The the" with "The" or "the") and then submit all my changes in rapid succession. A global rate limit would inconvenience me. --Guy Macon (talk) 03:55, 9 October 2016 (UTC)
I do the same thing as Guy Macon. If you look in my contributions, you'll see edit rates as high as ten per minute when I am running an easy script with no false positives. I open all of the pages in tabs, run the script on each one, then quickly look through the proposed edits and save them in quick succession. I inspect every edit before saving. Rate limits should probably be listed on Wikipedia:Perennial_proposals; I have seen it come up a few times. – Jonesey95 (talk) 15:41, 11 October 2016 (UTC)

RFC on deferred changes

There is now a RFC on whether to implement deferred changes. Please comment at Wikipedia:Deferred changes/Request for comment 2016. Cenarium (talk) 09:05, 14 October 2016 (UTC)

Wikipedia:WikiProject Africa/The Africa Destubathon

Proposing that people sign up for this ;-) One last invite. If anybody wants to win up to $1800 (£1500) (in Amazon vouchers and subscriptions etc) for fleshing out a few African stubs this autumn sign up and help out! There's a chance to win a prize for most destubs for each African country, so 55 chances to win something, $1100 for that max. Then larger prizes for most geography/wildlife, women, core stubs and Good Article produced during the whole contest! People who win enough can get British Library, JSTOR and other subscriptions they want. Even if not interested in prizes any help is appreciated. Hope people here see that it is a good cause. It starts in just over two hours time and lasts until November 27th!♦ Dr. Blofeld 20:43, 14 October 2016 (UTC)

Animals don't adapt.

Animals don't adapt. A lot of articles just matter-of-factedly state things like "animals can adapt to [...]". It's just plain wrong. Animals don't adapt, animals are adapted. These errors should really be seen to. UtherPendrogn (talk) 19:48, 7 October 2016 (UTC)

Please provide scholarly sources which say so. Staszek Lem (talk) 20:48, 7 October 2016 (UTC)
And especially don't make edits like this:[16][17] without citation to scholarly sources which back up your rather *cough* unusual opinions about whether species adapt to environmental changes. --Guy Macon (talk) 22:00, 7 October 2016 (UTC)
Without a specific context a general context for your comment must be assumed. And in a general context, your comment is false. Animals can adapt. Animals adapt (i.e., change their behavior) all the time to suit the current environment. I suspect you are referring to "adapt" in terms of evolutionary change of species and in that regard you have a point but without specific examples, I'm be unwilling make any general statement like it's always incorrect to say "Animals adapt". Language has a surprisingly large amount of flexibility. I can perfectly well imagine sentences where somebody writes "Animals adapt" and they are using the word "animal" as a direct synonym for "species" and saying "species adapt" is surely not objectionable. There's lots of play here possible with the semantics, especially if the word "animal" is referring to an individual or a species. Your proposal doesn't seem fleshed out enough for serious consideration. Anyway, I can't imagine that there are so many instances that you cannot tackle this as a personal issue. WP:Be Bold and fix it. Jason Quinn (talk) 18:09, 8 October 2016 (UTC)
They shouldn't be so bold as to "fix it" without strong cited source support. Obvious enough to you and me, apparently not so obvious to the OP. ―Mandruss ☎ 19:25, 8 October 2016 (UTC)
Adapted by whom, one wonders? Chuntuk (talk) 13:24, 10 October 2016 (UTC)
It is usually best to avoid the passive tense unless the subject of the sentence is implicit. For example do not say "animals were adapted," say "x adapted the animals." Which raises the question, who or what adapted the animals? TFD (talk) 03:18, 11 October 2016 (UTC)
The passive should be used when the subject is unknown, unknowable or irrelevant. Consider: "the starting gun was fired and the runners surged forward...", no one cares or knows who fired the gun. Using a dislike of the passive to try to imply that a conciousness is required to drive evolution is a poor bit of rhetoric. Martin of Sheffield (talk) 08:59, 11 October 2016 (UTC)
It is explicit that the person firing the gun is a race official, because of the reaction of the unnamed runners. Compare your wording with "a gun was fired and the people fled in terror..." In that case we expect that at some point the writer will explain something about the identity of the gunman. TFD (talk) 08:16, 13 October 2016 (UTC)
err, that should be IMplicit. In your example there is no reason to assume that within the sentence the identity will be revealed. Indeed, perhaps the identity cannot be known, all that is important is the stampede occurred. Martin of Sheffield (talk) 09:50, 13 October 2016 (UTC)

Please see Adaptation. --167.58.115.233 (talk) 17:13, 18 October 2016 (UTC)

Wikipedia articles should have an additional expert-reviewed form, that would be "locked" from editing and updated periodically

Irrespective of all of the effort and good-will that goes into creating Wikipedia, one aspect of its use that seems to me an insurmountable problem is that whenever one reads something on Wikipedia, he or she - because of the anyone-can-edit feature of its method of assembling knowledge - can never be sure that what he or she "learned" is actually true. That is, even if the information is well-sourced and was perhaps prepared by putting earnest effort into it, it is still something that cannot insure one that what one learns on Wikipedia is something that one can have trust in and, for example, tell others without fear of misleading them. It might seem far-fetched, but I don't think it is impossible to imagine some large scale drive of humanity getting together and creating an unsurpassed in terms of its scope compendium of all of human knowledge that would also be reliable. But I do not see how that could be achieved without some form of expert review. — Preceding unsigned comment added by Curve-angle (talk • contribs) 21:25, 16 October 2016 (UTC)— Curve-angle (talk • contribs) has made few or no other edits outside this topic.

Odd that this is not already listed at Wikipedia:Perennial proposals. Whatever; I've seen many discussions of expert review over the years, and I recall that was the direction that Citizendium went in, to no good effect. Expert review is welcome, and there is a mechanism for supporting this. But freezing articles, or freezing the article which is displayed, has never had much support. Articles are edited on a daily basis. Experts are few and far between. The proposal, even were it possible, which I highly doubt, is largely unworkable. And there are other mechanisms, not least continual review by editors, to assure quality. Anticipating a sufficiency of experts is magic-wand thinking. Finally, it would be as well to try to encourage readers to be critical readers, and to evaluate and use the references. --Tagishsimon (talk) 21:27, 16 October 2016 (UTC)
And, less that's all too TL;DR, Citizendium has about 17,000 articles, of which 160 have been expert reviewed as of August 2016, despite this being their alleged modus operandii, and Wikipedia has 5M+ articles in English alone. So someone who really really tried hard to get that approach to work failed: now you suggest we implement the failed model on an article base 2 orders of magnitude greater. --Tagishsimon (talk) 21:32, 16 October 2016 (UTC)
I cannot help but think that the only way to deal with the problem of the fact that Wikipedia's current way of assembling knowledge leads to it being something that is such that if one uses it, one can never be sure that what one "learns" is actually true, and - unfortunately, but not impossibly-to-deal-with - something which, at the same time, is something in which an amount of knowledge with which no other initiative of a similar nature can compete is stored, cannot be dealt other than by rethinking and implementing some new form of knowledge processing and presentation, which is also something that I don't - realistically - know in what other way could it be achieved than by making the new method of knowledge creation dependent on pre-review by experts and establishing a new form of articles which would stay in their expert-reviewed form and be updated only periodically - every, say, 6 months. They could exist side by side with the editable by anyone articles - the old Wikipedia could, in fact, remain as it is - and part of their creation would rest on an appraisal and use (unless the editing was scarce or of low quality) of the contributions by users accumulated over that time. The experts could also - as Iazyges mentioned - be external to Wikipedia, although the precise nature of the organisation of this could take many forms - it could be people who do not work in universities or other educational institutions, it could be people from such institutions (such as, say, any given worker "adopting" an article or set of articles and being, perhaps in collaboration with an editor or other experts, responsible for it), it could be partnerships with institutions as wholes and not with individual people, or it could be something run by a coordinating organisation outside of the Wikimedia foundation (I do not want to claim credit for invoking the idea of outside partnerships - this goes to Iazyges, since he or she first mentioned it, but I am writing out what I think since I have too thought of this a bit). If an initiative of this scope - which I recognise, would not necessarily be something very easy to actually start implementing - became such that it gained sufficient traction, it could, (a) provide a relatively large number of people with an opportunity to contribute to something very much needed, in my opinion, by others - a free and reliable online encyclopaedia on any topic, and, (b) lead to a kind of new stage in Wikipedia's - and, perhaps, although to a smaller extent - humanity's development. I do not agree with your statement that there would be a lack of people who could edit it - especially in departments of fields such as psychology or sociology there are many people whose chief focus is to study things like "urban landscapes of dissent" or "identities" or to make up all kinds of clever sounding words which do not have much meaning beyond generic ones that already exist (such as calling analysis "deconstruction"). The measures that you have suggested - continual review by non-expert editors and encouragement of readers to be critical with regard to what they read - cannot address the problem of Wikipedia's inability to assure one that what one "learns" on it is something that one can have confidence in as being true.
Thanks also for mentioning Citizendium - it is not something I knew existed, although since I cannot look at it now I still do not have a good understanding - beyond what you mentioned - of what it is. There are not many things to which I want to commit to a 100%, so if I think I have a duty of a greater or lesser, but less than 100% extent, I cannot express this without sounding awkward, but what I want to say is that there is a high probability that I will look at what Citizendium is later :-).Curve-angle (talk) 15:39, 17 October 2016 (UTC)
What if we created a process known as expert review? It would be much like GA or FA but with external groups, perhaps universities who would review it? The danger in this is the risk of "handing over control" for lack of a better word. Iazyges Consermonor Opus meum 22:51, 16 October 2016 (UTC)
We have employed expert review in the past - not that I can find traces of it right now - but in the form of an expert doing a review - like GA or FA - and submitting a report on which editors do or do not act. So that differs from the OP's proposal in that we don't have the expert edit the article, nor do we 'lock' the article to the most recently reviewed version. And iirc it all worked well enough; reviews were done in good faith, results were acted on in good faith. There was no handing over of control. I'd be happy to see more of this done (and wikipedia is large enough that for all I know it still is going on_. --Tagishsimon (talk) 22:57, 16 October 2016 (UTC)
@Tagishsimon: Wikipedia:Expert review is a failed proposal. Experts are always welcome to give their opinions on a matter but since on the Internet, nobody knows you're a dog and there is no way to verify "experts" are who they say they are, expert opinions are treated the same way any other editor's opinion is. --Majora (talk) 01:02, 17 October 2016 (UTC)
I believe the medical editors are looking into something along these lines. I support the concept, but think it should be done as a pilot in a very limited way, and medical articles seem like a good candidate. I haven't checked recently, so I do not know whether the initiative is still being explored.--S Philbrick(Talk) 01:46, 17 October 2016 (UTC)
@WhatamIdoing and Doc James: probably have details. I know at least one Wikipedia article was submitted and accepted into some journal or another. --Izno (talk) 12:03, 17 October 2016 (UTC)
The article was dengue fever. Can be seen on pubmed here.
The WikiJournal of Medicine on Wikiversity is accepting submissions.[18]
If you are making an important decision you should never base it off a single source. If you spend enough time reading the medical literature you will find "errors" in journal article (including the Lancet), medical textbooks, and government websites. Wikipedia is no exception. Doc James (talk · contribs · email) 17:55, 17 October 2016 (UTC)
@Majora: Did you read what is written on the page and the related pages to which it links before linking to it? From that what is written on some of those pages (I did not read everything that is there, but did, in my opinion, read a sufficient amount to form an opinion) it seems that what the person or persons who wrote it are saying is that the references on which information in Wikipedia articles is based should be reviewed by experts. This does not have anything to do with what I'm proposing.Curve-angle (talk) 15:39, 17 October 2016 (UTC)
There are many other things I have to do at the moment, so my reply is not as appropriate time-wise as it perhaps could be desired, but I am already exerting quite a lot of effort. I just want to say that part of what S Philbrick said seems to me right - that, initially, at least, it would be a good idea only to attempt to implement such an initiative in a limited way. This could take the form of selecting, based on criteria such as (I, by the way, do not support the proposal that it should be medical articles that should be chosen first, but this is not something I want to get into on this talk page) to what extent does the article deal with knowledge that has entered the scientific or scholarly community and broader society as something well-known and widely accepted or the need to include equal numbers of articles for distinct fields of study, a set of initially chosen articles and then adding to that if the initiative is able to successfully move ahead.
With regard to Doc James's comment - it is not the case that experts' work is infallible, but it is something the nature of which is such that, if one uses it and is mislead, one can justify oneself better than if what one used were descriptions of facts, laws, theories and conceptions which were submitted into a system which does not require those, who want to submit, to disclose their identities and creates opportunities for falsifying them, and which is also such that the level of social significance of the sanctions that it can impose on those whose behaviour is in some way inappropriate cannot compare, meaningfully, to the significance that sanctions like having to justify oneself to one's colleagues or some university committee or being fired from a university have.Curve-angle (talk) 02:05, 19 October 2016 (UTC)
  • Define "expert". Then prove you are one. Then convince me that experts are less prone to edit warring and problematic behavior. Perennial proposal full of problems. Dennis Brown - 2¢ 10:39, 17 October 2016 (UTC)
    There's no evidence that they are more likely to eat bananas either. This needs to be investigated. Hawkeye7 (talk) 20:55, 17 October 2016 (UTC)
  • I jotted down some ideas a while ago about something like this. Basically have a separate 'shell' on a separate domain, that allows people to discuss/review wikipedia content and flag versions of articles etc. People on there would have to connect with verified identities and connect their profiles to their research etc. The idea is to bring 'experts' and 'amateurs' together, by keeping them separate, but giving them communication channels. —TheDJ (talk • contribs) 11:44, 17 October 2016 (UTC)
    • Half of our core medical editor community are health care professionals. We have a good number of experts here already. Doc James (talk · contribs · email) 17:56, 17 October 2016 (UTC)
      • On the Internet, nobody knows you're a dog. I have no doubt that medical experts are editing Wikipedia right now, to great benefit. The difference between saying that and proving that a particular editor is an expert is the problem; such certification processes would be rife with problems, including creating a "super class" of editors whose actions would be open to less scrutiny and who would have special privileges. We ALREADY use experts. It's called WP:RS and WP:V. Since we don't write original content, there's no real fear so long as people can read and summarize properly anyways. You don't need to be an expert to do that. Also see Essjay controversy, which is why many old-time Wikipedia editors (such as myself) are generally against expert certification. --Jayron32 18:26, 17 October 2016 (UTC)
        Wouldn't a proper certification system have prevented the Essjay scandal? Hawkeye7 (talk) 20:35, 17 October 2016 (UTC)
        Probably yes, but false credentials (which was the root of paparazzi hype) was not supposed to be a damage for wikipedia content, because from the very beginning, as wikipedia critics (starting from Larry Sanger) state it, "wikipedia is hostile towards experts" (in fact, wikipedia has no piety towards experts). IMO all drastic actions towards Essjay were under public pressure rather than because of actual harm Essjay brought to wikipedia content. In a way, IMO Essjay was a scapegoat to cover up wikipedians' gullibility in the times when everybody knows that nobody knows you're a dog. Staszek Lem (talk) 21:00, 17 October 2016 (UTC)
      • Izno, I believe that User:Anthonyhcole has done the most work on this. WhatamIdoing (talk) 02:59, 18 October 2016 (UTC)

All kinds of reviewing should be processes to improve pages. --167.58.115.233 (talk) 17:19, 18 October 2016 (UTC)

While having designated experts edit Wikipedia articles could be implemented, I believe that due to drawbacks in the nature of expertise this would end up being a bigger mess than a help. On the one hand, designating someone as an expert is possible (in general, it would be based on a publication & employment history; people will squabble over what "publication history" & "employment history" actually should mean), then providing that person with an account that identifies them as that person (since Twitter can do it, the Wikimedia Foundation should be capable of doing it). On the other hand, when it comes down to identifying experts in a given field, one finds that number to be surprisingly small. For example, when I was working on articles related to the history of the Empire of Trebizond, it soon became obvious that the number of living people who were publishing papers in all languages on that topic were not more than half a dozen -- & of whom only 2 or 3 could be expected to be proficient enough in English to edit the English language Wikipedia. While it could be said any expert in Byzantine -- or Turkish -- history could be qualified an expert, their knowledge of this chapter of Byzantine/Turkish history would not be that much better than an experienced Wikipedian who decided to devote a year of their spare time learning about the subject. And then there is the issue that if only one or two experts exist who could review a given group of articles, what's to prevent them from intentionally or unintentionally introducing errors or biases of their own? Wikipedia simply doesn't have the quality control system of, say, the Stanford Encyclopedia of Philosophy, which was structured to deal with the issue of having, in essence, one person write & own an article. Maybe someday Wikipedia will need to look at this option, but it doesn't help the project today. -- llywrch (talk) 21:22, 18 October 2016 (UTC)

Just going more off of this, what exactly qualifies a person as an "expert" in a field? I consider myself an expert in DNA since that is my job and I deal with it on a daily basis (minus weekends). I'm not published though. I have no peer reviewed articles that can prove my expertise. I am an expert by practice and experience. How would we deal with situations like that? Who decides who is an expert and in what field they are an expert in? I don't expect people to submit resumes/CVs in order to be qualified as an expert on Wikipedia. Where would they sent it to anyways? The WMF? That isn't going to happen. The Foundation doesn't generally intervene in project level affairs unless it is a legal matter. OTRS? Good luck with that one. We are swamped as it is with what we have. An expert noticeboard? That isn't going to work. Information that would show expertise is generally private information and I doubt many people would disclose such things on a public forum just to get an "expert check mark". Then there is one of the founding principles of Wikipedia that every editor is equal. Minus some of the user level implementations that has pretty much remained constant since the beginning. Qualified experts in a field would not be any more "correct" in a dispute than any other editor. They wouldn't get special privileges since that is not what Wikipedia is. There are just far too many problems with any expert qualification system. I just don't see this as gaining any actual traction. --Majora (talk) 20:40, 19 October 2016 (UTC)
And when they violate our policies and guidelines because they don't know them? Who's going to train them? And I don't know how you get over the fact that in fields where there are disputes between experts, how would we deal with this? Take a look at Earthquake prediction which is at WP:COIN right now. Doug Weller talk 20:42, 19 October 2016 (UTC)

Filter languages

Don't know if this is the right forum, but Is it possible to choose which languages appear under "Languages" in the left-hand menu bar? This in order to eliminate the need to scroll up/down when switching between languages that are alphabetically far from each other. Vesaraisanen (talk) 14:53, 17 October 2016 (UTC)

There is: Compact Language Links. You can turn it on in the Beta preferences tab. – Finnusertop (talk ⋅ contribs) 15:01, 17 October 2016 (UTC)
If you turn this on, then it will first 'guess' which languages you might want (based on location and the language you start at). After that, it will 'learn' which languages you want by seeing what other Wikipedia languages you visit the most often. Whatamidoing (WMF) (talk) 20:43, 19 October 2016 (UTC)

Collapse refrences

proposal lapsed with the blocking of the OP --Tagishsimon (talk) 22:12, 19 October 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 am proposing a way to collapse long reference sections — Preceding unsigned comment added by Marfyman (talk • contribs) 21:05, 19 October 2016 (UTC)

What the user is doing currently is using discussion-collapse templates ({{hat}} and {{hab}}) to collapse the reference section. Since that leaves a message about the discussion being closed, that is absolutely an inappropriate way to collapse the reference sections. —C.Fred (talk) 21:12, 19 October 2016 (UTC)
Marfyman, can you point me to anywhere where you have got consensus for collapsing reference sections? Or are you doing this simply because you don't value reference sections? More importantly, can you tell me, does the reference system survive your collpsing. If I click on a reference-number in the text, am I taken to an uncollapsed reference? --Tagishsimon (talk) 21:17, 19 October 2016 (UTC)
Collapsing references sections is a bad idea, and there is consensus for not doing so, as documented here. – Finnusertop (talk ⋅ contribs) 21:27, 19 October 2016 (UTC)
I agree that it is a bad idea. It should be noted that the OP also started this thread Wikipedia:Administrators' noticeboard/Incidents#Refrence hatting and reverts. MarnetteD|Talk 21:31, 19 October 2016 (UTC)
Update: Marfyman is now blocked so this can be closed unless anyone sees need for further discussion. MarnetteD|Talk 22:06, 19 October 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.

What would be nice - and no consensus is needed for this - is for some user script that will do this. עוד מישהו Od Mishehu 18:06, 20 October 2016 (UTC)

Since the suggestion goes against MOS:DONTHIDE it looks like consensus would be needed.MarnetteD|Talk 18:22, 20 October 2016 (UTC)
I came out of the other side of that double-take, realising the OP means a script which users can voluntarily inflict upon themselves. --Tagishsimon (talk) 18:26, 20 October 2016 (UTC)
DONTHIDE applies to the content shown to the general public, not to scripts which individual users use only because they personally want to. If I want to have content hidden for me, while I'm logged in, I'm permitted to use a script to do this. עוד מישהו Od Mishehu 19:38, 20 October 2016 (UTC)
The OP (of the closed thread) is Wikipedia:Long-term abuse/ItsLassieTime whose latest socks have taken to collapsing reference sections in articles. That content is, most definitely, shown to the general public. Individual scripts (which your first post makes no mention of) have nothing to do with the matter at hand. However, and by all means, if you want something that works for you why not ask at the VPT as someone there can probably whip up what you need. MarnetteD|Talk 16:42, 22 October 2016 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_134&oldid=1136718825"