Как мне справиться со сложным программистом, присоединяющимся к проекту с открытым исходным кодом?

У меня есть скрипт с открытым исходным кодом для определенного сайта (я пытаюсь не называть здесь ничего по имени), который я и несколько других разработчиков недавно переместили на GitHub. С тех пор, как мы перешли на новую систему, у нас появилось несколько новых разработчиков, в том числе один очень активный. Тем не менее, этот активный начал многое менять в проекте.

Прежде всего он удалил нашу систему управления версиями (не как Git, а так - мы назвали ее версиями v4.1.16) и сказал, что было бы лучше просто отправить код на сайт, когда мы думаем, что он готов. Теперь нет централизованного места для размещения заметок о выпуске, что стало раздражать.

То, что подготовило меня к тому, чтобы собирать вещи и идти, - это сценарий push. Другой разработчик проекта написал простой push-скрипт на основе Python. Поскольку мы поддерживаем несколько версий скрипта в сети в разных местах, я начал кодировать большую Java-программу с графическим интерфейсом, который заменит скрипт Python. Я пошел на IRC, чтобы уведомить всех об этом, и я получил очень раздражающий ответ от программиста, в котором говорилось, что старый скрипт на основе Python может делать все, что может делать мой, и он намного проще (он также отметил, что считает, что Python был лучше, чем Java и так далее). Я просмотрел код для старого push-скрипта и увидел, что ни одна из функций, которые он сказал, не существует.

Так что теперь я хочу знать, что делать. Я потратил много времени на этот проект, поэтому я не хочу просто вставать и уходить, но мне трудно работать с этим новым разработчиком. С другой стороны, он теперь является коммиттером № 1 в проекте с еще большим количеством коммитов, чем ведущий разработчик. Я не совсем уверен, что с этим делать. Кто-нибудь еще сталкивался с этой проблемой? Если так, что ты сделал?

ОБНОВЛЕНИЕ 1 : Я отключил доступ к коммитам для всех и прошу людей проходить запросы на получение. Я также предложил несколько мер для решения других проблем. Все остальные не проявили никакой поддержки. Беспокойный разработчик просто сказал, что люди, которые не следуют «обязательству», могут думать, что проект дезорганизован, хотя на самом деле это не так. Я, очевидно, не согласен с этим, поэтому я серьезно думаю об уходе из проекта.

ОБНОВЛЕНИЕ 2 : Ведущий разработчик начал разглагольствовать по поводу того факта, что один из моих коммитов предположительно удалил три новых строки в коде (обратный коммит появился сразу после того, как я опубликовал обсуждение, и даже не ссылается на мой «коммит»), а затем двое из них начали обсуждать, аннулировать ли мне доступ к коммиту. Итак, я сделал логичную вещь и покинул проект. Спасибо всем за помощь!

1. Вы можете выйти. Не самое конструктивное занятие, но иногда это единственный вариант. Если вы это сделаете, не сидите без дела и не стоните о том, как вы должны были бросить это, возьмите эту энергию и вложите ее прямо во что-то другое - «двигайтесь дальше», другими словами.

2. Вы можете раскошелиться. Там нет причин, почему вы должны работать с кем-либо. Форк, улучшите код и позвольте другим продолжать проводить свой собственный эго-фестиваль. Ваш новый проект будет просто конкурировать со старым и решать вам, добьетесь ли вы успеха или старый превзойдет вас с точки зрения пользователей и возможностей.

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

Это может быть трудно, когда кто-то приходит и меняет безопасные и удобные процедуры, к которым вы привыкли, но можно сказать, что если кто-то пришел и встряхнул старые, удобные практики, это уже хорошо для себя.

Вы сделали немного неясным, какова ваша роль здесь. Ответ зависит от того, как вы подходите.

Если вы руководите проектом и управляете репозиторием git

Вернуть контроль. Если этот парень делает коммиты, которые вам не нравятся без консультации с вами, удалите его прямой коммит. Он может раскошелиться на проект и сделать запросы на слияние для объединения своих коммитов. Вот как должен работать open source, пока пользователь не создаст доверие. Вам не нужно и не следует давать полный доступ сразу же.

Если кто-то еще контролирует репо

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

Пожалуйста, прости мою резкость, но твое сообщение читается как напыщенная речь.

Вы говорите, что это другой парень, который хочет бессмысленных изменений, но затем вы противоречите себе, когда говорите об этой вашей новой блестящей Java-программе.

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

Пожалуйста, также тщательно подумайте о разделении труда в проекте - войны за газоны неизбежны, если у вас нет четких границ, говорящих вам, кто в чем компетентен . Да, иногда приходится доверять суждениям других людей.

В нескольких ответах уже упоминалось, что разделение труда является одним из способов уменьшения конфликтов. Вот несколько конкретных примеров:

1. Баланс производительности и стабильности. Чтобы позаимствовать аналогию из стратегических игр, команда должна состоять из сочетания Boom, Turtle и Rush , а товарищи по команде должны быть готовы поменяться ролями в ответ на ситуацию.
   • Когда кто-то увлекается производительностью, другие могут работать над:
   • Другие свойства
   • Исправление ошибок
   • Спецификации (управление запросами новых функций и проверка соответствия программного обеспечения согласованным критериям)
   • Гарантия качества
     • Ручное (поисковое) тестирование
     • Автоматизированное тестирование
   • Документация
   • Рефакторинг и очистка кода
   • Проводить пользовательские исследования для сбора идей для улучшения
   • и т.п.
2. Проект может быть модульным (как в архитектуре программного обеспечения) или даже разделенным (как в управлении проектом), так что каждый модуль может работать независимо.
   • В целом, большинство программ, которые содержат как интерфейс, так и фон, должны быть модульными, поскольку они имеют разную скорость разработки.
   • UX-богатое программное обеспечение может быть трудно модульным из-за интенсивного использования межмодульной маршрутизации событий.
   • Сопровождающий проекта может захотеть сохранить проект простым, избегая модульности.
3. Особенность ветки . Каждый разработчик может раскошелиться на проект, поработать над своей любимой функцией питомца и запросить слияние после завершения реализации. Ведущий разработчик может окончательно сказать, следует ли принять слияние.

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

Почему управление важно? Представьте, что однажды бывший товарищ по команде взял часть программного обеспечения и подал в суд на команду за нарушение. Или команда подала в суд на патентного тролля. Или никто не знает, кто решил отправить уведомления DMCA на сайт хостинга проекта и потребовать стереть исходный код проекта.

Как минимум:

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

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

Я видел проблему раньше. Но через несколько лет вы действительно устали от проекта, поэтому я решил покинуть проект . Это может не сработать для вас, но проблема в том, что разные люди думают по-разному. Особенности, которые вы считаете очень важными, совсем не важны для других людей.

Хорошим планом было бы разделить задачи разных людей. Если вы можете договориться с лицами о том, какая часть проекта находится в ведении каждого человека, то только один человек принимает решения по определенной части проекта. Но работать в команде всегда сложно. Вам по-прежнему никогда не понравятся решения, принимаемые другими программистами. Лучшее решение - никогда не смотреть на то, что решили другие программисты. Достаточно просто доверять им, чтобы они поступали правильно.

Общая цель сосредоточит ваши усилия на важных вещах. Трудно найти каждого, кто работает в одном направлении, и конфликты все равно будут иметь место. Для определения общей цели необходимо знать, каков текущий статус проекта, а затем решить, где он должен быть через некоторое время.

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

Четыре варианта, я бы сказал.

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

Лично я предпочел бы вариант 4.

Google несколько раз говорил об этом несколько лет назад. Смотреть их:1 ,2 . В двух словах:

1. Осмысление : Понимание мотивации вашего сообщества к работе над проектом против всех других издержек, и сохранить эти причины.
2. Укрепление : Создайте здоровое сообщество с социальными нормами вежливости, уважения, доверия и смирения.
3. Определите : ищите контрольные признаки ядовитых людей (слишком много, чтобы перечислить, но если вы задаете этот вопрос, вы, вероятно, уже знаете многих из них).
4. Дезинфицируйте : будьте спокойны и стойте на своем, оставайтесь не реагирующими на оскорбления, пренебрежения, вызовы, неуважение и т. Д. И настойчиво укрепляйте нормы вашего сообщества.

Исчерпывающие письменные наброски доступны также , если вы предпочитаете читать вместо часов.

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

Сказав это, я твердо верю, что вы должны высказать свои опасения. Вы можете записать их в электронное письмо и показать его своим доверенным друзьям, которые не являются частью команды и не интересуются или не интересуются тем, что вы делаете. В этом случае вы можете получить хороший отзыв, чтобы текст вашего письма не был слишком резким. Придерживайтесь фактов, хотя. Не обвиняй и не обвиняй. Просто факты о том, что вам сложно что-то сделать, потому что «бла» отсутствует. Почему «бла» отсутствует, должно быть понятно каждому члену команды, т. Е. «Новый программист» удалил или ничего не достиг.

Опять же, отправка этого электронного письма трудна, но сама по себе она является отличным опытом, который может быть очень полезен для дальнейшего развития. Отличный урок для изучения.

PS: я не хотел казаться слишком родительским. Однако это действительно то, что я бы сказал всем, в том числе и моим детям.