This repository has been archived by the owner on Mar 25, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 22
Правила и стандарты ведения проекта Drupal.ru
bumble edited this page Sep 26, 2017
·
15 revisions
- Ведение задач (ISSUES)
- Стандарты реализации / кодирования
- Отправка / Прием Pull Request'ов
-
Прочее
- описание методов и принципов сотрудничества с участниками не касающихся коддинга (дизайнеры, SEO, копирайтеры и пр.)
- Перед подачей ISSUE необходимо ознакомится с уже существующими, возможно такое (или косвенное) уже есть.
- ISSUE обязательно должно касаться проекта Drupal.ru! Любые обсуждения, напрямую не касающиеся вопроса могут быть расценены как флуд.
- В одном ISSUE следует обсуждать только один функциональный момент, или несколько разных моментов завязанных на 1 функционал. Не нужно составлять мультизадачи по решению всего!
- ISSUE должно содержать точное описание проблемы и перечень шагов, в соответствии с которыми проблему возможно воспроизвести. По возможности, должны быть приложены скриншоты / схемы. Старайтесь описать максимально понятными терминами, не стесняйтесь расписывать в мельчайших деталях "как детям" - то что понятно одному человеку, может быть совершенно непонятно другому.
- Желательно, прилагать к ISSUE варианты решения проблемы. Это могут быть PR'ы, патчи, фрагменты кода, описание алгоритма решения проблемы, предположения о причинах проблемы и т.п. Если Вы не уверены, или не обладаете навыками для решения проблемы - укажите это в ISSUE, чтоб другие участники могли предлагать свои решения.
- Будьте вежливыми. Не используйте "нецензурную" лексику, не высказывайте свои недовольства и не пишите ISSUE в формате претензии. Здесь все трудятся исключительно на добровольных началах.
- Если автор ISSUE не является автором идеи - обязательно необходимо указать автора, ссылаясь на его профиль (на аккаунт GitHub, Drupal.ru, Drupal.org или любой другой, с помощью которого можно идентифицировать автора).
- Оставляйте комментарии по делу. Если Ваш комментарий не касается вопроса напрямую - он может быть расценен как флуд.
- Пункт о вежливости при составлении ISSUE касается и комментирования, в той же степени.
- Для внедрения нового или отключения старого функционала, а так же для сбора среза мнений по поводу любых функций ресурса - можно разворачивать небольшие опросы (голосования) в ISSUE.
- Голосование ЗА и ПРОТИВ осуществляется путем оставления реакций на топ или комментарий. 👍 == ЗА | 👎 == ПРОТИВ.
- Голосование можно развернуть в любом ISSUE. Оно должно напрямую относиться к текущему ISSUE и вопросам связанным с ним.
- В топе / комментарии с опросом допускается предложение о голосовании только единого вопроса, трактовка которого может иметь только одно значение! Вопрос должен быть поставлен корректно, ответ на вопрос должен четко выражать позицию голосующих (ДА / НЕТ | ЗА / ПРОТИВ и т.п.)
- Любое подобное голосование не может считаться высшей инстанцией и быть решающим моментом в принятии решении. Это всего лишь сбор мнений на счет конкретного момента.
- Итоговое решение о принятии или отклонении функционала заявленного в опросе принимает тимлид. Тимлид не может отклонить решение, набравшее большинство голосов, без детального описания причин отклонения (проблемы архитектуры, конфликт с другим issue, потенциальная уязвимость и т.п.).
- Реализация функционала представленного в ISSUE распределяется на добровольных основах. Каждый может взяться за реализацию любого открытого ISSUE, у которого нет исполнителя или исполнитель которого просрочил реализацию.
- Для назначения на исполнение ISSUE необходимо выразить свою инициативу, например в комментарии к ISSUE, или связавшись с администраторами проекта любым удобным способом.
- Сроки реализации ISSUE обговариваются с их реализаторами и отображаются (помечаются) на текущих линейках проекта.
- При написании дополнительного функционала (модулей, тем оформления, библиотек и прочего кодового актива) следует руководствоваться стандартами кодирования PSR. В частности PSR-2 и PSR-4.
- Дополнительно, нужно учитывать общепринятые стандарты кодирования Друпал, описанные на Drupal.org.
- Запрещается производить автоматическую стилизацию кода в существующей кодовой базе (
Shift
+Ctrl
+L
в PHPStorm и аналоги в других IDE, автолинтерах и системах CI). Например, в случае доработки функционала существующих темы или модуля. У всех могут быть различные настройки автостилизации кода. Этот пункт позволяет не отображать 90% изменений в оформлении кода, при реально правленной 1й строке. - Предпочтительно, использовать краткий способ объявления массивов.
- Использование символов отличных от латиницы в переводимых строках - запрещено.
- Комментарии классов, методов и функций - обязательно.
- Запрещено комментирование на языках отличных от английского.
- Спорные моменты не вошедшие в текущие правила, можно решить с координаторами проекта.
- Прием и принятие Pull Request'ов осуществляется группой тимлидов проекта.
- Сроки рассмотрения PR'ов не должны превышать одну неделю.
- Причиной отказа и основанием для отправки PR на доработку может служить не соответствие любому из текущих правил.
- Ревьюинг и проверку кода может осуществить любой участник сообщества, с обязательной перепроверкой ответственных тимлидов.
- Сотрудничество с участниками не касающимися коддинга (дизайнеры, SEO, копирайтеры и пр.) осуществляется по предпочтению тимлидов и администрации направления.