Ожидания от участников OSS

Будь то dbt-core, адаптеры, пакеты или сам сайт документации, участие в разработке открытого исходного кода, поддерживающего экосистему dbt, — это отличный способ поделиться своими знаниями, повысить свой уровень как разработчика и внести вклад в сообщество. Цель этой страницы — помочь вам понять, чего ожидать при участии в разработке открытого программного обеспечения (OSS) dbt.

Вы видели что-то в других OSS-проектах, что вам очень понравилось, и думаете, что мы могли бы из этого извлечь уроки? Откройте обсуждение на форуме сообщества dbt или начните разговор в Slack-сообществе dbt (например: #community-strategy, #dbt-core-development, #package-ecosystem, #adapter-ecosystem). Мы всегда рады услышать ваше мнение!

Принципы

Открытый исходный код — это участие

Мы все вместе создаем dbt — будь то написание кода или внесение идей. Используя dbt, вы вкладываетесь в будущее инструмента и играете активную роль в продвижении стандарта аналитической инженерии. Вы уже получаете выгоду от использования кода и документации, внесенных членами сообщества. Участие в сообществе dbt — это ваш способ быть активным участником того, что мы все создаем вместе.

Есть и очень практическая причина: OSS отдает приоритет нашим коллективным знаниям и опыту над опытом одного человека. У нас нет опыта использования каждой базы данных, операционной системы, среды безопасности и т.д. Мы полагаемся на сообщество пользователей OSS, чтобы улучшать возможности нашего продукта и документацию для широкого спектра контекстов, в которых он работает. Таким образом, dbt становится результатом работы тысяч людей, а не нескольких десятков.

Мы серьезно относимся к нашей роли хранителей стандарта

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

Мы также считаем, что dbt как фреймворк должен быть достаточно расширяемым, чтобы "делать простые вещи простыми, а сложные — возможными". В этой связи мы не считаем, что для dbt уместно иметь готовое решение для каждой нишевой проблемы. Пользователи имеют гибкость для достижения многих пользовательских поведений, определяя свои собственные макросы, материализации, хуки и многое другое. Мы считаем своей обязанностью как хранителей решать, когда что-то должно быть "возможным" — через макросы, пакеты и т.д. — и когда что-то должно быть "простым" — встроенным в стандарт dbt Core.

Итак, когда мы скажем "да" новым возможностям для dbt Core? Сигналы, которые мы ищем, включают:

• Голоса за проблемы в наших репозиториях GitHub
• Открытые пакеты dbt, пытающиеся закрыть пробел
• Технические достижения в экосистеме

Тем временем — мы постараемся ответить на новые проблемы с:

• Ясностью о том, входит ли предлагаемая функция в предполагаемый объем dbt Core
• Контекстом (включая ссылки на связанные проблемы)
• Альтернативами и обходными путями
• По возможности, указаниями на код, который может помочь участнику сообщества

Инициатива — это все

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

• Если вы открываете отчет об ошибке, она с большей вероятностью будет идентифицирована.
• Если вы открываете запрос на функцию, он с большей вероятностью будет обсужден.
• Если вы комментируете проблему, взаимодействуя с идеями и связывая ее с вашим собственным опытом, она с большей вероятностью будет приоритетной.
• Если вы открываете PR для исправления выявленной ошибки, она с большей вероятностью будет исправлена.
• Если вы комментируете существующий PR, чтобы подтвердить, что он решает конкретную проблему для вашей команды на практике, он с большей вероятностью будет объединен.

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

Практические аспекты

Обсуждения

Обсуждение лучше всего подходит для предложения Большой Идеи, такой как совершенно новая возможность в dbt Core или адаптере. Любой может открыть обсуждение, прокомментировать существующее или ответить в потоке.

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

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

Проблемы

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

Лучшие практики для проблем

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

Вы нашли существующую проблему, которая вас интересует. Что вам следует сделать?

Прокомментируйте ее! Объясните, что вы столкнулись с той же ошибкой или у вас была похожая идея для новой функции. Если проблема включает подробное предложение об изменении, скажите, какие части предложения вам кажутся наиболее убедительными, а какие вызывают у вас сомнения.

Вы открыли новую проблему. Чего вы можете ожидать?

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

Что если вы открываете проблему в другом репозитории? У нас есть инженерные команды, посвященные активному обслуживанию dbt-core и его компонентных библиотек (dbt-common + dbt-adapters), а также нескольких адаптеров для конкретных платформ (dbt-snowflake, dbt-bigquery, dbt-redshift, dbt-postgres). Мы открыли исходный код для ряда других программных проектов за эти годы, и большинство из них не имеют такой же активности или гарантий обслуживания. Проверьте, есть ли ответы на другие недавние проблемы или когда был добавлен последний коммит в ветку main.

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

• Предполагаемый объем или пользовательский опыт предлагаемой функции требует дальнейшей доработки от хранителя
• Мы считаем, что требуемое изменение кода слишком сложное для внешнего участника

Мы постараемся объяснить открытые вопросы или сложность, и когда / почему мы могли бы предвидеть ее приоритизацию.

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

Метки проблем

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

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

Некоторые из наиболее распространенных меток объяснены ниже:

тег	описание
triage	Это новая проблема, которая еще не была рассмотрена хранителем. Эта метка удаляется, когда хранитель рассматривает и отвечает на проблему.
bug	Эта проблема представляет собой дефект или регрессию от задокументированного поведения
enhancement	Эта проблема представляет собой узкое расширение существующей возможности
good_first_issue	Эта проблема не требует глубоких знаний кодовой базы для реализации и подходит для первого вклада.
help_wanted	Эта проблема сложнее, чем "хорошая первая проблема". Требуемые изменения разбросаны по кодовой базе или их сложнее тестировать. Хранители рады помочь опытному участнику сообщества; они не планируют приоритизировать эту проблему сами.
duplicate	Эта проблема функционально идентична другой открытой проблеме. Хранители закроют эту проблему и призовут членов сообщества сосредоточить обсуждение на другой.
stale	Это старая проблема, которая недавно не обновлялась. В репозиториях с большой активностью устаревшие проблемы периодически закрываются.
wontfix	Эта проблема не требует изменения кода в репозитории, или хранители не хотят объединять изменение, которое реализует предложенное поведение.

Pull-запросы

Каждый PR должен быть связан с проблемой. Почему? Прежде чем вы потратите много времени на работу над вкладом, мы хотим убедиться, что ваше предложение будет принято. Вы должны сначала открыть проблему, описав желаемый результат и наметив планируемое изменение. Если вы нашли старую проблему, которая уже открыта, прокомментируйте ее с планом вашей реализации до того, как начнете работу над открытием pull-запроса.

PR должны включать надежное тестирование. Комплексное тестирование в рамках pull-запросов имеет решающее значение для стабильности dbt. Приоритетное внимание к надежному тестированию обеспечивает надежность нашей кодовой базы, минимизирует непредвиденные проблемы и защищает от потенциальных регрессий. Мы не можем объединять изменения, которые могут привести к несовместимости с задокументированными поведениями. Мы понимаем, что создание тщательных тестов часто требует значительных усилий, и ваша приверженность этому процессу значительно способствует общей надежности проекта. Спасибо за вашу приверженность поддержанию целостности нашей кодовой базы и опыта всех, кто использует dbt!

PR проходят два этапа проверки. Сначала мы стремимся ответить с отзывом о том, считаем ли мы реализацию подходящей с точки зрения продукта и удобства использования. На этом этапе мы закроем PR, которые, по нашему мнению, выходят за рамки dbt Core или могут привести к несогласованному пользовательскому опыту. Это важная часть нашей роли как хранителей; мы всегда открыты для обсуждения несогласия. Если PR проходит этот первый этап проверки, мы ставим его в очередь на кодовую проверку, на этом этапе мы стремимся протестировать его сами и предоставить тщательный отзыв.

Мы получаем больше PR, чем можем тщательно проверить, протестировать и объединить. Наши команды имеют ограниченные возможности, и наш главный приоритет — поддержание хорошо определенного, высококачественного фреймворка для десятков тысяч людей, которые используют его каждую неделю. В этой связи мы должны отдавать приоритет общей стабильности и запланированным улучшениям над длинным хвостом нишевых потенциальных функций. Для достижения наилучших результатов укажите, на что именно вы хотели бы получить отзыв, и объясните, что значило бы для вас, вашей команды и других членов сообщества, если бы предложенное изменение было объединено. Меньшие PR, решающие хорошо определенные проблемы, как правило, легче и быстрее проверяются. Два примера PR, внесенных сообществом:

• (dbt-core#9347) Исправление конфигурации превращения предупреждений теста в ошибки
• (dbt-core#9863) Улучшенное сообщение об ошибке при попытке выбрать отключенную модель

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

• Тесты, тесты, тесты. Когда вы открываете PR, запускаются некоторые тесты и проверки кода. (По соображениям безопасности некоторые из них могут потребовать одобрения хранителя.) Мы не будем объединять PR с неудачными тестами. Если вы не уверены, почему тест не проходит, пожалуйста, скажите об этом, и мы постараемся разобраться в этом вместе.
• Соглашение о лицензировании участников (CLA): Это гарантирует, что мы можем объединить ваш код, не беспокоясь о неожиданных последствиях для авторских прав или лицензии на программное обеспечение с открытым исходным кодом dbt. Для получения более подробной информации прочитайте: "Соглашения о лицензировании участников"
• Журнал изменений: В проектах, которые включают ряд изменений в каждом выпуске, нам нужен надежный способ сигнализировать о том, что было включено. Механизм для этого будет варьироваться в зависимости от репозитория, поэтому следите за примечаниями о том, как обновить журнал изменений.

Включение в версии релизов

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