Wikimedia Meta-Wiki

Опитування побажань спільноти (2015)/Інструменти модерування та адміністрування

< Community Wishlist Survey 2015
This page is a translated version of the page Community Wishlist Survey 2015/Moderation and admin tools and the translation is 100% complete.
Other languages:

Вдосконалення сторінки історії редагувань

Сторінка історії редагувань є ключовим інструментом управління сторінкою! Деякі можливі покращення:

  • Надійніше компонування; більш наочне відокремлення рядків, та/або краща результативна поведінка.
  • Краще відокремлення даних від дій. До «даних» належать посилання на версії, мітка часу, інформація про користувача, опис редагування, теги тощо. До «дій» належать відкоти, скасування, вдячності тощо.
  • Менше «напівтаємних» речей, які можуть виявитись заплутаними для новачків. Наприклад: з посилань «поточн.» та «попер.» не очевидно, що вони мають значення «відмінність від поточної версії» та «відмінність від попередньої версії» відповідно.
  • Візуальна репрезентація даних. Наприклад, графічно оформлені посилання між версіями без відмінностей (зазвичай між відкотом редагування та версією, до якої був здійснений відкіт). Ключовою ідеєю тут є «інформація на сторінці історії редагувань, яка не вимагає вчитування в слова чи числа», наявність якої спростить сприйняття історії змін сторінки при першому ж перегляді.

Я вже трохи грався з деякими з цих речей за допомогою JavaScript; зацікавлені особи можуть використати код importScript("User:Nihiltres/nothingthree.js");, а потім вставити nothingthree.customRevs.testRun(); у консоль на сторінці історії редагувань в англійській Вікіпедії, аби побачити, чим завершилися мої експерименти. Наприклад, я роблю різницю кількості байтів більш самозрозумілою, змінюючи «(65 176 байтів) (+1 234)» на «+1 234 → 65 176 байтів».

Я припинив возитися з цим а) тому, що це втомлювало мене та б) тому, що це треба впровадити у MediaWiki, а не переробляти всю кляту сторінку історії редагувань за допомогою JavaScript. Можливо, команда Community Tech, все-таки хотіла б взятися за щось із всього цього? {{Nihiltres|talk|edits}} 20:25, 17 July 2015 (UTC)[reply]

Earlier discussion and endorsements
I've wanted for a long time some visual representation of the history inspired by the lines on the left of e.g. git histories. That would be something very interesting to have. Helder 12:23, 10 November 2015 (UTC)[reply]

Голосування

  1.   Support Ckoerner (talk) 17:07, 1 December 2015 (UTC)[reply]
  2.   Support --Usien6 (talk) 19:59, 1 December 2015 (UTC)[reply]
  3.   Support although this should run as a beta before full rollout, as I'm sure there would be lots of feedback and differing opinions on various aspects. It's possible that if there is too much consternation over the changes, that this may work best as a gadget. We'll see. Stevie is the man! Talk • Work 22:49, 1 December 2015 (UTC)[reply]
  4.   Support Casliber (talk) 13:32, 2 December 2015 (UTC)[reply]
  5.   Support This is a really fundamental feature of Wikipedia that needs some people to think about what they can do to make it better. But be real sure you have community support before actually implementing it. Wnt (talk) 23:32, 2 December 2015 (UTC)[reply]
  6.   Support Pengo (talk) 01:58, 3 December 2015 (UTC)[reply]
  7.   I support most of this proposal, but I strongly oppose replacing "cur" with "diff with current revision". Hovertext would be OK, but please don't use up real estate with needless repetition. YBG (talk) 06:26, 3 December 2015 (UTC)[reply]
  8.   Support SantiLak (talk) 10:44, 4 December 2015 (UTC)[reply]
  9.   Support Kvardek du (talk) 10:34, 5 December 2015 (UTC)[reply]
  10.   Support all of the above are great suggestions. --Waldir (talk) 15:12, 8 December 2015 (UTC)[reply]
  11.   Support Matěj Suchánek (talk) 21:04, 9 December 2015 (UTC)[reply]
  12.   Support Alkamid (talk) 22:26, 13 December 2015 (UTC)[reply]

Вдосконалений механізм захисту/блокування для окремого користувача та для окремої статті

Tracked in Phabricator:
Task T2674

Зараз є два механізми, використавши які можна зупинити користувача від редагування певної статті у Вікіпедії — захистити статтю від редагування будь-ким, або ж заблокувати користувача, щоб він взагалі нічого не міг редагувати. От і все.

Я справді досить чітко відчуваю, що нам потрібне щось середнє між цими двома крайностями — спроможність захистити чи заблокувати конкретному користувачеві редагування конкретної статті. Це б забезпечило технічні підоснови для запровадження тематичних банів, та дозволило б запобігати втручанню певних редакторів у конкретні теми, які за їхньої участі стають надто конфліктними — і водночас це залишало б для таких користувачів якнайкращі умови для подальшої праці деінде. Ми потребуємо редакторів, однак іноді нам просто доводиться приймати таких редакторів, яких ми маємо, і при цьому якось справлятися з підривними елементами.

Лише перегляньте сторінку ANI в англійській Вікіпедії, або почитайте будь-які обговорення, що стосуються блокувань, аби побачити наскільки драматичними бувають такі ситуації — будь-що, що може послабити такі конфлікти, на мою думку, варте уваги. Я вже змінив код локальної інсталяції MediaWiki, якою я керую, де дозволив «автоматичне G7», тобто, будь-який користувач у моїй вікі (не лише адміни) може вилучити будь-яку сторінку, яку він створив, тож я переконаний, що це технічно можливо. Ritchie333 (talk) 13:02, 29 May 2015 (UTC)[reply]

Earlier discussion and endorsements
Occasionally one both needs to both protect the article and than continually block new socks as they are created :-) It is to easy to get around this. You just keep creating socks. Getting them auto confirmed and editing around the semi protection. We have a few people who do this. Not sure what the solution is. Doc James (talk · contribs · email) 13:20, 29 May 2015 (UTC)[reply]
  Endorsed +1. We are currently using AbuseFilter for personal restrictions, but native solution would be better --AS (talk) 13:50, 9 June 2015 (UTC)[reply]

Голосування

  1.   Support 4nn1l2 (talk) 03:16, 30 November 2015 (UTC)[reply]
  2.   Support MER-C (talk) 09:45, 30 November 2015 (UTC)[reply]
  3.   Support Samwalton9 (talk) 10:32, 30 November 2015 (UTC)[reply]
  4.   Support IJBall (talk) 13:54, 30 November 2015 (UTC)[reply]
  5.   Support NE Ent (talk) 14:05, 30 November 2015 (UTC)[reply]
  6.   Support
    ⋙–Berean–Hunter—► ((⊕)) 15:38, 30 November 2015 (UTC)[reply]
  7.   Support - And also a system to block a user except a small, pre-defined list of pages. This would certainly be useful in many cases on English Wikipedia. עוד מישהו Od Mishehu 16:18, 30 November 2015 (UTC)[reply]
  8.   Support Tryptofish (talk) 18:11, 30 November 2015 (UTC)[reply]
  9.   Support. --Stryn (talk) 19:11, 30 November 2015 (UTC)[reply]
  10.   Support - All-or-nothing blocks are too binary. In my experience on other websites, granular blocking is a much better way to police behaviour.Jo-Jo Eumerus (talk) 20:14, 30 November 2015 (UTC)[reply]
  11.   Support Matiia (talk) 20:28, 30 November 2015 (UTC)[reply]
  12.   Support Orlodrim (talk) 20:30, 30 November 2015 (UTC)[reply]
  13.   Support --Grind24 (talk) 20:49, 30 November 2015 (UTC)[reply]
  14.   Support This is currently possible, but only with the abuse filter, and it would be good if we could do this without requiring the abuse filter to run on every edit by everyone. Nyttend (talk) 21:52, 30 November 2015 (UTC)[reply]
  15.   Oppose This will only encourage more socking. I do believe we need more tools in this area, but I'd prefer to see tools which focus on the content rather than the editor, or auto-blocks based on previous content by the editor (using ORES). John Vandenberg (talk) 02:09, 1 December 2015 (UTC)[reply]
  16.   Support. I think this would give much needed flexibility in dealing with problems, and might even decrease the amount of work at an/i and arbcom. DGG (talk) 02:21, 1 December 2015 (UTC)[reply]
  17.   Oppose Per-topic bans already solve this problem and they are more effective.--Isacdaavid (talk) 02:27, 1 December 2015 (UTC)[reply]
  18.   Support--Shizhao (talk) 09:40, 1 December 2015 (UTC)[reply]
  19.   Support--Kimdime (talk) 12:18, 1 December 2015 (UTC)[reply]
  20.   Support--Максим Підліснюк (talk) 14:48, 1 December 2015 (UTC)[reply]
  21.   Support tufor (talk) 15:12, 1 December 2015 (UTC)[reply]
  22.   Support - Whaledad (talk) 15:15, 1 December 2015 (UTC)[reply]
  23.   Support --AS (talk) 15:33, 1 December 2015 (UTC)[reply]
  24.   Support Goombiis (talk) 16:43, 1 December 2015 (UTC)[reply]
  25.   Support If this system will be easy for learning, I'll support it. Maybe there should be an option that allow sysops to block user edit all articles in category and it's subcategories and an option for block user edit in all articles in one namespace or allow only one namespace (for example user can edit talk pages but he cannot edit articles). --Urbanecm (talk) 17:38, 1 December 2015 (UTC)[reply]
  26.   Support--Alexmar983 (talk) 18:30, 1 December 2015 (UTC)[reply]
  27.   Strongly oppose --Usien6 (talk) 20:02, 1 December 2015 (UTC) // The en:Wikipedia:Edit filter already does the job.[reply]
    We want something that does this with a lower performance impact, so that we can use more of them and free up the scarce edit filter resources for something else. MER-C (talk) 20:25, 1 December 2015 (UTC)[reply]
  28.   Support Great idea! --I am One of Many (talk) 20:28, 1 December 2015 (UTC)[reply]
  29.   Support Good idea, but I worry whether socks will make this useless. StevenJ81 (talk) 22:31, 1 December 2015 (UTC)[reply]
  30.   Support for the flexibility this gives to administering Wikimedia projects. I understand the sock issue, but this proposal doesn't seem to be trying to solve that. At the same time, if a user is blocked only from editing particular articles or topic areas, they could just as easily decide to work on other parts of the wiki than socking to return to articles they were blocked from editing. Also, I like that this reduces pressure to implement full blocks and demonstrates we're a kinder site that doesn't levy ultimate punishments for narrow crimes. I can also see this being used for 3RR blocks. Stevie is the man! Talk • Work 23:02, 1 December 2015 (UTC)[reply]
  31.   Support - Yes, please! RonnieV (talk) 11:23, 2 December 2015 (UTC)[reply]
  32.   Support --β16 - (talk) 11:56, 2 December 2015 (UTC)[reply]
  33.   Support Technical enforcement of topic bans would be useful and would lighten the load of those editors who help make sure those bans are enforced.  DiscantX 12:31, 2 December 2015 (UTC)[reply]
  34. Comment This needs to be expanded for all pages and not just articles. Please see Jimbo's response here.
    ⋙–Berean–Hunter—► ((⊕)) 12:49, 2 December 2015 (UTC)[reply]
  35.   Support Casliber (talk) 13:33, 2 December 2015 (UTC)[reply]
  36.   Oppose, Special:AbuseFilter already does this — NickK (talk) 15:18, 2 December 2015 (UTC)[reply]
  37.   Support Fluffernutter (talk) 15:51, 2 December 2015 (UTC)[reply]
  38.   Support, though nervously. If admins/arbitrators could be persuaded to actually tailor their topic bans to a pre-agreed enumerated list of articles, then people who are topic-banned could actually avoid being sucked down the drain by detractors waiting for a gotcha. OTOH I fear this may be prone to be used like a "less than lethal weapon", i.e. on anything that moves because hey, it's not banning everything. Still, it is interesting enough that it should be researched. Note ultimately its viability as a tool depends on the level of self-control that administrators can manage, rather than the people blocked. Wnt (talk) 23:30, 2 December 2015 (UTC)[reply]
  39.   Support although slightly skeptical of when this would be used. JQTriple7 (talk) 23:33, 2 December 2015 (UTC)[reply]
  40.   Support Rzuwig► 09:31, 3 December 2015 (UTC)[reply]
  41.   Support on condition that it would also apply to all "confirmed sockpuppets" as I could see users creating a new account to go around the protect/block. Krett12 (talk) 16:12, 3 December 2015 (UTC)[reply]
  42.   Support Though I think this could be done with an improved edit filter, eg edit filters attached to individual users, or pages so as to seriously cut the performance impact of running for all. Graeme Bartlett (talk) 04:35, 4 December 2015 (UTC)[reply]
  43.   Support SantiLak (talk) 10:44, 4 December 2015 (UTC)[reply]
  44.   Support GY Fan★ 11:28, 4 December 2015 (UTC)[reply]
  45.   Support Graham87 (talk) 11:33, 4 December 2015 (UTC)[reply]
  46.   Support Bináris tell me 18:34, 4 December 2015 (UTC)[reply]
  47.   Support --H4stings (talk) 14:27, 7 December 2015 (UTC)[reply]
  48.   Support --Waldir (talk) 15:13, 8 December 2015 (UTC)[reply]
  49.   Support If properly implemented, this could really cut down on both AN/I drama and the ArbCom's caseload. Daniel Case (talk) 19:23, 8 December 2015 (UTC)[reply]
  50.   Support - Bcharles (talk) 00:37, 9 December 2015 (UTC)[reply]
  51.   Support Lsanabria (talk) 15:23, 10 December 2015 (UTC)[reply]
  52.   Support AlbinoFerret 18:27, 10 December 2015 (UTC)[reply]
  53.   Support as nominator. In all seriousness, I thought this proposal was a perennial one that would be tossed into the bit bucket! Regarding some of the opposes - I appreciate this won't necessary solve socking, but I don't think any tool can solve every problem ever. It is indeed technically possible to use the edit filter to do some user / page level blocking, but IMHO the user interface (or rather the absence of it!) isn't enough to make it safe for general-purpose use. Admins do not need to be programmers. Ritchie333 (talk) 13:35, 11 December 2015 (UTC)[reply]
  54.   Support --Aervanath (talk) 20:23, 12 December 2015 (UTC)[reply]
  55.   Support --Sphilbrick (talk) 15:35, 13 December 2015 (UTC)[reply]
  56.   Support Alkamid (talk) 22:27, 13 December 2015 (UTC)[reply]
  57.   Support --MisterSanderson (talk) 04:36, 14 December 2015 (UTC)[reply]
  58.   Neutral This proposed tool is a blade, metaphorically: it is a two-handed-vorpal-flaming-broadsword when a rouge admin hands out dozens of rapid-fire page-blocks to "calm" things down (cf: backfire), but when used as a scalpel, by surgically precise admins, it is less bitey to page-block for 31 hours than to enWiki-block for 31 hours, because the admin can block edit-warriors solely from the page that was the locus of the disruption, and not from enWiki entirely. Upside: proportionate, and therefore preventative-not-punitive. Upside: edit-war participants can go edit some other page. Downside#1: page-block will halt edit-warriors on THAT page, but if the dispute is hot enough, the edit-warriors will simply migrate the dispute to another page, such as usertalk (discussion is fine but hurling invective is not). Downside#2: unintended consequence, will encourage more socking. (Ritchie333: the worry is not that page-block fails to SOLVE socking, the worry is that page-block will tend to generate MORE socking than the regular enWiki-block does... BECAUSE it is a surgical block, it is hypothesized to be more likely to encourage socking "to get around that biased admin" ... i.e. the blockee will see an page-block as "that admin tried to keep me from putting the truth into enWiki" whereas the blockee will *more often* see enWiki-block as "that admin does not want me to edit-war anywhere.) Downside#3: again with the unintended consequences, blockees will perceive corruption where admins are page-blocking in order to control content (in the eyes of the blockee at least), rather than halting edit-warring. My even-more-extensive comments are hidden here.[1] Some implementation-suggestions, *if* this is decided to be a wise feature to implement, are hidden here.[2] In any case, although I can see value in this proposal, there are a lot of risks here. Please be exceedingly careful, if you do implement this stuff. 75.108.94.227 12:15, 14 December 2015 (UTC)[reply]


Вдосконалення пошуку за діапазоном дат на Спеціальна:Внесок

Tracked in Phabricator:
Task T120733

Не існує хорошого способу проводити пошук за періодом часу у Спеціальна:Внесок. Зараз там можна встановити дату, однак в такий спосіб Ви отримаєте ВСІ попередні редагування аж до цієї дати — а це може бути надто багато редагувань, аби їх хоч якось відфільтрувати. Було б добре вдосконалити пошук за датами, додавши можливість шукати від точки А до точки Б у часі. Як приклад, ми повинні б мати можливість шукати внесок за останні три місяці, і ЛИШЕ за останні три місяці. Кожен редактор чи адмін, що полює на лялькарів, спамерів, оплачуваних редакторів, постійних порушників правил тощо, отримав би чимало користі від такого нововведення, оскільки воно б дозволило зробити їхній пошук більш відповідним меті. Станом на зараз, дуже мало користувачів маніпулюють пошуковими рядками в URL, аби вручну вказати діапазон часу, тим більше, що це незграбна робота. Ви додаєте рядок, що відповідає такому візерунку: « ?ucstart=yyyymmddhhmmss&ucend=yyyymmddhhmmss » Будь ласка, перегляньте цей приклад маніпуляції з URL, а також кінцівку цієї теми, аби побачити, що люди шукають способи виконувати такий пошук. Будь ласка, змініть запити та вигляд цього інтерфейсу так, щоб можна було вибирати початкову та кінцеву дату пошуку, та шукати в межах певного часового вікна.
⋙–Berean–Hunter—► ((⊕)) 23:26, 9 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  Endorsed This would be nice. This, that and the other (talk) 01:06, 10 November 2015 (UTC)[reply]
  Endorsed This would be very useful at RFA and might even focus people's attention on the recent edits of the candidate rather than dragging in ancient stuff that no longer applies. WereSpielChequers (talk) 19:38, 10 November 2015 (UTC)[reply]
  Endorsed. This is an annoyance with core software that can be easily addressed. MER-C (talk) 21:52, 10 November 2015 (UTC)[reply]
  Endorsed Fluffernutter (talk) 17:24, 11 November 2015 (UTC)[reply]
  Endorsed Heck, yeah! In addition, they need to change the search functionality on Special:Contributions so you can at least search BY DAY (if not by hour!) and not "by month" (which is ridiculous!) IJBall (talk) 03:40, 17 November 2015 (UTC)[reply]
I agree that it is good to have this improved granularity in time range control. I should point out that anyone evaluating IP ranges for blocks would likely be interested in searching through only the last three months to understand the potential for collateral damage. These changes would allow for filtering out all of those edits from previous years.
⋙–Berean–Hunter—► ((⊕)) 16:34, 17 November 2015 (UTC)[reply]
Comment These improvements are scalable to all page histories (articles, talk pages, etc.) as they are currently constrained in the same way (example). I hadn't thought of that when I first posted but adding time window searching to those would also be an improvement and anywhere that form of query may be found.
⋙–Berean–Hunter—► ((⊕)) 17:26, 17 November 2015 (UTC)[reply]
  Endorsed And similar improvements to History and Special:Log pages as well if feasible. the wub "?!" 01:02, 25 November 2015 (UTC)[reply]

Голосування

  1.   Support Jenks24 (talk) 10:40, 30 November 2015 (UTC)[reply]
  2.   Support Should take less than a day, too. MER-C (talk) 11:02, 30 November 2015 (UTC)[reply]
  3.   Support NE Ent (talk) 14:05, 30 November 2015 (UTC)[reply]
  4.   Support, but as per my Endorsement comments the search "range" function should also be improved from a "per month" value to a "per day" (at least!) value (i.e. improved "granularity"). IJBall (talk) 14:12, 30 November 2015 (UTC)[reply]
  5.   Support as proposer.
    ⋙–Berean–Hunter—► ((⊕)) 15:37, 30 November 2015 (UTC)[reply]
  6.   Support. --Stryn (talk) 19:11, 30 November 2015 (UTC)[reply]
  7.   Support — Bilorv (talk) 19:57, 30 November 2015 (UTC)[reply]
  8.   Support Orlodrim (talk) 20:30, 30 November 2015 (UTC)[reply]
  9.   Support Dalba 20:44, 30 November 2015 (UTC)[reply]
  10.   Support --Grind24 (talk) 20:49, 30 November 2015 (UTC)[reply]
  11.   Support An easy win. John Vandenberg (talk) 02:14, 1 December 2015 (UTC)[reply]
  12.   Support Mahdy Saffar (talk) 06:52, 1 December 2015 (UTC)[reply]
  13.   Support--Alexmar983 (talk) 09:53, 1 December 2015 (UTC)[reply]
  14.   Support --Steinsplitter (talk) 11:27, 1 December 2015 (UTC)[reply]
  15.   Support. Mathonius (talk) 14:57, 1 December 2015 (UTC)[reply]
  16.   Support · · · Peter (Southwood) (talk): 15:01, 1 December 2015 (UTC)[reply]
  17.   Support Sadads (talk) 15:55, 1 December 2015 (UTC)[reply]
  18.   Support Goombiis (talk) 16:44, 1 December 2015 (UTC)[reply]
  19.   Support Ckoerner (talk) 17:09, 1 December 2015 (UTC)[reply]
  20.   Support--Calak (talk) 18:30, 1 December 2015 (UTC)[reply]
  21.   Support.--Nahum (talk) 19:35, 1 December 2015 (UTC)[reply]
  22.   Support. Jules78120 (talk) 19:54, 1 December 2015 (UTC)[reply]
  23.   Support --Usien6 (talk) 20:05, 1 December 2015 (UTC) // Great value, given it's pretty easy to implement.[reply]
  24.   Support  Trizek from FR 22:12, 1 December 2015 (UTC)[reply]
  25.   Support - Kertraon (talk) 22:31, 1 December 2015 (UTC)[reply]
  26.   Support Stevie is the man! Talk • Work 23:06, 1 December 2015 (UTC)[reply]
  27.   Support Spencer (talk) 01:09, 2 December 2015 (UTC)[reply]
  28.   Support Risker (talk) 04:21, 2 December 2015 (UTC)[reply]
  29.   Support Graham87 (talk) 10:29, 2 December 2015 (UTC)[reply]
  30.   Support Quick and useful fix.  DiscantX 12:28, 2 December 2015 (UTC)[reply]
  31.   Support, quick, easy and useful fix — NickK (talk) 15:19, 2 December 2015 (UTC)[reply]
  32.   Support Fluffernutter (talk) 15:52, 2 December 2015 (UTC)[reply]
  33.   Support Mule hollandaise (talk) 18:41, 2 December 2015 (UTC)[reply]
  34.   Support Wnt (talk) 23:43, 2 December 2015 (UTC)[reply]
  35.   Support --AS (talk) 09:53, 3 December 2015 (UTC)[reply]
  36.   Support — Arkanosis ✉ 14:07, 3 December 2015 (UTC)[reply]
  37.   Support as long as you could put "earliest" or "current" into the boxes. Krett12 (talk) 16:13, 3 December 2015 (UTC)[reply]
  38.   Support SantiLak (talk) 10:44, 4 December 2015 (UTC)[reply]
  39.   Support GY Fan★ 11:29, 4 December 2015 (UTC)[reply]
  40. Very strong   Support Bináris tell me 18:36, 4 December 2015 (UTC)[reply]
  41.   Support Avgr8 (talk) 21:02, 4 December 2015 (UTC)[reply]
  42.   Support --Emptywords (talk) 01:45, 5 December 2015 (UTC)[reply]
  43.   Support — Rhododendrites talk \\ 00:41, 7 December 2015 (UTC)[reply]
  44.   Support — seems easy enough to implement. Wbm1058 (talk) 18:58, 7 December 2015 (UTC)[reply]
  45.   Support --Waldir (talk) 15:14, 8 December 2015 (UTC)[reply]
  46.   Support Wugapodes (talk) 18:36, 11 December 2015 (UTC)[reply]
  47.   Support Ekkt0r (talk) 06:38, 13 December 2015 (UTC)[reply]
  48.   Strong support as an easy-to-implement project, which already is supported in the core codebase, and just needs a few GUI-bits added to let folks take advantage of it. Prefer a datepicker, but anything is an improvement over hand-modifying the querystring. If you want a more difficult task, implement an improved contrib-search feature, broadly construed. 75.108.94.227 21:12, 13 December 2015 (UTC)[reply]
  49.   Support --MisterSanderson (talk) 04:37, 14 December 2015 (UTC)[reply]


Вдосконалення інструментів блокування в MediaWiki

Наші інструменти блокування — просто шлак. Обійти блокування — тривіальна справа, і кожен вартісний вандал може зробити це з заплющеними очима. (Користувач:Philippe). Кожен, хто мав справу з розслідуванням випадків лялькового театру чи був жертвою повторюваних утисків та переслідування у вікі, зможе підтвердити це. Обхід блокування не завжди буває цілеспрямованим — у деяких частинах світу користувачі можуть виконувати кожне редагування з нової IP-адреси, яку їм щоразу заново надає їхній інтернет-провайдер. Ми, фактично, не маємо засобів для того, аби зупинити таких користувачів.

Ціль тут тригранна — зробити обхід блокування складнішим завданням, полегшити для нас процес якомога швидшої ідентифікації та роботи з потенційними сокпапетами — в ідеалі, ще до того, як вони почнуть редагувати — і при цьому зберегти супутню шкоду на мінімальному рівні. Ця пропозиція має декілька аспектів:

  • Перегляньте інші форуми/блоги/вікі (напр., Wordpress, vBulletin) та їхнє програмне забезпечення, і визначте які інструменти блокування можуть бути інтегровані в MediaWiki (не як розширення) з урахуванням наших обмежень, окреслених політикою конфіденційності. Впровадьте ці інструменти.
  • Здійсніть такі завдання на Фабрикаторі:
  • Додано 27 листопада: дослідити використання подібних до Evercookie та інших доступних методів стеження для того, аби ускладнити вилучення куків, при цьому не порушуючи меж нашої політики конфіденційності.
  • Блокування за ID пристрою (спершу треба, щоб юридична команда перевірила сумісність із політиками ФВМ )
  • Додано 27 листопада: якщо обліковий запис із зареєстрованою електронною адресою заблокований, а також заблокована можливість створення нових облікових записів, заборонити також створення будь-яких нових облікових записів із тією електронною адресою. (Необов'язково, оскільки ми не вимагаємо вказувати електронну адресу при реєстрації.)
  • Будь-які інші пропозиції від спільноти, здатні допомогти вирішити цю проблему.

Вдосконалені інструменти блокування можуть спочатку надаватися лише групі чек'юзерів, аби можна було зробити висновок про те, як багато супутньої шкоди вони можуть приносити. В ідеалі вони допоможуть полегшити ношу підчищання за спамерами, вандалами та іншими особами, що часто порушують правила, це б допомогло зменшити кількість випадків цькувань такого типу, як у дифі вище, і принесло б користь для усіх редакторів з благими намірами в будь-якій інсталяції MediaWiki. MER-C (talk) 12:06, 8 November 2015 (UTC)[reply]

Earlier discussion and endorsements

Голосування

  1.   Support 4nn1l2 (talk) 03:14, 30 November 2015 (UTC)[reply]
  2.   Support as proposer. MER-C (talk) 09:45, 30 November 2015 (UTC)[reply]
  3.   Support Samwalton9 (talk) 10:31, 30 November 2015 (UTC)[reply]
  4.   Support Jenks24 (talk) 10:38, 30 November 2015 (UTC)[reply]
  5.   Support Lugnuts (talk) 12:07, 30 November 2015 (UTC)[reply]
  6.   Support
    ⋙–Berean–Hunter—► ((⊕)) 15:28, 30 November 2015 (UTC)[reply]
  7.   Support Yes please- right now, the only solution for IP-hopping vandals is literally to wait until they get bored. PresN (talk) 18:32, 30 November 2015 (UTC)[reply]
  8.   Support. --Stryn (talk) 19:11, 30 November 2015 (UTC)[reply]
  9.   Support Matiia (talk) 20:22, 30 November 2015 (UTC)[reply]
  10.   Support Dalba 20:46, 30 November 2015 (UTC)[reply]
  11.   Support --Grind24 (talk) 20:50, 30 November 2015 (UTC)[reply]
  12.   Support Mike V • Talk 02:43, 1 December 2015 (UTC)[reply]
  13.   Support Doc James (talk · contribs · email) 09:32, 1 December 2015 (UTC)[reply]
  14.   Support --Steinsplitter (talk) 11:27, 1 December 2015 (UTC)[reply]
  15.   Support Goombiis (talk) 16:44, 1 December 2015 (UTC)[reply]
  16.   Support wow--Temp3600 (talk) 16:45, 1 December 2015 (UTC)[reply]
  17.   Support --Snaevar (talk) 16:48, 1 December 2015 (UTC)[reply]
  18.   Support One big way to help folks feel more welcome is to improve the tools to keep the jerks out. Ckoerner (talk) 17:09, 1 December 2015 (UTC)[reply]
  19.   Support--Calak (talk) 18:33, 1 December 2015 (UTC)[reply]
  20.   Support --Usien6 (talk) 20:07, 1 December 2015 (UTC) //   Neutral on the other proposals.[reply]
  21.   Support StevenJ81 (talk) 22:35, 1 December 2015 (UTC)[reply]
  22.   Support generally - whatever can be proven to work and not cause new issues. Stevie is the man! Talk • Work 23:12, 1 December 2015 (UTC)[reply]
  23.   Support In veritas (talk) 04:30, 2 December 2015 (UTC)[reply]
  24.   Support ... I especially like checking the machine code and setting a cookie. Binksternet (talk) 06:14, 2 December 2015 (UTC)[reply]
  25.   Support Graham87 (talk) 10:33, 2 December 2015 (UTC)[reply]
  26.   Support--Syum90 (talk) 12:49, 2 December 2015 (UTC)[reply]
  27.   Support any reasonable solution. It is very easy to delete a blocking cookie, however, but we should think of possible improvements — NickK (talk) 15:21, 2 December 2015 (UTC)[reply]
  28.   Support Matěj Suchánek (talk) 15:52, 2 December 2015 (UTC)[reply]
  29.   Support If I had to pick only one improvement to vote for, it would be this. While mediawiki's software has gotten slicker and more accessible, the tools that underlay much of the work people do with it have lagged behind. Fluffernutter (talk) 15:55, 2 December 2015 (UTC)[reply]
  30.   Support -- Dave Braunschweig (talk) 22:12, 2 December 2015 (UTC)[reply]
  31.   Oppose Blocking the worst problem users is a pipedream. Helping out the NSA and its ilk by doing mass surveillance of regular users and occasional visitors by storing troves of user-agent data or sending people out on the web bleeding fancy hacked Evercookie type data polluting their browser ... that's the reality. Just don't. Wikipedia would be better off if it never blocked anyone, and relied solely on positive certification of good users, but at least don't dig the hole any deeper. Wnt (talk) 23:35, 2 December 2015 (UTC)[reply]
  32.   Oppose if you don't like playing whack a mole, stop. problem is not lack of tools, but lack of leadership. Slowking4 (talk) 02:46, 3 December 2015 (UTC)[reply]
  33.   Support I think you should put all of these in, but beware even though evercookies are in theory harder to remove, in practice they are quite easily circumvented. Krett12 (talk) 16:16, 3 December 2015 (UTC)[reply]
  34.   Support GY Fan★ 11:32, 4 December 2015 (UTC)[reply]
  35.   Support It won't stop everyone, but every reduction in abuse is obvious win. Alsee (talk) 16:24, 5 December 2015 (UTC)[reply]
  36.   Support Courcelles 08:34, 8 December 2015 (UTC)[reply]
  37.   Support I wouldn't go so far as to say our blocking tools suck—IME there are far more of the users easily deterred by the extra effort involved to circumvent them than the proposer, or Phillippe in his linked edit, seem to realize—but I won't argue that they could be better. Daniel Case (talk) 19:30, 8 December 2015 (UTC)[reply]
  38.   Oppose - I don't see how clearing a cookie is more difficult than changing an IP. There are bigger concerns with a persistent cookie strategy, as mentioned by User:Wnt at point 31 above. Bcharles (talk) 00:48, 9 December 2015 (UTC)[reply]


Список дописувачів

Проблема: CC-BY-SA та GFDL вимагають додавати список дописувачів при кожному копіюванні матеріалу з одного проекту до іншого або куди-небудь за межі вікі (із WP до WB, із en-WB до de-WB, але також і з цього форуму до de-WB чи з de-WB до будь-якого зовнішнього файлу PDF). В усіх цих випадках необхідно додавати такий список. В минулому існував інструмент, створений користувачем Duesentrieb на тулсервері, який не працює з липня 2014 року. Потім був інструмент на Xtools, який не працює з червня 2015 року — див. GitHub опис проблеми. Тож зараз немає способу отримати єдиний список для усіх сторінок (включно з підсторінками) однієї книги на Вікіпідручнику.

Користувачі: Всі користувачі, які копіюють контент, в основному — адміни.

Станом на зараз, спершу доводиться експортувати сторінку як pdf чи книгу через Інструменти, а потім копіювати створений список в експортований твір.

Пропоноване рішення: Такий список може створюватись шляхом аналізу історії сторінки. Має також бути можливість включити цю функцію в програмне забезпечення MediaWiki та зробити її доступною через ІнструментиДрук/Експорт. Функція має пропонувати деякі опції: користувачі з обліковим записом — так/ні, IP-адреси — так/ні, включення сторінок за префіксом — так/ні. (Останній запит стосується чогось на кшталт b:de:Mathe für Nicht-Freaks, де підсторінки позначені двокрапками замість похилої риски.)
-- Juetho (talk) 14:48, 20 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  Comment (German) Die Liste wird auch benötigt, wenn zwei Seiten (z.B. WP-Artikel) zusammengefasst werden: Nachdem Inhalt per Cut&Paste übertragen wurde, kann die überflüssige Seite gelöscht werden. Dadurch verschwindet die Versionsgeschichte; stattdessen müssen die bisherigen Autoren genannt werden. -- Axum (talk)
(try to translate in English) This list is necessary in cases where two sites (WP articles, e.g.) are merged: After content is transferred via Cut&Paste, the obsolete site maybe deleted. The history vanishes; one has to store the list of contributors instead of. -- Axum (talk)

Голосування

  1.   Support.--Nahum (talk) 19:40, 1 December 2015 (UTC)[reply]
  2.   Support  Trizek from FR 22:12, 1 December 2015 (UTC)[reply]
  3.   Support Seems reasonable. Stevie is the man! Talk • Work 23:15, 1 December 2015 (UTC)[reply]
  4.   Support Necessary per our licenses, and useful to spread the idea of F/LOSS. The opposite would also be great (User X has contributed 57% of article A, 21% of article B, and so on). --Pgallert (talk) 18:27, 2 December 2015 (UTC)[reply]
  5.   Support SantiLak (talk) 10:44, 4 December 2015 (UTC)[reply]
  6.   Support Halibutt (talk) 22:50, 4 December 2015 (UTC)[reply]
  7.   Support Juetho (talk) 11:58, 8 December 2015 (UTC)[reply]
  8.   Support --Waldir (talk) 15:18, 8 December 2015 (UTC)[reply]
  9.   Support Why have we waited so long even to suggest this? Daniel Case (talk) 19:30, 8 December 2015 (UTC)[reply]
  10.   Support Wugapodes (talk) 18:45, 11 December 2015 (UTC)[reply]
  11.   Support Yes, this does seem like something that should have been put in place a long time ago. Mz7 (talk) 04:39, 12 December 2015 (UTC)[reply]
  12.   Support Nicely done will be non-trivial (comparing to some other proposals) and can save much time, lead to better compliance with license terms. aegis maelstrom δ 11:04, 14 December 2015 (UTC)[reply]

Машинне навчання для ідентифікації сокпапетів

Tracked in Phabricator:
Task T107600

Впровадьте використання машинного навчання та дослідження тексту для виявлення потенційних лялькових облікових записів. Див. Ознаки «лялькового театру», отримані з автоматизованого аналізу стилю письма. MER-C (talk) 22:31, 18 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  Endorsed We can use every tool that we can get for hunting socks.
⋙–Berean–Hunter—► ((⊕)) 14:38, 20 November 2015 (UTC)[reply]

Голосування

  1. This is something WMF Legal would benefit from as well IMHO. -- とある白い猫 chi? 19:53, 30 November 2015 (UTC)[reply]
  2.   Support Per personal experience on other sites; also, if one can make an antivandal bot (like enwiki's en:User:ClueBot NG) making a sockpuppet catcher bot should be possible to.Jo-Jo Eumerus (talk) 20:16, 30 November 2015 (UTC)[reply]
  3.   Support --Isacdaavid (talk) 02:28, 1 December 2015 (UTC)[reply]
  4.   Support Stevie is the man! Talk • Work 23:17, 1 December 2015 (UTC)[reply]
  5.   Support Binksternet (talk) 06:15, 2 December 2015 (UTC)[reply]
  6.   Neutral for now due to the effort required for implementation -- there are easier ways to cut block evasion and sockpuppetry as detailed above. This will be, eventually, become a part of a defence in depth approach to combat sockpuppetry and is still worth doing... once all the obvious problems with core MediaWiki software are sorted. Might be a good research project. MER-C (talk) 15:33, 2 December 2015 (UTC)[reply]
  7.   Neutral better to use machine learning for good edit versus vandalism. Slowking4 (talk) 02:50, 3 December 2015 (UTC)[reply]
  8.   Oppose Just because two editors write the same doesn't make them the same person. Krett12 (talk) 16:18, 3 December 2015 (UTC)[reply]
    • Funny ... that's the first line you read from any sockpuppet account when you raise the subject. Daniel Case (talk) 19:32, 8 December 2015 (UTC)[reply]
    • Statistically speaking AI in this area is used even by Law Enforcement to prosecute criminal cases, most noteworthy is the en:Enron Corpus which was a product of the investigation of the en:Enron Scandal where en:Text mining was used. In a nutshell AI was able to identify authors of fake email accounts to the real people accounts to identify who was engaged in the illegal activities. Naturally, processing emails and on wiki edits are different tasks but that is more of a matter of feature selection and fine tuning. Such a tool would probably be better than humans in identifying patterns and such (humans cannot review every revision, machines can for example). Such a tool would also identify lobbyist groups and other such coordinated efforts of POV pushing (meatpuppets) which are also a problem. -- とある白い猫 chi? 03:54, 29 December 2015 (UTC)[reply]
  9.   Support Wouldn't be perfect, but would identify something for us to take a closer look at. Daniel Case (talk) 19:32, 8 December 2015 (UTC)[reply]
  10.   Support Any help in identifying possible socks is a good thing. AlbinoFerret 18:29, 10 December 2015 (UTC)[reply]

Перевірка дозволів OTRS

Tracked in Phabricator:
Task T88620

Для звичайного користувача неможливо дізнатися, чи дозвіл OTRS є дійсним, чи ні. Наприклад,цей шаблон пропонує зв'язатися з волонтерами OTRS. Це дуже крихка система. Я пропоную відкрити спеціальну сторінку (чи будь-що подібне), де можна було б вказати номер OTRS, а у відповідь отримати логічне значення. Система також має легко піддаватися програмному розпізнаванню для того, аби можна було отримувати автоматичні відповіді про правильність/хибність/наявність вандалізму у введеному номері. --AlessioMela (talk) 10:12, 10 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  Endorsed it could be very useful when there is no OTRS volunteers available. Restu20 10:16, 10 November 2015 (UTC)[reply]
  Endorsed even if OTRS volunteers are available it is infeasible to check a large number of tickets. --Incola (talk) 10:32, 10 November 2015 (UTC)[reply]

Голосування

  1.   Support Definitely. Nyttend (talk) 21:55, 30 November 2015 (UTC)[reply]
  2.   Support We need information to be shared as much as possible, when possible.--Alexmar983 (talk) 09:48, 1 December 2015 (UTC)[reply]
      Support Seems reasonable. Stevie is the man! Talk • Work 23:21, 1 December 2015 (UTC)[reply]
    Removed support per Earwig's reply below. This proposal is unnecessary. We should be able to trust OTRS members. Stevie is the man! Talk • Work 18:59, 4 December 2015 (UTC)[reply]
  3.   Support but see "Earlier discussion and endorsements"--Jarekt (talk) 03:48, 2 December 2015 (UTC)[reply]
  4.   Support When I sometimes delete a talk page on which an OTRS ticket is present (because of the deletion of the article itself), the only way I can notify people who would like to restore the article in the future is to explicitely specify the OTRS ticket number in the deletion log. This is not very satisfactory. Litlok (talk) 08:32, 2 December 2015 (UTC)[reply]
  5.   Support, I already witnessed people adding OTRS permission tickets without getting the permission — NickK (talk) 15:22, 2 December 2015 (UTC)[reply]
  6.   Support--Manlleus (talk) 15:29, 2 December 2015 (UTC)[reply]
  7.   Oppose so as far as I can see, you want the information sent in the ticket to be made visible? Unfortunately, not going to happen any time soon, it's against the access to non-public data policy. If the ticket has been added by an OTRS volunteer, then it's as good as valid in any case. Mdann52 (talk) 18:01, 2 December 2015 (UTC)[reply]
    Is there a direct way to confirm that the editor adding the ticket is an OTRS volunteer? :) Stevie is the man! Talk • Work 18:38, 2 December 2015 (UTC)[reply]
    @Stevietheman: OTRS/Users is usually a good place to start (every OTRS agent has access to a list of former accounts as well, so if it isn't listed there, feel free to ask :) ) Mdann52 (talk) 14:36, 5 December 2015 (UTC)[reply]
    @Mdann52: no, I don't want to make any information visible. I just want a system that tell me a certain ticket is valid. Without showing anything else. --AlessioMela (talk) 19:56, 2 December 2015 (UTC)[reply]
    There is already an edit filter (on enwiki) (642) which verifies that the person adding an OTRS permission template is an OTRS member. — Earwig talk 02:12, 4 December 2015 (UTC)[reply]
    @The Earwig: Do you think this filter is easy to use to check after, for example, one year if a ticket is valid? How about if the OTRS member made a mistake copying the ticket number? Isn't better to have a stronger system directly connected with the OTRS database? --AlessioMela (talk) 21:41, 4 December 2015 (UTC)[reply]
    I'm not really sure, hence my lack of a vote on this one yet. It would be frustrating to go through the filter logs to see whether an edit from a year ago was tagged, but the idea is that it lets us deal with nefarious additions as they happen. As for mistakes copying the ticket number, I've never heard of this being a problem; is it?
    There's a more central issue with this. In order for a verifier to be useful, it needs to do more than just check if the ticket exists, because anyone can copy an OTRS template from another page and pretend it applies. There needs to be a check that the permission (a) applies to the resource in question, and (b) is a properly handled ticket. I don't think a non-human tool can do this, based on how OTRS works internally (I'm an OTRS member, but not of permission queues, so I am not 100% informed of procedures). We can require all OTRS members to log permissions in a secure area, but is this really necessary? It seems like that would take more work than just asking an OTRS member if you suspect something is wrong. — Earwig talk 22:13, 4 December 2015 (UTC)[reply]
    So as someone who has done work on permissions, it's a mess to be frank. There are so many different outcomes that there is little or no way to connect this directly with the database (the only useful flags on there are the ticket "closed as", which are all set to the same sort of thing anyway). This seems like a neat idea - however, there are no better ways of implementing this compared to what we have now in practice. Mdann52 (talk) 14:36, 5 December 2015 (UTC)[reply]
  8.   Support Kvardek du (talk) 10:35, 5 December 2015 (UTC)[reply]
  9.   Support --Waldir (talk) 15:21, 8 December 2015 (UTC)[reply]
  10.   Support --Edgars2007 (talk) 09:07, 12 December 2015 (UTC)[reply]

Інструмент для пошуку автора параграфа

Research:Wikiwho Provenance Api.

Іноді вандали додають шматок беззмістовної інформації в саму середину великої статті, яка після цього роками залишається прихованою в цій статті. Такі ситуації трапляються особливо часто в португальській Вікіпедії, яка не має достатньої кількості волонтерів для миттєвого реагування на вандалізм. Було б чудово, якби існував інструмент для визначення авторства певного параметра, як у GitHub. Я маю на увазі інструмент, який, якщо задати йому певний параметр (чи набір параграфів), у відповідь видасть останню версію сторінки (або, можливо, всі сторінки), в яких цей параграф з'являвся у відмінностях між версіями. Іноді це може не працювати через об'єднання та переміщення текстів, але, ймовірно, працюватиме у 99%. --Usien6 (talk) 03:06, 11 November 2015 (UTC)[reply]

Earlier discussion and endorsements

Голосування

  1.   Support; this tool should also be useable for old revisions (i.e a user adds gibberish in one place in a paragraph; an other user then edits an other part of the paragraph. Find the first user form the latest revision before the second user's edit). עוד מישהו Od Mishehu 16:19, 30 November 2015 (UTC)[reply]
  2.   Support Orlodrim (talk) 20:30, 30 November 2015 (UTC)[reply]
  3.   Support --Isacdaavid (talk) 02:31, 1 December 2015 (UTC)[reply]
  4.   Neutral http://wikipedia.ramselehof.de/wikiblame.php --Purodha Blissenbach (talk) 14:53, 1 December 2015 (UTC)[reply]
  5.   Support --Usien6 (talk) 20:11, 1 December 2015 (UTC)[reply]
  6.   Support I probably wouldn't have to use this much, but when I need it, it will be very handy. Stevie is the man! Talk • Work 23:24, 1 December 2015 (UTC)[reply]
  7.   Support Rdrozd (talk) 00:33, 2 December 2015 (UTC)[reply]
  8.   Support – Ham II (sgwrs / talk) 20:58, 2 December 2015 (UTC)[reply]
  9.   Support - I know there are already things along this line, but until they are really obvious and right in the face of every user who potentially can look up how something odd got in an article, they won't really get used. And it's far too common for people to fix one sentence by a vandal and leave another somewhere else, or to merely soften it in a way that camouflages that it is a bogus claim because they don't realize it was just abuse. Wnt (talk) 23:38, 2 December 2015 (UTC)[reply]
  10.   Support YBG (talk) 06:29, 3 December 2015 (UTC)[reply]
  11.   Support --V111P (talk) 10:21, 3 December 2015 (UTC)[reply]
  12.   Support SantiLak (talk) 10:44, 4 December 2015 (UTC)[reply]
  13.   Support I can't count the times I would have liked to have had this. Daniel Case (talk) 19:33, 8 December 2015 (UTC)[reply]
  14.   Support - Good idea if it can be implemented the way Wnt outlined above. - Pointillist (talk) 14:03, 9 December 2015 (UTC)[reply]
  15.   Support - I'm not sure it's exactly what's proposed here, but the ability to enter some text and find when that text appeared in the page would be much more efficient than the current method of looking at each diff or version of page. DexDor (talk) 20:44, 9 December 2015 (UTC)[reply]
  16.   Support Could be helpful in tracking odd claims; a simplified version of a more complicated (but probably needed) tool showing who wrote what, eg with background colours. aegis maelstrom δ 11:08, 14 December 2015 (UTC)[reply]
  17.   Comment This is something ORES provides. It only provides a score for the entire revision though. -- とある白い猫 chi? 04:06, 29 December 2015 (UTC)[reply]

Інструменти для запитів на коментар

Tracked in Phabricator:
Task T31923

Ймовірно, існує кращий спосіб вислухати ідеї спільноти щодо таких речей, як оцей документ чи різні запити на коментар. Вони мають тенденцію приносити дуже типові для спільноти Мета-вікі результати, і стають іноді трохи занадто складними для менш технічно підкованих людей (що іноді призводить до поразки мети). Можливо, існують інструменти, здатні підвищити рівень міжмовної та міжпроектної участі. Можна було б впровадити також деякі уроки, створені проектом IdeaLab.

Earlier discussion and endorsements
  Endorsed This is really an area, where I agree we could truly use 'community' tech. Delection discussion/Voting/RFC'ing is a core element of our community workflows, that is sorely unsupported by tools. —TheDJ (talk • contribs) 18:17, 19 May 2015 (UTC)[reply]

Голосування

  1.   Comment Does anyone have any examples of RFCs where such tools could have had a positive impact? I'm trying to better visualize this proposal. Stevie is the man! Talk • Work 23:30, 1 December 2015 (UTC)[reply]

Спільні змінні для Фільтра зловживань

Наприклад, для зберігання регулярних виразів із поганими словами, при чому такі змінні могли б використовуватися в багатьох фільтрах --AS (talk) 22:20, 15 June 2015 (UTC)[reply]

Earlier discussion and endorsements
phab:T57472?--Qgil-WMF (talk) 10:53, 16 June 2015 (UTC)[reply]
I'm not sure what global filters are, but I think I mean different thing: be able to declare a variable, which would be available in each filter. --AS (talk) 10:13, 18 June 2015 (UTC)[reply]
See also:
Helder 13:52, 9 July 2015 (UTC)[reply]
  Endorsed MER-C (talk) 10:18, 16 November 2015 (UTC)[reply]

Голосування

  1.   Support John Vandenberg (talk) 02:01, 1 December 2015 (UTC)[reply]
  2.   Support --Alexmar983 (talk) 09:52, 1 December 2015 (UTC)[reply]
  3.   Support --Usien6 (talk) 20:16, 1 December 2015 (UTC) // The code of most filters miserably lacks separation between data and logics, killing maintainability.[reply]
  4.   Support Helder 23:41, 1 December 2015 (UTC)[reply]
  5.   Support --AS (talk) 13:19, 2 December 2015 (UTC)[reply]
  6.   Support --Edgars2007 (talk) 09:08, 12 December 2015 (UTC)[reply]
  7.   Oppose I would strongly recommend against this. You will find that such a generic list brings collateral damage. I would instead suggest using machine learning tools that will weight bad words and other content based on the existing content/wiki. ORES can provide this. -- とある白い猫 chi? 04:03, 29 December 2015 (UTC)[reply]

Special:NewPagesFeed всіма мовами

Tracked in Phabricator:
Task T50552

Привіт. Я б хотів, щоб сторінка Спеціальна:Стрічка нових сторінок в англійській Вікіпедії була увімкнена і в усіх інших мовних версіях Вікіпедії (особливо в моїй мовній версії — у французькій Вікіпедії). Це дуже корисна сторінка для кожного дописувача та для перевірки нових статей. Дякую! --Consulnico (talk) 14:25, 10 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  Endorsed בנימין (talk) 15:04, 10 November 2015 (UTC)[reply]
To enable page curation, this should be fixed. --Edgars2007 (talk) 16:20, 10 November 2015 (UTC)[reply]
  Endorsed --Superjuju10 [Aubline available to you], 22:24, 10 November 2015 (UTC)[reply]
  Endorsed Thibaut120094 (talk) 23:29, 10 November 2015 (UTC)[reply]
  Endorsed--Shizhao (talk) 02:29, 11 November 2015 (UTC)[reply]
  Endorsed Amir (talk) 10:12, 11 November 2015 (UTC)[reply]

Голосування

  1.   Support This is a very important workflow tool built but not yet finished as it only works on English Wikipedia. I would very much like to see the Community Tech team work with one or two wikis to set it up adequately for those communities needs, which will iron out some bugs, and help other wikis follow in their footsteps. John Vandenberg (talk) 02:13, 1 December 2015 (UTC)[reply]
  2.   Support--Shizhao (talk) 09:41, 1 December 2015 (UTC)[reply]
  3.   Support Sadads (talk) 15:54, 1 December 2015 (UTC)[reply]
  4.   Support --Temp3600 (talk) 16:44, 1 December 2015 (UTC)[reply]
  5.   Support Papuass (talk) 17:20, 1 December 2015 (UTC)[reply]
  6.   Support Stevie is the man! Talk • Work 23:35, 1 December 2015 (UTC)[reply]
  7.   Support Spencer (talk) 01:10, 2 December 2015 (UTC)[reply]
  8.   Support per John Vandenberg and other commenters. That several of the supporters of this edit primarily in languages other than English should add some bonus points to this. Risker (talk) 04:25, 2 December 2015 (UTC)[reply]
  9.   Support--Barcelona (talk) 12:02, 2 December 2015 (UTC)[reply]
  10.   Support Very useful over at en.wp, I'm sure the other wikis could benefit as well.  DiscantX 12:27, 2 December 2015 (UTC)[reply]
  11.   Support--Manlleus (talk) 15:29, 2 December 2015 (UTC)[reply]
  12.   Support Mule hollandaise (talk) 19:00, 2 December 2015 (UTC)[reply]
  13.   Support – Ham II (sgwrs / talk) 21:02, 2 December 2015 (UTC)[reply]
  14.   Support SantiLak (talk) 10:44, 4 December 2015 (UTC)[reply]
  15.   Support Avgr8 (talk) 21:04, 4 December 2015 (UTC)[reply]
  16.   Support, we could really use something like this on pl.wiki (and we can help ironing out the bugs) Halibutt (talk) 22:53, 4 December 2015 (UTC)[reply]
  17.   Support --Yeza (talk) 16:49, 5 December 2015 (UTC)[reply]
  18.   Support - Bcharles (talk) 01:08, 9 December 2015 (UTC)[reply]
  19.   Support Matěj Suchánek (talk) 21:05, 9 December 2015 (UTC)[reply]
  20.   Support --Edgars2007 (talk) 09:08, 12 December 2015 (UTC)[reply]
  21.   Support - Superb tool at en. SBaker43 (talk) 03:55, 14 December 2015 (UTC)[reply]

Пропозиції фільтрів зловживань через програмне навчання

Останнім часом нам доводиться вручну вписувати код (збіги рядків, регулярні вирази тощо) до Розширення:Фільтр зловживань. Це дуже важка робота для нетехнічних користувачів (простого адміна якоїсь вікі) і поглинає чимало часу користувачів із відповідними технічними навичками.

Я пропоную автоматичні програмні пропозиції готового коду для Фільтрів зловживань, аби зменшити такі труднощі та затрати. Наприклад, коли я ставлю позначки на певні редагування чи користувачів, я міг би отримувати пропоновані візерунки коду, згенеровані шляхом програмного навчання, які б створювалися на основі спільних рис, що простежуються у вказаних редагуваннях чи у внеску користувача.

У мене немає якихось конкретних пропозицій щодо методів чи впровадження, оскільки я не спеціалізуюся ані в програмному навчанні, ані в природній обробці мов. Однак я чув, що це не неможливо.--aokomoriuta (talk) 23:56, 9 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  Endorsed See also Research:Revision scoring as a service and Objective Revision Evaluation Service. Helder 11:30, 10 November 2015 (UTC)[reply]
  Endorsed -- とある白い猫 chi? 11:42, 14 November 2015 (UTC)[reply]
I hesitate to endorse this. It's interesting to do and I support it, but I'm not sure its feasible. MER-C (talk) 22:06, 18 November 2015 (UTC)[reply]

Голосування

  1.   Neutral --Usien6 (talk) 20:22, 1 December 2015 (UTC) // The idea is indeed genial but, until someone comes up with the working thing, it's just sci-fi...[reply]
    It's somehwat related to Research:Revision scoring as a service. /Johan (WMF) (talk) 09:34, 8 December 2015 (UTC)[reply]
    I would argue that Revision scoring may make AbuseFilters obsolete as we would no longer need to rely on simple word matches & regexes to identify problematic behavior. I would argue that current AbuseFilter implementation acts like a sledge hammer. While we wield it with great care, collateral damage is inevitable - more so on some smaller wikis where good content is often blocked due to the poor management of local AbuseFilters as the person setting it up simply may not be editing anymore. Main problem with AbuseFilters is that it is non-trivial to setup and maintain even for seasoned regex users as a simple syntax error can block a wide margin of edits which may remain unnoticed for quite some time. -- とある白い猫 chi? 04:00, 29 December 2015 (UTC)[reply]

Черги робіт

Використовуючи величезну колекцію en:WP:TC (шаблонів впорядкування), які ми маємо у статтях, я б хотів, щоб кожен вікіпроект мав відповідну сторінку, на якій би відображалася інформація про завдання (та їхню кількість), які можуть бути виконані для покращення статей в межах окремого вікіпроекту. (Я б також хотів, щоб була окрема сторінка для всього мовного розділу Вікіпедії.) Я описав варіант цієї ідеї на сторінці Grants:IEG/Automated inventory pages for all WikiProjects. Джерелом мого натхнення була сторінка http://www.wikihow.com/Special:CommunityDashboard Дякую. Biosthmors (talk) 19:56, 19 May 2015 (UTC)[reply]

Earlier discussion and endorsements

We need work queues. A system, that shows articles that are in a certain group, for a certain reason and that need to be '(pre)processed' in a certain way. The person who can crack the task of solving this in a generic enough and expandable enough way, usable for multiple wiki types, in a way that editors can build new queues themselves, will be my ULTIMATE hero. Inspiration: WikiGrok + NewPagePatrol + WikiHow dashboards, Wikipedia:Huggle and Wikipedia:STiki, etc. I consider this the key to our long term survival. —TheDJ (talk • contribs) 18:29, 19 May 2015 (UTC)[reply]

  Endorsed And I saw this comment after I posted mine below about "Inventory pages". Agreed. Biosthmors (talk) 19:57, 19 May 2015 (UTC)[reply]
  Endorsed +1 --AS (talk) 16:45, 27 May 2015 (UTC)[reply]
The Parsoid team would like something like this as well for wiki linting (finding and correcting wikitext errors or deprecated usage). Cscott (talk) 18:23, 11 November 2015 (UTC)[reply]

Голосування

  1.   Support Though this sounds like the work already in place by Bambots for English: https://tools.wmflabs.org/bambots/cwb/ . Its probably scalable to other language editions, Sadads (talk) 15:57, 1 December 2015 (UTC)[reply]
  2.   Support per Sadads. These cleanup listings are wonderful. Stevie is the man! Talk • Work 23:40, 1 December 2015 (UTC)[reply]
  3.   Oppose - The extensive disfiguration of articles in the English Wikipedia is something that should be strongly prevented. Please do not try to enforce this frustrating way of working, for both users and readers, upon other wiki's. RonnieV (talk) 13:20, 2 December 2015 (UTC)[reply]
  4.   Support per Sadads - SantiLak (talk) 10:44, 4 December 2015 (UTC)[reply]
  5.   Support - Would need to focus on a dozen or so tasks at any given time that could use new recruits to help out. Could have customizable set of "widgets" that user has interacted with. Bcharles (talk) 01:49, 9 December 2015 (UTC)[reply]

Notes

  1. ↑ Although technically illegal, 31 hour blocks for edit-warring *do* in fact act as cooldown blocks. Page-blocks are not gonna cool things down, if the dispute is personalized, or if the dispute is about a broader real-world topic that spans multiple articles/areas/pages, whereas (because they are so disproportionately broad) the normal enWiki-blocks do tend to double as cool-down, in addition to halting the disruption.   Going back to the blade-metaphor, we've talked about page-block being used against couple-few edit-warriors on a single page, which is using page-block as a scalpel. But what about the admin who is trying to halt widespread disruption, spanning a large number of pages? That is, by using a large number of page-blocks applied against a single editor, the admin is creating a technologically-enforced topic-ban. In the recent ArbCom case involving GMOs, there were 28 enumerated articles that received extra scrutiny during the case, and most of the participants were calling for topic-bans to cover hundreds of articles (several participants called for ... and that actual remedies specify ... literally thousands of articles as being within the t-ban). In those sorts of situations, double-digit-page-blocks are no longer surgical, they are either two-handed broadswords, or maybe suitcase-nukes, with the enWiki-block-for-a-year being the tactical nuke, and the global site-ban being the ICBM. Clearly there is a need for double-digit-page-blocks, in ArbCom cases... but those are given out by the consensus of *dozens* of admins, and with months of in-depth consideration.   Do we want individual admins, too busybusy to delve into the details of a long-running dispute, given the power to hand out double-digit-page-blocks? I'm not sure we do. Do we want admins to be able to start out surgical, page-blocking an edit-warrior from a single article for 31 hours, and then as that still-hot dispute migrates across the 'pedia, have the same admin follow the disruptive person around, adding more page-blocks to the blockee's block-log, with longer and longer durations? What started out as a means to *limit* disruption, and give out *proportionate* blockage, has snowballed into a long chain of disruption that ends up giving the blockee months of "cool down" time. I think admins are human, and will get consciously or unconsciously angry at the blockee, whom they were trying to HELP by merely handing out a 31-hour page-block, just yesterday, and today they are handing out month-long double-digit-page-blocks to that same disruptive blockee dammit!   In some ways, NOT having the page-block button is a blessing: admins will have the option of going to usertalk, and damping the disruption using words, or if need be, pulling out the big old broad-swath enWiki-block and bring the hammer down. By adding the page-block, in the future admins will be FAR less likely to immediately think of that enWiki-block. Which at first seems like a good thing: less trigger-happy admins is good, right? But the unintended consequence is that admins, unless they are *wonderfully* sagacious self-controlled wise humans indeed, are gonna be sorely tempted to give a half-assed attempt at using words to damp disruption, and then get very scalpel-happy, handing out page-blocks all around. Currently, there are about 1% of admins who are trigger-happy. There are exactly 0% of admins who are scalpel-happy, because there is no scalpel available.   Page-block is that scalpel, and I expect we'll see a very large number of incidents that result in page-blocks, when before they would have resulted in mere explanations-and-warnings on talkpages. I don't know if my prediction will come true, but human psychology strongly suggests it will. Sorry about the long post here. I wish I could come up with an actual conclusion. But in the end, I'm neutral: page-block is a blade. It could be used for Good Things, like a surgeon with a scalpel, carefully cutting out disruption whilst always pledging to first-do-no-harm. It could also easily be a constant source of unintended Bad-Thing consequences: when you poke somebody with a scalpel, and page-block them, sometimes they go on a rampage, until finally you pull out the double-handed broadsword... and some people will LIKE wielding that sword, and defend their admin actions by saying, hey, at least I didn't enWiki-block them, all I did was double-digit-page-block them. These types of things will drive good contributors away, unless admins are exceedingly wise and careful.
  2. ↑ Agree with the others above, that this should be implemented -- IFF page-blocking IS decided to be a net positive -- so it works for pages and/or categories and/or namespaces, not merely works for articles. Specifically, it makes sense that if User:TheAdmin wants to give a page-block to User:Ed_T._Wharr the correct procedure would be something like this: User:TheAdmin creates the subpage en:User:Ed_T._Wharr/page-block_page-list, and then adds whatever is appropriate. In some cases that might be a single article such as en:Draft:NTA_(company), with an page-block length of 31 hours, and the explanation for why the page-block was imposed, and how to avoid the behavior in the future, right there in the subpage. The subpage should be fullprot, obviously. Later, when our now-page-blocked user attempts to click edit at the top of en:Draft:NTA_(company), or click edit on a subsection thereof, or click undo in the edit-history thereof, a low-level mediawiki feature first checks whether en:User:Ed_T._Wharr/page-block_page-list exists, and if so, whether en:Draft:NTA_(company) is on it, and not yet expired.   For the sake of efficiency, it will dramatically speed up this check, if the contents of all the page-block_page-list entries across enWiki are regularly sucked into an indexed database-table, so that the low-level mediawiki feature is implemented as a pre-compiled SQL proc which accepts UID and pageID as inputs, and returns the allowed/disallowed response without needing to re-parse the current contents of the wikitext stored at en:User:Ed_T._Wharr/page-block_page-list.   Besides adding specifically-named pages to the list, TheAdmin can also add something like en:Category:Israeli–Palestinian_conflict, with a duration of M hours, and have that category-style page-block apply to ALL pages listed at that category. The main advantage here is that admins will be able to create a custom-designed category, something like en:Category:Pages_where_disruption_related_to_dispute_XYZ_occurs, add that category to the subpage of an editor causing disruption *across* that specific "topic" area, and then as needed, easily and quickly insert *new* pages into the *category* (without needing to make any updates to the page-block subpage). Using HotCat or a similar semi-automated tool, TheAdmin will be able to quickly damp down any kind of drama... and because of the way in which categories are implemented, and the way I'm suggesting page-blocks be implemented, the block-log of en:User:Ed_T._Wharr will remain unchanged. Page-blocks will just be a specialized kind of scalpel-block, which prevents editing.   It probably should also be possible for User:TheAdmin to put a special notation into en:User:Ed_T._Wharr/page-block_page-list which will prevent that editor from making any edits to a particular namespace for N hours. There does not seem to be a ready-made way to implement this; perhaps a new "Moniker:NS3" pseudonamespace (to block from usertalk), or perhaps adding additional stuff like "Special:NS3" to the extant one (same purpose but different syntax).
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2015/Moderation_and_admin_tools/uk&oldid=26128282"