вт, 13/11/2012 - 00:23
Категория задачи:
- функционал сайта
Статус:
- приостановлено
Как тот или иной модуль, написанный сообществом, становится известен другим?
Каждый друпалер, прежде чем кинуться писать свой модуль, пытается найти что-то в репозитарии. Но реально там найти что либо сложно. Из каких-то эзотерических соображений он настраивает фильтр, в том что найдено, пытается из скупых описаний автора понять, что же делает модуль, после чего скачивает и ставит модуль, активирует его и достаёт бубен.
Например, однажды мне понадобилось реализовать следующее: есть родительская нода, типа А (условно альбом). И есть дочерние ноды, типа Б (условно песни в нем) . И альбом должен содержать поле - выпадающий список, где источник - все песни этого альбома.
По фильтру "relate" на drupal.org выпало 989 модулей. Я установил, разобрался в работе, и удалил около 20 модулей, ибо по описанию понять принцип работы невозможно. То есть я изучил работу 20-ти модулей, имеющих примерно одинаковое название, и схожий функционал. Методом тыка. Сейчас я, уже забыл, кто из них и как работает, а это обидно.
Суть предложения:
создать структуру, аналогичную репозитарию drupal.org.
в неё, каждый, кто установил модуль, и разобрался с помощью бубна, как он работает, где какие настройки имеет, что они означают, и т д, пусть не до конца, может добавить человеколюбивую инструкцию по работе с модулем.
Ведь кроме нескольких широкоизвестных модулей, нет нигде руководства, что делает модуль, и как с ним бороться. Есть скупое описание на английском, и в лучшем случае перевод его же на русский.
Комментарии
Проще говоря, это призыв: "Вы
Проще говоря, это призыв: "Вы же ставили такой-то модуль, долго разбирались зачем он нужен, что умеет и как работает. Расскажите остальным!"
согласен. не помешали бы
согласен. не помешали бы статьи из разряда Cookbook/Best practice. с описанием модулей/связок из модулей для решения задачи. Таким образом, можно сделать примерно такую цепочку:
каталог типовых задач -> варианты решения (модули, которые понадобятся) -> описание модуля.
По фильтру "relate" на drupal
Этот вопрос тоже поднимал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 (до сих пор не найду, чей это труд:). Но там недостаточно комментариев, что бы понять, как установить или настроить некий модуль. В общем - мотив в этих примерах понятен - кто-то для себя пишет, что бы не забыть, а кто-то для трафика. Может еще какие варианты, которые я упустил.
А вот в нашем случае? Будут ли участники сообщества старательно заполнять бубны? Именно не один-два, а постоянно. Т.е. системно.
Пока сомневаюсь. Но думаю, пробовать надо. Тем более, что технически этот сервис реализовать не сложно.
Сам готов позаполнять этот контент тип, чтобы посмотреть, что получится.
А что должно произойти, чтоб
А что должно произойти, чтоб данный функционал на сайте появился? Если все, включая разработчиков сайта, ЗА ?
А что должно произойти, ...
Инициатор этого проекта, т.е. Вы, должен сообщить участникам: - сам он будет это все настраивать, или делегирует это кому-то другому.
Наверно так, если я Вас правильно понял.
Может кто-то из участников меня поправит или предложит свое решение?
Я думаю нужно начать писать
Я думаю нужно начать писать что-то с блогов. Когда количество таких постов-описаний модулей превысит количество постов другого содержания в каком-то разумном промежутке времени, тогда можно будет продолжить разговор о вынесении таких постов в отдельную секцию на сайте.
Давайте лучше подумаем, как нам улучшить блоги, чтобы участники туда писали?
Структурированный список
Структурированный список описаний работы модулей куда лучше блога, который проще вести на собственном сайте... Как мне кажется, наполнение его будет более успешным.
И такой раздел, куда удобнее для посетителей в плане доступа к информации.
Nestelus, глубоководное
Nestelus, глубоководное исследование!
Я так скажу, для начала надо разрешить пользователям добавлять картинки и embed-видео в текст блога :) Заливать что-то на imgur, потом вставлять сюда — это утомит даже самого упёрного бубенщика :)
Далее стоит написать пару таких статей-«бубнов». Т.е. начать с какого-то содержимого, чтобы понять какое оно вообще будет.
Классная мысль, kalabro.
Классная мысль, kalabro.
О картинках надо отдельно думать ибо:
1) Картинки требуют дискового пространства и оно не бесконечно.
2) Хранение картинок на том же серваке увеличивает количество запросов к серваку.
А давайте создадим отдельную инициативу, типа "Улучшить редактор для блогов", где каждый, кто столкнулся с теми или иными трудностями при написании постов в блог, сможет написать об этом и/или предложить свой вариант решения проблемы.
Да, и канал опять же
Да, и канал опять же загружается... Но при теперешней нагрузке, проблем быть не должно бы. И очень большим сообщество масштаба города всё же не станет.
А загрузка изображений на внешние ресурсы издевательство над авторами, которых надо всячески мотивировать, а не вставлять палки в колёса.
Спасибо за ваше мнение!
Спасибо за ваше мнение! Некоторое время назад включили загрузку картинок. Если не работает, то сообщите.
Могу предложить возможность
Могу предложить возможность добавить тег "Бубен" к статьям на сайте сообщества. Когда таких статей станет достаточное количество, думать о отдельном разделе.
Я считаю, что тег должен быть
Я считаю, что тег должен быть «обзор модуля» или «инструкция к модулю», а никак не бубен :)
Может организовать поддомен,
Может организовать поддомен, типа Вики движка с описаловом модулей?
Статьи с тегами не требуют
Статьи с тегами не требуют дополнительных усилий на администрирование. Отдельный сайт, особенно вики, требует адских усилий на модерацию и администрирование.
Но если ты готов взяться за отдельный домен, то можем обсудить детали?
Я в инете нашел информацию, в
Я в инете нашел информацию, в которой в завуалированной форме объясняется необходимость написания собственных модулей, и о смысле данной инициативы.
Приостановил, так как, на
Приостановил, так как, на сколько мне известно, работа по этой инициативе не идет.