Представьте себе две команды разработки. И ребятам из одной частенько нужны изменения в коде второй для решения своих бизнес-задач. Как водится, есть два варианта - либо "заказывать" разработку у оунеров, либо контрибьютить самим.
Плюсы "заказного" варианта понятны - первой команде не нужно разбираться в чужом коде, вторая команда лучше контролирует свой сервис. Но и минусы очевидны, и главный из них - долго ждать. Потому что у второй команды нет соответствующей задачи ни а планах, ни в интересах, им своей работы хватает. А пытаться насквозь приоритизировать свою задачку у соседей через всех заказчиков - то еще удовольствие.
Остается второй вариант - контрибьютить к соседям. Тебе надо - ты и делай. И вроде все понятно. Но всегда начинаются какие-то тёрки. Первая команда приносит какую-то фигню в PR-ах, вторая долго ревьювит и не хочет аппрувить. Переделай. Нет, так тут не принято. А вы вообще нам тесты сломали. В общем, конфликт. А мы конликты не любим.
На помощь приходит методология inner-source, которая фиксирует пререквизиты, процесс и обязательства сторон в более-менее четкий контракт. Эдакие правила игры, которые, если обе стороны договорились соблюдать, снижают градус полемики вокруг "гостевых" изменений в чужом монастыре. Набор практик, направленных на ослабление кордонов и призванных повысить гибкость и эффективность нашей работы. В зрелых командах инженерная культура должна позволять кодить у соседей в мирном и продуктивном ключе.
Поделюсь некоторыми правилами, которые были написаны
1. Тот, кто хочет внести какие-то изменения, должен перед этим рассказать свою задумку мейнтейнерам и согласовать примерный способ решения задачи.
2. У команды, в которую часто приходят иннер-сорсить, должна быть краткая и понятная документация на сервис, чтобы гостевой разработчик лучше понимал специфику сервиса, и как его случайно не сломать.
3. Должен быть документ, коротко и понятно описывающий принятые в конкретной команде подходы и традиции - от код-стайла до отношения к слоям абстракции - во избежание комментариев на код-ревью в духе "у нас тут так не принято", когда весь код уже написан.
4. Существует и выполняется разумный SLA на ревью (притом в каждой итерации, если их >1). Зеркально: автор ПР-а вносит требуемые правки достаточно оперативно, чтобы не размывать фокус ревьювера (спустя 2 недели ревьюверу трудно вспомнить, о чем был ПР).
5. В сервисе должно быть высокое покрытие тестами (юниты, авто, любые не-ручные), чтобы иметь достаточную степень уверенности в безопасности прошедших тесты правок. Количество флапов и ситуаций "а, да, этот тест сломан, не обращай внимание" должно быть околонулевым.
6. Если одна и та же гостевая команда часто вносит правки в сервис, в ней можно выбрать trusted-коммитера. Его коммиты можно ревьювить не так придирчиво (то есть как от своих), и он сам может ревьювить и аппрувить коммиты от других участников гостевой команды.
7. Гость, в свою очередь, в полной мере отвечает за качество своего коммита, стабильность релиза, возможные багфиксы, поддержку этого кода, как за свой сервис. Соблюдает подходы из п.3, разбирается в специфике из п.2, следит за тестами из п.5 и добавляет тесты на свой код.
8. Любые разногласия устраняются в конструктивном ключе, без лишних препонов. В случае необходимости обсуждаются лично или с эскалацией до лидов. Главное - помнить, что мы тут одно дело делаем, а работаем - в коллективе.
