Этот пост посвящен проблемам общения разработчиков в очередях проблем на drupal.org (Issue queues). Если в начале своего пути, друпаллер не так часто там появляется, то, по мере профессионального роста, вам все чаще придется сообщать об ошибках, постить свои патчи и помогать другим.

Далее мы рассмотрим некоторые сценарии и пути их эффективного разрешения.

#1 Я нашел ошибку в ядре!

Друпал не идеален. Каждый новый релиз приносит с собой 2-3 серьезных исправления и до дюжины мелких.

Довольно немногие знают какова процедура исправления ошибок в ядре. Некоторые слышали что код «заморожен» и это навсегда, некоторые считают что они ничем не могут помочь, некоторые считают что ошибки должен исправлять лично Дрис — словом, ходит много мифов об этом.

Цикл разработки Drupal

Все дороги ведут в HEAD

HEAD-веткой ядра называется ветка, которая в данный момент находится в активной разработке. На сегодняшний день это Drupal 7. Для остальных версий выходят сервис-релизы, в которых лишь латаются дыры и ошибки. Исходя из этого, ваш «патч, с улучшением системы кеширования для шестерки» в лучшем случае переназначат в HEAD.

Теперь вернемся к исправлениям. Почти все баги, которые вы можете найти в системе — наследственны. Это означает, что если баг есть в Drupal 6, он наверняка присуствует и в Drupal 7. Вот почему, если вы запостите заплатку для более ранней версии, вас попросят сперва портировать ее для HEAD, а затем уже каскадно спускать это исправление вниз по версиям.

В остальном же, исправление ошибок в ядре сходно с процессом исправления ошибок в модулях.

#2 Я нашел ошибку в стороннем модуле!

По моим наблюдениям, классические варианты поступков людей в данном случае выглядят так:

Максимально эффективный способ решения проблем с модулями:

Плюсы:

• 100% решение проблемы.
• Отсутствие проблемы в следующих версиях.
• Помощь сообществу.

Минусы:

• Нужно потратить время на все шаги.

#3 Я отправил bug-репорт, но мне никто не отвечает!

Такое бывает в двух случаях — или ваш bug-репорт составлен неправильно и на него никто не удосужился ответить, или вам просто некому ответить (бывает в случае модулей).

Правильный bug-репорт

Начнем с правильного bug-репорта. Он должен состоять из 4 частей — Описания, Шагов повторения, Ожидаемых результатов, Фактических результатов. Вот пример правильного bug-репорт:

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

Шаги повторения:
1. Настроить многоязычный сайт с двумя языками (en+ru).
2. Вынести блок переключения языков на экран.
3. Создать ноду на английском (без перевода).
4. Зайти в эту надо и посмотреть что отображается в блоке переключения языков.

Ожидаемое:
В блоке присутствует ссылка на английскую версию, русский язык отключен.

Фактический результат:
В блоке присутствуют обе ссылки.

По мотивам #518364.

Прекрасным дополнением к такому bug-репорту мог бы быть патч, исправляющий проблему.

Если никто не отвечает, а исправить нужно срочно

Вы можете не получать ответы и по другим причинам:

• Баг может быть некритичным, а у автора много других дел.
• Автор может отдыхать на Мальдивах.
• Автор мог возненавидеть Друпал и перейти на руби.

В любом случае, вы можете стать ко-майнтейнером, получить доступ в CVS-ветку этого модуля и исправить все самостоятельно. Для этого нужно создать тему "Co-maintainership" в issue queue модуля, и если в течение двух недель вам никто не ответит, вы сможете перенести эту ветку в раздел Drupal.org webmasters и администрация drupal.org сама одобрит ваше "усыновление" модуля.

#4 Помогайте решать проблемы

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

#5 Будьте вежливыми

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

via drupaldance.com