Вклад в Glarus BI¶
Спасибо¶
Во-первых, спасибо за ваш интерес к Glarus BI и за желание внести свой вклад!
В этом руководстве мы обсудим, как создаётся Glarus BI. Это должно дать вам хорошее представление о нашем процессе и о том, где вы, возможно, захотите помочь.
В общем, мы бы хотели иметь открытую задачу для каждого запроса на включение (PR), которую можно использовать как место для обсуждения характера любой ошибки или предлагаемого улучшения. Каждый PR должен решать одну проблему и содержать как исправление, так и описание PR, а так же тесты, подтверждающие, что PR устраняет рассматриваемую проблему.
Чтобы исправить ошибку, отправьте PR для целевой ветки master. Время от времени наша команда будет переносить выбранные исправления критических ошибок в стабильную/релизную ветку.
Ожидается, что важные добавления функций будут обсуждаться в прикрепленной задаче. Любая функция, требующая серьезного решения, должна иметь письменную спецификацию. Целью этой спецификации является четкое изложение допущений, ограничений и компромиссов, которые будут содержаться в реализации любой конкретной функции. Суть не в том, чтобы создать документацию, а в том, чтобы дискуссия прошла в контексте обсуждаемого дизайна и позволила другим участникам рассмотреть потенциальные последствия.
Лицензионное соглашение участника¶
Нам не нравятся судебные иски, поэтому перед слиянием любого запроса на включение нам потребуется, чтобы каждый человек, добавляющий код, подписал Лицензионное соглашение участника.
Что мы пытаемся построить¶
Glarus BI предназначена для того, чтобы позволить нетехническим пользователям получить доступ к данным своей организации. Мы пытаемся максимально увеличить гибкость инструмента, который может с комфортом использовать тот, кто хорошо разбирается в своём бизнесе, склонен к анализу количественных показателей, но, вероятно, чувствует себя комфортно только с Excel.
Важно помнить об этих целях проекта Glarus BI. Достаточно часто предложения по новому функционалу будут помечены как «Out of scope» и таким образом будут лишены приоритета в разработке. Это не означает, что предложение бесполезно или что мы не заинтересованы в его реализации в качестве побочного проекта или экспериментальной ветки. Однако это означает, что в ближайшем будущем мы не будем привлекать к этой разработке основную команду или ключевых участников. Функционал, который немного выходит за цели проекта Glarus BI, будут оставаться открытым в случае если сообщество решит оказать поддержку данной разработке.
Чтобы понять конечные цели, обязательно прочитайте Дзен Glarus BI.
Наш производственный процесс:¶
Основная команда работает по довольно чётко определённому производственному процессу. Он активно дорабатывается, но ниже приведено довольно точное его описание на момент написания. Вы должны иметь четкое представление о том, как мы работаем, прежде чем приступать к PR.
A) Определите потребности сообщества в продуктах¶
Мы активно ищем идеи новых функций от нашего сообщества, пользовательской базы и на основе нашего собственного внутреннего использования Glarus BI. При этом мы концентрируемся на проблеме или потребности, а не на запросах конкретных функций. Хотя иногда предлагаемые функции создаются по запросу, часто мы обнаруживаем, что они включают изменения в существующие функции и, возможно, предполагают совершенно другое решение основной проблемы. Обычно они собираются в группы и помечаются как Proposal
B) Синтезируйте эти потребности в конкретную функцию¶
Обычно мы собираем группу проблем или предложений в новую концепцию основных функций. При этом мы создаем рабочий документ, в котором собраны все «открытые запросы» относительно того, что функция должна делать и (что более важно) не делать. Мы будем общаться с нашими пользователями, возможно, проведем подробные интервью и в целом попытаемся четко определить функцию. Если кажется, что функция требует времени для обсуждения и масштабирования, она будет помечена как Предложение/Обсуждается, чтобы обозначить, что он Всё ещё активно обсуждается.
C) Разработайте функцию¶
Как только функция определена, обычно её берет на себя дизайнер продукта. Он создаст макеты, получит отзывы от наших пользователей и сообщества и выполнит несколько итераций своей работы.
После того, как основные потоки UX будут определены, появится высококачественный визуальный дизайн.
Готовые к дизайну функции отмечаются тегом Требуется дизайн. После того, как функция имеет достаточно завершённый визуальный дизайн, она должна быть помечена как Требуется помощь.
D) Создайте функцию¶
Как только функция помечена как Требуется помощь, она считается готовой к разработке. Член основной команды (или вы, невероятно полезный человек) можете начать над этим работать.
Если вы создаёте что-то, что пользователи увидят в Glarus BI, обратитесь к Руководству по стилю (находится по адресу https://storybook.metabase.com), чтобы узнать, как и когда использовать различные элементы пользовательского интерфейса Glarus BI.
Как только один или несколько человек начали работать над функцией, она должна быть помечена как В процессе. Как только появляется ветка разработки и некоторый код, открывается PR, связанный с функцией и с любыми задачами по этой разработке, которые были собраны вместе.
E) Проверка и слияние¶
Все PR, которые включают более чем незначительное изменение, должны быть просмотрены и проверены. См. наш Процесс проверки кода.
Если все идет хорошо, функция кодируется, проверяется, а затем PR вливается в основную ветку! На этом разработка заканчивается.
Если в PR отсутствуют тесты, есть проблемы со стилем кода или определённые архитектурные проблемы, их следует исправить перед слиянием. У нас очень высокая планка как кода, так и качества продукта, и важно, чтобы она сохранялась в будущем, поэтому, пожалуйста, будьте терпеливы с нами.
Способы помочь¶
Отправной точкой было бы знакомство с продуктом Glarus BI. Если вы используете его на работе, это здорово! Если нет, скачайте Glarus BI и поэкспериментируйте с ним. Прочтите документы и в целом получите представление о сути продукта.
Вот несколько способов, которыми вы можете помочь, в порядке увеличения координации + взаимодействия с нами:
Помощь в определении потребностей и проблем, которые может решить Glarus BI¶
Если вы хотите помочь, попробуйте Glarus BI. Используйте его в своей компании и сообщайте о том, что вам нравится, не нравится и о любых проблемах, с которыми вы сталкиваетесь. Помогите нам понять вашу модель данных, требуемые метрики и общие шаблоны использования. Эта информация напрямую влияет на качество продукта. Чем больше вы расскажете нам о проблемах, с которыми вы сталкиваетесь, тем лучше мы сможем их решить.
Помогите нам провести сортировку и поддержите других пользователей¶
Потратьте время на discourse.metabase.com и на указанные проблемы и попытайтесь воспроизвести обнаруженные ошибки. Если у вас есть знания, помогите людям, у которых есть проблемы с базами данных, о которых вы знаете. Кто знает, может, в будущем они вам тоже чем-то помогут.
Полезно, если вы понимаете нашу структуру расстановки приоритетов.
Расскажите своим друзьям¶
Расскажите своим друзьям о Glarus BI. Создайте группу пользователей в вашем регионе. Твитнуть о нас. Ведите блог о том, как вы используете Glarus BI, и делитесь тем, что вы узнали.
Исправление ошибок¶
По нашему определению, «ошибки» — это ситуации, когда программа не делает того, что от неё ожидалось в соответствии с функционалом или спецификацией. Обычно они относятся к ситуациям, для которых существует четко определённое правильное поведение. Вы можете взять ошибку, исправить её и отправить PR (с тестами!). Они будут объединены без особых проблем, если только PR не коснется большого объема кода. Не обижайтесь, если мы попросим вас внести небольшие изменения или добавить больше тестов. У нас немного обсессивно-компульсивное расстройство в отношении покрытия кода тестами и стиля кодирования.
Помощь с документацией¶
Есть много документов, а это означает, что поддерживать их в актуальном состоянии сложно. Если вы заметили несоответствия, ошибки или устаревшую информацию, пожалуйста, помогите нам поддержать актуальность документации!
Обратите внимание, что в настоящее время мы не можем принимать переводы для документации. Мы поддерживаем переводы в приложении и поддерживаем только языки со 100% охватом. Но 1) текст в приложении на несколько порядков короче нашей документации, 2) он меняется медленнее, и 3) нам помогает много людей. Мы можем рассмотреть возможность поддержки документации на нескольких языках в будущем, но сейчас нам нужно сосредоточить наши ресурсы на улучшении нашей существующей документации (и расширении ее, чтобы включить все новые функции, которые мы добавляем).
Работа над функциональностью¶
Некоторые элементы, например драйверы базы данных, не имеют конкретного пользовательского представления. Поэтому разработка драйверов может быть отличным стартом: она не потребует долгих обсуждений, нахождения компромиссов и чёткого следования процессу.
В ситуациях, когда дизайн уже сделан, мы всегда готовы воспользоваться вашей помощью. Обратитесь к PR или к комментариям к задаче и предлагайте помощь.
Вообще говоря, любая проблема, помеченная Требуется помощь подходит для работы.
#YOLO ПРОСТО ДОБАВЬТЕ PR¶
Если вы придумали что-то действительно классное и хотите поделиться этим с нами, просто отправьте PR. Если он не прошел через описанный выше процесс, мы, вероятно, не объединим его как есть, но если он убедителен, мы более чем готовы помочь вам с помощью проверки кода, проверки дизайна и, как правило, не будем слишком сильно придираться, чтобы он соответствовал остальной части нашей кодовой базы.