Skip to content
This repository has been archived by the owner on Mar 25, 2019. It is now read-only.

Правила и стандарты ведения проекта Drupal.ru

Jump to bottom
bumble edited this page Sep 21, 2017 · 15 revisions

Секции*:

Свод**:

Ведение задач (ISSUES)

Правила подачи ISSUE

  • Перед подачей 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. В частности PSR-2 и PSR-4.

Соответствие стандартам кодирования Drupal.org.

Реализация спорных моментов

  • Запрещается производить автоматическую стилизацию кода в существующей кодовой базе (Shift + Ctrl + L в PHPStorm и аналоги в других IDE, автолинтерах и системах CI). Например, в случае доработки функционала существующих темы или модуля. У всех могут быть различные настройки автостилизации кода. Этот пункт позволяет не отображать 90% изменений в оформлении кода, при реально правленной 1й строке.
  • Предпочтительно, использовать краткий способ объявления массивов.
  • Использование символов отличных от латиницы в переводимых строках - запрещено.
  • Комментарии классов, методов и функций - обязательно.
  • Запрещено комментирование на языках отличных от английского.
  • Спорные моменты не вошедшие в текущие правила, можно решить с координаторами проекта.

Отправка / Прием Pull Request'ов

Ответственные за прием PR

  • Прием и принятие Pull Request'ов осуществляется группой тимлидов проекта.

Cроки рассмотрения Pull Request'ов

  • Сроки рассмотрения PR'ов не должны превышать одну неделю.

Причины отказа / основания для отправки на доработку

  • Причиной отказа и основанием для отправки PR на доработку может служить не соответствие любому из текущих правил.

Ревьюинг кода

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

Прочее

  • Сотрудничество с участниками не касающимися коддинга (дизайнеры, SEO, копирайтеры и пр.) осуществляется по предпочтению тимлидов и администрации направления.
  • * Предложить свои секции и подсекции можно в ISSUE.
  • ** Предложить свои правила и принципы можно в ISSUE

Clone this wiki locally