Проект "Бубен" : Инструкции к модулям
Как тот или иной модуль, написанный сообществом, становится известен другим? Каждый друпалер, прежде чем кинуться писать свой модуль, пытается найти что-то в репозитарии. Но реально там найти что либо сложно. Из каких-то эзотерических соображений он настраивает фильтр, в том что найдено, пытается из скупых описаний автора понять, что же делает модуль, после чего скачивает и ставит модуль, активирует его и достаёт бубен. Например, однажды мне понадобилось реализовать следующее: есть родительская нода, типа А (условно альбом). И есть дочерние ноды, типа Б (условно песни в нем) . И альбом должен содержать поле - выпадающий список, где источник - все песни этого альбома. По фильтру "relate" на drupal.org выпало 989 модулей. Я установил, разобрался в работе, и удалил около 20 модулей, ибо по описанию понять принцип работы невозможно. То есть я изучил работу 20-ти модулей, имеющих примерно одинаковое название, и схожий функционал. Методом тыка. Сейчас я, уже забыл, кто из них и как работает, а это обидно.
Суть предложения: создать структуру, аналогичную репозитарию drupal.org. в неё, каждый, кто установил модуль, и разобрался с помощью бубна, как он работает, где какие настройки имеет, что они означают, и т д, пусть не до конца, может добавить человеколюбивую инструкцию по работе с модулем.
Ведь кроме нескольких широкоизвестных модулей, нет нигде руководства, что делает модуль, и как с ним бороться. Есть скупое описание на английском, и в лучшем случае перевод его же на русский.
Комментарии
Проще говоря, это призыв: "ВыПроще говоря, это призыв: "Вы же ставили такой-то модуль, долго разбирались зачем он нужен, что умеет и как работает. Расскажите остальным!"
согласен. не помешали бысогласен. не помешали бы статьи из разряда Cookbook/Best practice. с описанием модулей/связок из модулей для решения задачи. Таким образом, можно сделать примерно такую цепочку: каталог типовых задач -> варианты решения (модули, которые понадобятся) -> описание модуля.
По фильтру "relate" на drupalПо фильтру "relate" на drupal.org выпало 989 модулей. Я установил, разобрался в работе, и удалил около 20 модулей, ибо по описанию понять принцип работы невозможно. То есть я изучил работу 20-ти модулей, имеющих примерно одинаковое название, и схожий функционал. Методом тыка. Сейчас я, уже забыл, кто из них и как работает, а это обидно.
Этот вопрос тоже поднималcя на Кафе. В частности мной :) Есть раздел у лулаботов — Module Monday. Это безусловно не исчерпывающая база по контриб-модулям, но очень респектабельная. То, что одобрил Jeff Eaton, однозначно заслуживает внимания и доверия (на мой взгляд). Всё, что нужно, чтобы создать такую же базу — разобраться в модуле, снять 1-2 скриншота, написать не очень длинный рассказ или заснять видюху и запостить в блог с тегами «Модули», «7.x» :)
Пытаться спарсить все модули с d.org и что-то как-то отсортировать, мне кажется, бессмысленно. Модулей слишком много. Мы просто не найдём столько ресурсов, чтобы все это описать, классифицировать и оценить.
весь за данную затею :-)весь за данную затею :-) to kalabro я думаю что тут не имелось ввиду описание прям всех модулей с д.орг, а только те которые совсем не очевидны в настройках и использовании и которые попались сейчас человеку из нашего сообщества и у него есть время написать об этом тут, так сказать маленькая база хау ту :-) со своей стороны, как сделаю helpdesk без использования maestro обязательно сделаю доклад что к чему. Если всё таки сделаю. :-)
Для реализации пилотнойДля реализации пилотной версии проекта «Бубен», на мой взгляд, необходимо следующее: 1. Словарь «Модули» 2. Словарь таксономии «Разделы». 2.1. Заполнить разделами с drupal.org 3. Словарь «Ветки». Значения «6», «7», «8» 4. Создать тип содержимого «Бубен». Поля: 4.1. Название 4.2. Ссылка на термин «Модуль». Обязательное поле. Автодобавление ввода. Создание нового термина. 4.3. Ветка. Обязательное. Флаг. Модуль может быть для всех веток, но бубен для какой-то одной. 4.4. Ссылка http на страницу модуля drupal.org 4.5. Ссылка http на страницу модуля drupaler.ru 4.6. Поле «Зависимость» - ссылки на словарь модулей. Многозначное. Только на существующие термины. 4.7. Текстовая область «Применение» для описания ситуации, в которой автору потребовался этот модуль 4.8. Текстовая область «Установка» с текстом по умолчанию: «Скачайте файлы в нужное место, отметьте галочку на странице модулей, нажмите «Сохранить»». В это поле автор добавляет особенности установки, если такие есть. 4.9. Текстовое поле «Изменение». Многозначное. Сюда нужно надо указывать путь к страницам, где появились изменения. Например: Конфигурация – Правила – Import Rule 4.10. Текстовая область «Настройка». Сюда надо описывать все галочки и птички, где их найти, на что они влияют, что означают, и т д при настройке модуля. 4.11. Текстовая область «Использование». Здесь описание работы модуля, с точки зрения пользователя. 4.12. Галерея скриншотов. Пронумерованная. Для ссылок на них из текстов описания. 5. View «Бубен» - как главная страница сервиса. На ней должно быть некое описание, фильтры по веткам, разделам и названиям модулей, и ссылочный список бубнов, по соответствующим запросам. 6. View «Бубен» - как блок ссылок на бубны того же модуля, что и текущий. 7. View «Бубен» - как блок ссылок на бубны того же раздела, что и текущий. 8. Раздать права зарегистрированным пользователям на создание бубнов. 9. Дать возможность комментировать бубны. Где-то так.
Что скажете?Nestelus, лично мне все понятно. Дело нужное. Как это реализовать на сайте - достаточно подробно по пунктам описано. Но.
На мой взгляд, не решен главный вопрос: каков мотив у участников сообщества заполнять подобные документы? Ведь это что-то вроде отчета. Личное время, членораздельные формулировки, скриншоты. В общем - немалый труд. Да плюс еще последующие комментарии к написанному.
Я так же согласен с kalabro:
Понятно, что не нужно описывать все модули, а только те, где недостаточное или не понятное описание на drupal.org, или в readme.txt модуля. И то - только по мере получения личного опыта.
Если посмотреть вокруг - то похожие вещи веб-разработчики пишут в своих блогах. А кто-то пишет целые обзорные статьи/инструкции к конкретным модулям. Или вот, к примеру, переводы модулей content-management-systems.info/drupal/project (до сих пор не найду, чей это труд:). Но там недостаточно комментариев, что бы понять, как установить или настроить некий модуль. В общем - мотив в этих примерах понятен - кто-то для себя пишет, что бы не забыть, а кто-то для трафика. Может еще какие варианты, которые я упустил.
А вот в нашем случае? Будут ли участники сообщества старательно заполнять бубны? Именно не один-два, а постоянно. Т.е. системно. Пока сомневаюсь. Но думаю, пробовать надо. Тем более, что технически этот сервис реализовать не сложно. Сам готов позаполнять этот контент тип, чтобы посмотреть, что получится.