Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Izno (talk | contribs) at 15:53, 10 May 2017 (→‎RfC: LTA Knowledgebase: sign as third and final closer). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


Adding an 'infrared flash photography' page to the wiki

After reviewing your 'Pages in category “Photography by genre”' I see you are missing a listing for infrared photography and infrared flash photography on the list. I gave up wasting my time with the Wiki after you deleted 200 of my photos because I would not allow commercial use. But if you want to add an infrared flash photography page you can take what you like from my photos here:

https://danielteolijr.wordpress.com/2015/08/17/piercing-darkness-update/

Just no commercial use of the photos, only educational and editorial use. The link also discusses the history of infrared flash photography which I am a specialist and world leader in.

Best Regards,

danielteolijr

We already have Category:Infrared imaging whereas Genre I would think refers to something else rather than the recording medium, method etc., itself. Yet it is worth considering a fresh look at these cats.Aspro (talk) 16:02, 27 April 2017 (UTC)[reply]
Because Wikimedia Commons is the main host for images, the development of categories should be mostly there. I have uploaded images myself in the infrared category, but not used flash. Instead most are illuminated by sunlight. Anyway as soon as there is one image uploaded in that category, you are welcome to create the category. The structure on commons is untidy. There its in category "Photography by style". Subcats could be thermal infrared images, astronomical images, naturally lit NIR, artificially lit NIR (eg for animals so they are not disturbed), and you can add flash, but I see no images like that now. On commons images should have an educational use, and be free. Here images should at least be useful. Graeme Bartlett (talk) 23:29, 2 May 2017 (UTC)[reply]

Project participants bot

A lot of WikiProjects have a participants page where people can sign up and say they are a member; however, those pages tend to get stale over time. I'd like to see a bot analyze the contributions of users who edit pages under a project banner and then give out a list of those editors who are, for example, in the top 25th percentile for activity. I would think that it should only run once a month, similar to how Popular Pages worked (or is it back again)? –Fredddie™ 21:16, 27 April 2017 (UTC)[reply]

@Fredddie: see Wikipedia:Bot requests to request someone build a bot. — xaosflux Talk 00:12, 28 April 2017 (UTC)[reply]
OK, but I was hoping I'd get some input on whether or not it's a good idea. –Fredddie™ 10:47, 28 April 2017 (UTC)[reply]

That would be useful for lots of other things, like asking for help to someone that is not active or another lot of functions that people enrole just once. Whatever list of inactive members is annoying --Neurorebel (talk) 23:06, 1 May 2017 (UTC)[reply]

You may be interested in Wikipedia:WikiProject Directory/All, which lists the participants (people who edit the WikiProject's talk page) and editors (people who edit the articles in its scope, even if they don't know or care about the group's existence).
If you are trying to make a list of who's edit the identified articles the most times, then it's a bit more complicated, but WP:MED does this every year. WhatamIdoing (talk) 06:34, 8 May 2017 (UTC)[reply]

Contribs link for signatures

Withdrawn
 – by OP. ―Mandruss ☎ 16:47, 1 May 2017 (UTC)[reply]

Hello, I would like to point to this discussion about a proposal of mine to also have a contributions link automatically created when adding one's signature. I think this could be a quite useful improvement, as we already have user page, talk and contribs links for all edits listed in revision histories. What do you think about that?--Hubon (talk) 16:22, 29 April 2017 (UTC)[reply]

Might be a good idea. Maybe do this: [[User:Example|Example]] ([[User talk:Example|talk]] | [[Special:Contributions/Example|contributions]]). It looks like this: Example (talk | contributions). The only real problem I can envision is length. RileyBugz会話投稿記録 17:19, 29 April 2017 (UTC)[reply]
This is already done for IP addresses. At one time, only usernames were linked in signatures so it is possible we could extend to include contributions too. I do agree though, that's a lot of links. Aiken D 17:21, 29 April 2017 (UTC)[reply]
Take a look at Wikipedia:Tools/Navigation popups. If you enable this and hover over a user signature on a talk page or history or watchlist, you get a pop-up displaying all sorts of information about a user including a link to their contributions. StarryGrandma (talk) 00:32, 30 April 2017 (UTC)[reply]
This is already done for IP addresses. Apparently not. ---> 68.97.37.107 (talk) 01:08, 30 April 2017 (UTC)[reply]
It is in place of the user page. RileyBugz会話投稿記録 01:19, 30 April 2017 (UTC)[reply]
I sit corrected, but it's still not equivalent to what is being proposed. 68.97.37.107 (talk) 01:21, 30 April 2017 (UTC)[reply]
In my opinion this shouldn't be done system-wide, although any editor can choose to do it with a custom signature. It took me a few days to learn how to get to contribs quickly enough, via the page history of the user page or the user-talk page, or any other page history where the editor has edited recently. It takes 3 or 4 clicks and 5 or 10 seconds in most cases. Granted, we could say the same for the talk link, but it's already in place and thousands of editors are used to having it there (and, unlike contribs, use of user talk is a fundamental part of good editing). In any case, such a dramatic change will not be made without clear consensus in an RfC here, so we're wasting time in this discussion. If this is just "testing the water", that's more appropriately done at WP:VPI. ―Mandruss ☎ 01:40, 30 April 2017 (UTC)[reply]
@Hubon: I have now belatedly read the Help desk discussion, now archived here. A couple of points:
1. You have multiple times argued that the presence of contribs links in page histories justifies them in signatures. In my view that's an argument against. As I said above, the contribs are accessed easily enough via any of a number of page histories.
2. The change is not without a cost. Except for RileyBugz's brief comment above - The only real problem I can envision is length. - the downside of this change hasn't been stated in either discussion, probably because it should be obvious. It would significantly increase the length of the code for every default signature, thus using more of the edit window for code "overhead" and less for comments. By my count the number of characters added would be (38 plus the length of the username). If we wanted the spaces on either side of the vertical bar to be non-breaking spaces ( ), that becomes (48 plus the length of the username). It would also add 11 characters to every default signature on the rendered page. (These counts assume that it would be Example (talk | contribs), consistent with page histories, not Example (talk | contributions) as shown above). And finally, the change would also result in more contribs links in custom signatures, as many of those editors would be reluctant to provide less functionality than the default. ―Mandruss ☎ 00:33, 1 May 2017 (UTC)[reply]
@Mandruss: Thanks for getting involved! Now, if you ask me, I'd definitely still say it would be worthwhile – since the contribs link is in any case just as significant as the user page or user talk link, if not even more meaningful to immediately find out about the user's editing behavior and experience, their areas of interest, their activity in general etc. And as far as I'm concerned, we don't need spaces next to the middle bar at all. Though the others might take a different view... Best regards--Hubon (talk) 01:13, 1 May 2017 (UTC)[reply]
@Hubon: Ok, well I think it's time for you to go to RfC or drop the issue (remember, there is a strong inertial force working against you). You would need to clearly lay out the options (I see 3 options plus "no change") and the precise costs of each option. If you want some help with that, hit me up on my talk page and we can develop it in one of my sandboxes. ―Mandruss ☎ 01:34, 1 May 2017 (UTC)[reply]
  • This isn't going to fly, sorry. If it were compulsory it might be worthwhile because then there would be a uniform approach to how signatures work. However, compulsion will not work regarding signatures (see a couple of threads near the bottom of WT:Signatures as examples where even timestamps are being abused). Adding to clutter on talk pages simply to allow people to find someone's contributions in one click rather than two is pointless. As mentioned, anyone can add a contribs link to their own signature if they think their contributions warrant highlighting. Johnuniq (talk) 02:28, 1 May 2017 (UTC)[reply]

In discussion at my TP, it came to light that contribs are already just two clicks away from the signature, via the sidebar of the user page. (In hindsight, Johnuniq may have hinted at this above.) Thus, this change would save only one click. With that information, the OP said they withdraw the proposal. I agree with them that an optional tool to add these links only for oneself (at rendering time) would be nice, if there is an editor with the skills, the time, and the inclination. Marked as resolved. ―Mandruss ☎ 16:47, 1 May 2017 (UTC)[reply]

I added a contribs link to my own signature some time ago, and I know other users have links in their own custom sigs. I don't know if anyone finds it useful. I think *I* find it useful from time to time. Ivanvector (Talk/Edits) 23:58, 3 May 2017 (UTC)[reply]

On-wiki requests for oversight

Looking for an unrelated thread, I came across the "Where can I request visibility of edits to be removed?" section of Wikipedia:Help desk/Archives/2016 December 14, and a new-for-me idea came to mind. What if we had a submit-requests-here page for requesting oversight, monitored by a bot that would (1) automatically oversight the request itself immediately after it was made, and (2) add it to a fully protected page that lists not-yet-handled requests, so that the oversighters could see what's waiting to be resolved? Benefits: simpler request process (it's all on-wiki; no email needed), at a central location rather than requiring everyone to make requests privately (of course, this wouldn't be a reason to tell people not to make private requests), it's all in the history of in that central location (so the oversighters can see who's making requests, if necessary) rather than being done on oversighters' talk pages and via email, it's secure thanks to the watchful bot (if you're not an oversighter, you can't see anything about the request), and if you game the system by submitting bad requests, the oversighter can reject the request just by removing the entry from the log. Downsides: it depends on the bot constantly running, and it requires a tiny bit of extra work from oversighters, as they have to remove the entry from the log as well as doing the oversight. I don't see these downsides as significant, compared to the benefits. Your opinions? As soon as I hit "save", I'm going to email the oversight list with a request for opinion from the oversighters. Nyttend (talk) 01:38, 1 May 2017 (UTC)[reply]

Only problem I could see with this is that it essentially gives anyone the ability to redact history entries. A troll (or group of trolls) can force the redaction of hundreds of pages before they were stopped. The cleanup could potentially be immense.

I would like to know some stats before I comment further than that. How long does it take for normal oversight requests to be handled? I frequent IRC and I can usually find an oversighter immediately when necessary as one is usually available 24/7. How about the turn-around time for the email queue? --Majora (talk) 01:43, 1 May 2017 (UTC)[reply]

I see no problem with current oversight process. I've deleted some pages requiring oversight and contacted the oversighters via e-mail. I was very pleased with the timeliness of their response-- almost immediate. Oversight requires human clue and sensitivity. Potential problems from making it bot related could be enormous and increase risk of exposure of sensitive material. Dlohcierekim 01:56, 1 May 2017 (UTC)[reply]

The potential for abuse is startling. I have used oversight several times (by email) and the response has always been very fast. Only experienced editors understand what needs oversight and how to get that done, and such editors generally have email enabled. Other editors generally post somewhere like AN or ANI despite the edit notices telling them not to. Johnuniq (talk) 02:33, 1 May 2017 (UTC)[reply]

  • My concern with this would be that often oversight requires multiple revisions, and from personal experience dealing with rev del and oversight for a variety of reasons, there are a limited number of admins who know how to handle revision deletion requests with the correct number of revisions (oftentimes an admin will either over rev del or under rev del). This makes me not like the idea of a bot handleing it automatically. The times I have requested oversight, the oversighters have always gotten the correct number of revisions right. Basically, if some of our admins have issues getting rev del correct for less sensitive matters, I don't think your average user is going to be able to list the revision numbers needed to the precision needed for a bot to act upon it. The email based system works best IMO. TonyBallioni (talk) 02:41, 1 May 2017 (UTC)[reply]

I'm very confused why people find this problematic on abuse or technical grounds. How would someone be able to get something oversighted improperly, and why do we care about a bot's ability to handle multiple revisions? I'm suggesting that the bot oversights the request (so that we avoid drawing undue attention to the page with problematic information) but doesn't touch anything else. The bot would start with the workflow of a sandbox-clearing bot (when the page is edited, wait a period of time and then restore it to a specified condition) with a much shorter delay before clearing (30 seconds? 1 minute?), but unlike the sandbox-clearing bot, it would then oversight the edit that made the request and add a link to the log page saying basically "Oversighters, here's a request that you need to examine". An oversighter would look at the request, remove it from the log, and either do something about the request (if it warranted action) or ignore it (if it didn't). Nyttend (talk) 03:13, 1 May 2017 (UTC)[reply]

@Nyttend: I misread your statement as saying that the bot would oversight the requested revisions. My bad. I've struck my comment. I don't see any issue with the current system, but after your explanation I don't see any reason to not have your proposal. TonyBallioni (talk) 03:25, 1 May 2017 (UTC)[reply]
My mistake as well, Nyttend. I misunderstood the proposal. I'm still not completely convinced this would be necessary though. And even having it onwiki at all still presents problems with visibility. I'd still like to know the turn-around time for currently available oversight requests. If it is already reasonably short, this may not be that necessary. --Majora (talk) 03:37, 1 May 2017 (UTC)[reply]

Logistical point: emailing oversight turns your email into an OTRS ticket. Normally those are handled by one person. There's no way for non-oversighters to directly email the oversight discussion list, so the usual way is to email the functionaries list instead, which I just did. On the substantive issue, this seems to add a lot of moving parts for not a lot of obvious advantage. In general, simple OS requests are handled pretty quickly. If a request sits around for a while, it's probably because it's not obvious that suppression is the best option. Is there a problem with the current system that you think needs solving? Opabinia regalis (talk) 03:51, 1 May 2017 (UTC)[reply]

  • I don't see any advantage to this proposal, and considering the potential of an offline bot leaving the requests sitting in the open, a lot of disadvantage. The current system isn't perfect, but it serves its purpose. ​—DoRD (talk)​ 12:32, 1 May 2017 (UTC)[reply]
  • My first thought is the Streisand effect. It would be trivially easy for someone to set up a bot to scrape the requests page and then the linked article or edit before it could be examined by an oversighter (we're quick but we're not bots) and copy that to some off-wiki venue for later perusal of personal details, etc. I think this strongly outweighs any potential benefits this might bring (and I'm not really convinced there are any significant benefits), so I'm firmly opposed. Thryduulf (talk) 13:58, 1 May 2017 (UTC)[reply]
  • Per Thryduulf; if we can create a bot that watches the page and oversights it right away, someone else can create a bot that watches the page and makes a copy of the page before it's oversighted. Combine that with the possibility of the bot going down, and with the lack of evidence that there's a problem with the way we handle things now. We've chosen not to rely on bots to protect images on the main page; it seems unwise to rely on them for oversight requests. --Floquenbeam (talk) 14:53, 1 May 2017 (UTC)[reply]
  • There's a lot of benefit to having dialogue with the submitters of requests. Ignoring the biggest hurdle (an offline bot), I think the second biggest problem with this idea is how much harder it would make it to communicate. Sometimes people email us back to say we missed something when we thought we'd finished oversighting. Sometimes we have to ask for further information. And we often have to respond to say that the request doesn't meet the criteria. If the submitter doesn't have email enabled or doesn't have an account at all, how would we contact them? Knowing their user name or their IP would be useless. Keeping all this in a ticket and corresponding via email is helpful, or by IRC. And the third stumbling block, I think, is that if the request is immediately oversighted, then there's little confirmation for the submitter that the request has gone through, or if they formatted it correctly. It's not like being able to confirm that you definitely sent an email to the correct email address. If suppression wasn't dealt with immediately, or within hours, or within days, the user would probably end up emailing anyway. And if it wasn't dealt with because it didn't meet the criteria, for example, and not because of backlog, then we double the work in that case by another oversighter having to check the same content for suitability. Julia\talk 15:02, 1 May 2017 (UTC)[reply]
  • This long-term member of the suppression team is recoiling in horror at the very idea. This strikes me as a clunky, overly complicated error prone alternate process that offers little to no benefit over the current method. Email addresses are literaly free and unlimited, so that is not a real hurdle to reporting. Although using Wikiepdia's internal email system is the easiest way, it is not required and we get mail all the time from outside of the internal system. There's just too much risk here and not enough benefit. Beeblebrox (talk) 02:18, 2 May 2017 (UTC)[reply]

Sorry, everyone; I didn't realise that this would be deemed such a big risk, and I was totally unaware of the importance of dialogue between oversighter and requester — I've only ever made a few requests, and as far as I remember, they always got accepted with just a "thank you", so I figured all requests were answered with "thanks, we got it" or "thanks, but this doesn't qualify". Nyttend (talk) 16:55, 3 May 2017 (UTC)[reply]

No problem! It's always good to come up with ideas, even if they don't work out. (And I was totally bewildered by oversight and everything involved for, oh, like my first 4 months on the job. Or maybe more. So I get it.) Julia\talk 21:08, 3 May 2017 (UTC)[reply]

Tentative solution to promotional articles

We all know all the bearing the community does about them but promotional articles are not a problem if they are neutral enough, the real problem is the over-existence of them over other more sensitive to Wikipedias aims, then a way of balancing this could be instating the exigence that for every article about a company, brand or service, relevant or not that itscreator to before create or improve sanother more sensitive article like one of which creation or improvement is being reclaimed. This proposal being put on practice will equiparate every article about a company with other article describing another area of knowledge, being this one good article for every promotional one.

On the favor of my proposal are total neutrality and balance.

This does not mean more promotional articles but equal or less quantity of them and much more non promotional oriented ones. 

--Neurorebel (talk) 23:43, 1 May 2017 (UTC)[reply]
I'm really trying to parse out what exactly you are proposing here, but you haven't made it easy. Are you suggesting a quid pro quo system of some sort? You may want read my essay on how to propose policy changes before proceeding with this, as it is I wouldn't expect much of a reply because your proposal is terribly unclear. Beeblebrox (talk) 02:12, 2 May 2017 (UTC)[reply]
@Neurorebel:, Like Beeblebrox, I don't really know what you are trying to say here, but one thing is reasonably clear and I will respond to that. You say but promotional articles are not a problem if they are neutral enough, but that is incorrect. Promotional articles are by definition NOT neutral. If they were neutral they would not be considered promotional. I suspect that the rest of your proposal rests on the premise that promotional and neutral are compatible, so the argument fails. Cheers, • • • Peter (Southwood) (talk): 12:11, 2 May 2017 (UTC)[reply]
@Beeblebrox: YOu have perfectly resumed what i wanted to tell: Quid pro quo for articles describing brands, companies or any other profit activity, and which (for sure) already accomplish with neutrality standards.--Neurorebel (talk) 20:22, 2 May 2017 (UTC)[reply]
@Pbsouthwood: Despite of my bad english and the quick redaction i think the proposal would be clear to understand at a glance if you dont fringe the terms that much, I have used another more extensive definition of promotional article and its every article that in some way involves a commercial brand or a company or any kind of campaign.
I will clarify with an example: lets suppose that someone wants to create an article about a music group hence according to my proposal that person would have to apply to two conditions: 1) Neutrality (that already it is) 2) Write or improve one article that is requested by the community before creating his desired one (this is the part of my proposal), for the sake of the example Hutchison effect .
We can resume this idea as "only good doers can involve on sensitive articles in the community".
This additional requirement would discourage any publicist that feels that his company can get beneficed even through accomplishing with neutrality standards. --Neurorebel (talk) 19:50, 2 May 2017 (UTC)[reply]
Well, you've made it slightly more clear that it is a proposal for a quid pro quo system, which I would give a 0% chance of being enacted. Even if you somehow convinced the community here that this was desirable, I'm pretty sure the Wikimedia Foundation would not allow it. Many of our best articles started in pretty poor shape, created by new users with no clue. Beeblebrox (talk) 20:21, 2 May 2017 (UTC)[reply]
Neurorebel, Sorry, that was the only part of your proposal that I could understand at the time. I responded as appeared appropriate at the time. It is up to you to make yourself understood, not for us to puzzle out what you might possibly mean. There are just too many ways we could get it wrong. Cheers, • • • Peter (Southwood) (talk): 05:48, 3 May 2017 (UTC)[reply]
@Beeblebox: You gave me term, thanks, Better that that "poor article" be a requested one, that another one more about Justin Beaver, or what is worse that brand new hotel chain looking for free advertisement.--Neurorebel (talk) 20:37, 2 May 2017 (UTC)[reply]
There is a small nod to this idea, in that new users have to have made ten edits and wait four days before creating a new article. New users can get away with making none of the ten edits in mainspace, of course, but I'm sure a number of them spend the four days improving articles. IMO it is more sensible to encourage new users to improve the existing articles than to expect them to create new ones on subjects chosen by someone else.—Anne Delong (talk) 02:09, 3 May 2017 (UTC)[reply]
Anne Delong. Do you know if there are any stats on what the 10 edits usually involve? • • • Peter (Southwood) (talk): 05:48, 3 May 2017 (UTC)[reply]
Sorry, Pbsouthwood, I don't know.—Anne Delong (talk) 12:25, 3 May 2017 (UTC)[reply]
Neurorebel. I see no useful purpose in putting an additional obstacle before a new editor who may have good contributions in mind but no interest or knowledge relating to the list of article requests. People edit and create articles on subjects that interest them and about which they generally have some knowledge. • • • Peter (Southwood) (talk): 05:48, 3 May 2017 (UTC)[reply]
@Pbsouthwood: No problem against that last, I must make me understand here, Does all that stuff about the new users come from the assumption that new user tend to create promotional articles? if not I cant figure out from where it comes besides that ten editions rules that Anne Delong mentioned, my focus is on potentially promotional articles and not on the poor new user that yet have a lot of impediments. --Neurorebel (talk) 06:01, 3 May 2017 (UTC)[reply]
(ec) Neurorebel. To get back to your original proposal: There is no contravention of terms of use to write an article that in some way involves a commercial brand or a company or any kind of campaign. provided that the subject is notable and coverage is encyclopedic, i.e.: neutral, accurate, verifiable, due, etc. If an entity gains in some way by having an encyclopaedic article about it, that is a side effect which is not contrary to the purpose of Wikipedia. • • • Peter (Southwood) (talk): 06:09, 3 May 2017 (UTC)[reply]
Pbsouthwood then that is the part of the terms of use that we should change since hosting overnumbered articles that talk about a company should be contrary to the purpose of Wikipedia.--Neurorebel (talk) 06:21, 3 May 2017 (UTC)[reply]
I have done a lot of work at WP:AFC, where many new users write their first article, and there certainly is an overweight of such drafts that are promotional and company/organization-related. If two subjects are equally notable, but the first is about a general scientific or cultural topic and the second is about a subject through which someone can make money, chances are much greater that there will be single-purpose users, new or not, making sure that there is an article about the second topic. Also, a lot of our other editors' time is taken up in removing the promotional aspects of these articles, when they could be off improving articles about science, geography or culture. However, I think the best way to rebalance is through encouragement, not coercion. For example, if a new editor is waiting for a review of a draft about a restaurant, he could be approached to improve an article about food, or cooking equipment, or a cooking show, or about the town in which the restaurant is located.—Anne Delong (talk) 12:25, 3 May 2017 (UTC)[reply]
{U|:Anne Delong} It is the posiblity that trusted editors get counted more than untrusted editors, eg. changing the system of number of editions contabilization, I agree that something should be done, however this is a laying problem ¿should Wikipedia cease of its neutrality on favour of equilibrium and hence neutrality of its global content? ¿Or should global content of Wikipedia at last not be neutral on the act of reflexing the polarization of its community and by transitiveness, the society? — Preceding unsigned comment added by Neurorebel (talk • contribs) 23:57, 4 May 2017 (UTC)[reply]

Use of translation tool by unconfirmed eduitors

[Here| https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/CXT] it was resolved that its not possible. I dont see much sense about that decission, crap can be copy/pasted or created without any tool, if it is to much work to remove them, then let a bot do it, thats it searching for pages that are not in English and should not be so much intuitive that a bot cant do it. Translation tool is lot of useful if well employed, if has amazing good template translation and link transposition is not that bad. Also there should be a way that an unconfirmed editor could benefit from it like submitting that article to approval. At least they could warn the user before doing the translation and make him save time. --Neurorebel (talk) 00:25, 2 May 2017 (UTC)[reply]

Two things:
  • Again, per the thread at the help desk, you must be in the extended confirmed group, not the much lower bar of a confirmed account
  • Forgive my bluntness, but the level of English in your comments here suggests that the restriction is working as intended. Beeblebrox (talk) 02:27, 2 May 2017 (UTC)[reply]
I certainly wouldn't want a bot to translate articles for Wikipedia. ANd while "crap can be copy/pasted or created without any tool", the restriction of using this tool d'does' prevent many cases of good-faith creation of junk. עוד מישהו Od Mishehu 11:04, 2 May 2017 (UTC)[reply]
@Beeblebrox: Please judge me by my articles and not by my discussions. Im trying to share ideas here, not dispatching lessons of good English. Let us leave standards at the main namespace. --Neurorebel (talk) 20:09, 2 May 2017 (UTC)[reply]
Already, @Neurobel:, I'll judge you by your articles: I've looked them over, and your command of English is not sufficient to be writing and editing articles on English Wikipedia. You really should stop, and edit the Wikipedia of your native tongue, because you simply cannot write coherently in English. I've corrected some of what you've written, but other editors should look over your stuff as well, considering how long you've been editing here. Beyond My Ken (talk) 03:39, 5 May 2017 (UTC)[reply]
@Mishehu: Reading comprehension: The bot that i mention is for search and destroy articles written on other languages that are not English since administrators are too busy to remove them by hand, not for plain translating articles, that what you say is an abomination, have little more faith on me.--Neurorebel (talk) 20:09, 2 May 2017 (UTC)[reply]
Od Mishehu, a typo prevented you from getting pinged in the edit just above mine. Nyttend (talk) 17:05, 3 May 2017 (UTC)[reply]

Unblocking after community-imposed block

Unblocking discussion

In the last few days, there's been a big to-do at WP:AN after an admin unblocked someone who was blocked several weeks earlier as the result of a community discussion. Everyone's well aware that you mustn't unblock someone who's been banned by the community or by Arbcom (unless they've been unbanned, of course), but I don't think I've ever seen a firm statement on this kind of situation, and WP:BLOCK doesn't appear to address community-imposed blocks at all. Proposal, therefore: add something to WP:BLOCK covering this situation. I'd like to see one of the following, although probably with better wording:

  1. Community-imposed blocks — the community may impose a block on a user, either for a period of time or indefinitely. Such a block is not a ban, but it must not be removed by an administrator without consensus from the community or instructions from the Arbitration Committee.
  2. Community-imposed blocks — the community may impose a block on a user, either for a period of time or indefinitely. Such a block is not a ban, so it may be removed by an administrator as if it were a block imposed by an individual administrator.

So...do you support the first, or the second, or a third option, or do you believe that we're best off with the status quo and not addressing this subject in WP:BLOCK? I'm not in favor of the status quo, of course, but I'm undecided between #1 and #2. Nyttend (talk) 17:01, 3 May 2017 (UTC)[reply]

  • I'm with #1. Keeping "consensus from the community" somewhat vague is fine with me; typically such matters should be discussed at AN, IMO, but we don't need to stipulate everything.

    Oh, why? Because it is common sense: admins work at the behest of the community and with the fiat of that community: if the community decides it wants this or that editor blocked, no single admin should be undoing that without consulting said community. Drmies (talk) 17:31, 3 May 2017 (UTC)[reply]

  • I believe WP:CONSENSUS already fills in the hole. No single editor should act against consensus with the usual exceptions.--v/r - TP 17:33, 3 May 2017 (UTC)[reply]
  • TParis, are you agreeing with Drmies, or do you prefer that we retain the status quo? Nyttend (talk) 17:43, 3 May 2017 (UTC)[reply]
  • I generally oppose new policy. I think the status quo has worked for years and we shouldn't tie our hands just because it failed once.--v/r - TP 18:54, 3 May 2017 (UTC)[reply]
  • Okay. Thanks for the clarification. Nyttend (talk) 19:01, 3 May 2017 (UTC)[reply]
  • Option 1 - while it's true that consensus can change, you must show that it did (by a new discussion) before overriding a community decision. If it didn't, a single user certainly can't override thwe community. Notre that his applies to a community block, not a block to enforce a community ban. עוד מישהו Od Mishehu 17:39, 3 May 2017 (UTC)[reply]
  • Option 1 - let's formalize this best practice. But note this will prevent admins trying to rehabilitate these blocked editors via email and presenting this unblock (along with editing restrictions) as a fait accompli. --NeilN talk to me 18:03, 3 May 2017 (UTC)[reply]
  • Option 3: community-imposed blocks are in fact community bans. That's really what we're discussing here. If the community has a discussion and decides that an editor is no longer welcome to edit, then that user is sitebanned. They can also be blocked to enforce the ban (and usually are) but there really is no such thing as a community-imposed block. Ivanvector (Talk/Edits) 18:09, 3 May 2017 (UTC)[reply]
(edit conflict) And woe betide the administrator who unblocks a sitebanned user with no discussion (option 1). Ivanvector (Talk/Edits) 18:17, 3 May 2017 (UTC)[reply]
  • In other words, "Community-imposed blocks — the community may impose a block on a user, either for a period of time or indefinitely. Such a block is to be treated as a community ban for the duration of the block." Does this reflect your intentions? Nyttend (talk) 18:11, 3 May 2017 (UTC)[reply]
Not exactly. I argue that the community does not have the authority to hand out blocks - blocks are a technical function to prevent a user from editing, which can be used to enforce a ban, which the community can impose. I'm being pedantic, but we're talking about changes to a policy, and I would prefer "community-imposed blocks" not be a thing we invent here. Ivanvector (Talk/Edits) 18:17, 3 May 2017 (UTC)[reply]
Sure, which is why I'm asking :-) Do you have a wording proposal? I just want to avoid a close where people agree with the closer's decision ("of course consensus is in favor of that option") but dispute the wording that gets added. Nyttend (talk) 18:24, 3 May 2017 (UTC)[reply]
I suggest adding as a bullet below "unblocking will almost never be acceptable" similar to: * when a block explicitly enforces a community ban, and there is no consensus to overturn the ban. Ivanvector (Talk/Edits) 18:40, 3 May 2017 (UTC)[reply]
For reference, see Wikipedia:Banning policy for an explanation of bans versus blocks. The community can reach a consensus agreement on an editing restriction; blocking is a tool to help implement the restriction. isaacl (talk) 18:31, 3 May 2017 (UTC)[reply]
  • Option 2 Let's not pretend that "the community" (meaning 47,344,033 people has reached a consensus) imposes blocks. Instead it's usually some small number of people, usually at most a few dozen. The block may or may not be justified, but that is independent of the process which imposed it, which usually involves a small number of people anyways. If admins can be trusted to impose a block without asking the community every time, they can be trusted to unblock someone for same. If we can't trust admins, then why give them the tools? --Jayron32 18:12, 3 May 2017 (UTC)[reply]
  • This is already covered by WP:UNBAN: community bans may be appealed to the community or the Arbitration Committee. isaacl (talk) 18:24, 3 May 2017 (UTC)[reply]
User:Isaacl the technical issue here is "block" vs "ban". There is nothing written anywhere about an admin unblocking someone blocked by community consensus. Jytdog (talk) 18:30, 3 May 2017 (UTC)[reply]
Blocking is a tool to implement a ban; the community can agree upon an editing restriction that requires a block to be carried out (see Wikipedia:Banning policy and in particular, "Community bans and restrictions"). There is no "community block". isaacl (talk) 18:33, 3 May 2017 (UTC)[reply]
See below. The kind of blocks we are talking about are imposed to implement the close of a community discussion, where there is a consensus that this is what should happen. In these cases the block was not one admin's judgement. They are generally not treated as if they are one admin's judgement but there is no language in policy expressing this practice. This is just bringing the writing in line with long standing practice. Jytdog (talk) 18:38, 3 May 2017 (UTC)[reply]
  • option 1 this is somewhat legislating clue but I reckon we need this spelled out since it involves use of the bit. Jytdog (talk) 18:27, 3 May 2017 (UTC)[reply]
  • Option 3 per Ivanvector. I find his rationale convincing. Blocking is technical while banning is not. The community as a whole does not have technical skills, we have consensus. Administrators can enforce consensus through a technical measure, i.e. a block. This can be considered support for option 1 if no one else gets behind this level of hairsplitting, but I too think it is good to make policy specific in language. TonyBallioni (talk) 18:38, 3 May 2017 (UTC)[reply]
  • Point of order Right now, we sometimes have community discussions that result in people being blocked without a ban being mentioned. If we're going to bring bans into this situation, we need to mention them explicitly (how will such a discussion be interpreted from a ban perspective), or we could (ironically) ban the concept of community-imposed blocks, with all such discussions being for temporary or indefinite site bans instead. Nyttend (talk) 20:03, 3 May 2017 (UTC)[reply]
  • Essentially, I would consider a block imposed by consensus of the community to be identical in every way that matters to a community imposed site ban. The procedure for overturning it should be the same. Regardless, administrators should never overturn community consensus on anything by unilateral action. Even if we would make some distinction between a "community block" and a "community ban", the decision to overturn it should also require community consensus in all cases. Seraphimblade Talk to me 20:32, 3 May 2017 (UTC)[reply]
I think this is covered by Wikipedia:Banning policy#Authority to ban, which is an exclusive list of the persons who may impose bans. #1 is the community. It also explicitly states that individual administrators may not impose bans (i.e. implying that admin sanctions are not bans). The text below WP:CBAN that you referred to in the next section is what should probably be tightened. CBAN is also the section which describes the method by which the community can formally enact a sanction ("community sanctions may be discussed ..." etc.). Also note that there is no section in WP:BLOCK or elsewhere that I know of which describes a method for community consensus to compel a sanction, suggesting in my mind that all community sanctions are bans. I definitely agree that, if this is the case, then the policy ought to state this explicitly to head off this exact problem in future. I'll have to think for a bit to formulate a proposal to change this, but I have IRL stuff to do for a bit. Ivanvector (Talk/Edits) 20:51, 3 May 2017 (UTC)[reply]
  • Option 1 - An administrative action is carried out on the behalf of the community, therefore a block based on an explicit community decision should not be overturned by an individual administrator. I think the community should have the option to block a user as opposed to banning them. — Godsy (TALKCONT) 22:54, 3 May 2017 (UTC)[reply]
  • Option 3 per Ivanvector. The "community" does not have a block button. We merely need to be careful in saying that we intend to ban when we intend to ban. As an attorney, I find this comparable to a jury-imposed jail sentence. The jury recommends a sentence, the judge orders it (typically in accordance with the jury's recommendation), and prison officials carry out the actual incarceration of the convict. The jurors do not take the convict home with them to personally imprison him. The idea of a community-imposed "block" sounds to me like the jurors deciding to keep the prisoner in one of their basements, rather than leaving that step to the jailer. bd2412 T 02:27, 4 May 2017 (UTC)[reply]
  • Option 3 per Ivanvector. Optoin 1 and 2 do have merits but option 3 makes better sense. Blackmane (talk) 03:06, 4 May 2017 (UTC)[reply]
  • Option 2 I believe option 2 is current WP policy per WP:CBAN: In some cases the community may have discussed an indefinite block and reached a consensus of uninvolved editors not to unblock the editor. Editors who remain indefinitely blocked after due consideration by the community are considered "banned by the Wikipedia community". A mere block isn't enough to be considered banned by the community, only a consensus in favor of not unblocking the user (in addition to the block) makes the person effectively banned by the community and cannot be undone by a single admin. The reason for this is that blocks are meant to be short term (unless used to enforce a ban). Once there is evidence that the person will not continue the disruptive behavior (such as a good faith acknowledgement of the problem and a reasonable claim to not do it again), the block should be lifted. Bans are meant to be long term, which is why it needs to require the community to agree to lift the ban. A block used to enforce a ban, falls under the ban and shouldn't be lifted but by consensus of the community. -Obsidi (talk) 04:08, 4 May 2017 (UTC)[reply]
  • Option 3. There is no difference between a block and a ban, if it is imposed based on community consensus. -- King of ♥ ♦ ♣ ♠ 04:34, 4 May 2017 (UTC)[reply]
  • Option 3 - (I would have agreed with Option 1 until Ivanvector brought up #3) The underlining theory is that while single admins have a great deal of authority and power to operate on their own, there are certain restraints upon them. For instance, they cannot undo a checkuser block, they cannot act against WMF policy, they cannot act against an ArbCom decision (although they have fairly wide latitude in imposing penalties based on ArbCom decisions) and, pertinent here, they cannot override the will of the community, once that will has been properly expressed and then implemented by an admin. If they disagree with what the community has decided, they, like any other editor, can bring up their objections in a new discussion, to see if consensus has changed, or if they can change it by argumentation, but once the community has decided, they can no longer use their admin powers to impose their own judgment counter to that of the collective. Beyond My Ken (talk) 03:01, 5 May 2017 (UTC)[reply]
  • Option 3 per Beyond My Ken. Remember WP:NOBIGDEAL? An admin has certain tools; they do not have a mandate to override a valid community decision. If an admin wants to change the outcome of such a decision, let them join the queue like everyone else. Johnuniq (talk) 05:14, 5 May 2017 (UTC)[reply]
  • Option 3 - A block is just a technical feature. A ban is the formal social decision to exclude someone. A community-sanctioned block is and always has been considered a ban—what was a block has become a community consensus to formally exclude the blocked user. Drawing a distinction between a ban and a community-imposed block is unnecessarily confusing and, frankly, wrong. Swarm ♠ 06:29, 5 May 2017 (UTC)[reply]
  • Option 3 per Swarm, King of Hearts, Beyond My Ken et al. There is not such thing as a community block - a block can only be imposed by a single administrator. If it was imposed per the consensus of a community discussion, then the block is enforcing a community ban. Thryduulf (talk) 12:47, 5 May 2017 (UTC)[reply]
  • Option 2 The fact is that many of these decisions are made by half a dozen users and often the same users. Just look at the case that spawned this proposal: Riceissa. Many of these blocks/bans can hardly be called a community consensus with so few users. We really need administrative review of blocks imposed by so few users.--I am One of Many (talk) 19:14, 6 May 2017 (UTC)[reply]
  • Option 3. Functionally, a block imposed by the community is a community ban, per Thryduulf. There's no good reason why a discussion cannot be held at AN to review these blocks. ---- Patar knight - chat/contributions 00:02, 7 May 2017 (UTC)[reply]

Discussion: community blocks

  • It is true that the community cannot impose blocks. To make it more concrete, how about something like "blocks administered to implement the close of a community discussion"? (in the recent case, what should have been done instead of an unblock was a close challenge....) Jytdog (talk) 18:35, 3 May 2017 (UTC)[reply]
    • Perhaps to enforce sanctions based on community consensus or something like that. That way it emphasizes that the sanction was not just one admin acting as closer, but the community as a whole sanctioning. TonyBallioni (talk) 18:41, 3 May 2017 (UTC)[reply]
    • The banning policy still applies: the community has reached a consensus agreement to impose an editing restriction. Where there is a question of the validity of the close, a case request must be filed with the Arbitration Committee. isaacl (talk) 18:43, 3 May 2017 (UTC)[reply]
      • You are getting closer but you are still not there. UNBAN does mention "editing restriction" but it does not explictly say "indefinite block". Which is why this discussion is happening. It is very technical and somewhat legislating clue but there it is. Jytdog (talk) 19:08, 3 May 2017 (UTC)[reply]
        • The types of restrictions that can be imposed by the community are discussed under the "Community bans and restrictions" section, which includes a site ban. isaacl (talk) 19:15, 3 May 2017 (UTC)[reply]
            • Which is different from an indefinite block. I am done responding to you. Jytdog (talk) 19:30, 3 May 2017 (UTC)[reply]
              • The indefinite block is the tool used to implement the site ban imposed by the community. The editor can appeal the ban sanction, in order to get the block lifted. I agree with TParis above; just because one admin didn't follow the existing policy already spelled out for community bans (as well as common English Wikipedia convention: consensus agreements are not supposed to be unilaterally overturned) doesn't mean a change is required in yet a different policy. We can afford to wait to see if a pattern will be established. isaacl (talk) 19:38, 3 May 2017 (UTC)[reply]
                • The community has traditionally had discussions about explicitly banning an editor. These are different from indef blocking an editor. The editor in question was not community banned. --NeilN talk to me 19:43, 3 May 2017 (UTC)[reply]
  • There is no authority under the blocking policy for the community to block a user (defined as technically preventing them from editing via the software). The only authority for an editor to be prevented from editing by the consensus of the community is derived from the banning policy. Editing restrictions resulting from community discussions are bans by definition, whether the participants in the discussion choose to define it as such or not. Ivanvector (Talk/Edits) 20:08, 3 May 2017 (UTC)[reply]
  • I will make one more response here. In the real world of actual community practice, it is not uncommon at ANI/AN that someone proposes that X be indeffed, and that ends up being the consensus. Folks are saying that this is "in effect" a "siteban" or "editing restriction" discussed in BAN which is kind of true, but what actually happens at ANI is actually a consensus for indef, which is then implemented by an admin and recorded as such. BAN and BLOCK are not explicit about the appeal process for this specific situation and as we have just seen, an admin thought himself fully justified in solo reversing that indef, looking only at BLOCK. Everybody else was horrified. I generally don't support legislating clue but as this involves the bit, I do support it here. And all this does is catch up the writings with community practice and understandings. Jytdog (talk) 20:12, 3 May 2017 (UTC)[reply]
  • @Ivanvector: I disagree. WP:CBAN: In some cases the community may have discussed an indefinite block and reached a consensus of uninvolved editors not to unblock the editor. Editors who remain indefinitely blocked after due consideration by the community are considered "banned by the Wikipedia community". --NeilN talk to me 20:15, 3 May 2017 (UTC)[reply]
    • This is for the case where an admin imposed an indefinite block which was subsequently discussed by the community who declined to lift the block. At that point the community has enacted a site ban, converting the admin-imposed indefinite block into a community-imposed sanction that is within its scope to pass. isaacl (talk) 20:28, 3 May 2017 (UTC)[reply]
  • (edit conflict) @NeilN: I don't think that says what you think it says, it's just another example of how when the community decides that an editor should not edit, then the community has enacted a ban. If a user finds themselves blocked, they can appeal; if the community then discusses the block and decides that, yes, this user should not be allowed to edit, then the community has enacted a ban. This section does not grant authority to the community to enact a block. Ivanvector (Talk/Edits) 20:35, 3 May 2017 (UTC)[reply]
  • That's your (perfectly valid) interpretation. As long as other valid interpretations exist, this situation is going to occur again if the language isn't cleaned up. --NeilN talk to me 20:34, 3 May 2017 (UTC)[reply]
  • I think part of the problem here is that the blocking policy generally predates both the AN page and the CBAN policy. There was a time when all blocks were effectively unilateral, and if you wanted a ban you needed ArbCom to step in. I think the current discussion of implementation of this policy may make it too easy to effectively use mob mentality to permanently ban someone in controversial or unclear situations. We used to entrust admins with the ability to review and unilaterally overturn blocks, as I did in this case, and as some have pointed out, we don't really have a "community blocking" policy without the harsher sanction of a full ban. Because I've been here a long time and not always active, it's possible this may have shifted in a way that I didn't keep up with, and my understanding is out of date. I do think the bar for a permaban should be higher than just a few users weighing in on a thread for a day or so. Andrevan@ 22:16, 3 May 2017 (UTC)[reply]
  • Yes, let's go with option 2 in my opinion. Andrevan@ 22:35, 3 May 2017 (UTC)[reply]
  • This is quite maddening. If you search the ANI archives you will see many "proposal to indef" threads, where a close is made that acknowledges that consensus, and then an admin does that. Hypertechnicallegally you can ground this in BAN as the community imposing an "editing restriction" or a "siteban", but on the surface they are discussed as an indef, implemented as one, and recorded as one. There have been some closes that expressed discomfort with the notion due to the lack of clarity in BAN, or that described the indef as being done on the admin's authority rather than based on community consensus. But there are plenty that just do it straight. There is some interesting ambiguity here. But this is community practice which is actual policy in WP. We do this. The writings just record consensus practice and right now the written policy lags community practice, and does need to be updated.
Here are diffs from ANI threads with community-driven indefs. (the older ones are kind of random -- this is because our intra-WP search engine completely sucks but that is another conversation. They are from the first pages of a search. I also browsed through the current ANI page and archives from 953 (most recent) to 939 (Nov 2016).
  • 2010 Request of indef block for user PCE. Discussed whether 2 week block was enough or should it be indef. Decision was indef.
  • 2011 NPA again. Proposal was ban/indef block, many of !votes were "indef". Spot on example of indef/ban ambiguity. Final-final outcome was an indef.
  • 2013 Arctic Kangaroo yet again I formally propose that AK be blocked indefinitely..., !votes were indef or not, close was Indef block for WP:CIR issues: enacted.
  • 2013 User:omdo proposal: I have no option but to suggest a block, !votes were for indef, the last one being Indefinitely blocked by the admin who enacted what everyone had !voted for, which was recorded in the close.
  • 2013 Time to close? one segment of a long discussion about Danjel, where a move was afoot to indefinitely block them. Interesting close: There is no community blocking procedure, and no consensus for one if there were. That said, consensus that Danjel is creating a problem exists (only thing I have seen like this....)
  • 2013 EMr_KnG . Discussion about indef. Close: User is being engaged directly on his talk, with a view to avoiding the indefinite block that there is consensus should be applied if his edits continue to be troublesome.
  • 2016 God's Godzilla doesn't appear to have learned his lesson Proposal: Indef block of God's Godzilla Proposal. Close: Indefblocked, following lengthy discussion that included the user in question. Update: I note that Mr. Rnddude has now opposed the block, but by that point it was already complete; this is a race condition, and I will not object if another admin wants to revert this block for that reason.
  • 2016 Meatpuppet incident at Albert Cashier Proposal was First off, I take it for granted that Lgbt.history.ig needs to be indeffed at this point.. close was Lgbt.history.ig has been indefinitely blocked by BethNaught, with the unanimous support of the community, for abusing multiple accounts and improper off-wiki canvassing.
  • 2016 Wrongful accusation from Walter Görlitz, resulted in boomerang indef, by community consensus. proposal was in subsection Indefinite block for Cedric and close was Cedric tsan cantonais indefinitely blocked. I'm not sure I've ever seen a consensus so overwhelmingly in favor of blocking.
  • 2017 John Carter. community discussion of block for IBAN violation. Close is interesting : John Carter blocked for a month. This discussion establishes that John Carter violated a community-imposed interaction ban....This is an enforcement action in my individual capacity as an administrator, subject to normal review by colleagues, and not an attempt at assessing consensus in this discussion. ...
  • 2017 Single-purpose account promoting geocentrist and paleo-Catholic Robert Sungenis. Indef was proposed, !voting started, and an admin jumped in and indeffed, writing I've reviewed this material and don't see any reason to take this to a vote. Their goals here are clear enough, and a block is the appropriate response, so I'm going to block them.
  • 2017 Riceissa 'this is the one, the unblocking of which sparked this discussion. proposal was: I think this justifies either an editing restriction or an outright ban. Bluntly, Riceissa appears to be here to spam.. !votes were indef and close was Indeffed. The pages mentioned below are up for deletion at Wikipedia:Miscellany for deletion/User:Riceissa/Animal Charity Evaluators
  • 2017 Topic ban for Wiki-Pharaoh proposal was TBAN but community discussion moved to indef. close: Blocked indefinitely. Additionally, all project space pages and shortcuts are to be userfied or deleted (at administrator's discretion)

-- Jytdog (talk) 03:13, 4 May 2017 (UTC)[reply]

All of those (other than John Carter and the Robert Sungenis SPA, which are odd special cases) are community discussions leading to a formal editing sanction against an editor, an action described by the banning policy; thus, they're bans. The block thus enacted by an administrator is enforcement of the ban, which is described in the blocking policy. What we need to make clear, regardless of the nomenclature, is that if there is a community discussion leading to a formal sanction of an editor, then it is up to the community to remove that sanction. That's option 1 above, but I don't like how either option defines this in regard to the technical function of blocking.
The confusion comes when a community discussion leaves a result in which the community implicitly expresses its wish that the sanction be reversible by any administrator acting in the interest of the discussion, if/when the issue leading to the sanction is resolved. In the discussions which Jytdog posted, this is referred to as a "block", but it's not a block because the community cannot push the block button. What it is is what we seem to need to define, and it should be in the banning policy as the policy which defines available community sanctions and how they may be enacted/appealed. Whether we want to call it a semi-ban, or a reversible ban, or a discretionary ban, or a pancake, it's still a form of formal sanction, and those are described by the banning policy.
A possible related question is, does the community desire to define a permanent ban? We've never done anything permanent by definition with regard to sanctions, apart from office actions, but some Wikipedias do. I don't support it personally, but just throwing it out there. Ivanvector (Talk/Edits) 13:18, 4 May 2017 (UTC)[reply]
The first paragraph is great. The second paragraph is really confused. Those indef discussions do not assume that the indef can be lifted by any old cowboy admin, which is why pretty much everyone reacted as they have to the event that sparked this. They are done in the spirit that we want this person technically prevented from editing. It is well understood that the community entrusts only a few people with the power to do that and the expected outcome of the consensus is that some admin will fulfil the responsibility that comes with the power, and do the indef. Yes, policy needs to catch up with practice. Blocks administered to implement the close of a community discussion are not like other blocks; they are a form of editing restriction per BAN. Jytdog (talk) 20:46, 4 May 2017 (UTC)[reply]
User:Obsidi thanks for bringing that! The paragraph where that was diff made is so.. convoluted. See proposal below... Jytdog (talk) 21:16, 4 May 2017 (UTC)[reply]

Proposal: clarification of community blocks

To catch up with practice and clarify the language, Wikipedia:Banning_policy#Community_bans_and_restrictions should just be changed as follows:

In some cases the community may have discussed reviewed and upheld an indefinite block imposed by administrator on his or her own authority, or may have reviewed an unblock request from such an indefinitely blocked editor and reached a consensus of uninvolved editors not to unblock the editor. Editors who remain indefinitely blocked after due such consideration by the community are considered "banned by the Wikipedia community".

In some cases the community may have reached a consensus to indefinitely block an editor, and an indefinite block is imposed by an administrator acting under that consensus. Such an editor is considered "banned by the Wikipedia community".

Thoughts? Jytdog (talk) 21:16, 4 May 2017 (UTC)[reply]

Not to open a can o' worms, but taking out "indefinite(ly)" covers off the cases when the community has decided on a time-limited block. --NeilN talk to me 23:55, 4 May 2017 (UTC)[reply]
User:NeilN I like it! I made changes accordingly, showing only the redaction for changes to the original language, not the proposed language. See below (am proposing adding language "to the extent that..." to make it clear it extends from a short term block to an indef... hopefully not too messy with that.)

In some cases the community may have discussed reviewed and upheld an indefinite a block imposed by an administrator on his or her own authority, or may have reviewed an unblock request from such a blocked editor and reached a consensus of uninvolved editors not to unblock the editor. Editors who remain indefinitely blocked after due such consideration by the community are considered "banned by the Wikipedia community" to the extent of the original block.

In some cases the community may have reached a consensus to block an editor, and a block is imposed by an administrator acting under that consensus. Such an editor is considered "banned by the Wikipedia community" to the extent of the block decided by the community.

does that work better? Jytdog (talk) 01:54, 5 May 2017 (UTC)[reply]
Instead of "to the extent...", I suggest "for the length of the block", in both cases. (I don't think "original" is required for the first case.) isaacl (talk) 02:38, 5 May 2017 (UTC)[reply]
  • I don't think any of that extra verbosity is any sort of improvement. Simply keeping the original statement and just removing the "indefinite" specification would literally work just as well. Swarm ♠ 06:37, 5 May 2017 (UTC)[reply]
No, clarification is definitely required. See all the editors above who interpreted this section as meaning that the community can impose blocks. Ivanvector (Talk/Edits) 12:49, 5 May 2017 (UTC)[reply]
However, I do agree that being excessively verbose works against clarity of the policy (one might observe this is an ironic view coming from me). A couple points:
  1. I don't think 34 words are necessary in the first sentence; at least some are repeating themselves. "In some cases the community may review an administrative block or an editor's unblock request and reach a consensus not to unblock the editor." seems to me to work just as well with 10 fewer words. (I also prefer present tense for policy)
  2. "... to the extent of the original block". Necessary? A block or ban with an expiry date doesn't require consensus or admin action to overturn upon expiry, and as far as I know it's rare for a time-limited sanction to be appealed. But on the balance I guess Isaacl's suggestion serves the purpose.
  3. The second para, that's what I have been getting at but there doesn't seem to be agreement on that point. I'm worried about "consensus to block an editor" because, as discussed above, the community has neither authority nor technical capability to functionally block an editor. Can we say "consensus to sanction an editor" and "to the extent of the sanction" instead? It would work just as well to cover those cases that resulted in a "consensus to block" as described above.
--Ivanvector (Talk/Edits) 13:04, 5 May 2017 (UTC)[reply]
Happy to simplify. The reason for the "to the extent" is that I don't want to leave the door open for some cowboy admin to overturn a 3 month block that the community endorsed after review on the hyperlegalistic reasoning that it was not a SITEBAN. As for the third paragraph, how is a block not an editing restriction (which the community is empowered in letter and spirit to impose)? How in the world can you say that community cannot reach a consensus that someone should be indefinitely blocks when the community actually does this, going back a long way? You continue to treat policy like it is a reified thing and not an expression of common community practice. Please review the letter and spirit of WP:PAG. The writing has to adapt. If you continue to hold this stance we may need an RfC but that would really surprise me if it were needed..... Jytdog (talk) 16:24, 5 May 2017 (UTC)[reply]
I presume the proposed second paragraph was intended to replace the current first bullet point? How about changing the text as follows:
The community may reach a consensus to impose various types of sanctions on editors as described in Wikipedia:Banning policy § Types of bans:
  • If an editor has proven to be repeatedly disruptive in one or more areas of Wikipedia, the community may engage in a discussion to site ban, topic ban, or place an interaction ban or impose an editing prohibition restriction via a consensus of editors who are not uninvolved in the underlying dispute. When determining consensus, the closing administrator will assess the strength and quality of the arguments made.
  • The community may review the circumstances of a block imposed by an administrator on his or her own initiative, and reach a consensus to enact an editing prohibition. It may be on the same terms of the original block, or a newly-created restriction.
  • In some cases the community may have discussed an indefinite block and reached a consensus of uninvolved editors not to unblock the editor. Editors who remain indefinitely blocked after due consideration by the community are considered "banned by the Wikipedia community".
Once a sanction has been imposed or upheld by the community, it assumes responsibility for the restriction. Appeals must follow the procedure described in Wikipedia:Banning policy § Appeals of bans imposed by the community.
isaacl (talk) 16:40, 5 May 2017 (UTC)[reply]
My proposal was only intended to replace the 2nd bullet point. The more extensive changes to the first are not needed; it is clear enough. The changes to the 2nd don't address the mess that started this, nor the need to update this to deal with the reality that the community has, for a long time, agreed that someone needs to be indeffed (a form of editing restriction or ban, as you like). I don't think we should introduce new terms like "prohibition") Here is a revised proposal that takes into account everything above and incorporates the reality of community-imposed indefs:
revised 2nd bullet per above, now leaving the markup out:

In some cases the community may review an administrative block or an editor's unblock request and reach a consensus not to unblock the editor. Editors who remain blocked after such consideration by the community are considered "banned by the Wikipedia community" for the length of the block.

In some cases the community may reach a consensus to ban or place an editing restriction on an editor by means of a time-limited or indefinite block, and a block is imposed by an administrator acting under that consensus. Such an editor is considered "banned by the Wikipedia community" for the length of the block decided by the community.

- thoughts? as mentioned if folks are going to keep insisting that a block is not a valid form of "editing restriction" we will need an RfC, but again, this would surprise me. Jytdog (talk) 16:51, 5 May 2017 (UTC)[reply]
The reason I changed both bullet points is to avoid duplication of language regarding what is considered a community ban/editing restriction. Since this applies to both bullet points, I felt it would be better to pull out this part into a separate paragraph that applied to both. Since the key point is that appeals must follow the procedure for community bans, I also thought it would be good to highlight this specifically. "Prohibition" is taken from the first sentence of the banning policy page: A ban is a formal prohibition... I only used it as a synonym for ban (as used in the banning policy page), since some people have different connotations for that word.
On a side note, the incident that triggered this discussion is covered by the current first bullet point, not the second: the community reached a decision to enact a ban which was then enacted. isaacl (talk) 17:09, 5 May 2017 (UTC)[reply]
Jytdog: it's exactly that door that I'm trying not to leave open, by specifying within the policies that sanctions deriving from community discussions should not be modified by any administrator acting in a sole capacity. I think that we're in agreement on that. Being wishy-washy about "current practice" and the "spirit of the policy" is what leads to administrators having to interpret what we're allowed to do and not do, and in the case which led to this discussion led to a community-imposed editing restriction being overturned by an administrator who in good faith believed they had the authority to do so, and it's not really clear that they didn't. That's why I'm being "hyperlegalistic" as you call it about what words we use in the policy.
Now as far as current practice, my suggestion to replace "block" with "sanction" within the banning policy is meant to cover the situation where the community discusses an editor and reaches a "consensus to block" or "consensus to indef" or whatever. By specifying that this is a sanction within the banning policy, and not a technical restriction within the blocking policy, then the banning policy already describes that the sanction can only be modified by subsequent community consensus (and not by one "cowboy admin"). I believe this is the intended result of all of those discussions which resulted in "consensus to block". If you believe that's not the case, can you describe how you believe the intended result of such a discussion differs? Ivanvector (Talk/Edits) 18:36, 5 May 2017 (UTC)[reply]
I don't know why I didn't get an edit conflict notice on this, but never mind. Reviewing what you wrote below apparently while I was writing this. Ivanvector (Talk/Edits) 18:41, 5 May 2017 (UTC)[reply]
I see what you mean about the first bullet. On the Riceissa thing it was interesting that the nom was for a ban but all the !votes were for an indef. One can interpret that a lot of ways (for example,. the community wanted a site ban with the specific editing restriction created by a block, for example...), but the community spoke clearly that it wanted an indef.
Here is proposal for the whole section, being conservative with changes:
The community may reach a consensus to impose various types of sanctions on editors:
  • If an editor has proven to be repeatedly disruptive in one or more areas of Wikipedia, the community may engage in a discussion to site ban, topic ban, or place an interaction ban or editing restriction (which may include a time-limited or indefinite block) via a consensus of editors who are not involved in the underlying dispute. When determining consensus, the closing administrator will assess the strength and quality of the arguments made.
  • In some cases the community may have discussed an indefinite block review an administrative block or an editor's unblock request and reached a consensus of uninvolved editors not to unblock the editor. Editors who remain indefinitely blocked after due consideration by the community are considered "banned by the Wikipedia community" for the duration of the block.
Community sanctions may be discussed on the Wikipedia:Administrators' noticeboard (preferred) or on Wikipedia:Administrators' noticeboard/Incidents. Discussions may be organized via a template to distinguish comments by involved and uninvolved editors, and to allow the subject editor to post a response. Sanction discussions are normally kept open for at least 24 hours to allow time for comments from a broad selection of community members. If the discussion appears to have reached a consensus for a particular sanction, an uninvolved administrator notifies the subject accordingly and enacts any blocks called for. The discussion is then closed, and the sanction should be logged at the appropriate venue if necessary, usually Wikipedia:Editing restrictions or Wikipedia:Long-term abuse.
Comments? Jytdog (talk) 17:38, 5 May 2017 (UTC)[reply]
I don't like that the sentance Editors who remain indefinitely blocked after due consideration by the community are considered "banned by the Wikipedia community" for the duration of the block. Is only in the second bullet. This should apply to the first case as well (not only reviews of blocks/appeals), assuming that is the intreprtation you want. -Obsidi (talk) 18:00, 5 May 2017 (UTC)[reply]
OK, maybe make it a third bullet like this instead of repeating it?
The community may reach a consensus to impose various types of sanctions on editors:
  • If an editor has proven to be repeatedly disruptive in one or more areas of Wikipedia, the community may engage in a discussion to site ban, topic ban, or place an interaction ban or editing restriction (which may include a time-limited or indefinite block) via a consensus of editors who are not involved in the underlying dispute. When determining consensus, the closing administrator will assess the strength and quality of the arguments made.
  • In some cases the community may have discussed an indefinite block review an administrative block or an editor's unblock request and reached a consensus of uninvolved editors not to unblock the editor.
  • Editors who are or remain indefinitely blocked after due consideration by the community are considered "banned by the Wikipedia community" for the duration of the block.
Community sanctions may be discussed on the Wikipedia:Administrators' noticeboard (preferred) or on Wikipedia:Administrators' noticeboard/Incidents. Discussions may be organized via a template to distinguish comments by involved and uninvolved editors, and to allow the subject editor to post a response. Sanction discussions are normally kept open for at least 24 hours to allow time for comments from a broad selection of community members. If the discussion appears to have reached a consensus for a particular sanction, an uninvolved administrator notifies the subject accordingly and enacts any blocks called for. The discussion is then closed, and the sanction should be logged at the appropriate venue if necessary, usually Wikipedia:Editing restrictions or Wikipedia:Long-term abuse.
Does that do it? Jytdog (talk) 18:22, 5 May 2017 (UTC)[reply]

This works pretty well for my concerns. With this wording "an administrative block" can just be "a block" I think. Thinking about the second bullet, something seems off to me but I'm not sure what yet. Ivanvector (Talk/Edits) 18:47, 5 May 2017 (UTC) [reply]

I think it's that the second bullet now isn't really saying anything. Here, I'll give it a go. This is a bit more exotic, so I haven't tried to mark it up.
The community may reach a consensus to impose various types of sanctions on editors:
  • If an editor has proven to be repeatedly disruptive in one or more areas of Wikipedia, the community may engage in a discussion to impose a topic ban, interaction ban, site ban or other editing restriction (which may include a time-limited or indefinite block) via a consensus of editors who are not involved in the underlying dispute. When determining consensus, the closing administrator will assess the strength and quality of the arguments made.
  • In some cases the community may review a block or an editor's unblock request and reach a consensus of uninvolved editors to endorse the block as a community sanction.
  • Editors who remain indefinitely blocked after due consideration by the community are considered "banned by the Wikipedia community".
Community sanctions may be discussed on the Wikipedia:Administrators' noticeboard (preferred) or on Wikipedia:Administrators' noticeboard/Incidents. Discussions may be organized via a template to distinguish comments by involved and uninvolved editors, and to allow the subject editor to post a response. Sanction discussions are normally kept open for at least 24 hours to allow time for comments from a broad selection of community members. If the discussion appears to have reached a consensus for a particular sanction, an uninvolved administrator notifies the subject accordingly and enacts any blocks called for. The discussion is then closed, and the sanction should be logged at the appropriate venue if necessary, usually Wikipedia:Editing restrictions or Wikipedia:Long-term abuse.
How's that? Ivanvector (Talk/Edits) 19:07, 5 May 2017 (UTC)[reply]
generally great! My only concern is that with only the "remain" in the third bullet (your taking out of the "are or" remain blocked) I am little concerned that cowboy admins would consider any block imposed under the 1st bullet lift-able on their own, which is what got us here. Did you intend to leave this open to that? Jytdog (talk) 19:14, 5 May 2017 (UTC)[reply]
Good point, it can say "who are or remain". I also think we should specify separately in the unblocking section of the blocking policy that community sanctions defined here cannot be overturned by an administrator without explicit community consensus, like Arbcom's own motion. Like this: "When the block is explicitly enforcing an active Arbitration remedy or community sanction and there is no ArbCom authorization or "a clear, substantial, and active consensus of uninvolved editors at a community discussion noticeboard (such as WP:AN or WP:ANI)" (Arbcom motion)." Although this wording comes from Arbcom and might need their authorization to change. Ivanvector (Talk/Edits) 19:22, 5 May 2017 (UTC)[reply]
Great. Seems like we are agreed. Perhaps easier to get done if we just add a parallel statement about community sanctions, after the arbcom statement? more clunky I know. Jytdog (talk) 20:03, 5 May 2017 (UTC)[reply]
How about a statement that refers to Wikipedia:Banning policy#Appeals of bans imposed by the community? This would parallel the existing statement referring to the Arbitration Committee motion. For example: When the block is implementing a community-imposed ban that has not been successfully appealed. isaacl (talk) 04:11, 6 May 2017 (UTC)[reply]
How about this? (Modifying Wikipedia:Blocking policy#Unblocking)
Unblocking will almost never be acceptable:
  • When it would constitute wheel warring.
  • To unblock one's own account (unless an administrator blocked themselves).
  • When the block is implementing a community sanction which has not been successfully appealed.
  • When the block is explicitly enforcing an active Arbitration remedy and there is no ArbCom authorization or "a clear, substantial, and active consensus of uninvolved editors at a community discussion noticeboard (such as WP:AN or WP:ANI)" (Arbcom motion).
Each of these may lead to sanctions for misuse of administrative tools—possibly including desysopping—even for first-time incidents.
I use "sanction" (linked to the section above, to be revised) instead of "ban" to head off wikilawyering that a block agreed to by the community didn't specify "ban" explicitly. Thoughts?
I do think that once we're agreed on these changes that we ought to post this as an RfC at WP:VPP. The three or four of us working it out here isn't a good basis for changing the wording of a policy that's likely to be controversial. Ivanvector (Talk/Edits) 13:18, 6 May 2017 (UTC)[reply]
I sandboxed a proposed RfC here. Ivanvector (Talk/Edits) 13:47, 6 May 2017 (UTC)[reply]
My suggestion would be to hold a discussion at Wikipedia talk:Banning policy or Wikipedia talk:Blocking policy. I'm not sure a full RfC is warranted, since no policy is being changed. The changes are essentially a restatement of what is already in the policies (and thankfully in alignment with current practice). I'm sure, though, that they'll be more wordsmithing proposed. isaacl (talk) 15:40, 6 May 2017 (UTC)[reply]
The proposed changes to UNBLOCK are good by me and I agree they are also needed to keep everything SYNCed. I would say post both sets of changes on the Talk page of BAN, and post a note on the talk page of BLOCK pointing to it, to keep the discussion in one place. If things go beyond wordsmithing and into serious conceptual contention we can go to an RfC.... Jytdog (talk) 19:20, 6 May 2017 (UTC)[reply]
Well if we don't think this needs to go to an RfC in a central location, then posting a note to WT:BLOCK and WT:BAN referring to this discussion is probably good enough. It's pretty clearly laid out here what we want to do, and why. Ivanvector (Talk/Edits) 16:45, 7 May 2017 (UTC)[reply]
Done here and here. Thanks for this productive discussion. Jytdog (talk) 17:47, 7 May 2017 (UTC)[reply]

Continued at meta:Wikimedia Forum#Updating Wikipedia Logo

This may not be the best place for this topic, so feel free to point me elsewhere. I feel it's time to update the branding of Wikipedia. I understand this is inherently a subjective topic, but I feel the current logo a bit dated. Unlike Wikisource, Wikidata, and even the fun Wikimania logos, Wikipedia is by far the "busiest." It's also one that isn't terribly recognizable when seen from a distance, which is typically a requirement for a good logo. I know I'm going to get a lot of "don't fix it, if it's not broken". Also, I understand we're not in the business of selling anything, so we don't need to "attract" people. But I would argue that a refresh of the brand would do a lot for our community and the community we serve to feel more at home. Any feedback would be appreciated. Drewmutt (^ᴥ^) talk 21:38, 3 May 2017 (UTC)[reply]

I'd agree to do some refreshment of the logo, but it should be taken with extreme care. Wikipedia logo may not be recognizable "from a distance", but it is terribly well-known and recognizable "in general", having appeared in traditional mass-media (TV, magazines) around the world; few online-only organizations get that much exposure in off-digital communication channels. Also, the missing jigsaw piece is a staple. The other Wikimedia logos are more generic, with no simple details as distinctive as this one.
Maybe removing the shadow gradient and adding contrast to the jigsaw edges would simplify its shape, making it more proffessional-looking. But more drastic changes should be avoided; any changes to the logo should make it appear "just like the same old one, just cleaner". I would also try to avoid merely turning it into its "flat" version; that would age really quickly. Diego (talk) 22:23, 3 May 2017 (UTC)[reply]
Probably something best brought up at Meta? FACE WITH TEARS OF JOY [u+1F602] 02:05, 4 May 2017 (UTC)[reply]
I'd like the logo to be animated as a constantly turning version of itself. bd2412 T 02:28, 4 May 2017 (UTC)[reply]
@BD2412: File:Wikipedia logo puzzle globe spins horizontally and vertically, revealing the contents of all of its puzzle pieces (4K resolution) (VP9).webm? --Majora (talk) 02:45, 4 May 2017 (UTC)[reply]
That would work. Is it technically feasible to have that default to being the object in the corner of the page? bd2412 T 02:55, 4 May 2017 (UTC)[reply]
It doesn't look like the software can handle moving logos unfortunately. I just tried it out with a CSS switch (you can do this for any image by the way, just replace the URL with the direct upload link). It will work for the static image but not for the moving one. It just shows a blank space when the moving image is placed there. Perhaps it is just me, see if you see anything different.

If you want to try it out put the following into your personal CSS (note you do not have to actually save, previewing will activate the script)

CSS code to replace logo
#p-logo a, #p-logo a:hover {
    background: url(https://upload.wikimedia.org/wikipedia/commons/6/60/Wikipedia_logo_puzzle_globe_spins_horizontally_and_vertically%2C_revealing_the_contents_of_all_of_its_puzzle_pieces_%284K_resolution%29_%28VP9%29.webm) 35% 50% no-repeat !important;
}

--Majora (talk) 03:04, 4 May 2017 (UTC) [reply]

I'll give it a whirl. bd2412 T 03:21, 4 May 2017 (UTC)[reply]
  • While I don't oppose this idea, I would note that the Wikipedia globe logo is, unlike everything else here, copyrighted by the WMF. WP:CONEXCEPT would seem to apply. They might be open to the idea, but they would have to be part of the conversation unless we're talking about a completely different logo that does not employ any elements of the current one, and even then they probably could block it if they didn't like it. Beeblebrox (talk) 19:31, 4 May 2017 (UTC)[reply]
Wait, doesn't the logo appearing on this site mean it is required to comply with the site license, which allows derivative works? Ivanvector (Talk/Edits) 19:33, 4 May 2017 (UTC)[reply]
We don't have a site license. We have a text content license, image licenses, the MediaWiki software license (and each and every extensions' license). But not overall blanket license. —TheDJ (talk • contribs) 21:28, 4 May 2017 (UTC)[reply]
Just a note here TheDJ. The logo is under a free license but it is also trademarked. There is a pretty extensive wmf:Trademark policy on the matter along with wmf:Visual identity guidelines that have to be followed if anything is going to change. Those two things do add a bit of constraint to any proposals of this nature. --Majora (talk) 22:07, 4 May 2017 (UTC)[reply]
Plus this needs to be discussed on Meta because it will affect all language Wikipedias, unless we for some reason want a different logo here than every other language Wikipedia. Sam Walton (talk) 22:12, 4 May 2017 (UTC)[reply]
Keep the current logo for brand recognition but create a system like Google where the displayed logo on Enwiki can change day to day (or per week). It should remain recognizable, but has some new flare or variation (like Google logo changes). Users can submit their version and the community picks the next weeks version like DYK. -- GreenC 19:53, 4 May 2017 (UTC)[reply]
Whats stopping them ? Let's get some perspective. Google employs 10-15 people who work let's say 240 days a year at say 50 hours a week... Let's go conservative 12*240*40 == 115000 hours a year. Now sure, their doodles are hella elaborated, but I would be surprised if we can find more than 1 person interested in spending 3 hours a week for 1 doodle, more than a couple of times a year. We can't even keep the WP:Signpost running... I do agree it would be cool though :) —TheDJ (talk • contribs) 21:26, 4 May 2017 (UTC)[reply]
  • Okay, I'm gonna be honest. I'm a pretty young editor, and Wikipedia's been around just about my whole life. I've seen it on computer screens around my house since I can't remember when. So, personally, the Wiki logo as it is holds a pretty nolstalgic status. I'm sure it does for a lot of other people, too. I'd say leave it. Best, Liam Gibson (talk) 22:19, 4 May 2017 (UTC)[reply]

Hey guys, thanks for all the feedback so far. I'm not a fan of the spinning logo, in fact, I think it kinda exacerbates the issue. I get what you guys are saying regarding brand recognition, but I would argue that the "WikipediA" is typically more associated in people's minds than the puzzle globe. As a compromise, what do you guys think about simply using the W? Drewmutt (^ᴥ^) talk 22:57, 4 May 2017 (UTC)[reply]

Is that even available for trademark? Can you trademark a single letter of the alphabet in a specific font? The letter "W", obviously, has a significant amount of prior use (even as far as other websites are concerned), and I wonder whether a specific ordinary font is sufficient for the distinctiveness test. Note that copyright isn't an issue, since WMF released the logos under a free license (probably cc-by-sa) some months ago. Nyttend (talk) 23:35, 4 May 2017 (UTC)[reply]
"Can you trademark a single letter of the alphabet in a specific font?" Wordpress seem to have managed to use a W as a logo, but I guess that's a reason that Wikipedia shouldn't - so we don't get confused with Wordpress. I'm in the "ain't broke, don't fix" camp myself.Chuntuk (talk) 14:45, 8 May 2017 (UTC)[reply]
Plain text in a specific font can't be trademarked in the United States (not sure about other jurisdictions). From a practical perspective (not that the law always takes this into account), it would be unduly burdensome, for example, to avoid using the letter "W" in contexts where there may be brand confusion with Wikipedia. If other stylistic elements are added, then this combination can be trademarked. (Whether or not the Wordpress logo has sufficiently modified the "W" so that its trademark would stand up in court, I do not know.) isaacl (talk) 16:08, 8 May 2017 (UTC)[reply]
  • I for one don't want to get rid of the puzzle globe. It's great. Andrevan@ 23:12, 4 May 2017 (UTC)[reply]
It's a big "W" I tells ya. Those of us of a certain age will remember this. If it ain't broke don't fix it. The globe is just fine. I see no reason - compelling or otherwise - to change it. Samwalton9 is correct any change needs to be discussed on Meta. MarnetteD|Talk 23:47, 4 May 2017 (UTC)[reply]
  • @Drewmutt: Why are you trying to discuss a "compromise"? Did you even read the feedback? We'd have to consult with the Foundation to clarify as to whether we'd acutally be allowed to just change the trademarked logo, because if they're not on board, any such proposal is DOA. Secondly, even if they approved it, this is just one branch of Wikipedia. This would not be the place for such a proposal, as has been pointed out. Meta would be the place for a proposal affecting a wide spectrum of Wikipedias. Slow your roll. I hate to break it to you, but your proposal is an extreme long shot. Swarm ♠ 06:59, 5 May 2017 (UTC)[reply]
@Swarm: Thanks for the honesty, I did read the feedback and referred to it specifically, and yep, I'm going to move this to meta and I already reached out to the WMF folks. I know it's a long shot, but that's what Village Pump is about, throw an idea out, and see if there's traction. Everything can be improved, and thankfully we had that mentality in 2006. Simply, I feel the logo a bit dated, and I think it could benefit from a facial. Drewmutt (^ᴥ^) talk 22:45, 5 May 2017 (UTC)[reply]
  • Note - see also the WMF draft annual plan which includes a focus on branding and identity. Risker (talk) 05:51, 7 May 2017 (UTC)[reply]
  • I think it is fine as is. I would be adamantly opposed to having it be a spinning (or otherwise moving) one. LadyofShalott 17:48, 8 May 2017 (UTC)[reply]
  • Some of the ideas in this thread are absolutely awful. Suggesting the idea of an animated logo suggests one has zero concept of design. I suppose nobody remembers the web of the 90's when websites were loaded with animated elements and it, well, completely sucked. It took a while but eventually people realized that animated elements are extremely distracting to readers, just as blinking text and any flashing elements are. As somebody who remembers the last time the logo was updated (geez the time past quickly), suggesting changing the logo (even now years later) feels very tiresome because I remember how much discussion and effort went into the present logo. Quite frankly, I wish people were as willing to put as much effort into content creation or article improvement as they are with something like a logo change, which strikes me mostly as a lateral change. Jason Quinn (talk) 17:49, 9 May 2017 (UTC)[reply]

Protesting turkey's block of wikipedia

Turkey has blocked Wikipedia in all langages since 10 days ago. Besides a bbc article it seems that this has passed bellow the radar. Which is really sad. Wikipedia as a community should stand together with our fellow turks cry for a right to freedom of knowledge. I suggest that Wikipedia will show for at least one week at the top of every wiki page an announcement that informes readers of Turkey's government action. The announcement can lead to a page with a black background that offers our solidarity and raises a load voice for the removal of this horrible censorship.

--ג'יס (talk) 23:48, 9 May 2017 (UTC)[reply]

Wikipedia has been blocked by quite a few countries over the years; see Censorship of Wikipedia. The Wikimedia Foundation put out a blog post regarding the situation in Turkey. I don't think having a banner makes sense. --Yair rand (talk) 01:53, 10 May 2017 (UTC)[reply]
We have a movement statement on Meta which has garnered the support of more than 5,000 signatures.
It explains some of the ways to get around the block. Next we need to get the media to pick up and write about what we are doing to help make our content avaliable even if states try to restrict access.
This is important information not just for Turks as pointed out. Doc James (talk · contribs · email) 02:09, 10 May 2017 (UTC)[reply]

RfC: LTA Knowledgebase

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.
Summary:-- The answer to the question Should the English Wikipedia have an off-wiki LTA database that can only be viewed and edited by trusted editors? is yes, but there is more to discuss first.

Details and Caveats:-- The WP:BEANS argument given by many supporters seems primarily good. The opposition to this proposal, despite being outvoted roughly 1:2 in favour of support, were nearly unanimous in their concerns about possible unintended and detrimental effects of restrictions of access. Specifically, the concerns of "what do we do with the existing on-wiki LTA database" and "how do we define "trusted editor?" were widely prevalent in the discussion.

This leads us to believe that the answers to the aforesaid questions are integral for the smooth conduct of the entire process. The following themes are the issues brought up that will require successful discussions before this project can proceed:

  • Theme 1--The first issue is what to do with the existing LTA database hosted on Wikipedia. The proposers, and many of the support voters, were in agreement that the existing pages should be kept, and going forward generic information should continue to be added in order for even new editors to view at the very least the basics of a particular LTA. The exact nature of such information will need to be discussed in a future discussion, though it may not need to be a formal RFC if a decision can be easily reached and agreed upon. Either way, existing information currently on Wikipedia will not be lost. While only briefly mentioned in the RFC, a concern was raised about private information being included in this database. Consideration should be given towards how private data will be dealt with.
  • Theme 2--The second issue is in defining a "trusted editor". This must be the next phase in implementing the proposed LTA Knowledgebase. There was no answer to this question in this RFC, except that many mentioned it may not be too strict lest it deny good-faith NEWBIES editing in vulnerable areas the access required to combat LTAs. While it should go without saying, we highly encourage the editors making their proposal to consider the concerns made in this RFC when crafting the next discussion.

Signed by:

Background

Our Long-Term Abuse (LTA) pages are an extremely valuable repository for Wikipedians doing anti-vandalism work - they inform editors on how particular vandals edit, even when those edits may seem innocent when taken out of context, let them know what to look out for in certain areas of the encyclopedia, and contain suggestions on how to treat certain users; no editor can know about the behaviour of every regular vandal. The records are also used for tracking purposes, informing edit filters for example.

But these pages aren't without their drawbacks. Vandals are often drawn to this system, either by aiming to become an LTA as some kind of badge of honour, trying to live up to their name once listed as an LTA, or by new vandals attempting to emulate the well documented vandalism methods. We should be doing a better job of denying recognition to these vandals, but this is hard to do whilst also keeping a comprehensive open record of their actions on Wikipedia. The other issue with having these records in a public space is not being able to properly document the vandals' edit patterns or our counter measures to avoid BEANS issues, leaving out information that could be valuable to anti-vandal editors.

Proposal

We are therefore proposing a new tool for Wikipedians, called the LTA Knowledgebase, which would be an off-wiki database of LTA records, available for viewing and editing to only (probably approved) experienced editors. Samtar has been working on this for a little while now, and you can see a proof-of-concept version here. With this database vandal fighters will be able to both log information on more recurring vandals as well as covering their editing habits and what we're doing in response in more detail (documenting how relevant targeted edit filters work for example). This will be especially beneficial for those LTAs who we don't even document in order to fully deny recognition. LTAs won't know whether they have an entry, nor what that entry contains.

This tool will not be for extra personal information on these users; it will only encourage more behavioural details, and rules will need to be in place for tool admins to remove any personal information that is added. Requirements for access can be debated in another RfC, but the approach would likely be that users would require manual approval from a tool admin with the needed experience level somewhere between that of NPP and OTRS, requiring sufficient time and experience working on anti-vandalism work to be trusted. Future RfCs could also decide on criteria for the addition of an LTA to the tool and whether all users are able to add an entry or whether new entries might require approval by a tool admin, for example.

Subsequent discussions can be held to clarify the details and specifics so these needn't be debated here beyond suggestions and initial discussion. Sam Walton (talk) and Samtar talk · contribs 16:21, 5 February 2017 (UTC)[reply]

The first question that needs to be answered is: Should the English Wikipedia have an off-wiki LTA database that can only be viewed and edited by trusted editors?

Support (LTA Knowledgebase)

  • Support - excellent idea and needed. Search should be on anything so searching on "Armenia" should find the LTA record for Ararat arev. -- GreenC 17:41, 5 February 2017 (UTC)[reply]
  • Support - and probably all admins should be approved automatically on request. עוד מישהו Od Mishehu 04:38, 6 February 2017 (UTC)[reply]
  • Support provided there is or will be an option to filter by active wiki and/or topic areas they're mostly active in (some LTAs are also belligerents in topic areas known to be warzones; for example Runtshit's second most favourite pastime is stirring the Israel/Palestine pot). —Jeremy v^_^v Bori! 05:06, 6 February 2017 (UTC)[reply]
  • Support. This is an excellent idea, and of course it would make sense to automatically approve all sysops. Tony Tan · talk 06:19, 7 February 2017 (UTC)[reply]
  • Support and make it automatic for Admins. -- Iazyges Consermonor Opus meum 06:22, 7 February 2017 (UTC)[reply]
  • Support, of course, because the proposal would solve the very serious BEANS problem associated with LTA pages. A similar solution would be good for sockpuppet investigations, for the same reason. Binksternet (talk) 06:43, 7 February 2017 (UTC)[reply]
  • Support Good BEANS solution (although I'll be sad to lose the innocent enjoyment of browsing that den of depravity) -- Elmidae (talk · contribs) 17:11, 7 February 2017 (UTC)[reply]
  • Strong support This is much-needed! — Gestrid (talk) 19:34, 8 February 2017 (UTC)[reply]
  • Support per above. MER-C 05:28, 11 February 2017 (UTC)[reply]
  • Support This is needed. ThePlatypusofDoom (talk) 13:08, 14 February 2017 (UTC)[reply]
  • Support with the suggestion that the requirements for access should be low - anyone with any of the various admin-granted user rights (rollback, reviewer, autopatrol etc) should be approved. This will prevent it from becoming seen as a secret cabal. Hut 8.5 18:36, 14 February 2017 (UTC)[reply]
  • Support I have read through the proposal, and it seems like a fantastic idea. Qaei ☎ 21:12, 14 February 2017 (UTC)[reply]
  • Support as others this is needed. There are a growing number of LTA cases where the main motivation seems to be generating larger and larger LTA report entries - if these occur off-wiki and in a less conspicuous location, I'm certain some LTA disruption will cease. I'd also add, the growing use of Wikidata as a repository for certain key data sources will require something to be done to co-ordinate action against LTA cases running across multiple sites, and speaking as an English Wikipedia and Commons administrator, it's very difficult to co-ordinate action as it is when all we're dealing with at Commons is (mainly) copyright issues, once WD seriously starts to become another place to fight over sources, data and page titles (you know, the sort of shit we've been dealing with over Eastern Europe, the Balkans, Israel/Palestine for every day I've been editing) it'll be imperative we can provide our WD colleagues as much data as possible so they can deal with issues. Nick (talk) 21:17, 14 February 2017 (UTC)[reply]
  • Conditional support With the proviso that the LTA pages stay useful enough so that inexperienced editors can refer to them to see the nature of the disruption and how to spot possible socks. --NeilN talk to me 21:21, 14 February 2017 (UTC)[reply]
  • (edit conflict) Support As far as some of the responses regarding attention seeking not being such a big issue, even if that were true (which I wholeheartedly disagree that it isn't) patterns are also a big part of tracking and identifying LTAs and discussion of those patterns is equally as important but discussing (as in identifying) them on-Wiki kinda gives it away (and also WP:BEANS may apply) and they may begin a newer pattern that isn't as easily identified. Though I support this for many more reasons as well...Chrissymad ❯❯❯ ¯\_(ツ)_/¯ 21:25, 14 February 2017 (UTC)[reply]
  • Support – We can probably hammer out the finer details in a second discussion, but a change in this general direction would be welcomed. I've always seen the LTA pages as almost diametrically contrary to WP:DENY (and publicly stating what kinds of edits to look for lets the abusive editors know exactly what kinds of edits to avoid, unless they want to be seen). One word of caution that I would advise is that the requirements for gaining access these pages should be low. I don't even think you need to have any additional user rights or a demonstrated need; anyone who is demonstrably WP:HERE should be able to see these pages on request. (Perhaps the ability the create and edit the pages could be restricted to a higher access level?) The more they are hidden, the less comfortable good-faith editors who don't have access to the pages feel. We want to find the right balance between preventing disruption and maintaining transparency in project administration. Mz7 (talk) 22:06, 14 February 2017 (UTC)[reply]
  • Support - I only have a little bit of experience with LTA cases, but I think that in each case, I came to the conclusion that it wouldn't be productive to "tip our hand" by adding to the details about a user's behavior when it may not be obvious to that user that others are onto a particular strategy/habit/pattern. Of course, this may be presuming that the SPI information that goes along with the LTA cases could also be hidden, and that may not actually be intended here. — Rhododendrites talk \\ 00:48, 15 February 2017 (UTC)[reply]
  • Support I think this solution is appropriate to the problem. Chris Troutman (talk) 12:21, 16 February 2017 (UTC)[reply]
  • Support - details about enforcement should rightfully be hidden from the public at large. That said, access control shouldn't be strict - given that it's meant to be an anti-vandalism reference, giving all rollbackers access sound about right. — Train2104 (t • c) 20:21, 17 February 2017 (UTC)[reply]
  • Support. It's a great idea! That page is like the "How to become an experienced vandals" for them. But I think only users with a certain number of construtive edit can access. By the way it's an important source for newbies too so everyone in the community knows what to do to block distruptive vandals.Justmeonhere (talk) 20:56, 19 February 2017 (UTC)[reply]
  • Support the concept. Oppose some small but serious details with the implementation plan, pending a pause before the next phase for conversation to address those details. I want the benefits and agree with the idea but I would not want the current implementation direction advanced without conversation, and I really do believe there are non-controversial, low risk paths forward. The WMF recently published advice to set up a sort of LTA Knowledgebase, so there is institutional support for the concept. That support and other hints of the idea are in the November 2016 meta:Training modules/Online harassment/First draft and meta:Training modules/Keeping events safe/First draft. With many others I proposed meta:Grants:IdeaLab/Centralised harassment reporting and referral service some time ago, which is a similar concept. Blue Rasberry (talk) 20:00, 22 February 2017 (UTC)[reply]
  • Support, this would be so helpful for SPI. It's frustrating to be asked to handle a case where the evidence is "same as always" or "WP:BEANS," so this would make it much easier to process complex LTA cases. However, I strongly believe that we should create some sort of threshold to prevent socks from gaining access to the database and developing new, undetectable modes of behavior, or vandalizing (?) the system. Maybe an ECP-style 30/500 will do... GABgab 04:41, 26 February 2017 (UTC)[reply]
  • Support. Good idea. However access control will have to be carefully thought out. We want regular established users and vandal fighters to not have to jump through too many hoops to get access to it, but as per GAB above we don't want socks etc. -- œ™ 04:46, 28 February 2017 (UTC)[reply]
  • Support - Having this information out in the open makes it a cat and mouse game that is impossible for us to win. Agree with others that access control is the key issue. It should be open enough to be relatively transparent (i.e. not a cabal), but restrictive enough to keep out sockpuppets. Kaldari (talk) 18:40, 3 March 2017 (UTC)[reply]

Oppose (LTA Knowledgebase)

  • Oppose. There's not much I can do to prevent an off-wiki database, though I think it's probably not a good idea, I'm generally opposed to removing the information from Wikipedia. It's useful for editors to be able to look up cases to be able to recognise LTAs. It's also useful for admins to just link to the cases instead of having to provide detailed explanations each time, when blocking and so on. Here for example, an IP user could tell me all I needed to know by linking to an LTA page. Reports at AIV for example will often just say "see WP:LTA/xxx", which is something I don't think should be restricted to a trusted subset of users. More eyes on reports means more good information and less incorrect information as far as I'm concerned. Like I say, there's nothing preventing anyone setting up a private LTA database anywhere they like, but the on-wiki version is useful, so for this reason I'm landing in the oppose section. -- zzuuzz (talk) 20:00, 8 February 2017 (UTC)[reply]
    • Changed my vote to meh, per my comments above and below... LTA to remain in use, which is good, but I fail in enthusiasm for the proposition. -- zzuuzz (talk) 21:29, 14 February 2017 (UTC)[reply]

*Provisional oppose. Until a concrete plan is hammered out for how the existing LTA pages will be used and updated. --NeilN talk to me 14:27, 10 February 2017 (UTC)[reply]

  • Oppose. Until there is a proper way to prevent abuse of this new system, and that WMF legal ascertains that this is compliant with the privacy policy. Cenarium (talk) 21:04, 11 February 2017 (UTC)[reply]
  • @Cenarium: We've talked with commtech quite a bit. Not sure what you mean by "to prevent abuse of this new system," but I'm pretty sure it is compliant with the PP as it has no personal information. Dat GuyTalkContribs 17:38, 14 February 2017 (UTC)[reply]
  • @DatGuy: The stated goal of this project is to collect information on users, so it is more than likely that personal information with be shared there, whether intended by the designers or not. Regardless of the alleged ills that caused the reported users, this is a problem that should be taken seriously. There should be an oversight-like system to remove personal information. ArbCom should have jurisdiction, to reduce the probability for this type of incidents and settle any such incident. We need a real assessment that this complies with the privacy policy, not just some vague feeling it does. Cenarium (talk) 23:05, 14 February 2017 (UTC)[reply]
  • Oppose the "LTA as a badge of honour" conjecture is just that. I'm sure some find it amusing. But they find it amusing to be reverted. All the best: Rich Farmbrough, 23:46, 13 February 2017 (UTC).[reply]
    • @Rich Farmbrough: Not sure I can find the diffs right now but I know I'm not the only one to have reverted vandals who are quoting their LTA page or making explicit references to it. It's clear that for some this page is something they strive to build like some kind of vandalism resume. Sam Walton (talk) 00:02, 14 February 2017 (UTC)[reply]
      • Diffs like this or this should suffice to demonstrate the point. IMO, this is clear indication that they don't need and should never have an LTA page. -- zzuuzz (talk) 08:05, 14 February 2017 (UTC)[reply]
  • Very Strong Oppose Please, no more secrets. Look, if the requirement was going to be extended confirmed, I might consider it. But I see no reason for more cabals. Tamwin (talk) 04:42, 14 February 2017 (UTC)[reply]
  • It will probably be more lenient than extconf. I believe the 'requirements' are just that the user is a good contributor, in any way shape or form. Dat GuyTalkContribs 17:38, 14 February 2017 (UTC)[reply]
  • Oppose as self-defeating. The entire point of LTA is to inform editors of how to deal with serious vandalism. Moving this to a secret database which few have access to (and few would request access to, I believe) makes LTA pointless. I could only support this if the requirement for viewing was extended confirmed. Laurdecl talk 09:51, 14 February 2017 (UTC)[reply]
  • Not "moving," more "adding to." The current LTA list will stay. As said above, probably more lenient than extconf. Dat GuyTalkContribs 17:38, 14 February 2017 (UTC)[reply]
  • As long as it requires something like WP:PERM to have access to, I'm opposing. Laurdecl talk 07:00, 15 February 2017 (UTC)[reply]
  • @Laurdecl: I don't know what you mean 'requires something like WP:PERM.' If we continue with a labs tool and not a wiki, you will click on "request account." Following a short amount of time, if you are not a vandal and some you will be accepted. For example, you would be accepted. Dat GuyTalkContribs 15:04, 15 February 2017 (UTC)[reply]
  • @DatGuy: "would require manual approval from a tool admin with the needed experience level somewhere between that of NPP and OTRS" sounds to me like WP:PERM. Anyway the issue is not whether I would get accepted, but whether this would restrict casual editors from learning about LTAs. LTA is supposed to educate editors about persistent vandals they may stumble across. Most editors would not even bother requesting permission and by the time they are approved would have lost interest. Again, if access was automatically given with extconf, I wouldn't oppose. Laurdecl talk 06:19, 16 February 2017 (UTC)[reply]
  • Oppose. On-wiki lists (pertaining to matters exclusively to that wiki) need to remain exclusively on-wiki. The alternate way to improve LTA would to make the on-wiki page more accessible and searchable. Steel1943 (talk) 14:12, 14 February 2017 (UTC)[reply]
@Steel1943: I don't think you get the point. We want the page to be less accessible, so vandals can't look at the LTA page, completely change their behavior, and not get caught. Also, an LTA page that's easily accessible kind of goes against WP:DENY, as it gives the vandals attention. ThePlatypusofDoom (talk) 22:19, 14 February 2017 (UTC)[reply]
@ThePlatypusofDoom: Oh, but I do ... since having such a database also restricts good-faith editors without whatever user right or program will be necessary to access this database from figuring out what in the world those with access are talking about, or for that matter, even know how to identify a LTA case themselves. So, the argument here is between figuring out if WP:BEANS or the risk of removing the transparency of the Wikipedia project is preferred. And with that being said, I think the latter is worse since hiding information such as this per WP:BEANS goes against some of the public domain licenses and goals of Wikipedia, especially considering that most of these LTA cases are already posted and thus have, in turn, already been agreed upon to be available to essentially any reader per the applicable license(s). In a nutshell, I worry that creating a separate, "inaccessible to some" database could have legal ramifications that I think the foundation would really rather not have to deal with. Steel1943 (talk) 22:30, 14 February 2017 (UTC)[reply]
...Come to think of it, I guess I could just attempt to confirm my concern with one of the proposers of this: @Samwalton9: I know you may have some insight on this: Per my comment above, would you think there would be and legal issues with such a database, and if not, why? Steel1943 (talk) 22:33, 14 February 2017 (UTC)[reply]
I'm very much not a lawyer, but I can't see why something that's been posted on Wikipedia is somehow required to stay on Wikipedia. Pages and edits are deleted and oversighted on a regular basis after all and any content copied over would be attributed in some way. The only legal concerns I could see would be around users assuming it more reasonable to post private/personal information there, but this is obviously a serious concern that would be given importance. Sam Walton (talk) 22:42, 14 February 2017 (UTC)[reply]
@Samwalton9: Yeah, I was more or less asking you in the event that you knew something as part of your "other life". For a few years now, I had the assumed understanding that unless there was some sort of legal issue with keeping something on Wikipedia, the information on a page, deleted or not, could be provided to almost anyone who requests. (But of course, whether or not it stays on Wikipedia is up to the community.) Just trying to ensure that any decision established as a result of this discussion will not cause legal issues that could bite the foundation later. Steel1943 (talk) 22:49, 14 February 2017 (UTC)[reply]
You'd need to ask someone from Legal for an official word on that, but either way, I think it would be reasonable to keep the text that's currently on LTA pages there (it's out in the open now at any rate) and simply not add any more to them from now on. Sam Walton (talk) 22:54, 14 February 2017 (UTC)[reply]
@Samwalton9: Understood and thanks! Not sure how or who to ask "from legal" though since I'm embarrassingly not sure how to do that. Steel1943 (talk) 22:57, 14 February 2017 (UTC)[reply]
@Steel1943: In the past, I've been able to contact Legal by simply leaving a message at User talk:Mdennis (WMF), and Maggie Dennis will liaise with the legal team for you. I think, however, you can also contact legal@wikimedia.org directly per wmf:Contact us, though I've never tried it that way. Mz7 (talk) 23:07, 14 February 2017 (UTC)[reply]
  • Oppose. As an administrator on a sister project I have found the publicly viewable LTA documentation here very valuable, because a number of these abusers take their activity cross-wiki when their efforts are frustrated by anti-vandalism measures here. If this research and documentation is kept behind closed doors then my job will be more difficult. (I am not persuaded that this proposal does not deprecate public LTA tracking: publicly viewable pages would fall into disuse and cease to be a valuable resource.) ~ Ningauble (talk) 17:56, 15 February 2017 (UTC)[reply]
    @Ningauble: There would certainly be plans to make sure this could be used and accessed across other language Wikipedias, but you raise a fair concern that this should be a priority before deployment. Sam Walton (talk) 18:27, 15 February 2017 (UTC)[reply]
    Sam, I was referring to a sister project rather than another language Wikipedia, but the case of my personal anecdote can be generalized in various ways. The most important generalization, common to both, is explicit in my post above: "publicly viewable" wikis. ~ Ningauble (talk) 18:57, 15 February 2017 (UTC)[reply]
  • Oppose on general principle of not maintaining such an archive as an off-wiki resource, and as well as limiting access to any specific group. I get the BEANSy-ness of the argument, but moving this off-wiki leaves us using an off-wiki repository for enforcement when any LTA comes back up. Access limitations to such a resource would plainly limit the ability of some editors to review such material and contribute to consensus. It should be made more usable, and some kind of archiving is a good idea, but it should stay inside the project, and available to all editors. Jim Miller See me | Touch me 19:48, 15 February 2017 (UTC)[reply]
  • Strongest oppose Creating an off-wiki restricted database with the express purpose of identifying particular users? No thanks. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 20:06, 19 February 2017 (UTC)[reply]
  • Oppose I could see such a system for off wiki info. On wiki allowed stuff should be on wiki. Also the site should be a wiki not whatever this is. Doc James (talk · contribs · email) 17:51, 20 February 2017 (UTC)[reply]
  • Oppose per Steel1943. Such stuff needs to remain on wiki. If you want to make an improved interface for accessing and searching LTA pages (which remain on wiki) that's fine. Kind of like Wikipedia:AutoWikiBrowser/CheckPage: primarily used by external software but still accessible on-wiki. feminist 09:45, 21 February 2017 (UTC)[reply]
  • Oppose I've been hesitating here , trying to make up my mind, and I think at the end of the day I oppose this. I tangled with one of the more notorious LTA cases early in my wiki-career, and free and easy access to the page about them helped me quickly understand what I was dealing with and how to respond appropriately. Moving it off-wiki, no matter how you do it, lowers the profile iof this important resource, possibly preventing newer users from even being aware of it. Duplicating it offline while keeping it here seems pointless. So I think we should keep it here. Beeblebrox (talk)
  • Oppose I think there are serious transparency issues that need to be addressed before I could support a proposal like this moving forward, and I'm not sure they can be. The fundamental problem is that if this is useful, it means we are using access restricted/secret information, as justification for on-wiki action that will likely involve blocking people. It is already problematic when Arbcom and other functionaries do it, but in that case, they are a very small group, of highly vetted and trusted users, and the secret information they use cannot be posted publicly. It also has various checks built in to provide review and limit abuse. It would be better if we didn't need it, but it is in the end a necessary evil. This does not appear to be such. If someone is being blocked for LTA, they should have the right to see the evidence presented against them. Moreover, if the block ends up being reviewed at WP:AN the community must be allowed to see the evidence, so they can judge the block. I would still have concerns, but at the least, I think there needs to be a way to make the entire LTA case fully public for review. Monty845 06:03, 24 February 2017 (UTC)[reply]
    • If a usermass-creates attack pages, he will be blocked on evidence that only admins can see. Since all admins, and some other users, will be able to view the LTA, this will have at least as much transparency as a user who mass-creates attack pages. עוד מישהו Od Mishehu 22:20, 4 March 2017 (UTC)[reply]

Discussion (LTA Knowledgebase)

What's going to happen to the existing LTA pages if this is implemented? --NeilN talk to me 16:30, 5 February 2017 (UTC)[reply]

I guess that's open to discussion, the options would be to retain them since the information has been public for long enough already, archive them and provide links to the new tool which may contain extra information, or remove/delete them. I think the preferable option would be to retain/archive so that existing links still work, but include a link to the tool and tell users to add content there rather than on-wiki. Sam Walton (talk) 16:46, 5 February 2017 (UTC)[reply]
I would probably oppose anything which prevented me from helping new/occasional editors (i.e., "non-approved" editors) understand what's going on by pointing to a LTA page explaining the nature of the abuse/disruption, what to look out for, etc. --NeilN talk to me 16:58, 5 February 2017 (UTC)[reply]
@NeilN: Perhaps we could repurpose the on-wiki pages to provide very general descriptions, moving all the specifics and IP/account records to the tool. Sam Walton (talk) 21:11, 5 February 2017 (UTC)[reply]

This is an interesting proposal and I know a case where it would help me have useful discussions about a particular LTA. Sam Walton, I don't think this is your part of the WMF, but something like this has been suggested in the new Community Health Initiative grant proposal, page 11. Had you heard of this? If so, do you have any thoughts about how it might tie in? BethNaught (talk) 17:05, 5 February 2017 (UTC)[reply]

@BethNaught: Interesting - I hadn't had a chance to read that document yet and wasn't aware that such a tool was already being talked about. It seems that the resource proposed there would be broader, documenting cases of harassment and editing restrictions too. We'll speak to Community Tech to see if it's worth continuing with this tool if they're planning to work on that. Sam Walton (talk) 21:13, 5 February 2017 (UTC)[reply]
Indeed, we were planning on making a similar, more broadly scoped tool that I think will account for all types of abuse. The LTA Knowledgebase as currently constructed could be adapted for this purpose, along with adding multi-project support and i18n. The harassment project as a whole is still in its very early stages, so for now I would carry on and assume there won't be any conflicts with what WMF will be working on. It is nice to see the community getting a head start and this RfC attracting support. Assuming you all are OK with joining forces (we certainly are), Community Tech will soon be in touch with Samtar, Sam Walton, and any other Sams involved :) — MusikAnimal talk 16:34, 7 February 2017 (UTC)[reply]

How about hosting a multilingual LTA on Meta? KATMAKROFAN (talk) 17:42, 5 February 2017 (UTC)[reply]

Down the road, it is planned that there will be multilingual support, especially for dewiki. Dat GuyTalkContribs 17:47, 5 February 2017 (UTC)[reply]

Please spell out the proposal ("viewing and editing to only (probably approved) experienced editors" is ambiguous). Currently it is possible to link to an LTA page in a comment or edit summary to explain an action. It is desirable to minimize such linking per WP:DENY but it is sometimes needed. Would the new system allow such links? What happens when people (an IP, a new account, an autoconfirmed account, an approved LTA operator) click them? I'm asking because if the information is available to all, why is the new system better than LTA pages? But if it's only available to approved operators, a link loses its explanatory power, although a link to generic information with a tag like an WP:OTRS ticket for more details would be good. Johnuniq (talk) 00:45, 6 February 2017 (UTC)[reply]

I would think that some standard similar to ECP would be used, albeit with a bit more restrictions on time and edit number (I'm thinking 1yr/10K edits on any one project). Anyone with sysop permissions on any wiki should automatically be trusted. I do have to ask, though; is there (or will there be) an option to filter LTAs by the wiki(s) they're active on? —Jeremy v^_^v Bori! 04:59, 6 February 2017 (UTC)[reply]
@Jéské Couriano: It is possible to link using toollabs:lta/publicdemo/view.php?lid=8 or via an external link. Currently its only enwiki, but when it will be expanded to other wikis there definitely will be an option to filter LTAs. There are no set requirements, but sysops will be always approved. There might be consensus on requirements in this RfC. Dat GuyTalkContribs 06:48, 6 February 2017 (UTC)[reply]
Above link doesn't work, try https://tools.wmflabs.org/lta/publicdemo/view.php?lid=8 -- Samtar talk · contribs 12:00, 6 February 2017 (UTC)[reply]

Why not implement this as a private wiki? We already have the private "arbcom-en.wikipedia.org" wiki as a precedent. I don't see why a custom tool on Labs is necessary; wikis come with a lot of built-in features like revision history. And availability is another consideration – what will be done during one of Labs' brief but regular outages? LTA response is not something which can wait until the outage is over, unlike, say, edit counting or category intersections. — This, that and the other (talk) 09:19, 9 February 2017 (UTC)[reply]

I second this comment. LTA databases should have lots of links back to the wikis targeted. Don't reinvent the wheel -- a private wiki is a very good solution for this problem. MER-C 05:33, 11 February 2017 (UTC)[reply]
@Samtar: We discussed this on IRC, but could this be restricted to people with Rollback? It's not hard to get and most vandal fighters have it already, and the requirements wouldn't be that strict, but it wouldn't be very easy for an LTA to get. ThePlatypusofDoom (talk) 17:30, 14 February 2017 (UTC)[reply]

To resolve some of the transparency issues involved, would it be feasible to use WP:OAuth and allow users to log in with their regular Wikipedia account, rather than create a separate Knowledgebase account? We could, perhaps, then allow all extended confirmed (or even lower) users to view LTA pages just to maintain transparency, and then grant editing access to the Knowledgebase using the manual approval process mentioned in the proposal. Mz7 (talk) 23:01, 14 February 2017 (UTC)[reply]

@Mz7: Samtar can clarify, but I believe the plan would be to use OAuth. Sam Walton (talk) 18:28, 15 February 2017 (UTC)[reply]
You login using OAuth. It still needs to go through a confirmation process if it is your first time though (even for viewing currently). Dat GuyTalkContribs 19:24, 15 February 2017 (UTC)[reply]
Ah excellent. Thank you both for the clarification. Mz7 (talk) 21:00, 15 February 2017 (UTC)[reply]
Request for listing

Could someone list this on WP:CENT? Seems suitably important. Tamwin (talk) 04:59, 14 February 2017 (UTC)[reply]

 Done Tamwin (talk) 06:46, 14 February 2017 (UTC)[reply]

Clarification ref current LTA pages

Hi all - a couple of people have raised concerns about what who happen to the current WP:LTA pages should a tool like this been accepted by the community - personally I wouldn't do anything with them, but others have suggested generalising them with WP:BEANS and WP:DENY in mind. What definitely won't be happening is them being deleted as this would seriously affect the ability of newer editors being able to assist with anti-vandalism. This tool has been designed to compliment and enhance our current methods of LTA-handling, and not to entirely replace it -- Samtar talk · contribs 15:34, 10 February 2017 (UTC)[reply]

Not sure if you've seen this @NeilN and Zzuuzz:. Dat GuyTalkContribs 10:29, 11 February 2017 (UTC)[reply]
Yes, but I'd like a more concrete plan. Not deleting is one thing, but how about updating and adding new cases? --NeilN talk to me 14:13, 11 February 2017 (UTC)[reply]
I think I have similar concerns to NeilN. Where would LTA reports go? Where do we point IP users who want to be informed of an LTA, and how can they point me to a page in order to get a block or page protection? How will this differ from the current system? If the current LTA system is unaffected, then we'll just carry on at LTA like normal (in the useful manner I've described above) and my oppose can be shifted from oppose to meh (for various (possibly unfashionable and idiosyncratic) reasons I don't think semi-private forums, like WP:WEA, are usually a net positive). But if the effectiveness of LTA is reduced by these changes then I have concerns. -- zzuuzz (talk) 20:53, 11 February 2017 (UTC)[reply]
Don't see how you can "generalise" without effectively deleting them. All the best: Rich Farmbrough, 23:47, 13 February 2017 (UTC).[reply]
@Rich Farmbrough, Zzuuzz, and NeilN: The current LTA system will stay the same. The tool could be seen as a "bonus." Dat GuyTalkContribs 17:38, 14 February 2017 (UTC)[reply]
The second paragraph of the introductory background for this proposal, beginning at "But these pages aren't without their drawbacks...", seems quite clear about deprecating the existing LTA pages. If a private database is adopted and used by a critical mass of (approved) anti-vandal editors, I find it hard to imagine that the existing LTA pages would not fall into disuse, at least, and might ultimately disappear. ~ Ningauble (talk) 17:32, 15 February 2017 (UTC)[reply]
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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=779719554"