У меня есть скрипт с открытым исходным кодом для определенного сайта (я пытаюсь не называть здесь ничего по имени), который я и несколько других разработчиков недавно переместили на GitHub. С тех пор, как мы перешли на новую систему, у нас появилось несколько новых разработчиков, в том числе один очень активный. Тем не менее, этот активный начал многое менять в проекте.
Прежде всего он удалил нашу систему управления версиями (не как Git, а так - мы назвали ее версиями v4.1.16
) и сказал, что было бы лучше просто отправить код на сайт, когда мы думаем, что он готов. Теперь нет централизованного места для размещения заметок о выпуске, что стало раздражать.
То, что подготовило меня к тому, чтобы собирать вещи и идти, - это сценарий push. Другой разработчик проекта написал простой push-скрипт на основе Python. Поскольку мы поддерживаем несколько версий скрипта в сети в разных местах, я начал кодировать большую Java-программу с графическим интерфейсом, который заменит скрипт Python. Я пошел на IRC, чтобы уведомить всех об этом, и я получил очень раздражающий ответ от программиста, в котором говорилось, что старый скрипт на основе Python может делать все, что может делать мой, и он намного проще (он также отметил, что считает, что Python был лучше, чем Java и так далее). Я просмотрел код для старого push-скрипта и увидел, что ни одна из функций, которые он сказал, не существует.
Так что теперь я хочу знать, что делать. Я потратил много времени на этот проект, поэтому я не хочу просто вставать и уходить, но мне трудно работать с этим новым разработчиком. С другой стороны, он теперь является коммиттером № 1 в проекте с еще большим количеством коммитов, чем ведущий разработчик. Я не совсем уверен, что с этим делать. Кто-нибудь еще сталкивался с этой проблемой? Если так, что ты сделал?
ОБНОВЛЕНИЕ 1 : Я отключил доступ к коммитам для всех и прошу людей проходить запросы на получение. Я также предложил несколько мер для решения других проблем. Все остальные не проявили никакой поддержки. Беспокойный разработчик просто сказал, что люди, которые не следуют «обязательству», могут думать, что проект дезорганизован, хотя на самом деле это не так. Я, очевидно, не согласен с этим, поэтому я серьезно думаю об уходе из проекта.
ОБНОВЛЕНИЕ 2 : Ведущий разработчик начал разглагольствовать по поводу того факта, что один из моих коммитов предположительно удалил три новых строки в коде (обратный коммит появился сразу после того, как я опубликовал обсуждение, и даже не ссылается на мой «коммит»), а затем двое из них начали обсуждать, аннулировать ли мне доступ к коммиту. Итак, я сделал логичную вещь и покинул проект. Спасибо всем за помощь!
источник
Ответы:
Вы можете выйти. Не самое конструктивное занятие, но иногда это единственный вариант. Если вы это сделаете, не сидите без дела и не стоните о том, как вы должны были бросить это, возьмите эту энергию и вложите ее прямо во что-то другое - «двигайтесь дальше», другими словами.
Вы можете раскошелиться. Там нет причин, почему вы должны работать с кем-либо. Форк, улучшите код и позвольте другим продолжать проводить свой собственный эго-фестиваль. Ваш новый проект будет просто конкурировать со старым и решать вам, добьетесь ли вы успеха или старый превзойдет вас с точки зрения пользователей и возможностей.
Вы можете привлечь остальных разработчиков к проекту, чтобы высказать свои опасения. Не делайте это лично, но заметьте, что вы недовольны оттоком кода, отсутствием установленных процессов обеспечения качества или недовольны тем, что новые решения просто выдвигаются без согласия всех. Вам либо скажут, что нет ничего плохого, чтобы измениться, либо вы получите согласие нескольких других с вами на то, что команде необходимо все исправить. Это может привести к тому, что разрушительный парень потеряет доступ к коммитам. Возможно, вы все согласитесь с тем, что некоторые изменения не являются улучшениями, и проект необходимо отменить. (Этот последний вариант является наиболее вероятным результатом, если он не превращается в массивный аргумент укоренившихся мнений.)
Это может быть трудно, когда кто-то приходит и меняет безопасные и удобные процедуры, к которым вы привыкли, но можно сказать, что если кто-то пришел и встряхнул старые, удобные практики, это уже хорошо для себя.
источник
Вы сделали немного неясным, какова ваша роль здесь. Ответ зависит от того, как вы подходите.
Если вы руководите проектом и управляете репозиторием git
Вернуть контроль. Если этот парень делает коммиты, которые вам не нравятся без консультации с вами, удалите его прямой коммит. Он может раскошелиться на проект и сделать запросы на слияние для объединения своих коммитов. Вот как должен работать open source, пока пользователь не создаст доверие. Вам не нужно и не следует давать полный доступ сразу же.
Если кто-то еще контролирует репо
Высказывайте свои опасения тому, кто это делает, и поощряйте более дисциплинированный процесс планирования и утверждения изменений Если руководство не поддается процессу, вы можете принять статус-кво и продолжать вносить свой вклад, вы можете раскошелиться на проект и работать над собственной версией (взять с собой любого, кто с вами согласен), или вы можете оставить и работать над другими вещами. В любом случае вы не обязаны продолжать заниматься этим.
источник
Пожалуйста, прости мою резкость, но твое сообщение читается как напыщенная речь.
Вы говорите, что это другой парень, который хочет бессмысленных изменений, но затем вы противоречите себе, когда говорите об этой вашей новой блестящей Java-программе.
Сделать перерыв; это не улица с односторонним движением, пожалуйста, попробуйте найти компромиссы (если вы хотите продолжить работу над проектом - разветвление - это самое простое решение, но оно не приведет вас к чему-то полезному, хотя оно может поразить ваше эго).
Пожалуйста, также тщательно подумайте о разделении труда в проекте - войны за газоны неизбежны, если у вас нет четких границ, говорящих вам, кто в чем компетентен . Да, иногда приходится доверять суждениям других людей.
источник
В нескольких ответах уже упоминалось, что разделение труда является одним из способов уменьшения конфликтов. Вот несколько конкретных примеров:
Помимо аспекта предотвращения конфликтов, очевидно, что проект может иметь недостаточное управление .
Почему управление важно? Представьте, что однажды бывший товарищ по команде взял часть программного обеспечения и подал в суд на команду за нарушение. Или команда подала в суд на патентного тролля. Или никто не знает, кто решил отправить уведомления DMCA на сайт хостинга проекта и потребовать стереть исходный код проекта.
Как минимум:
Большинство сайтов с открытым исходным кодом могут предоставлять готовые уставы управления проектами.
источник
Я видел проблему раньше. Но через несколько лет вы действительно устали от проекта, поэтому я решил покинуть проект . Это может не сработать для вас, но проблема в том, что разные люди думают по-разному. Особенности, которые вы считаете очень важными, совсем не важны для других людей.
Хорошим планом было бы разделить задачи разных людей. Если вы можете договориться с лицами о том, какая часть проекта находится в ведении каждого человека, то только один человек принимает решения по определенной части проекта. Но работать в команде всегда сложно. Вам по-прежнему никогда не понравятся решения, принимаемые другими программистами. Лучшее решение - никогда не смотреть на то, что решили другие программисты. Достаточно просто доверять им, чтобы они поступали правильно.
Общая цель сосредоточит ваши усилия на важных вещах. Трудно найти каждого, кто работает в одном направлении, и конфликты все равно будут иметь место. Для определения общей цели необходимо знать, каков текущий статус проекта, а затем решить, где он должен быть через некоторое время.
Вот пример того, чего следует избегать: например, большое количество программистов на c ++ считают, что код, не использующий библиотеку STL, не работает. Другие программисты считают, что любая зависимость от внешних библиотек нарушена, включая STL. Такие конфликты просто не могут быть разрешены должным образом - обе ситуации не могут быть реализованы одновременно - и самые проблемные люди будут высказывать свое мнение независимо от того, с какой оппозицией они столкнутся.
источник
Четыре варианта, я бы сказал.
Лично я предпочел бы вариант 4.
источник
Google несколько раз говорил об этом несколько лет назад. Смотреть их:1 ,2 . В двух словах:
Исчерпывающие письменные наброски доступны также , если вы предпочитаете читать вместо часов.
источник
Вы не можете просто уйти, не прилагая усилий, чтобы выразить свои проблемы и трудности. Я знаю, это может быть сложно. Если факт, что вы и члены вашей команды достаточно молоды, чтобы не сталкиваться со многими социальными проблемами, возникающими в какой-либо команде разработчиков, это может быть очень сложно.
Сказав это, я твердо верю, что вы должны высказать свои опасения. Вы можете записать их в электронное письмо и показать его своим доверенным друзьям, которые не являются частью команды и не интересуются или не интересуются тем, что вы делаете. В этом случае вы можете получить хороший отзыв, чтобы текст вашего письма не был слишком резким. Придерживайтесь фактов, хотя. Не обвиняй и не обвиняй. Просто факты о том, что вам сложно что-то сделать, потому что «бла» отсутствует. Почему «бла» отсутствует, должно быть понятно каждому члену команды, т. Е. «Новый программист» удалил или ничего не достиг.
Опять же, отправка этого электронного письма трудна, но сама по себе она является отличным опытом, который может быть очень полезен для дальнейшего развития. Отличный урок для изучения.
PS: я не хотел казаться слишком родительским. Однако это действительно то, что я бы сказал всем, в том числе и моим детям.
источник