Як мені впоратися зі складним програмістом, який приєднується до проекту з відкритим кодом?

У мене є сценарій з відкритим кодом для конкретного сайту (я намагаюся тут нічого не називати по імені), який я та ще кілька розробників нещодавно переїхали до GitHub. З моменту переходу на нову систему ми отримали кілька нових розробників, зокрема одного дуже активного. Однак цей активний почав змінювати багато проектів.

Перш за все, він видалив нашу систему версій (не як Git, але так - ми називали її версії v4.1.16) і сказав, що краще буде просто натиснути код на сайт, коли ми думаємо, що він готовий. Зараз немає централізованого місця для розміщення нотаток до випуску, що стало дратувати.

Річ, яка змусила мене майже готовий упакувати мої сумки та йти, - це сценарій push. Інший розробник проекту написав простий скрипт на основі Python. Оскільки ми зберігаємо в різних місцях кілька версій сценарію, я почав кодувати більшу програму Java з графічним інтерфейсом, який замінить сценарій Python. Я пішов на IRC, щоб сповістити всіх про це, і отримав дуже дратівливу відповідь від програміста, який сказав, що старий сценарій на основі Python може робити все, що можна зробити, і набагато легший (він також прокоментував те, що думав Python був кращий за Java тощо. Я переглянув код старого сценарію push і побачив, що жодної функції, яку він сказав, не існує.

Тож тепер я хочу знати, що робити. Я витратив багато часу на цей проект, тому мені не хочеться просто вставати та залишати, але мені важко працювати з цим новим розробником. З іншого боку, він зараз є виконавцем №1 проекту, причому навіть більше зобов'язань, ніж головний розробник. Я не дуже впевнений, що з цим робити. Хтось ще відчував цю проблему? Якщо так, що ви робили?

ОНОВЛЕННЯ 1 : Я відключив доступ для всіх, і я прошу людей переглядати запити на виклик. Я також запропонував кілька заходів для вирішення інших питань. Всі інші не виявили жодної підтримки для цього. Смутний розробник просто сказав, що люди, які уважно не дотримуються "вчинення дій", можуть думати, що проект дезорганізований, коли він насправді не є. Я, очевидно, не згоден з цим, тому я серйозно задумуюсь про відставку від проекту.

ОНОВЛЕННЯ 2 : Провідний розробник почав оскаржувати те, що один з моїх комітетів нібито видалив три нові рядки з коду (фіксація повернення з'явилася одразу після того, як я розмістив дискусію, і навіть не посилається на мою "фіксацію"), а потім двоє з них почали обговорювати, чи потрібно відкликати моє право доступу. Отже, я зробив логічну справу і пішов з проекту. Дякуємо за вашу допомогу в цьому!

1. Можна кинути. Не найконструктивніше, що потрібно зробити, але іноді це єдиний варіант. Якщо це так, не сидіти навколо і не стогнати про те, як вам довелося відмовитися від нього, візьміть цю енергію і перекладіть її прямо в щось інше - «рухайтеся далі» іншими словами.

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

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

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

Ви трохи зрозуміли, яка саме тут ваша роль. Відповідь залежить від того, як ти вмієш.

Якщо ви керуєте проектом і керуєте сховищем git

Беріть назад контроль. Якщо цей хлопець робить зобов’язання, які вам не подобаються, не консультуючись з вами, видаліть його прямий доступ для здійснення комісій. Він може розіслати проект і зробити запити на тягнення об'єднати свої зобов'язання. Ось як має працювати відкритий код, поки користувач не набуде довіри. Вам не потрібно одразу надавати повний доступ.

Якщо хтось інший контролює репо

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

Пробачте, будь ласка, мою тупість, але ваш пост читається, як розпуста.

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

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

Будь ласка, добре подумайте про розподіл праці в проекті - війни за дерни неминучі, якщо у вас немає чітких меж, які б вам сказали, хто в чому компетентний . Так, доводиться часом довіряти судженням інших людей.

У кількох відповідях вже згадується, що розподіл праці - це один із способів зменшити конфлікт. Ось кілька конкретних прикладів:

1. Збалансуйте продуктивність проти стабільності. Щоб запозичити аналогію у стратегічних іграх, команда повинна складатися з поєднання Буму, Черепахи та Раша , а товариші по команді повинні бути готові змінити ролі у відповідь на ситуацію.
   • Коли один із манерів продуктивності, інші можуть працювати над:
   • Інші особливості
   • Виправлення помилок
   • Технічні характеристики (управління новими запитами на функції та перевірка відповідності програмного забезпечення узгодженим критеріям)
   • Гарантія якості
     • Ручне (розвідувальне) тестування
     • Автоматизоване тестування
   • Документація
   • Рефакторинг та очищення коду
   • Проведіть дослідження користувачів, щоб зібрати ідеї для вдосконалень
   • тощо.
2. Проект можна модулювати (як в архітектурі програмного забезпечення) або навіть розділяти (як в управлінні проектами), щоб кожен модуль міг працювати незалежно.
   • Загалом, більшість програмного забезпечення, яке містить як передній, так і задній, має бути модульованим, оскільки вони мають різну швидкість розвитку.
   • Програмне забезпечення, багате на UX, може бути важко модулювати через їх велике використання маршрутизації подій між модулями.
   • Керівник проекту може захотіти зробити проект простим, уникаючи модуляризації.
3. Функціональна галузь . Кожен розробник може роздрібнити проект, попрацювати над його улюбленою функцією домашнього улюбленця та подати запит на об'єднання після завершення реалізації. Провідний розробник може остаточно сказати, чи приймати злиття.

Окрім аспекту уникнення конфліктів, очевидно, що проект може мати недостатнє управління .

Чому важливо управління? Уявіть, одного дня колишній товариш по команді взяв частину програмного забезпечення та подав позов до команди за порушення. Або команда подала позов за патентним тролем. Або ніхто не знає, хто вирішив надіслати повідомлення DMCA на сайт хостингу проектів і вимагати видалення вихідного коду проекту.

Як мінімум:

• Ліцензія, яка повинна використовуватись усім внесеним вихідним кодом
• Ліцензія (и), за якою може бути опублікований вихідний код проекту
  • Якщо вимагається нова публічна ліцензія, як отримати згоду від кожного учасника
• Хто може мати адміністративний доступ до проекту
• Хто буде призначений відповідати на законні запити (наприклад, повідомлення DMCA або патентні тролі)
• Хто буде керувати фінансами проекту (оплата витрат на сервер та облік доходів від реклами або пожертви)
• Хто матиме право голосу для включення нових членів та виключення членів.
• тощо.

Більшість сайтів проектів з відкритим кодом можуть надавати готові статути управління проектами.

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

Хорошим планом було б розділити завдання різних людей. Якщо ви можете погодитися з особами, яка частина проекту несе відповідальність за кожну особу, то лише одна людина приймає рішення щодо певної частини проекту. Але робота в команді завжди складна. Вам все одно ніколи не сподобаються рішення, прийняті іншими програмістами. Найкраще рішення - ніколи не дивитися на те, що вирішили інші програмісти. Досить лише довіритися їм, щоб вони зробили правильно.

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

Ось приклад речі, якого слід уникати: Наприклад, велика кількість програмістів c ++ вважає, що код, який не використовує бібліотеку STL, порушений. Інші програмісти вважають, що кожна залежність від зовнішніх бібліотек порушена, включаючи STL. Такі конфлікти просто не можуть бути вирішені належним чином - обидві ситуації не можуть бути заповнені одночасно - і найбільш проблемні люди підкажуть свою думку незалежно від того, з якою опозицією вони зіткнуться.

Я вважаю чотири варіанти.

1. Вигнати його. Ви (нібито) все ще головний чувак у цьому проекті; відкликати свої привілеї на поштовх і називати це день Найімовірнішим результатом є його розгортання проекту, розділення його спільноти, і тоді війна розривається, і коли осідає пил, одна з вилок стане популярною.
2. Розкладіть його і продовжуйте в іншому місці. Менш агресивний, ніж 1., але наслідки в іншому випадку однакові. Вам доведеться бути активним у громаді, хоча притягувати людей до себе.
3. Залиште так: просто нехай він робить те, що робить, заспокоюється і сподівається на краще.
4. Обговоріть із громадою, укладіть компроміс за потребою та вирішіть ситуацію.

Особисто я вважаю за краще варіант 4.

Про це кілька років тому Google провів пару технічних розмов. Дивіться їх:1 ,2 . Коротко:

1. Осмислення : Розуміння мотивації вашої спільноти до роботи над проектом проти всіх інших витрат, і зберегти ці причини.
2. Зміцнюйте : будуйте здорову громаду із соціальними нормами ввічливості, поваги, довіри та смирення.
3. Визначте : шукайте знакові ознаки отруйних людей (їх занадто багато, щоб перелічити, але якщо ви задаєте це питання, то, мабуть, ви багато з них знаєте).
4. Дезінфікуйте : будьте спокійні та будьте спокійні, не реагуйте на образи, кривди, виклики, неповагу тощо та наполегливо зміцнюйте свої норми громади.

Вичерпні письмові начерки доступні також , якщо ви віддаєте перевагу читати замість годин.

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

Сказавши це, я переконаний, що ви повинні висловити свою стурбованість. Ви можете записати їх в електронний лист і показати це своїм надійним друзям, які не входять до команди і не мають малого інтересу до того, чим займаєтесь. У цьому випадку ви можете отримати хороший відгук, щоб формулювання вашої електронної пошти було не надто суворим. Однак дотримуйтесь фактів. Не звинувачуйте і не звинувачуйте. Тільки факти, що важко щось зробити для вас, тому що "бла" немає. Чому пропущено "бла", має бути зрозуміло кожному учаснику команди, тобто "новий програміст" щось видалив або нічого не досяг.

Знову ж таки, надсилати цей електронний лист важко, але саме по собі це чудовий досвід, який може бути дуже корисним для вас у майбутньому. Чудовий урок, який потрібно засвоїти.

PS: Я не хотів звучати занадто батьківсько. Однак це дійсно те, що я б сказав усім, включаючи своїх дітей.