Это продолжение статьи Как скачать модуль с Drupal.org и не облажаться: Часть I.

Кроме текстового описания и файлов для загрузки страница модуля на Drupal.org содержит много полезной информации и инструментов, о которых многие даже не догадываются.

5. Issue queue [ишью кью] — встроенный баг-трекер на Drupal.org с поддержкой версий, статусов и поиска.

Количество открытых запросов в Issue queue модуля само по себе ничего не говорит.
Перед скачиванием нужно открыть и просмотреть список багов и убедиться, что они, во-первых, своевременно исправляются и не висят годами в трекере, и, во-вторых, что на данный момент нет открытых багов, которые совершенно точно помешают вам работать с модулем.
Если эти условия не выполняются, то см. Часть III «Я не уверен в модуле».

6. Документация

Если разработчик модуля что-то написал не на php, а на человеческом языке, то это обязательно к прочтению. Закон. Не шутите с законом.
Написать документацию к модулю — это настоящий подвиг, друзья! Я бы ссылку “Read documentation” для таких модулей сделала <h2> красным цветом. 80% ваших вопросов отпадёт, если вы пролистаете информацию на странице проекта, документацию и README.txt.

7. Демо

Демки обычно живут на поддоменах сайтов авторов. Я думаю, не за горами какой-нибудь стартап на эту тему.
Очень полезно бывает посмотреть на работающий модуль в том виде, в котором его предполагает использовать сам разработчик.
Если ссылки “Try out a demonstration” нет, можно запустить модуль на http://simplytest.me/, однако там его придётся устанавливать и настраивать самому.

8. Аналогичные и родственные проекты

В самом низу правого сайдбара иногда можно найти блок “Related projects”. Возможно, именно там вы найдёте недостающий пазл для вашего сайта.

9. Описание проекта

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

10. Ссылки для разработчиков

Ещё один полезный блок в правом сайдбаре любого проекта:

Ссылка “Repository viewer” позволяет просмотреть структуру и код проекта ещё до скачивания. Для некоторых разработчиков, которые код читают быстрее, чем английский текст, это экономит время. Я в том числе отношусь к этой категории людей и не скачиваю ничего нового, не заглянув в Repository viewer.

Там можно прочитать README.txt, INSTALL.txt и .info файл.

View change records — это нововведение, позволяющее каждому проекту на Drupal.org вести свой Changelog наподобие https://drupal.org/list-changes. Вероятно, ссылка должна помогать при переезде с 7‑ки на 8‑ку. Будет ли кто-то из разработчиков писать эти change records, я не знаю.

11. Release Notes

Зато я наверняка знаю, что авторы модулей заполняют полезной информацией обязательное поле Release Notes (11) при создании следующего релиза проекта на Drupal.org. Туда стоит заглядавать и при обновлении, и при первой установке модуля.

12. Тесты тяжело писать, тяжело поддерживать, тяжело запускать.

Но не тяжелее, чем каждый раз вручную пытаться полностью протестировать свой модуль. Поэтому если среди файлов модуля вы нашли что-то с расширением .test, это большой плюс.

Что ж, мы рассмотрели основные критерии качества проекта на Drupal.org, по которым можно оценить модуль ещё до скачивания и установки на сайт.

В третьей части я расскажу, что делать, если модуль всё-таки нужен, но он выглядит недостаточно надёжно.

А пока можно почитать Часть I и подискутировать в комментариях.