Цей розділ у кнайпі української Вікіпедії використовується для обговорення пропозицій, що не стосуються політик (для цього є Вікіпедія:Кнайпа (політики)).
Якщо у Вас є пропозиція щодо чогось, що на Ваш погляд є абсолютно очевидною річчю, а його відсутність в українській Вікіпедії викликає у Вас почуття здивування та обурення, перевірте тут, чи Ваша пропозиція випадково не видалась настільки ж очевидною ще комусь.
Будь ласка, підписуйте свої коментарі (для цього наберіть ~~~~
або натисніть кнопку над віконцем редагування).
Автоматична стабілізація найпопулярніших статей
Всіх вітаю, пропоную розглянути пропозицію автоматичної стабілізації найбільш популярних статей в українській Вікіпедії.
Нагадаю, що стабілізація — це таке налаштування сторінки, що незалогіненим чи новим користувачам показується остання затверджена (перевірена версія), а не версія з неперевіреними змінами. При цьому сторінка доступна для редагування будь-кому. В деяких інших розділах, наприклад, польському чи німецькому, від самої появи механізму патрулювання було вирішено впровадити автоматичну стабілізацію для усіх статей. У нас же, відповідно до консенсусу, стабілізація ставиться лише на статті, які часто вандалять, статті, які потенційно будуть вандалити або статусні статті. Станом на сьогодні, 1 червня, в нас 1910 стабілізованих статей.
Я пропоную налаштувати бота, який автоматично встановлюватиме стабілізацію на статті, які потрапили до 500 найпопулярніших за день та автоматично знімати позначку, якщо три дні підряд стаття не потрапляла в ТОП-500. Такі налаштування додадуть приблизно 700 стабілізованих статей (залежно від дня). Якщо запровадження системи буде вдалим, можна це число розширити до ТОП-1000 чи ТОП-750.
Я вже розробив автоматично оновлювану щогодини сторінку та інструмент для аналізу в реальному часі, які дозволяють стежити за неперевіреними змінами в популярних статтях щоб оперативно їх патрулювати.
Також я зробив невелике дослідження за минулий рік, в якому з'ясував, що кількість сторінок, які хоча б раз потрапляли в ТОП-500 складає менше 1% від усіх статей, при цьому сукупна кількість переглядів лише за ті дні, коли вони потрапляли в топ-500 складає понад 14% річних переглядів уквікі.
- Чому варто встановити стабілізацію на популярні статті
- Превентивний захист від вандалізму. Репутаційна шкода від вандалізму в популярних статтях набагато вагоміша, бо вандалізм який провисів навіть декілька хвилин вже може потрапити на очі десяткам людей, що дуже відчутно б'є по довірі до Вікіпедії, що особливо критично зараз на фоні зростання популярності чат-ботів з ШІ. Дякуючи моніторинговим інструменам для боротьби з вандалізмом, середній час, який вандалізм висить в статті, вдалось значно зменшити, проте він далеко не нульовий, а профілактика завжди краще ніж лікування.
- Більше уваги до популярних статей. За стабілізованими статтями потрібно стежити патрульним і перевіряти нові зміни, інакше вони не стануть видимі, тому і були розроблені додаткові інструменти. Крім цього, якщо патрульні будуть редагувати стабілізовані сторінки, що мають неперевірені зміни, їх редагування так само не будуть видимі більшості читачів, тому це буде ще однією мотивацією все таки спершу затвердити чи відхилити неперевірені редагування.
- Більше мотивації стати патрульними. У нашій Вікіпедії складається таке враження і я вже це неодноразово чув, що статус патрульного це щось абсолютно необов'язкове. Не відчувається ніякої особливої мотивації отримати статус, бо різниця насправді настільки невідчутна, що виглядає суто номінальною. Сподіваюсь, що стабілізація стане додатковим приводом подаватись на права патрульного.
Успішність впровадження цієї пропозиції напряму залежить від того, чи знайдеться підтримка спільноти не тільки на словах, а і на ділі. Кожного дня кількість неперевірених редагувань в популярних статтях може коливатись від 20 до 50 редагувань. Також для старту потрібно розгребти найпопулярніші статті, які накопчили пласт неперевірених редагувань за довгий період. Окрім цього, в ТОП деколи потрапляють сторінки, які могли не перевірятись місяцями або і роками. Потрапляють також зовсім ніразу неперевірені, але на них стабілізація не впливає.
При необхідності, я можу розробити також додаткові інструментми для відстеження особливо гострих випадків відставання (виділення червоним кольором / окремий канал сповіщення) для дуже застарілих статей, або в крайньому разі встановлення стабілізації лише для тих статей, в яких термін існування неперевірених редагувань складає менше певного часу.
Буду радий почути вашу думку та ваші пропозиції. --Mile.Horizon (обговорення) 17:52, 1 червня 2025 (UTC)
- Це дуже хороша пропозиція.
- Я також вважаю, що найбільша увага має в першу чергу приділятися найбільш популярним і читаним статтям (як протилежність ВП:Зайві статті). Саме з тих причин, що це має найбільший вплив на уявлення читачів про Вікіпедію. І стабілізувати автоматично популярні статті — хороша ідея. Це даватиме хоч якусь гарантію якості. --VoidWanderer (обговорення) 18:36, 1 червня 2025 (UTC)
- Я нейтрально ставлюся для пропозиції, але припущу, що якщо для її реалізації потрібно, щоб спільнота щось додаткове робила, то пропозиція може виявитися нежиттєздатною. Щоб це перевірити, можливо, варто не спочатку вводити стабілізацію, а потім очікувати регулярного патрулювання статей, а навпаки — вводити автоматичну стабілізацію після того, як (якщо) буде забезпечене їхнє вчасне патрулювання. І ще, в мене є враження, що для статей із відвідуваністю на межі бот буде трохи "засмічувати" їхню історію автоматичними короткочасними стабілізаціями. --Фіксер (обговорення) 19:22, 1 червня 2025 (UTC)
- 1. Як я вже сказав, в плвікі чи девікі по суті діє така ж пропозиція тільки на всі статті. Якщо іншомовна спільнота може самоорганізуватись і тримати беклог неперевірених редагувань дуже малим, хоча обсяг роботи в них без применшення в тисячі разів більший при співмірному розмірі спільноти, то я думаю зможемо і ми. В крайньому разі можна запровадити пропозицію, яку я висловив наприкінці, тобто не ставити стабілізацію якщо сторінка сильно відстала, наприклад неперевіреним редагуванням більше ніж пів року.
- 2. Саме щоб уникнути постійних встановлень і прибирань стабілізації я запропонував тримати стабілізацію поки стаття не з'являтиметься в ТОП-500 мінімум три дні. Можна це числ збільшити до 7 днів. Порівняльна таблиця для 2024 року:
Кількість встановлення + зняття стабілізації для однієї статті Три дні Сім днів 0 (лише встановлення) 325 529 1 5781 6671 2 2438 2565 3 1272 1232 4 805 713 5 561 480 6 382 346 7 286 247 8 232 207 9 186 135 10 149 103 11 132 68 12 104 40 13 113 36 14 72 17 15 80 9 16 80 7 17 65 - 18 53 2 19 41 - 20 42 - 21 31 - 22 31 - 23 17 - 24 21 - 25 22 - 26 23 - 27 16 - 28 12 - 29 7 - 30 10 - 31 5 - 32 2 - 33 1 - 34 5 - 35 2 - 36 1 - 38 1 - 39 1 -
- Загалом
За. --Repakr (обговорення) 07:12, 2 червня 2025 (UTC)
- Єдине, що хотів зауважити, що потрібно бота написати так, щоб не знімав стабілізацію зі сторінок, де вручну її виставили. --Repakr (обговорення) 07:46, 3 червня 2025 (UTC)
За. Хороша пропозиція. --Τǿλίκ 002 (обговорення) 07:29, 2 червня 2025 (UTC)
За Я за поширення стабілізації для популярних статей, але можливо варто спитати у проєкту що займається популярними статтями наскільки вони за чи проти. Duppertip (обговорення) 13:56, 2 червня 2025 (UTC)
За Підтримую. Давно вже час багато процесів автоматизувати та захищати від вандалізмом, а не після того як почнеться шабаш. З другого боку, необхідно патрульним розіслати масового листа з посиланням на такий список, щоби вони стежили за цим беклогом. Можливо, навіть в цей лист кинути купу інших цікавих інструментів чи посилань, які будуть корисні в патрулюванні і боротьбі з вандалізмом. --Kharkivian (обг.) 19:26, 2 червня 2025 (UTC)
- Можна прикріпити посилання на список до однієї зі сторінок патрулювання, навіть у ВП:ПАТ коли норма стане усталеною. Duppertip (обговорення) 07:07, 3 червня 2025 (UTC)
За, треба також автоматично стабілізувати вибраний вміст. --塩基 18:57, 7 червня 2025 (UTC)
- Взірцеві статті стабілізуються автоматично ботом VAdminBot. --Фіксер (обговорення) 22:02, 7 червня 2025 (UTC)
Впровадження стабілізації для найвідвідуваніших статей
Дякую всім за зауваження в обговоренні вище. На основі висловлених думок я створив узагальнену пропозицію, яку додам до загального оголошення:
Пропоную впровадити стабілізацію найпопулярніших статей за наступним механізмом:
- Автоматично вмикати стабілізацію для статей, що потрапили до ТОП-500 за кількістю переглядів за добу.
- Знімати стабілізацію лише через 7 днів після того, як сторінка більше не потрапляє до ТОП-500. Це дозволить уникнути постійного вмикання і вимикання стабілізації для статей які знаходяться «на межі» ТОПу через щоденні коливання переглядів.
- Не знімати стабілізацію, якщо її було встановлено вручну.
- Не вмикати стабілізацію для сторінок, де останнє (найраніше) неперевірене редагування зроблено понад 3 місяці тому. Аналогічно, вимикати стабілізацію, встановлену в рамках цієї пропозиції, якщо пласт неперевірених редагувань в сторінкки перевищив ліміт в три місяці. Це дозволить уникнути ситуацій, коли старі неперевірені правки зависають у стабілізованих сторінках і ніким не перевіряються. Для підсвічення таких статей в інструментах моніторингу будуть розроблені додаткові механізми привернення уваги.
- Паралельно популяризувати інструменти моніторингу популярних сторінок з неперевіреними редагуваннями, зокрема шляхом розсилання сповіщення всім патрульним перед фактичним впровадження пропозиції.
Обговорення триватиме мінімум тиждень, тобто фінальний підсумок буде підбито не раніше 15 червня.--Mile.Horizon (обговорення) 15:45, 8 червня 2025 (UTC)
- Пункт 4 до певної міри нівелює всю пропозицію. Бо після 3 місяців знову демонструватиметься непатрульована версія. Я розумію, що це такий собі баланс між актуальністю та якістю. Можливо, доречний баланс. Але однак, 3 місяці стабілізації — це краще, ніж нічого. Тож пропозиція добра. --VoidWanderer (обговорення) 16:35, 8 червня 2025 (UTC)
- Я б краще встановив критерії залежно від кількості переглядів, а не від рейтингу. Наприклад, стабілізувати при досягненні 500 переглядів за добу, знімати стабілізацію, якщо 7 днів поспіль нижче за 250 переглядів на добу. Бо підозрюю, що ті статті, де по 10+ дій — то статті хронічно середньої популярності на кшталт Англійська мова чи Чернівці, які завжди десь на межі топ-500, ніколи не мають надзвичайних сплесків, але так само не мають і надзвичайних спадів. Для таких статей, гадаю, найкращим варіантом буде поріг за кількістю переглядів, а не за місцем, щоб не залежати від сплесків популярності інших статей — NickK (обг.) 22:28, 8 червня 2025 (UTC)
- Погоджуюся з думкою NickK. Потрібно встановити розумну межу в кількості переглядів, вище якої встановлювати стабілізацію. Знімати через 7 днів - ок. Не знімати якщо стабілізацію було встановлено вручну, теж погоджуюсь, але тільки для тимчасових стабілізацій, решта стабілізацій познімати, якщо не було досягнуто потрібного рівня переглядів. З пунктом 4 не погоджуюсь, бо вважаю, що існування старих неперевірених змін у стабілізованій статті якраз має бути додатковим стимулом для патрулювання таких статей. Для прикладу можна кожному патрульному зарекомендувати додати у свій СС усі ці сторінки, а не знімати стабілізацію та ризикувати щоби багато читачів побачили якусь явно хибну інформацію. № 5 - за.--Andriy.v (обговорення) 22:50, 8 червня 2025 (UTC)
- Я не зовсім погоджуюся з тим, що варто знімати ручну стабілізацію ботом, якщо вже є така необхідність щодо знімання постійної ручної стабілізації, то варто це роботи людиною. Бо в іншому випадку стабілізація буде бездумно зніматися. Наприклад, можуть бути конфліктні сторінки, які не потраплятимуть до запропонованих критеріїв щодо стабілізації популярних статей, але зняття з неї стабілізації може призвести до потенційних вандальних дій. Наприклад, як назви проєктованих станцій метро, чиї назви не були декомунізованим/деколонізованими. З одного боку статті рідко переглядаються, але з іншого боку в будь-який час може зайти вандал і перейменувати статті на деколонізовані назви, які не зафіксовані жодним проєктом будівництва, тощо. Тому я вважаю, що постійну ручну стабілізацію треба знімати вручну і лише після того, як ознайомимося з причинами її встановлення. --Repakr (обговорення) 07:20, 9 червня 2025 (UTC)
- Конфліктні сторінки потрібно захищати, а не стабілізовувати. Стабілізацію розумно використовувати якраз для популярний статей, там де є велика кількість читачів. Я можу зрозуміти тимчасову ручну стабілізацію на сторінках осіб, які щойно померли, або подій, які щойно сталися, ручні безстрокові стабілізації для яких критерієм не є популярність я собі не уявляю. --Andriy.v (обговорення) 07:54, 9 червня 2025 (UTC)
- Одним із таких прикладів можуть бути взірцеві статті, зрозуміло, що там вже стабілізація робиться через бота, але не всі статті є популярними, наприклад,
Iz*One, кількість переглядів за день рідко більша за 15,
Великий приз Премії мистецтв Пексан (телебачення) — не більше 9 переглядів. --Repakr (обговорення) 09:09, 9 червня 2025 (UTC)
- Взірцеві і так вже стабілізуються ботом (див. VAdminBot) відповідно з них стабілізація не буде знята. --Andriy.v (обговорення) 09:14, 9 червня 2025 (UTC)
- Одним із таких прикладів можуть бути взірцеві статті, зрозуміло, що там вже стабілізація робиться через бота, але не всі статті є популярними, наприклад,
- Конфліктні сторінки потрібно захищати, а не стабілізовувати. Стабілізацію розумно використовувати якраз для популярний статей, там де є велика кількість читачів. Я можу зрозуміти тимчасову ручну стабілізацію на сторінках осіб, які щойно померли, або подій, які щойно сталися, ручні безстрокові стабілізації для яких критерієм не є популярність я собі не уявляю. --Andriy.v (обговорення) 07:54, 9 червня 2025 (UTC)
- @Andriy.v, @NickK початкова ідея була в тому, щоб мати передбачуваний щоденний обсяг роботи, тобто почати з топ-500, визначити чи справляємось з патрулюванням і потім запропонувати перейти на топ-750 і топ-1000. Проблема в тому, що кількість переглядів це дуже і дуже волатильний показник, який змінюється не лише рік до року чи місяць до місяця, при умовному порозі в 500 переглядів навіть день до дня може бути падіння чи ріст в два рази кількості статей, які його подолали. Якщо йти цим шляхом, то окрім того що розмір роботи не буде можливо передбачити, цей показник ймовірно буде потрібно якось коригувати з часом. --Mile.Horizon (обговорення) 12:50, 9 червня 2025 (UTC)
- Гаразд, погоджуюсь з Вашою думкою щодо тестування за регтингом через варіативність переглядів, але спершу потрібно зробити порядок з уже стабілізованими сторінками: познімати стабілізацію там де її непотрібно; створити список усіх стабілізованих статей де є неперевірені зміни. Я би наразі навіть не починав зі сторінок рейтингу, а з уже наявних стабілізованих. Якщо протягом місяця не буде застоїв, тоді включати ТОП-100, потім ТОП-200 і т.д. --Andriy.v (обговорення) 12:49, 11 червня 2025 (UTC)
- Я не зовсім погоджуюся з тим, що варто знімати ручну стабілізацію ботом, якщо вже є така необхідність щодо знімання постійної ручної стабілізації, то варто це роботи людиною. Бо в іншому випадку стабілізація буде бездумно зніматися. Наприклад, можуть бути конфліктні сторінки, які не потраплятимуть до запропонованих критеріїв щодо стабілізації популярних статей, але зняття з неї стабілізації може призвести до потенційних вандальних дій. Наприклад, як назви проєктованих станцій метро, чиї назви не були декомунізованим/деколонізованими. З одного боку статті рідко переглядаються, але з іншого боку в будь-який час може зайти вандал і перейменувати статті на деколонізовані назви, які не зафіксовані жодним проєктом будівництва, тощо. Тому я вважаю, що постійну ручну стабілізацію треба знімати вручну і лише після того, як ознайомимося з причинами її встановлення. --Repakr (обговорення) 07:20, 9 червня 2025 (UTC)
Якщо такій стабілізації передуватиме патрулювання останніх змін, то можна приймати. І що робити з дуже популярними статтями, які ні разу не перевірялися патрульними? Також дуже часто найвідвідуванішими є статті про актуальні події. Їх автоматична стабілізація шкодитиме іміджу Вікіпедії, як джерела актуальної енциклопедичної інформації. От що б варто обдумати, так це механізм інформування патрульних про досягнення невідпатрульованою статтею певного високого рівня відвідуваності. --Perohanych (обговорення) 06:05, 9 червня 2025 (UTC)
- Я вважаю що це не є проблема. Значна частина списку часто в ньому, тому перед запуском механізму можна довести такі статті до ладу чи принаймні допоки не залишаться статті з 1-2 невеликими правками та відносно незначними змінами. Я не думаю що за 1 день будуть великі зміни. Але це дійсно варто взяти до уваги. Також можливо потрібен інструмент з перегляду нещодавніх стабілізацій за останні 3-7 днів, це було б зручно. Duppertip (обговорення) 08:22, 9 червня 2025 (UTC)
- Є журнал [1] --Andriy.v (обговорення) 08:52, 9 червня 2025 (UTC)
- Тобто спочатку стабілізувати, потім патрулювати? Але ж потрібно навпаки? --Perohanych (обговорення) 11:40, 9 червня 2025 (UTC)
- не думаю, що є сенс дивитись список стабілізованих статей, бо там 60-80% будуть статті без неперевірених редагувань. Є сенс дивитись найпопулярніші стабілізовані статті, де вже є неперевірені правки, а це якраз ті самі статті, які публікуватимуться щогодини тут і в реальному часі тут (тільки треба розширити к-сть днів до 7 і можливо замінити ТОП-500 на статті, які подолали певний поріг переглядів). --Mile.Horizon (обговорення) 13:01, 9 червня 2025 (UTC)
- Є журнал [1] --Andriy.v (обговорення) 08:52, 9 червня 2025 (UTC)
- @Perohanych стабілізація на жодного разу не перевірені версії не впливає ніяк на те, що бачать читачі — якщо немає жодної перевіреної версії, то вони бачитимуть останню актуальну. Тому на такі статті стабілізація ставитись автоматично не буде. Інформація про найпопулярніші невідпатрульовані сторінки щогодини публікується тут, в реальному часі можна подивитись тут. --Mile.Horizon (обговорення) 12:57, 9 червня 2025 (UTC)
- Візьмімо поточну версію найпопулярнішої сьогодні статті https://uk.wikipedia.org/w/index.php?title=День_Святої_Трійці&oldid=45443582
- В ній 23 зміни очікують на перевірку https://uk.wikipedia.org/w/index.php?title=День_Святої_Трійці&diff=45443582&oldid=42871571
- Одна зі змін - нова дата святкування.
- Якщо цю статтю стабілізувати, то більшість читачів бачитимуть суттєво коротшу і застарілу версію https://uk.wikipedia.org/w/index.php?title=День_Святої_Трійці&oldid=42871571
- Тому проти. Стабілізація загалом демотвує незареєстрованих дописувачів, і доцільна лише для статей, що часто піддаються вандалізму. Або, на короткий час, для статей, в яких наразі йде війна правок. --Perohanych (обговорення) 14:28, 9 червня 2025 (UTC)
- @Perohanych ця стаття стабілізована не буде відповідно до умов описаних у пропозиції, бо перша неперевірена правка зроблена понад 3 місяці тому. --Mile.Horizon (обговорення) 15:17, 9 червня 2025 (UTC)
- Відповідно до діючих у нас правил, обґрунтування встановлення стабілізації не може включати в себе війну правок.
- Стосовно демотивації незареєстрованих дописувачів це спірна тема, адже стаття залишається доступною до редагування будь-кому і зміни (якщо вони конструктивні) будуть затверджені все одно. З мого досвіду, німецькі користувачі навпаки схвально відгукуються про стабілізацію (яка в них і поляків працює на абсолютно всі статті і не схоже що когось демотивує), бо, за їх словами, можна впевненіше вносити правки, знаючи що їх точно хтось перевірить. --Mile.Horizon (обговорення) 15:27, 9 червня 2025 (UTC)
Загалом За, якщо протягом початкового періоду не буде зніматися ручна стабілізація зі статей. Не проти в майбутньому знімати ручну стабілізацію зі статей, але якщо перед тим вручну проглянути весь список постійно стабілізованих статей і визначити чи потрібно вона там чи ні. Якщо ж буде одразу зніматися ручна стабілізація без аналізу чого вона там виставлена і чим її можна замінити, то я буду
Проти. --Repakr (обговорення) 10:45, 9 червня 2025 (UTC)
- Загалом я
За стабілізацію всіх статей за принципом німецької Вікіпедії, але це потрібно робити із суттєвим збільшенням кількості патрульних, тоді патрульні будуть встигати перевіряти статті. Пропонований механізм видається мені дещо заскладним, я б пропонував стабілізувати для початку топ-1000 за рік (чи місяць), тобто ті статті, що стабільно мають високу відвідуваність і докласти певних зусиль до їх патрулювання і таку стабілізацію не знімати. Я не впевнений, що потрібна стабілізація пікових статей але можна спробувати. --yakudza 16:03, 9 червня 2025 (UTC)
За стабілізацію усіх статей і експеримент зі стабілізацією ТОП 1000 за рік. --Perohanych (обговорення) 08:42, 10 червня 2025 (UTC)
- @Yakudza якщо брати топ за період (місяць чи тим паче рік), то туди якраз і потрапить купа статей які мали дуже високий піковий ріст в певні дні (тисячі і десятки тисяч переглядів), а решту періоду мали дуже мало переглядів. Наприклад три найпопулярніші статті в травні це Неліпа, Євробачення і Портнов, які сукупно подивились за травень майже пів мільйона разів. Зараз вони всі разом ледве 500 переглядів/день набирають. Щоб орієнтуватись на стабільну відвідуваність треба дивитись на поденну статистику. --Mile.Horizon (обговорення) 12:14, 10 червня 2025 (UTC)
- У цілому
За стабілізацію статей --Володимир 11:07, 12 червня 2025 (UTC)
За стабілізацію статей. Підтверджую підтримку ідеї у другому раунді. --Kharkivian (обг.) 19:08, 12 червня 2025 (UTC)
- Застереження. Слід моніторити частку невідпатрульованих статей. Якщо вона зростатиме, експеримент слід буде припинити. --Perohanych (обговорення) 09:53, 13 червня 2025 (UTC)
Підсумок
Вже майже два тижні в обговоренні не з'являється нових учасників, тому візьмусь підвести підсумок. Пропозиція, як така, очевидно має абсолютну підтримку, проте було висловлені деякі зауваження та пропозиції:
- не знімати автоматично стабілізацію встановлену вручну.
Для більшої прозорості та простоти пропоную, щоб розроблений інструмент стабілізації не знімав стабілізацію, яку встановив не він. Якщо виникають сумніви стосовно доцільності конкретної стабілізації то краще це обговорити напряму з адміністратором який її встановив та знімати її вручну після цього. Якщо якийсь адміністратор невиправдано встановлює постійну стабілізацію замість тимчасової, потрібно йому робити зауваження щоб запобігати таким діям, а не намагатись вирішувати проблему постфактум за допомогою інструменту.
- опиратись не на рейтинг, а на фіксовану кількість переглядів.
Дійсно, якщо брати до уваги загальне місце статті в ТОПі, а не просто кількість переглядів, то нові короткочасно популярні статті можуть витісняти з ТОПу певні статті які мають середню, проте тривалу і стабільну популярність. З іншого боку, абсолютна кількість переглядів — це досить волатильний показник, який окрім людського фактору може змінюватись і з технічних причин — в різні дні к-сть статей які подолали фіксований поріг на рівні, наприклад, 500 переглядів може відрізнятись в рази. Тому для початку експерименту я пропоную все ж вибрати фіксований ТОП. Такий підхід має переваги в тому, що можна передбачити к-сть стабілізованих статей і відповідно приблизний обсяг необхідної роботи з їх перевірки, яка накладається на патрульних і яку можна якісніше регулювати. Згодом можна буде ще раз оцінити цей підхід і за потреби змінити його на фіксовану к-сть переглядів.
- встановлювати стабілізацію незалежно від того, який пласт неперевірених редагувань там накопичився.
Це суперечливе питання. Очевидно шкідливі зміни якраз перевіряються (відхиляються) швидко, довго затримуються неперевіреними зазвичай складні і великі правки, які патрульні не наважуються відпратрулювати без фактчекінгу, який робити довго і нудно. Було озвучено думку, що стабілізація мотивуватиме перевірити їх швидше, але вже існуючі стабілізовані статті, де неперевірені правки так само можуть застрягати місяцями свідчать не на користь цього. Звісно, дуже важливо такі статті підсвічувати, щоб вони привертали більше уваги. Я пропоную залишити пункт про три місяці — зрештою прозвучало більше побоювань щодо того, що інструмент не створює запобіжників і очікує від патрульних виконання якоїсь роботи, коли їхня активність нестабільна і далеко не гарантована.
- включати стабілізацію на ТОП поступово (починати з ТОП-100 далі ТОП-250)/ моніторити частку невідпатрульованих статей.
За моїми спостереженнями, якщо стабілізувати топ-500, то це приблизно 50-60 нових статей з неперевіреними змінами щодня. При ТОП-100 це число зазвичай менше 10 і при цьому най-най-популярніші статті і без цього мають достатньо уваги що дозволяє швидше перевіряти правки. Я пропоную почати принаймні з ТОП-250 щоб мати прийнятний обсяг роботи. На основі активності з перевірки можна буде оцінити чи варто це число збільшити/зменшити.
Наступним кроком я сфокусуюсь на оптимізації існуючих інструментів і додаванні додаткового функціоналу підсвічування особливо застарілих статей, приверненні уваги до того обсягу неперевірених редагувань в популярних статей, який вже накопичився і який дуже бажано перевірити перед увімкненням інструменту (можливо провести тематичний тиждень) і т. д.. Після цього візьмусь за розробку та тестування самого інструменту автоматичної стабілізації, так щоб до кінця літа він запрацював в стабільному режимі.
Якщо у вас є додаткові зауваження чи пропозиції, будь ласка, не соромтесь поділитись ними.--Mile.Horizon (обговорення) 21:22, 27 червня 2025 (UTC)
- @Mile.Horizon автоматичною стабілізацією наскільки я зрозумів буде виконувати бот. Ви збираєтесь для цього залучити окремого бота для якого попросити права адміна, чи це завдання має виконувати VAdminBot? --Andriy.v (обговорення) 21:46, 27 червня 2025 (UTC)
- @Andriy.v так, це буде звичайний скрипт, який запускатиметься один раз на день (технічно можливо більше, бо звіт зі статистикою переглядів хоч зазвичай і з'являється в більш-менш конкретний час, деколи все ж може запізнюватись, а запускати стабілізацію бажано якомога раніше після його готовності.).
- Стосовно акаунту, мені технічно немає різниці з якого акаунту скрипт запускати, але я не бачу особливого сенсу створювати додаткового бота, якщо ви не проти поділитись мейнтейнерством. --Mile.Horizon (обговорення) 22:07, 27 червня 2025 (UTC)
- @Mile.Horizon перепрошу я не дуже зрозумів, що Ви маєте на увазі з "поділитись мейнтейнерством". Якщо ви про спільний доступ до обліковки бота, то це заборонено правилами (ВП:ЛТ). Будь ласка уточніть. --Andriy.v (обговорення) 17:34, 30 червня 2025 (UTC)
- @Andriy.v з точністю до навпаки, ВП:ЛТ в пункті «Колективні (спільні) облікові записи» чітко вказує, що підтверджені боти з кількома керманичами — дозволені. Це взагалі дуже поширена практика, ну хоч взяти user:Железный капут. Але я не наполягаю, з іншого боку окремий бот має свої плюси. --Mile.Horizon (обговорення) 19:11, 30 червня 2025 (UTC)
- Справді, але краще тоді окремий бот. Я наразі не готовий давати доступ комусь іншому до обліковки бота, зважаючи навіть на те, що бот виконує й багато інших завдань. --Andriy.v (обговорення) 19:38, 30 червня 2025 (UTC)
- @Andriy.v з точністю до навпаки, ВП:ЛТ в пункті «Колективні (спільні) облікові записи» чітко вказує, що підтверджені боти з кількома керманичами — дозволені. Це взагалі дуже поширена практика, ну хоч взяти user:Железный капут. Але я не наполягаю, з іншого боку окремий бот має свої плюси. --Mile.Horizon (обговорення) 19:11, 30 червня 2025 (UTC)
- @Mile.Horizon перепрошу я не дуже зрозумів, що Ви маєте на увазі з "поділитись мейнтейнерством". Якщо ви про спільний доступ до обліковки бота, то це заборонено правилами (ВП:ЛТ). Будь ласка уточніть. --Andriy.v (обговорення) 17:34, 30 червня 2025 (UTC)
Пропоную оновити код гаджета для відміток адмінів на мою версію — User:Serhio_Magpie/Gadget-markadmins.js. Це адаптований під укрвікі форк, що використовую стандартні хуки для оновлення контенту замість MutationObserver, який в поточній версій на кожну нову додану лінку (яких може бути тисячі в списках спостереження) намагається опрацювати заново всі наявні посилання на сторінці а не тільки те що оновилося. Це призводить до помітного зависання сторінки під час динамічного оновлення списків, чи якщо ще якийсь гаджет робить маніпуляції з деревом елементів. Переклад на хуки дозволить виводити флаги адмінів в інших динамічних елементах і гаджетах. Нова версія додає флаги після посилання юзера, що значно зменшує шанси проблем з кастомним підписом, і не змінює атрибут title, що не буде заважати іншим гаджетам його аналізувати. Сергіо (обговорення) 09:23, 9 червня 2025 (UTC)
- Нове налаштування для MediaWiki:Gadgets-definition:Сергіо (обговорення) 09:53, 9 червня 2025 (UTC)
* markadmins[ResourceLoader|package]|markadmins.js|markadmins.json|markadmins.css
- Подивлюсь, але наразі я не маю наміру створювати ідентичну копію гаджета рувікі. --Andriy.v (обговорення) 10:14, 9 червня 2025 (UTC)
- Добре, тоді ось відредагована наша версія — User:Serhio Magpie/Gadget-markadmins-uk.js, різниця, але я наполегливо рекомендую завантажувати json через require, щоби менше чекати. Сергіо (обговорення) 10:26, 9 червня 2025 (UTC)
- Подивлюсь, але наразі я не маю наміру створювати ідентичну копію гаджета рувікі. --Andriy.v (обговорення) 10:14, 9 червня 2025 (UTC)
Текст кнопки для приховування вмісту
Враховуючи те, що спільнота вирішила перейти на mw-collapsible, то хотів встановити який саме текст має використовувати ця кнопка. Попередня реалізація через NavFrame і collapsible використовує текст показати/сховати як в англ. вікі (show/hide) та деяких інших вікі. В той час як mw-collapsible використовує текст як задумали розробники, а саме розгорнути/згорнути (expand/collapse). Тому є два варіанти в цьому обговоренні:
- Використовуємо пару «розгорнути/згорнути».
- Використовуємо пару «показати/сховати».
--Repakr (обговорення) 10:39, 11 червня 2025 (UTC)
- Показати/сховати. Просто та зрозуміло. --Andriy.v (обговорення) 11:17, 11 червня 2025 (UTC)
- Сховати (англ. hide) — це коли об'єкт зникає зі сторінки повністю. Тому, якщо мова про навбокси, то я за «розгорнути/згорнути». --Рассилон 12:28, 11 червня 2025 (UTC)
- Загалом це стосується усіх згортувальних списків, бо фактично вони використовують одну реалізацію. Сюди входять: згортувальні таблиці, {{Oq}}, {{hidden}}, {{Collapsible list}}, {{sidebar with collapsible lists}}, {{navbox}}, {{маршрутна карта}} тощо. --Repakr (обговорення) 10:55, 12 червня 2025 (UTC)
- Якщо списки «згортувальні», а не приховувані, то ще один аргумент на користь варіанту №1. --Рассилон 18:18, 12 червня 2025 (UTC)
- Загалом це стосується усіх згортувальних списків, бо фактично вони використовують одну реалізацію. Сюди входять: згортувальні таблиці, {{Oq}}, {{hidden}}, {{Collapsible list}}, {{sidebar with collapsible lists}}, {{navbox}}, {{маршрутна карта}} тощо. --Repakr (обговорення) 10:55, 12 червня 2025 (UTC)
- Найкраще на мою думку - це "показати/приховати". Duppertip (обговорення) 17:38, 12 червня 2025 (UTC)
- 2. Використовуємо пару «показати/сховати». --Володимир 18:23, 12 червня 2025 (UTC)
Підсумок
Загалом в темі останній коментар було залишено понад два тижні тому, а отже можна підбити підсумок. Загалом Рассилон висунув доречне зауваження, що кращим іменуванням буде пара «розгорнути/згорнути», однак найбільше підтримки було висловлено саме варіанту «показати/сховати», тому буде замінено на цей варіант, а лише локально, а смае в межах української Вікіпедії, в інших проєктах наділі буде використовуватися варіант «розгорнути/згорнути» з TranslateWiki. --Repakr (обговорення) 10:37, 30 червня 2025 (UTC)
Додати в укр. Вікі бота приховувача
Вітаю! Висуваю пропозицію додати в українську Вікіпедію бота, який буде видаляти опис чи зміст редагування, якщо в них є непристойний вміст, а також за відкочувати їх. Заувага, бот буде приховувати через адміністративне право, а не групи приховувач --Vadikano (обг.) 14:48, 14 червня 2025 (UTC)
- А як бот буде визначати що зміст є непристойним? --Andriy.v (обговорення) 15:26, 14 червня 2025 (UTC)
- Тут я не знаю, бо не настільки підкований в технічному плані, але можливо якось налаштувати на конкретні слова --Vadikano (обг.) 16:58, 14 червня 2025 (UTC)
- Наразі такого бота не має, і я не дуже вмію їх робити, доречі @Andriy.v а вашого бота не можна так налаштувати? --Vadikano (обг.) 17:12, 14 червня 2025 (UTC)
- Не бачу особливої користі від такого бота, якщо його алгоритми технічно можливо реалізувати у фільтрах. --Рассилон 11:54, 17 червня 2025 (UTC)
- Підтримую колегу вище. Поки не думаю, що є якісь кращі та водночас надійні механізми для фільтрування. --MonAx (обговорення) 13:38, 17 червня 2025 (UTC)
Шаблони даних країн: міста України
По суті хочу виставити пропозицію:
- Доповнити Категорія:Шаблони даних міст України для всіх міст (для міст без прапора залишити пусте значення)
- Вилучити смт з категорії (та видалити їх бо мати Шаблони Даних Країн для селищ не є доцільним на мою думку)
- Почати використання на сторінках де це доцільно (наприклад, Міста України (за населенням), або там де прапор + назва міста прописані окремо)
- оновити та актуалізувати прапори міст за можливості
Частина пропозицій стосується деяких нетривіальних рішень (видалення смт) та просто початок вживання на інших сторінках (через шаблони на кшталт ПрапорТекст), що потребує додаткового обговорення та згоди спільноти. Якщо буде на це згода, я оновлю цю категорію та оновлю та додам шаблони. Duppertip (обговорення) 09:01, 17 червня 2025 (UTC)
Група користувачів «Організатори подій»
Недавно нам додали групу користувачів «Організатори подій», але ми її не використовуємо, через те, що не обговорили кому та навіщо її надавати. А я пропоную надавати цю групу тим користувачам, які проводять масові заходи, тобто їм потрібні додаткові права(члени Вікімедія Україна та інші). Наразі в групі є тільки 3 права, але я пропоную їх розширити, щоб функціонал був спеціально для всяких заходів.
Пропоновані мною права:
- Вмикання двофакторної автентифікації
(oathauth-enable)
- Без обмежень швидкості за IP
(autoconfirmed)
- Створення нових облікових записів
(createaccount)
- Без обмежень за швидкістю
(noratelimit)
- Використання вищих лімітів в API-запитах
(apihighlimits)
- Надсилання електронних листів учасникам події
(campaignevents-email-participants)
- Організація подій
(campaignevents-organize-events)
- Увімкнення реєстрації на події
(campaignevents-enable-registration)
- Перегляд записів журналу зловживань, позначених як приватні
(abusefilter-log-private)
- Перегляд приватних фільтрів зловживань
(abusefilter-view-private)
- Перегляд учасників приватних подій
(campaignevents-view-private-participants)
- Надсилання повідомлення кільком користувачам одночасно
(massmessage)
Пояснення деяких прав
- Права повʼязані з переглядом даних фільтру редагувань, потрібні, щоб якщо у користувачів, з яким проводиться захід сталися проблеми з фільтром редагувань, то організатори змогли б розібратися.
Додаток:
- Пропоную, щоб також у наш розділ були додані підтверджені користувачі«у саме використання», так як під час заходу, можуть знадобитися, учасникам права групи «Підтверджені користувачі». І також щоб організатори подій могли надавати користувачам ці права.
- Також разом з цією групою, може втрати сенс група «Створювачі облікових записів», щодо цього теж прохання висловитися інших користувачів в обговоренні.
- У разі прийняття групу «Організатори подій» будуть надавати адміністратори. Якщо, є ще якісь зауваги прохання висловлювати, їх в обговоренні!
--Vadikano (обг.) 14:17, 5 липня 2025 (UTC)
Обговорення
- Якщо вам це цікаво, варто спочатку розібратися з тими трьома правами, які є у групи event-organizer, що вони означають і як ними користуватися. І вже потім, можливо, обговорювати розширення прав. Надавати великій кількості учасників права, що зараз мають лише адміністратори - необачно. --Фіксер (обговорення) 20:21, 6 липня 2025 (UTC)
Проти тут перемішано все на купу: і те, що потенційно потрібно; і те, що зайве; і те, що зовсім недоречне. На скільки я розумію нові права організатора подій призначені переважно для користувачів, які організовують вікітижні чи якісь схожі заходи і це не є якийсь статус, тобто не є правами, які потредують певного рівня довіри, а просто інструмент для організаторів щоби спростити проведення заходу. Тому тепер по черзі пройдуся по кожному запропонованому праву:
oathauth-enable
- це потрібно для користувачів, які мають важливі права, для додаткового захисту аккаунту. Тут, як я вже сказав, не та ситуація, коли користувач з небезпечними правами потребує додаткового рівня захисту. А якщо й комусь захочеться захистити додатково аккаунт, то для цього є глобальні права тестувальника двофакторної автентифікації, які (здається) без особливих проблем можна отримати на меті.autoconfirmed
- важко уявити щоби неавтопідтверджений користувач проводив заходи у Вікіпедії, загалом це завжди користувачі які мають вже певний досвід.createaccount
- повністю зайве право, бо їх і так мають усі, включно з незареєстрованими.noratelimit
- не дуже розумію користь від цього права для організатора, хіба що для реєстрації нових облікових записів, якщо відбувається якийсь захід де залучено багато осіб, які ніколи ще не редагували Вікіпедію і не мають обліковки. Втім для цього вже є група створювачів облікових записів, а щодо доцільності додавати й такі права до групи організаторів я не впевнений, що це доречно.apihighlimits
- зовсім недоречні права, які ще й потребують певний рівень довіри. Для чого організаторам потрібно підвищувати обмеження на API-запити для мене є загадкою.abusefilter-log-private
таabusefilter-view-private
- ці права вкрай небезпечні, бо дозволять користувачу повністю бачити код фільтрів, які загалом призначені для протестояння вандалам, важко представити що може статися якщо ці права потраплять комусь з вандалів. Тут я категорично проти, бо такі права потребують вкрай високого рівня довіри. Також і потреби їх мати організаторам теж я не уявляю, бо приховані фільтри майже усі націлені на вандалів, а не на звичайних користувачів.campaignevents-view-private-participants
- теоритично може бути корисним, але тут потрібно бути більше ознайомленим з інструментом CampaignEvents для того щоби зрозуміти чому це право дали лише адмінам. Ймовірно для цього є поважна причина, як для прикладу знову аргумент довіри.massmessage
- на скільки я розумію організатори спілкуватимуться з учасниками події через листування або на сторінках самої події, тому наразі мати таке право здається зайвим, хоча можна обговорити, бо не впевнений
З рештою погоджуюсь зі зауваженням Фіксера - потрібно спочатку докорінно зрозуміти як правцює сам інструмент CampaignEvents перш ніж пропонувати якісь зміни до прав.--Andriy.v (обговорення) 21:12, 6 липня 2025 (UTC)
- Ця роль могла би замінити теперішнього створювача облікових записів (коли при організації якогось вікімарафону людям дають це право, щоб вони могли іншим створити акаунти). Відповідно createaccount, noratelimit знадобилось би, так само massmessage не завадить.--Анатолій (обг.) 21:54, 6 липня 2025 (UTC)
- Це все потрібно обговорювати після певного періоду використання інструменту, тоді організатори можуть самі дати пропозиції щодо покращення групи прав, а так зараз це переважно догадки, бо для прикладу можливо ні noratelimit ні massmessage не потрібні насправді. --Andriy.v (обговорення) 22:06, 6 липня 2025 (UTC)
Проти. Загалом ще вперше, коли побачив тему ще до того, як про неї згадали на ВП:ЗА, то вже сумнівався щодо необхідності давати права доступу до фільтра зловживань. Загалом погоджуюся з Andriy.v і Фіксером. --Repakr (обговорення) 07:22, 7 липня 2025 (UTC)
- Було б корисно увімкнути інструмент CampaignEvents в українській Вікіпедії для організації подій. Ми наразі маємо його на вікісайті «Вікімедіа Україна» (ось приклад), і це корисний інструмент для організації подій, щоб без потреби не змушувати людей користуватися сторонніми сервісами на кшталт Google-форм. Але не впевнений, чи організаторам подій потрібні якісь додаткові права окрім тих, що йдуть дефолтно. --Антон Процюк [ВМУА] (обговорення) 09:31, 7 липня 2025 (UTC)
- Сама група із певними правами в Українській Вікіпедії вже є (Спеціальна:Список прав груп - Організатори подій
- (event-organizer)). Не впевнений, чи це означає, що інструмент повністю увімкнутий, і якщо ні — що ще для цього треба. Але в цілому, на мою думку, вам та іншим колегам, які дійсно розуміють, навіщо цей інструмент і як його використовувати, варто отримати від адміністраторів ці права в тестовому, пілотному режимі, щоб зрозуміти, що там вже є і чого немає. Врешті решт це допоможе як наповнити сторінку Вікіпедія:Організатори подій, так і встановити регламент надання цих прав, затвердивши його із рештою спільноти. --Фіксер (обговорення) 11:26, 7 липня 2025 (UTC)
- @Фіксер, @AntonProtsiuk (WMUA), я подивився і в адміністраторів ці права вже включені, тобто їм не потрібно видавати права організатора подій. Наприклад, створити подію можна тут: Спеціальна:EnableEventRegistration. Я так розумію ці права більше для тих, хто не є адміністратором, але хоче організовувати події, наприклад, як утримувач якогось вікіпроєкту. --Repakr (обговорення) 11:46, 7 липня 2025 (UTC)
- Якщо хтось з організаторів подій є адміністратором і зголоситься перевірити цю функціональність самостійно, то можна і так, звісно. --Фіксер (обговорення) 13:50, 7 липня 2025 (UTC)
- @Фіксер та Repakr: і справді. Я трохи неуважно був прочитав анонс у техновинах і думав, що інструмент ще треба окремо увімкнути. Насправді він уже увімкнений і працює. Я щойно протестував зі свого волонтерського адміністраторського акаунту. Тобто на цьому етапі нам треба визначити: 1) чи варто включати додаткові технічні права (пропозиція Vadikano); 2) як отримувати ці права не-адміністраторам.
- Моя особиста думка: щодо 1) загалом погоджуюся з Andriy.v; щодо 2) — якщо ми не розширюємо права, то, думаю, що прапорець організатора подій має бути отримати просто; можливо, достатньо лише запиту на ВП:ЗА з поясненням, чому вони потрібні користувачу і як він/вона планує їх використовувати. --Антон Процюк [ВМУА] (обговорення) 13:50, 7 липня 2025 (UTC)
- Можна перекласти рекомендовані вимоги звідси: meta:Meta:Event organizers. Вони там теж доволі легкі; по суті, достатньо не бути заблокованим і планувати організувати подію. --Антон Процюк [ВМУА] (обговорення) 13:55, 7 липня 2025 (UTC)
- Має бути щось аналогічне до ВП:СОЗ, тобто адмін надає прапорець за запитом на ВП:ЗА тимчасово на період проведення події. --Andriy.v (обговорення) 13:55, 7 липня 2025 (UTC)
- @Фіксер, @AntonProtsiuk (WMUA), я подивився і в адміністраторів ці права вже включені, тобто їм не потрібно видавати права організатора подій. Наприклад, створити подію можна тут: Спеціальна:EnableEventRegistration. Я так розумію ці права більше для тих, хто не є адміністратором, але хоче організовувати події, наприклад, як утримувач якогось вікіпроєкту. --Repakr (обговорення) 11:46, 7 липня 2025 (UTC)
- Гадаю, що такий прапорець має надаватися автоматично особам, що вже організовували події, якщо під подіями маються на увазі вікізустрічі, віконференції, віківишколи та тематичні заходи в межах вікіпедії. Який має бути перелік прав інше питання (не аналізував, проте можливе є щось і корисне), проте як на мене відсутність прапорця не має стати перешкодою для проведення подій, а навпаки він має стати певною констатацією факту винагородою для активних організаторів (як от пан Шиманський, Юрій Пероганич чи Ата), водночас викликає сумніви автоматична наявність такого прапорця в кожного адміна, навіть такого, що ніколи нічого не огранізовував (я розумію коли це - NikK, Antanana, Yakudza чи AntonProtsiuk (WMUA), але ж не кожен має якусь оргісторію). Це моя думка як організатора. Головне, щоб не нашкодити.--Yasnodark (обговорення) 14:42, 8 липня 2025 (UTC)
- Щодо адміністраторів, то вони також мають права, які не мають організатори подій, а саме:
- Вилучення реєстрації на події
(campaignevents-delete-registration)
- Перегляд учасників приватних подій
(campaignevents-view-private-participants)
- Вилучення реєстрації на події
- А тому, мені здається, що якщо вони мають право видаляти події, то відповідно повинні мати право і створювати їх та вмикати реєстрацію на них. --Repakr (обговорення) 07:12, 9 липня 2025 (UTC)
- А чому організатори подій не мають цих прав? --Фіксер (обговорення) 13:41, 9 липня 2025 (UTC)
- Не можу тут підказати, можливо, Фонд вирішив, що ці права мають бути лише в адміністраторів. Але така ситуація наче скрізь, принаймні, в англ. вікі такий самий розподіл прав. --Repakr (обговорення) 14:58, 9 липня 2025 (UTC)
- Так, навіть на ua.wikimedia.org така сама ситуація. Але там більше адміністраторів ([2]), тобто майже всі, хто організовують події, вже мають ці права як адміністратори. В укрвікі, як я розумію, перетин цих двох груп менший (тобто далеко не всі, хто організовують події, є адміністраторами), тому я можу уявити, що комусь в укрвікі бракуватиме цих двох прав. Але, судячи з усього, якогось суттєвого досвіду, щоб впевнено стверджувати, що ці два права потрібні "Організаторам подій", у нас немає, тому для початку можна залишити все як є. --Фіксер (обговорення) 14:11, 10 липня 2025 (UTC)
- Не можу тут підказати, можливо, Фонд вирішив, що ці права мають бути лише в адміністраторів. Але така ситуація наче скрізь, принаймні, в англ. вікі такий самий розподіл прав. --Repakr (обговорення) 14:58, 9 липня 2025 (UTC)
- А чому організатори подій не мають цих прав? --Фіксер (обговорення) 13:41, 9 липня 2025 (UTC)
Проти в такому стані. Зі стандартним набором прав це порівняно легкий прапорець, який можна надати без або з мінімальним обговоренням (так само як і ВП:СОЗ). З запропонованим набором прав це стане серйозним прапорцем, зокрема, з доступом до приватних фільтрів (які дуже рідко спрацьовують на вишколах, а якщо й спрацьовують, то це зазвичай щось дуже нетривіальне, яке вимагає розуміння фільтрів). Гадаю, треба спочатку зрозуміти, які саме події там організовуватимуться: якщо це будуть віківишколи для новачків, то потрібен один набір прав (для цього зараз краще підходить СОЗ, плюс вимога реєстрації на вікі не дуже зручна, коли мова для новачків), якщо це будуть зум-дзвінки для досвідчених або ж онлайн-зустрічі на кшталт Дискорду — інший набір прав (по суті й поточних прав буде достатньо, можливо, додати можливість вилучення учасників). Але запропоновані права, на мою думку, не відповідають жодному з цих варіантів — NickK (обг.) 21:15, 10 липня 2025 (UTC)
- Щодо адміністраторів, то вони також мають права, які не мають організатори подій, а саме:
Додавання синоніма до префікса Event
У зв'язку з провадження розширення CampaignEvents у нас з'явився новий простір назв Event, але цей простір, поки не має українського префіксу. Тому пропоную додати україномовний префікс «Подія» як синонім до наявного префіксу «Event». --Repakr (обговорення) 12:05, 7 липня 2025 (UTC)
- Звісно
За. --Andriy.v (обговорення) 12:20, 7 липня 2025 (UTC)
За --Vadikano (обг.) 12:52, 7 липня 2025 (UTC)
За, очевидно. --Фіксер (обговорення) 13:49, 7 липня 2025 (UTC)
За --Perohanych (обговорення) 16:25, 7 липня 2025 (UTC)
За --Yasnodark (обговорення) 13:11, 9 липня 2025 (UTC)
За — NickK (обг.) 21:03, 10 липня 2025 (UTC)
Новий шрифт на вікі
Наразі, я бачу, що на вікі використовується усталений шрифт sans-serif. Я пропоную установити якйсь інший шрифт, оскільки поширені комбінації ії
та її
виглядають неправильно (див. Liberation Sans тут). Я не упевнений чи це через sans-serif чи Liberation Sans, але, на мою думку варто змінити шрифт на щось краще. Щось свого я запропонувати не можу, але на тому ж зображенні Ви можете побачити кілька інших схожих але кращих та відповідніших шрифтів --MetroKopUA (talk) 16:10, 11 липня 2025 (UTC)