Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

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

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

RfC: Deprecate named coordinates-related infobox parameters

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)#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. 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)
        • @RexxS: I personally don't have any objection against using coordinates from Wikidata (as long as it's clear that they're taken from Wikidata), but that would probably require another RFC, as Wikidata, somehow, is a very contentious topic and people hate it. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 08:49, 13 August 2016 (UTC)
          • Yes, there are several vocal editors who dislike Wikidata, and some of their reservations are well-founded. Nevertheless, we had an extensive RfC in 2013 that showed a clear consensus for infoboxes to draw information from Wikidata. There's no need for another RfC on that point. As for the recent RfC you indicate, we now have the ability to code infoboxes so that the choice of "opt-in" or "opt-out" may be made at the article level. --RexxS (talk) 09: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 | region | {{Coord|51|27|N|0|03|E|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)#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)

• Comment For future reference, there are about 200 templates each, not including sandboxes, containing either a latitude parameter or a coordinates parameter. The latitude parameter search has a few false positives, mostly assorted NATO insignia templates which use |lat= for some reason. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 07:42, 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.

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)

Proposal for a confidential COI mailing list

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)

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)

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)

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. Monty₈₄₅ 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 emergencywikimedia.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)

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)

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.

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)

Tag "lines" link to the tag in question

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)

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)