Кар'єра
Будувати інфраструктуру довіри для Wikipedia, Wikidata і AI-відповідей.
WikiBusines працює як внутрішня редакційна команда — без маркетплейсу фрилансу, без сфабрикованого висвітлення, із розкриттям paid-editing як non-negotiable. Приєднатися до нас — це працювати над реальними Wikipedia-проєктами поруч із senior-редакторами, які сперечатимуться з вами про політики, і вимірюватись тим, чи виживає ваша опублікована робота, а не тим, наскільки зайнятим/-ою ви виглядаєте.
Кого шукаємо
Три речі, які об'єднуватимуть вас із рештою команди
Навичкам можемо навчити. На ці три речі — наймаємо: без них онбординг не спрацює.
Ви бачите різницю між «процитувати джерело» і «вдати, що джерело є».
Ми працюємо на ринку, де «зрізання кутів» — норма: сфабриковане висвітлення, проплачені публікації, відмивання цитат. Ми так не робимо. Перше, що ми перевіримо, — як ви читаєте список джерел, а не як добре пишете питч.
Радше скажете «це не пройде», ніж відвантажите сторінку, яку видалять за 30 днів.
Сказати клієнту, який платить, «це не пройде notability» — це навичка. Так само як сказати senior-редактору, що драфт, який він передав, ще не готовий. Якщо «ні» коштує вам сну — ця команда не для вас.
Ви читаєте Wikipedia talk pages — для задоволення або за обов'язком.
І те, і те ОК. Що не обговорюється — вільне володіння WP:NCORP, WP:NPOV, WP:RS, а також реальною етикою edit summaries, обговорень AfD і відгуків AfC-рев'ювера. Ми наймаємо людей, які вже там живуть.
Відкриті ролі
Шість ролей, усі — навколо редакції
Якщо не бачите саме своєї назви, але читаєте Wikipedia-політики для задоволення — напишіть усе одно. Команда росте разом із роботою.
Київ / Remote-EU
Повна зайнятість
Senior Wikipedia-редактор (English)
Провідний редактор на проєктах англомовної Wikipedia — від оцінки notability через подання AfC до захисту на talk-page і моніторингу після публікації.
За що відповідатимете
- Вести редакційний цикл 6-10 паралельних EN-проєктів — від аудиту джерел до публікації.
- Робити оцінку WP:NCORP / WP:GNG на старті та повідомляти акаунт-команді, коли проєкт не варто запускати.
- Писати нейтральні, policy-compliant драфти простою енциклопедичною англійською; подавати через AfC під розкритим paid-editing-акаунтом.
- Захищати статті на AfD, коли їх оскаржують — з джерелами, посиланнями на політики і спокійним тоном.
- Менторити 2-3 джуніор-редакторів; ревʼюити їхні драфти до того, як вони дійдуть до клієнта.
- Координуватися з ресеч-подом щодо source-паків і з AI-visibility-аналітиком щодо післяпублікаційного покриття у LLM.
Вам тут буде добре, якщо
- У вас 500+ правок на EN Wikipedia під власним акаунтом і щонайменше одна опублікована стаття, яка пройшла AfC.
- Можете однією фразою пояснити, чому стаття Forbes contributor — це не reliable source.
- Вільно орієнтуєтесь у COI- та PAID-disclosure шаблонах і користувалися ними.
- Можете утримувати позицію в обговоренні видалення, не сприймаючи це особисто.
Як ми знаємо, що це працює
Онбординг — два тижні в парі з senior-редактором на реальній клієнтській роботі. Інструментарій — наш внутрішній dashboard для перевірки джерел, edit-pacing-трекер і AfD-watch — показуємо у перший день. Шляхи ескалації задокументовано: якщо драфт, який ви написали, оскаржують на AfD, пара founder+editor долучається до захисту впродовж 24 годин. Ви ніколи не залишитесь сам/сама на спірній статті.
Remote
Повна або часткова зайнятість
Wikipedia-редактор — інші мовні версії (DE / FR / ES / IT / PL / UA)
Носії мови або near-native рівень для не-англомовних Wikipedia-версій, у які ми відвантажуємо. Одна мова на роль; кілька ролей відкрито у DE, FR, ES, IT, PL, UA.
За що відповідатимете
- Робити локальну оцінку notability — що вважається reliable у DE Wikipedia, не дорівнює тому ж у EN.
- Перекладати й адаптувати затверджені EN-драфти у належно ре-джерелену локальну статтю — не машинний переклад, а перезібрану джерельну базу.
- Знаходити локальні джерела, яких EN-команда не знайде: регіональна преса, реєстри міністерств, судові матеріали, академічні бази.
- Подавати через процес перевірки конкретної мовної версії (AfC, NPP або пряме створення — залежно від культури вікі).
- Захищати на місцевому еквіваленті обговорення видалення (LP, PdS, AfD, KFA тощо) — місцевою мовою.
- Сигналізувати про локальні особливості політик, які треба знати EN-команді — у кожної Wikipedia своя етика.
Вам тут буде добре, якщо
- Носій або C2 у читанні й письмі цільовою мовою; англійську — на робочому рівні всередині команди.
- Наявна історія правок у цільовій мовній версії під власним акаунтом.
- Орієнтуєтесь у місцевій пресі досить добре, щоб упізнати проплачену публікацію з першого читання.
- Готові сказати «це працює в EN Wikipedia, але не в DE Wikipedia» — і пояснити чому.
Як ми знаємо, що це працює
Перші два тижні: shadowing senior-редактора на EN-стороні, щоб вивчити наш workflow перевірки джерел, потім ведення трьох невеликих локальних проєктів, де EN-сеньйор перевіряє якість джерел перед поданням. Із другого місяця — повна власність над своєю чергою. Щотижневий 30-хвилинний дзвінок усіх редакторів за мовними версіями — порівнюємо дрейф інтерпретації політик.
Київ / Remote-EU
Повна зайнятість
Ресечер / Аналітик джерел
Людина, яка вирішує, чи можна публікувати суб'єкта, ще до того, як редактор написав перший рядок. Володіє source-vetting, аудитом конкурентів і складанням source-паків.
За що відповідатимете
- Робити аудит джерел до старту проєкту — оцінювати кожне джерело за WP:RS і WP:NCORP; видавати письмовий висновок щодо notability, який команда продажів може захистити.
- Збирати source-пак, з яким працюватиме редактор: незалежні, secondary, in-depth джерела з однорядковою позначкою про reliability на кожному.
- Аудити покриття конкурентів у Wikipedia в ніші клієнта; позначати, що саме статті клієнта бракує, щоб порівнювально пройти notability.
- Відстежувати «гниття джерел» — те, що було сильним торік, може бути мертвим або downgrade-нутим цьогоріч (перекласифікація Forbes contributor, зміни URL у регуляторів тощо).
- Підтримувати командну довідкову таблицю reliable-sources по індустріях, з якими працюємо найчастіше.
Вам тут буде добре, якщо
- За пів хвилини відрізняєте sponsored-content від незалежного матеріалу.
- Без скарг читаєте первинні regulator-filings (SEC, BaFin, FCA, судові PDF).
- Готові сказати «цей клієнт не відповідає notability, проєкт варто відхилити».
- Думаєте чек-листами і пишете внутрішні нотатки, якими реально може скористатися наступний аналітик.
Як ми знаємо, що це працює
Онбординг — тиждень із senior-ресечером, який пройде з вами 15-20 минулих source-паків: і ті, які ми відвантажили, і ті, на підставі яких відмовили проєктам. Перший місяць — парні аудити; з другого — власна черга, і редакційний под трактує ваш висновок як авторитетний. Ескалація — напряму до власника, коли продажу потрібен висновок про notability під дедлайн.
Київ / Remote-EU
Повна зайнятість
Спеціаліст з PR-аутрічу
Source-pitch аутріч до журналістів Tier-1 і Tier-2 видань — не generic PR. Завдання — допомогти клієнтам стати coverage-worthy, а не спамити редакторів.
За що відповідатимете
- Знаходити реальних репортерів, які пишуть про беата клієнта в виданнях, що рахуються як WP:RS — за беатом і свіжими байлайнами, а не за назвою видання.
- Будувати source-pitch — історію, яку журналіст реально захоче, а не прес-реліз, який клієнт хоче розіслати.
- Вести аутріч end-to-end: питч, фоллоу-ап, обробка відповідей, ембарго-логістика за потреби.
- Координуватися з редакційною командою, яке покриття рухає notability, а яке — косметичне.
- Тримати чистий запис — хто сказав «так», хто «ні» і чому — для наступного раунду.
Вам тут буде добре, якщо
- 3+ роки досвіду journalist-facing аутрічу; знаєте напам'ять по 10 репортерів Tier-1 видань щонайменше у двох індустріях.
- Вас достатньо разів ігнорували, гостили й ввічливо відмовляли, щоб не сприймати це особисто.
- Можете написати 90-словний питч, який журналіст реально відкриє.
- У вас алергія на масові PR-розсилки, і ви відмовляєтеся ними користуватись.
Як ми знаємо, що це працює
Перші два тижні — читання нашого аутріч-архіву за останні 6 місяців (перемоги й поразки) і shadowing leader-а на трьох живих кампаніях. Інструментарій: внутрішній трекер відносин із журналістами (зроблений власноруч, без Meltwater) і командна бібліотека питчів. Ескалація — власник для чутливих акаунтів; редакційний лід — для неоднозначності щодо впливу на notability.
Київ / Remote-EU
Повна зайнятість
Акаунт-менеджер — Enterprise
End-to-end власність над 5-10 enterprise-клієнтами — мультимовні портфоліо, річна підтримка, мультистейкхолдерські погодження.
За що відповідатимете
- Вести комунікацію з клієнтом від kickoff до річної підтримки — письмові брифи, обговорення скоупу, погодження, ескалація.
- Переводити бізнес-цілі клієнта у редакційний скоуп, який редакторський под може реально виконати в межах політик Wikipedia.
- Управляти мультимовними портфоліо — 4-6 мовних версій паралельно для одного клієнта — це нормально; координуєте таймінг і консистентність.
- Вести квартальний health-check call: що live, що відредагувала спільнота, що під ризиком, який наступний хід.
- Бути людиною, яка скаже клієнту «це доповнення не пройде» ще до того, як це доведеться сказати редакторському поду.
Вам тут буде добре, якщо
- Маєте досвід ведення enterprise-клієнтів з річним бюджетом від €50k і пірамідою стейкхолдерів 3-4 рівні вглиб.
- Комфортно почуваєтесь в юридичних, комунікаційних і C-suite розмовах в межах одного тижня.
- Тримаєте скоуп, не стаючи опонентом редактора — взаємини працюють лише тоді, коли ви з редактором видимо на одній стороні.
- Можете написати статусний апдейт, який CEO дочитає до кінця.
Як ми знаємо, що це працює
Перший місяць — shadowing Head of Business Development на трьох наявних enterprise-акаунтах перед призначенням власних. Успадковуєте стартове портфоліо з 3-4 акаунтів із задокументованою історією; за пів року виростаєте до 5-10. Редакційні ліди та ресеч-под — це партнери 1:1, а не вендори, яким ви ставите задачі. Ескалація — власник по контрактних питаннях; редакційний лід — по інтерпретації політик.
Київ / Remote-EU
Повна зайнятість
AI Visibility-аналітик
Моніторить присутність клієнтського бренду у ChatGPT, Gemini, Perplexity і Google AI Overviews; будує плани source-recovery та source-strengthening, прив'язані до Wikipedia / Wikidata-роботи.
За що відповідатимете
- Робити щотижневі visibility-скани по LLM-стеку і будувати per-client дельти видимості — що змінилося, чому, що з цим робимо.
- Картувати джерела цитувань, з яких AI-движки реально витягують відповіді у ніші клієнта — інколи Wikipedia, інколи Wikidata, інколи ні те ні інше.
- Будувати плани source-recovery, коли згадка про бренд клієнта падає або атрибутується не тій сутності.
- Координуватися з редакційною командою щодо того, які саме Wikipedia / Wikidata-правки реально зрушать LLM-видимість, а які — ні.
- Тримати руку на пульсі архітектури retrieval і training-data у головних LLM-вендорів — цей ринок змінюється тижнями.
Вам тут буде добре, якщо
- Вільно орієнтуєтеся в retrieval-augmented generation у тому вигляді, як це існує у проді OpenAI / Anthropic / Google — щонайменше на рівні «можу прочитати paper».
- Скептично ставитеся до вендорських заяв про «AI SEO» і вмієте пояснити, чому більшість із них помилкові.
- Можете побудувати dashboard поза вендорським інструментом, коли треба.
- Пишете звіти, які зрозуміє нетехнічний клієнт.
Як ми знаємо, що це працює
Онбординг — перший місяць у парі з Head of Digital. Вивчаєте in-house моніторинговий стек (зробили свій — вендорські інструменти виявились недостатньо чесними) і читаєте client visibility reports за останні 12 тижнів. Ескалація: власник — по клієнтських рекомендаціях, Head of Digital — по інструментарію. Щотижня публікуєте внутрішню нотатку про те, що зрушилося у LLM-стеку — вона стає командним артефактом.
Як ми наймаємо
Чотири кроки. Орієнтовно два-три тижні end-to-end.
У нас одна сильна думка щодо найму: ті, хто вміє робити роботу, і ті, хто добре проходить інтерв'ю — це не завжди той самий список. Наш процес побудований навколо цього.
Заявка
Email на team@wikibusines.com — CV, посилання на роботи (портфоліо, Wikipedia username за наявності, актуальний список journalist-контактів для PR-ролей) і абзац про те, що привело вас саме до цієї роботи. Ми читаємо кожну заявку.
30-хвилинний скринінг-дзвінок
Коротка розмова з hiring lead ролі — не з HR. На дзвінку звіряємо, що правильно зрозуміли ваш досвід, і відповідаємо на ваші запитання про те, як реально працює команда.
Оплачуване тестове
Реальне завдання на 2-4 години — наприклад, аудит якості джерел на тестовому суб'єкті для ролі Ресечера або Wikipedia-драфт під WP:NCORP для ролі Редактора. Оплата — за пропорційною ставкою ролі. Працюєте з тим самим інструментарієм, що й команда.
Оффер — або чесний фідбек — упродовж 7 днів
Якщо це fit — надсилаємо оффер протягом 7 днів після тестового. Якщо ні — у той самий термін надсилаємо предметний фідбек: що спрацювало, що ні, де ви були б на місці. Ми платимо за тестове, бо наймаємо людей, які вміють робити роботу, а не людей, які добре проходять інтерв'ю.
Ми платимо за тестове, бо наймаємо людей, які вміють робити роботу, а не людей, які добре проходять інтерв'ю.
Чому тут варто працювати
Шість конкретних причин — без хайпу
Кожен рядок нижче член команди може перевірити в перший же день. Ми не пишемо careers-копірайту, який потім було б соромно захищати.
Внутрішня редакційна команда
Ви працюєте з senior-вікіпедистами і ресеч-подом у тому самому штаті — а не з маркетплейсом фрилансерів, які торгують вашим драфтом. Ревʼю — це розмови, а не мовчазні відмови.
Розкриття paid-editing як замовчуване
Кожен редактор у штаті публікує під розкритим paid-editing-акаунтом за WP:PAID. Вас ніколи не попросять приховувати, на кого ви працюєте. Клієнти це знають. Спільнота це знає. Це не обговорюється.
Інструменти, які ми зробили самі
Внутрішній source-vetting dashboard, edit-pacing трекер, AfD-watch, моніторинговий стек LLM-видимості. Зробили своє, бо вендорські інструменти виявилися недостатньо чесними щодо якості джерел, а нам потрібен був audit trail, який витримує клієнтське ревʼю.
1 000+ статей на рік
Реальний об'єм, реальна власність — ви не восьмий «погоджувач» чужого драфта. Коли є довіра — ви ведете свою чергу end-to-end, а вимірюємо ми результати (виживання статті, відсоток виграшу на AfD), а не активність.
50+ спеціалістів по ЄС
Редактори у DE, FR, ES, IT, PL, NL, UA працюють у власних часових поясах із щотижневими cross-language дзвінками. Ви не єдина людина, яка знає політику напам'ять — завжди є з ким посперечатися щодо інтерпретації NCORP.
Чесний refund-пункт
Наш оффер-договір містить реальний пункт про повернення коштів за borderline-роботу. Це не просто захист клієнта — це причина, чому ми не відвантажуємо сумнівні сторінки. Ваші опубліковані Wikipedia-URL — це доказ компетентності, а не сорому.
Як відгукнутися
Один email. Тема — у такому форматі.
Без порталу, без форми, без third-party ATS. Email потрапить до людини в команді протягом одного робочого дня.
Надсилайте заявку на team@wikibusines.com.
Рекомендована тема
Application — [назва ролі] — [ваше імʼя]
Будь ласка, додайте
- CV або резюме (бажано PDF).
- Посилання на LinkedIn.
- Wikipedia username, якщо застосовно — і мовні версії, у яких редагуєте.
- Один абзац — 6-8 речень — про те, що привело вас саме до цієї роботи. Не cover letter, а живий абзац.
Ми відповідаємо на кожну отриману заявку. Якщо не отримали відповіді протягом п'яти робочих днів — нагадайте, будь ласка. Інколи листи губляться.
Хочете дізнатися, з ким будете працювати? Познайомтесь із командою →
Не впевнені, яка роль ваша? Напишіть усе одно.
Якщо читаєте Wikipedia talk pages для задоволення і не можете сказати точно, ваш шлях — Редактор чи Ресечер, напишіть нам. Розберемося разом на скринінг-дзвінку.