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

65

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

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

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

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

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

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

Nathan2055
источник
46
Как один человек может самостоятельно изменить систему управления версиями? Конечно, он, должно быть, пользовался народной поддержкой, по крайней мере, среди некоторых людей. И, судя по другому комментарию, было изменение лицензии, чтобы ограничить все это - почему вы, ребята, не говорите громче, когда основы вашего проекта внезапно потрясены / заменены?
Охотник на оленей
32
Вы упускаете суть вопроса. Как новичок присоединился к вашему проекту и, казалось бы, взял на себя все это? Это может быть открытый исходный код, но подразумевается, что есть лидер или группа лидеров, и предположительно, что / эти лидеры будут единственными, кто сможет изменить такие важные части того, как работает проект.
Alroc
35
Это твой проект на github, верно? Есть ли причина, по которой вы не можете удалить его доступ к проекту? Или он сделал свою собственную вилку, из которой вы можете вытащить, если вам нравятся изменения? Если бы кто-то просто взял это, чтобы изменить то, как код был версионирован в моем проекте, они бы сразу исчезли.
GrandmasterB
6
Чем ты занимаешься? Вы публикуете на TheDailyWTF и делитесь ссылкой со всеми. Вы посрамите его в подчинении.
рат
24
Честно говоря, и независимо от других проблем, поставленных на карту, замена скрипта Python на графическую Java-программу для переноса программного обеспечения на веб-сайт выглядит для меня как безумный переподготовка.
Сэм Хочевар

Ответы:

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

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

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

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

gbjbaanb
источник
2
Я бы предложил вилку ();
ot--
1
Почему выход заявлен как решение № 1? Если проект действительно такой захватывающий, разве это не последний вариант?
Охотник на оленей
2
@DeerHunter: я не читал порядок возможностей как порядок предпочтений, но полезно иметь 1,2 в списке первым, так как эти возможности могут
дать
36
варианты перечислены в порядке их простоты для ввода.
gbjbaanb
Поменяйте местами №3 с № 1, вам придется отступить, потому что одинокий волк, не обращая внимания ни на что другое, может разрушить хороший проект.
Джонатан Нойфельд
39

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

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

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

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

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

Бен Маккормик
источник
23

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

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

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

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

Охотник на оленей
источник
4
@ Nathan2055 - Простой и работа это лучше, в моей книге (возможно , это только мне). В любом случае, кажется, что проект дрейфует без особого руководства.
Охотник на оленей
1
Я согласен с дрейфующей частью. Одна из вещей, о которых я забыл упомянуть, это то, что один и тот же разработчик случайно перепроверял проект, никому не сказав.
Nathan2055
24
Как именно один новый разработчик в одностороннем порядке изменил лицензию на существующую часть кода, над которой он не имеет единоличного контроля авторских прав? Как он получил такой доступ / полномочия и почему его не забрали?
KutuluMike
7
Вся эта ситуация не складывается. Никто не может пойти и в одностороннем порядке изменить лицензию на проект ОС. Поскольку вы не согласились с этим и (я полагаю) внесли свой вклад, его изменение означает присед.
Норкросс
9
@ Nathan2055 Изменение лицензии проекта без авторизации, вероятно, является основанием для немедленного увольнения даже в проектах с открытым исходным кодом. То, что это открытый исходный код, не означает, что какой-то случайный чувак может просто войти и взять на себя управление. Неважно, насколько эпичны его навыки программирования, если он не может работать в команде, вы не хотите, чтобы он был там, и вам нужно поговорить с ним и / или выгнать его. Если вы не рассказываете нам все ..
Томас
10

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

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

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

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

Как минимум:

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

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

rwong
источник
1
+1 за управление. Рано или поздно все проекты с открытым исходным кодом нуждаются в некоторых письменных правилах, а также в некотором коде, будь то полноценное управление для крупных проектов или просто простой кодекс поведения (например, wiki.gnome.org/CodeOfConduct ) для любых форумов, списков рассылки. , ошибка базы данных или SCCS вы все поделитесь.
calum_b
9

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

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

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

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

ТР1
источник
Хороший момент по разделению труда.
Охотник на оленей
3
Никогда не смотрите на то, что решили другие программисты, просто доверяйте им? Звучит опасно для меня. А как насчет контроля качества?
Стефан
6

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

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

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

tdammers
источник
6

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

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

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

эксцесс
источник
3
Не могли бы вы немного рассказать о том, что есть у каждого из этих ресурсов, и почему вы рекомендуете их как ответ на заданный вопрос? «Ответы только на ссылки» не совсем приветствуются на Stack Exchange
комнат
1
Добавлено резюме, как это?
Куртоз
5

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

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

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

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

Schultz9999
источник
7
«Вы не можете просто бросить» ... Да, вы можете . Это не выбор, который нужно делать легкомысленно, так как это означает, что вы сожжете каждый мост со всеми остальными в команде, если вы это сделаете, но если ситуация достаточно плохая (до такой степени, что вызывает эмоциональный стресс), просто уйти всегда можно ,
Шадур