Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Ivanvector (talk | contribs) at 16:45, 7 May 2017 (→Proposal: clarification of community blocks: re). 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:


Renaming Category:WikiProject Infoboxes

The CFD has completed with the outcome keep (no change to name). --User:Ceyockey (talk to me) 01:43, 1 May 2017 (UTC)[reply]

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

I just want to alert people that there is currently a proposal at CFD for renaming Category:WikiProject Infoboxes to Category:Wikipedia infoboxes [1]. Personally, I have opposed this, as this is obviously a maintenance category. I don't understand the rationale behind the proposal. ---Steve Quinn (talk) 18:04, 15 January 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.

Clicking on images

Tracked in Phabricator
Task T163875

Another proposal of mine (also for all Wikipedia versions, if possible) would be to make sure that after clicking on an embedded file in an article and entering the Commons page of that file, you get back right to the position of that image in the article when using the back-button of your browser. Up to now, this is not the case at least for the current Firefox, but instead you always end up at the beginning of the article once you have entered Commons. Would this also be worth forwarding to Phabricator in your view?--Hubon (talk) 15:31, 12 April 2017 (UTC)[reply]

You'd better ask this question on Wikipedia:Village_pump_(technical). Ruslik_Zero 20:15, 12 April 2017 (UTC)[reply]
Do you have "Enable Media Viewer" at Special:Preferences#mw-prefsection-rendering? Media Viewer is known to mess with the normal functioning of the back button. PrimeHunter (talk) 21:52, 12 April 2017 (UTC)[reply]
@Ruslik0: Thanks for your advice! @PrimeHunter: Yes, I do, but still: If we take the article Nazi plunder and click twice on image no. 5, we get to this site. Now, if we click "back", we end up at the very beginning of the article instead of the relevant section. And it's the same with all the other Wikipedias! As recommended by Ruslik, I will now refer the issue to Wikipedia:Village_pump_(technical).--Hubon (talk) 22:30, 13 April 2017 (UTC)[reply]
If Media Viewer is causing problems for you, then disable it. It's crap quality, buggy code, and I recommend against using it. -FASTILY 22:42, 15 April 2017 (UTC)[reply]
@Hubon: Preservation of scroll state is a browser function (I have no trouble with Chrome or Safari). Which browser are you using ? —TheDJ (talk • contribs) 13:06, 17 April 2017 (UTC)[reply]
@TheDJ: Thanks for your interest! I use the latest Firefox version. Now, do you think it would be very difficult for Phabricator to modify Media Viewer in a way that would render it compatible with all common broswers regarding preservation of scroll state? Greetings--Hubon (talk) 13:11, 18 April 2017 (UTC)[reply]
I can confirm that this is a problem with Firefox. You should report it in phabricator. —TheDJ (talk • contribs) 09:55, 20 April 2017 (UTC)[reply]

Note: Unfortunately, nobody answered on Wikipedia:Village_pump_(technical)... :-(--Hubon (talk) 21:04, 19 April 2017 (UTC)[reply]

user:TheDJ: Many thanks for your interest! Would you mind reporting the issue on Phabricator? As I've already communicated before, I'm admittedly not at all familiar with this platform... Thus, I'd be very grateful for any help with passing on the the request to the institutions responsible. Best--Hubon (talk) 19:28, 23 April 2017 (UTC)[reply]
@Hubon: Reported as T163875. You can subscribe to it using the "Subscribe button" in the right column (After you logged in using your Wikimedia account, by pressing the Mediawiki button on this page) —TheDJ (talk • contribs) 08:35, 26 April 2017 (UTC)[reply]
@TheDJ: Thank you so much!!! I just did as you told me. Now let's wait and see what happens. Thanks once again and best regards--Hubon (talk) 13:53, 26 April 2017 (UTC)[reply]
@TheDJ: Alright, just for your information: They've meanwhile closed the file... Best--Hubon (talk) 00:59, 1 May 2017 (UTC)[reply]

Recategorizing all medicine and biology articles using the more specific MeSH hierarchy

MeSH is a very important database created by the United States National Library of Medicine (NLM) to index books and journal articles in medicine and biology. It is updated annually. For 2017, it contains more than 55000 categories (they call them descriptors) which can very specifically categorize any article of biology or medicine. My idea is to import this tree hierarchy to Wikipedia. This could be achieved using AWB tool and an approved Bot account. I got already a *.xlsx file listing these descriptors from the official MeSH website. I have then converted it to a text file which is ready for mass category creation using CSV Loader Plugin of AWB. Some of these categories are already on Wikipedia, but I believe the majority are not yet. Each MeSH category will contain the following text: 

Template:empty category
Template:MeSH category, including the unique MeSH ID as a key.
template:cat main
MeSH definition:
category:Medical Subject Headings, including the tree number as a key.

Examples of such MeSH categories are: Category:Anatomic Landmarks, Category:Body Regions

I think also that this idea, if applied, will reveal hundreds of new red links.

Previous discussions:

Tools needed:

Support

Oppose

  • This seems a misuse of the categorization system. Finding which articles are missing is not the purpose of categories (or else they should be maintenance categories, hidden from sight), normally one would create one or more lists in project space for this where the redlinks can be listed. Having 55,000 categories for this is serious overkill (do we really need Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4, which has two different codes to boot?). Creating a category system using a higher level of grouping from this tree hierarchy seems a potentially good thing though, with just a few thousand categories. I also don't see how you propose to differentiate between categories with the same MeSh name (e.g. "Superficial Musculoaponeurotic System" is A01.456.505.875 and A01.598.500). The actual benefit you propose (" It will ease access to medical articles from categories.") can better be achieved by a somewhat smaller category tree than the massive one you propose. Fram (talk) 07:17, 20 April 2017 (UTC)[reply]
    • @Fram: Would you suggest a way to remove very very specific categories like Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4 from the hierarchy? Regarding categories with the same Mesh name, they are basically the same category but subcategorized under two different categories, that's why they have different tree numbers, but you can notice that they have the same "unique" ID number. --Brainist (talk) 07:29, 20 April 2017 (UTC)[reply]
      • I don't know a way whereby a bot can decide which categories are too specific, and which aren't. It isn't as easy as saying "lowest level is not used, all higher levels are used". Perhaps something like "only go three levels deep" may be a (simplistic) solution. Or perhaps this simply isn't a good bot task after all. Creating thousands of empty mainspace categories seems like a bad idea in any case. Fram (talk) 08:48, 20 April 2017 (UTC)[reply]
        • Thanks for making me aware of the duplicates, which after exclusion, the unique categories came out to be almost exactly the half, just 27900 categories. I don't think this number for categorizing all articles related to whole medicine, dentistry, veterinary medicine, biology is massive. They will be temporarily empty till I fill them. Notice that out of those 27900, there are already thousands of medical categories out there in Wikipedia which will be skipped by the bot. --Brainist (talk) 09:39, 20 April 2017 (UTC)[reply]
        • Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4 would be almost empty today containing just "PIN4", but after let's say 3 years, with the encyclopedia expanding, this category will contain articles about diseases caused by malfunction of this enzyme or drugs acting on it, etc. This hierarchy will be the last categorization needed for medical and biological articles, and it will be updated annually with the release of a newer version of MeSH database by NLM. --Brainist (talk) 09:51, 20 April 2017 (UTC)[reply]
          • We've had PIN4 for 9 years now, and no articles link to it. I see no reason to share your optimism that in a few years time, these categories will be populated with more articles suddenly. Subdividing categories when they turn out to be overpopulated is natural; creating thousands of empty and near-empty categories in the hope that they will magically become more populated in a few years time is not something I can support though. I also note that this is much wider than just medicine: your proposal would create categories like Category:Alouattinae, which owuld be a duplicate of Category:Howler monkeys. I don't see in your proposal how you wuold deal with the many, many similar cases where we already have a category for the common name and you would create one for the MeSH name. Basically, the more I look at this, the less erason I see to do this by bot or en masse. Fram (talk) 10:33, 20 April 2017 (UTC)[reply]
  • Oppose - we do need human judgement on which categories need to be created. For example, we have Category:Bonobo, so we don't need Category:Pan paniscus (on List of MeSH codes (B01)#MeSH B01.150.900 --- vertebrates, number B01.150.900.649.801.400.112.400.600); nor do we necessarily need Category:Papio anubis or its likely name Category:Olive baboon (number B01.150.900.649.801.400.112.199.120.610.050). While both of these items come from the organism subtree, I think similar attention would need to be given to the other subtrees. עוד מישהו Od Mishehu 11:41, 20 April 2017 (UTC)[reply]
  • I'm not going to use bold in this oppose, but is this not better done at Wikidata, which already has Mesh IDs? --Izno (talk) 12:20, 20 April 2017 (UTC)[reply]
  • Oppose We do not usually need this degree of specialization. There is no virtue in overly narrow categories-. For many of the MESH categroies, the WP search function will work quite well. Categoriews also normally use generally accessible terminology,; MESH is specialized. Our articles are intended for general readers. DGG ( talk ) 14:09, 20 April 2017 (UTC)[reply]
  • Oppose The human touch works well for creating needed categories. We do not need more elaboration in the form of over-specialization and creating overly narrow, contra-intuitive categories. If anything, the current tree needs pruning. Dlohcierekim 18:11, 20 April 2017 (UTC)[reply]
  • Oppose Please don't add them all, as it will result in many empty or useless categories, that will just have to be deleted. I think some human nouse will be required evaluate which ones are useful , and where they should be added into the already existing category tree. Graeme Bartlett (talk) 08:17, 21 April 2017 (UTC)[reply]
  • Oppose we have already had very poor experiences using alternate category and tree categorisation systems in the anatomy space. Problems that we encounter are trying to morph our existing content to match systems that don't match our unique scope, style or notability or requirements. The fact is, we are a unique encyclopedia and we do not need to duplicate other categorisation systems. Wikidata would be a more appropriate mechanism to deploy MeSH data, and then link that to articles.--Tom (LT) (talk) 11:29, 22 April 2017 (UTC)[reply]
  • Oppose for now The proposal doesn't seem to have given enough thought to the issues (and is not signed btw). This certainly would not work for categories without a huge amount of human help, and who would do that? Seems much more suited to Wikidata. Johnbod (talk) 15:19, 1 May 2017 (UTC)[reply]

Discussion

How will the bot identify which categories to give to each article? Chiswick Chap (talk) 21:37, 18 April 2017 (UTC)[reply]

The bot will be used to create the categories. Categorizing article I will then do manually. Do you have a better idea to do this using a bot? --Brainist (talk) 21:43, 18 April 2017 (UTC)[reply]
Some articles already have a MeSH code, so they could be classified automatically by a bot. But there are already 2,600 categories and over 30,000 articles in the scope of WikiProject medicine. Is it actually your intention to make use of all 55,000 MeSH descriptors and manually assign each of the 30,000 articles into categories based on those descriptors? --RexxS (talk) 21:54, 18 April 2017 (UTC)[reply]
@User:RexxS, I think the hardest part is creating 55,000 new categories. This must be done using a bot. It is ok if I do the categorization part manually, even if it takes a while.--Brainist (talk) 23:03, 18 April 2017 (UTC)[reply]
What is the benefit? Doc James (talk · contribs · email) 22:28, 18 April 2017 (UTC)[reply]
@User:Doc James, the same benefits of categorization in general. It will ease access to medical articles from categories. For example without Category:Amygdala, it would be hard to find all Wikipedia articles related to amygdala's anatomy, histology, physiology, diseases, and surgeries. And as I mentioned before, It will reveal the shortage in medical content. I noticed that many MeSH descriptors don't have a corresponding Wikipedia article. --Brainist (talk) 23:03, 18 April 2017 (UTC)[reply]
Okay sounds reasonable. This will also incorporate articles related to anatomy, molecular and cell biology, and physiology etc. Doc James (talk · contribs · email) 23:27, 18 April 2017 (UTC)[reply]

Is the source for this bot available so we can confirm it won't break everything? Also, how will the task be separated between the bot and AWB? PriceDL (talk) 17:23, 19 April 2017 (UTC)[reply]

@PriceDL: using the CSV loader plugin, the column header:
Bot using AWB tool in CSVLoader plugin
##article_name##$$##Unique_ID##$$##Description##$$##treenumb##
for example:
  • I should mention than unsued categoriwes can be speedily deleted; categories
##Category:Cavernous Sinus##$$##D002426##$$##An irregularly shaped venous space in the dura mater at either side of the sphenoid bone.##$$##A07.231.908.224.334##

will be used, with the general text: 

template:empty category
template:MeSH category|##Unique_ID## 
template:cat main
MeSH definition: ##Description##
category:Medical Subject Headings|##treenumb##

The AWB tool is semi-automated, namely it can find the column headers within a text and replace it, but it needs a user to click the save button for each category. In order to avoid clicking the save button 50,000+ times manually, I want a bot with AWB permission to automatically click the save button (see the picture). After creating all categories, the bot will use very simple pywikibot scripts to categorize them inside each other and form the MeSH tree.--Brainist (talk) 04:07, 20 April 2017 (UTC)[reply]

  • I should mention that it is part of general Deletion Policy for empty categories to be speedy deleted. Categories containing only very few items are routinely brought for discussion at WP:CFD, and almost always upmerged or removed. There is also a formal procedure for renaming categories. If anyone should add several tens of thousands of empty or almost empty categories, I expect it will be considered unconstructive. DGG ( talk ) 14:17, 20 April 2017 (UTC)[reply]

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]

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]

Response to 2017 ban in Turkey

Have started drafting a community response. Doing so on meta[2]. Wondering peoples thoughts. Best Doc James (talk · contribs · email) 17:12, 29 April 2017 (UTC)[reply]

  • An unfortunate development, this banning, but not surprising. There are frequent edit wars and article forks where political situations are involved and the article history can contain truly bad content, as can the talk page and talk page history. There is a fine line between the rights of a nation-state to control information flow across their borders and self-serving censorship. Without deeply thinking this through, it might be a great service to most people to "negotiate" with Turkey on their blocking specific articles while allowing the rest to pass through. Though sour tasting, this would allow access to 99% of Wikipedia rather than 0%. --User:Ceyockey (talk to me) 01:58, 1 May 2017 (UTC)[reply]
While I see your point, I can't really get on board with it User:Ceyockey, and I think most people won't. I (and I think most people) probably don't agree with "There is a fine line between the rights of a nation-state to control information flow across their borders...". There's no fine line. Nation-states have no moral right whatsoever to control information flow across their borders, as a general rule. There could possibly be some argument at the extreme margins (state secrets and so forth). Maybe. I get your 99% versus 0% point, but that feels like a possible slippery slope, and matters of principle are in play here. Herostratus (talk) 02:08, 1 May 2017 (UTC)[reply]

Acces: User of delete pages

أهلا إخوتي، لقد دخلت لصفحة ويكيبيديا:إداريون ووجدت الكم الهائل من المهام التي تقع على عاتقهم، لذلك لا يستطيعون القيام بها كلها رغم أنها مهمة جدا للحفاظ على جودة الموسوعة، منها حذف الصفحات المخالفة، لذلك أقترح نزع هذه المهمة من قائمة مهامهم، وإنشاء صلاحية جديدة هي "صلاحية الحاذف" لحذف الصفحات المخالفة بكبسة زر كما يفعل الإداري، لتخفيف الضغط عليه. تقدم هذه الصلاحية للأشخاص المهتمين بمكافحة التخريب الكبير (أي صفحات تخريبية وليس جمل أو فقرات) لحذف مثل هذه الصفحات بسرعة بدل انتظار إداري أو إرهاق المسترجعين بإرجاع التعديلات حتى نترك مجالا كبيرا مفتوحا للمسترجعين والإداريين بممارسة مهامهم بكل سهولة دون مهام تثقل كاهلهم.

  • (Google Translation: Hello, my brothers, I have entered the Wikipedia page: administrators and found the huge amount of tasks that they have, so they can not do all of them although they are very important to maintain the quality of the encyclopedia, including delete the infringing pages, so I suggest removing this task from their list of tasks, A new "privilege" to delete the infringing pages at the push of a button as the administrator does, to relieve the pressure on him. This allows people who are interested in combating vandalism (such as subversive pages, not sentences or paragraphs) to quickly delete such pages instead of waiting for administrators or overloading the returnees so that we leave a lot of room for those who can easily perform their tasks without burdening them.)

Mohamed Ajjani (talk) 13:19, 30 April 2017 (UTC)[reply]

Is this proposal for English Wikipedia, Arabic Wikipedia, both, neither or some other option? • • • Peter (Southwood) (talk): 18:11, 30 April 2017 (UTC)[reply]
If this is for the English Wikipedia it is a play on the always denied perennial proposal of "admin-light". Considering that deletion is one of the most sensitive tools in the admin toolkit and the one that could present the most problems I don't see how this proposal will ever be viable. At least not here. Other projects have their own things. --Majora (talk) 18:25, 30 April 2017 (UTC)[reply]
Personally, I do not feel overwhelmed. We seem to work through the backlogs. Not that I think "Admin light" is a bad idea per se, I just know we will never be able to work out the difficulties to make it viable. Dlohcierekim 18:42, 30 April 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]

There are many cases when an article on another language is linked only because its what best fit at that time but being not the best option, as Wikipedia is a dynamic encyclopedia creation of better suitable article could occur further in time but as I know meta links are not much undoable and then articles are mostly linked to other idioms what better suited at the time of its creation. Incredibly the fastest (if not the only) way of doing this is moving that article to other whit the name of the desired new article being linked, for then cut its content, place there the new article, save it and go back to the original article name where now is a redirection, edit its content removing the redirediction and placing there the original content, voila there is the old article not linked and the new article does be linked but this way as is reinventing the wheel is also the worst practice. Isnt there a way to deal with this? --Neurorebel (talk) 23:26, 1 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:
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]
  • 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]
  • 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 48,100,370 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]
  • 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]
  • 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]

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]
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]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=779207263"