Процесс внесения предложений в Go: история развития

Рассказывает Расс Кокс, разработчик Google

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

На ежегодном саммите GopherCon приняли участие около 30 разработчиков, которые помогли членам команды Go продумать многие вопросы. Если вам интересно узнать о саммите контрибьюторов подробнее, то можно посмотреть краткое изложение мероприятия 2017 года. В 2019 было примерно то же самое, но с другими темами для обсуждения. В зале было примерно 60 человек, из которых только половина была из Google.

Процесс внесения предложений

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

В 2015 году мы ввели официальный и документированный процесс подачи предложений, чтобы решить эту проблему. Подробнее рассказано в выступлении докладчика Эндрю Герранда на GopherCon 2015, начиная с 27:17. В своём выступлении спикер подчеркнул: «Этот процесс — эксперимент. Мы всё ещё обсуждаем, как настроить его на правильную работу».

В этом году я говорил на GopherCon о цикле «эксперимент, упрощение, поставка», который мы используем почти для всего. Мы проанализировали процесс предложения изменений, сделали корректировки и будем продолжать работать над ним.

Действующий процесс внесения предложений об изменениях выглядит следующим образом:

1. Автор создаёт тему для краткого обсуждения и ясно описывает в ней суть предложения.
2. Вопрос обсуждается на GitHub, после чего предложение принимается или отклоняется сообществом (запрашивается проектная документация).
3. Если шаг 2 закончился принятием/отклонением, тема закрывается. В ином случае автору следует изложить свои мысли и доводы в проектном документе, которые вновь выносятся на обсуждение в GitHub.
4. После проверки и редактирования проектного документа выносится вердикт (прочитайте оригинальный документ).

Эволюция процесса

Для многих людей процесс внесения предложений представляет собой не маленькие изменения в случайной выборке, а нечто большее вроде псевдонимов типов (2016), монотонного времени (2017), модулей Go (2018), новых числовых литералов (2019) и отказа от введения функции проверки ошибок try (2019). Эти большие изменения, несомненно, важны, и благодаря им мы узнали немного больше о том, что помогает делать успешные правки в языке, а что нет.

Дискуссия о предложении первоначальных псевдонимов помогла нам понять, насколько важно уметь мотивировать и обосновывать изменения. Тогда же меня познакомили с правилом из Rust — «решения должны приниматься только на основе публичного обсуждения данного предложения». С тех пор мы старались следовать ему, принимая сложные решения. Я отразил значимость мотивов для изменений, используя примеры с псевдонимами и монотонным временем на конференции GopherCon 2017.

Несмотря на то что мы не смогли обсудить плодотворно некоторые части из предложения о модулях Go, подход Rust пошёл на пользу — мы уделили значительное время обсуждению идей ещё до формальной подготовки предложения. Теперь явно прослеживается идея правила Rust — сначала публично обсуждаем, а затем решаем.

Мы усвоили кое-что из обработки предложения о псевдонимах (а потом и о модулях) — люди, внедряющие предложения, должны испытывать их в деле; изменения должны быть готовы к внедрению в начале цикла разработки. Мы приняли эту идею специально для внесения поправок в Go 2, а затем успешно добавили небольшие изменения в Go 1.13 вроде нового синтаксиса числового литерала.

Касаемо введения функции проверки ошибок try мы проследили эволюцию процесса, предоставили возможности разработчикам использовать изменения в начале цикла, в итоге реакция и обсуждение были очень горячими. Мы решили отложить это предложение всего за неделю до саммита. Единственное, что хотелось узнать — что же пошло не так в процессе обсуждения try, как совершенствовать этот процесс, чтобы последующие изменения происходили более гладко?

Над чем стоит поработать

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

Ясность и прозрачность

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

Масштабирование процесса

Предполагается, что подача предложения будет довольно проста, если изменение не первостепенно важное, как например добавление метода SubexpIndex к regxep.Regexp. По мере того, как предлагаемые изменения будут становиться более масштабными, имеет смысл ввести дополнительный процесс. Например, на саммите Gophercon 2018 мы опубликовали наши мысли об обработке ошибок и обобщений в виде проектных черновиков, а не предложений (подробнее в оригинальной статье).

Масштабирование дискуссий

Система учёта ошибок от GitHub не очень эффективна для широких дискуссий. Для крупных изменений мы хотели бы найти альтернативы, и желательно это сделать задолго до обсуждения тех самых изменений. Например, можно будет публиковать проектные черновики, или выступать перед разработчиками, или публиковать статьи — всё это способы достижения полезной, вовлечённой и плодотворной дискуссии, которая должна пройти при подготовке заявки ещё до принятия решений.

Прототипы и эксперименты

Большинство сложных изменений было бы полезно испытать до принятия решения. Сейчас это считается стандартной процедурой для небольших изменений: между моментом, когда внесли изменения, и публикацией релиза всегда проходит по меньше мере несколько месяцев, в течение которых можно что-то пересмотреть, откорректировать или удалить. Но для больших изменений, вероятно, понадобится способ сделать прототипы доступными по отдельности, чтобы выиграть ещё немного времени, подобно тому, как было с vgo (Versioned Go Command) для модулей Go.

Представители сообщества

Сейчас мы получаем гораздо больше предложений от сторонних организаций, чем в 2015, а это значит, что команда Go добилась определённых успехов. С другой стороны, более миллиона программистов работают с Go, но лишь 2300 из них прокомментировали тему предложения изменений, а это только четверть процента. Также известно, что в большей степени комментируют англоязычные пользователи. Одного GitHub мало для получения обратной связи, ведь для принятия наилучших возможных решений нужно получать информацию из большего числа источников и от более широкого круга сообщества.

Координация сообщества

Мы добились неоднозначных результатов, пытаясь вовлечь больше участников сообщества в разработку языка Go. Самым очевидным успехом можно назвать техническую разработку исходного кода Go. На сегодняшний день в списке контрибьюторов насчитывается 2000 адресов электронной почты, из них только 310 относятся к google.com или golang.org. Второе достижение — процесс подачи предложений — участие команды Go составляет 15 %, а количество принятых предложений достигает 30 % от общего числа. Также мы создали комитет по управлению пакетами (2016) и рабочие группы по взаимодействию с разработчиками с разным опытом и по проведению мероприятий для сообщества (2017). А ещё в 2018 году добавилась группа Golang-tools, предназначенная для обсуждения разработки инструментов для взаимодействия с Go.