KoltsoDevelopment
Материал из KoltsoWiki
Содержание |
[править] Вики разработчиков Кольца
Цель проекта Кольцо: создание иструмента координации людей, идей, ресурсов для реализации общественно-полезных проектов.
[править] Команда создателей Кольца
- Mikail - автор и разработчик проекта. ahundov гав gmail.com, ICQ: 16557175
- Frankenstein - программист с западной Украины. Delphi, PHP, HTML, MySQL, Corel, Photoshop, Flash. ICQ: 217643068, 996216. Опыт поддержки клиентов. E-mail: admin (at) retromusic.te.ua
- UserAd - программист и сисадмин. Rails Ruby MySQL, icq: 125042506, jabber: userad@jabber.ru, googletalk: userad@gmail.com. mail: userad@gamil.com, Skype: wind0wMaker
Кто нужен:
- Умеющие юзабилити
- Умеющие дизайн
- Умеющие Java, JBOSS Seam
- Умеющие postgres
- Опытные программисты-архитекторы
Записывайтесь в команду и, пожалуйста, указывайте свои координаты. Мы будет благодарны любому замечанию и совету.
[править] Базовые компоненты системы
[править] Участник
Несколько участников могут объединиться в группу с образованием комьюнити. Один участник может быть в нескольких комьюнити, может не быть ни в одном.
В системе должна присутствовать служба личных сообщений. Должна быть реализована возможность поиска участника по имени, нику и интересам.
У каждого участника ключевыми словами описываются отдельно интересы, умения и потребности.
Идентификационный номер участника - UUID. (QQ как в распределенной системе хранить инфу о соответствии человека и учетной записи?)
[править] Коммьюнити
[править] Ресурс
Ресурсы могут объединяться в группы.
Ресурс описывается ключевыми словами.
[править] Проект
Проекты могут объединяться в группы, также возможна связь на родительский проект и другие родственные проекты.
Предлагаю все-таки сделать только Проект без деления на Проект и Задачу. Но Проект будет иметь два состояния - Узловой или Обычный. У каждого Проекта только один ответственный Реализатор, а Админов может быть несколько. Узловыми Проектами будем называть то, что мы называли "Проектами", Обычными Проектами будет называться то, что мы называли "Задачами".
ИМХО автор Проекта - это ее первый Админ. А тот, кто реализует Проект - Реализатор.
Таким образом в Каталоге Идей будут лежать Проекты и Узловые/Обычные, все с Админом (автором) или несколькими, но все без добровольца-Реализатора.
Создавая новый Проект, чтобы поместить его в Каталог Идей, автор может прописать в свойствах Проекта - будет ли он Админом Проекта, когда за Проект возьмется Реализатор-доброволец и сможет ли Реализатор стать Админом.
У Проекта в Каталоге Идей могут быть следующие состояния
- Автор отказывается от прав Админства, тогда Реализатор-доброволец становится Админом Проекта
- Автор указывает, что он будет Админом Проекта. Реализатор-доброволец тоже становится Админом.
- Автор указывает, что он будет Админом Проекта. Реализатор-доброволец не сможет стать Админом.
Также каждый Админ может запрещать или разрешать другим участникам Кольца создавать подПроекты к своему Проекту.
Когда запустим Кольцо первым настоящим проектом будет проект развития самого Кольца (замыкаем рекурсию). подПроект - создание Кольца 0.2 и т.д. =)
Ссылка - создать новый проект - ярко выделена и висит на видном месте на всех страницах проекта (предложение такое мое)
Название проекта на всех страницах Кольца обрабатывается аналогично ЖЖ с ее тегом <lj-user=""> и имеет соотв иконку перед названием.
Форум и обязательно Блог включены перманентно
//можно также указывать, окончание какой задачи служит сигналом к началу выполнения данной задачи
//сигнал о возможности начала реализации (если хотя бы одна из задач, которая служит необходимым условием для реализации данной, не выполнена, то сигнал "красный", если выполнены 80% или более, то "желтый", если все, то сигнал "зеленый")
//Статусы реализации: формальный: реализация не начата, реализация идет в пределах срока, реализация идет с отставанием от графика, выполнено; оценка ответственным за задачу хода ее реализации на данный момент в процентах - если выполнение идет непропорционально сроку, то высвечивается предупреждающий сигнал, в том числе и на табло задач на странице проекта
Для выполненной задачи - ссылка на отчетную страницу, где есть итоговый комментарий ответственного за задачу и ссылки на файлы с отчетными, итоговыми документами, выработанными как результат задачи материалами. После выполнения задачи на странице тех задач, для которых выполнение данной задачи служит необходимым условием начала их выполнения, отображается факт выполнения данной задачи и приводятся ссылки на отчетную страницу данной задачи (выполнивший задачу в процессе оформления завершения задачи вызывает модуль создания отчета, где в числе прочих есть опция загрузки файлов с текстовым пояснением "добавить файл").
//Создает новую задачу модератор либо участник, которому для выполнения его задачи нужно выполнение другой задачи. Предложение ответственного осуществляется модератором или исполнителем другой задачи (предложений может быть несколько); окончательное утверждение осуществляется либо тем, кто согласится и тем самым утвердит себя; либо модератором проекта (в зависимости от настроек проекта – кто может утверждать ответственных за задачу, только модератор проекта или согласившийся участник). После утверждения ответственного модераторские права на задачу переходят к нему.
Могут ли участники создавать две параллельные реализации одного проекта? (QQ)
Нет, нет и еще раз нет! Это пустая трата ресурсов на глупую конкуренцию. Эта ситуация должна разруливаться в пользу проекта, который был создан ранее.
Возможно будет необходима модерация списка проектов с целью поиска повторяющихся идей и сведением интересующихся участников в единое "русло"? (QQ) Искать повторяющиеся проекты должны сами учасники. Должен быть предусмотрен алгоритм удаления дублирования.
В Проекте отдельно описывается ключевыми словами описание проекта, его потребности и то, что он дает.
[править] Wiki
Namespaces: ИМХО нужно доработать движок вики, чтобы мы могли создавать два вида ссылок. Ссылки на объекты только внутри вики страниц приписанных к конкретному проекту и ссылки на объект общие для всех страниц вики Кольца. Например ссылка-1"тротил" будет вести на страницу описывающую конкретный тротил для конкретного проекта, а ссылка-2"тротил" будет вести на общую страницу "тротил" с вики-страниц всех проектов Кольца. Различать их можно иконкой перед каждой вики-ссылкой, как это делается в ЖЖ с ссылками на юзеров и коммьюнити. ИМХО, если область действия ссылок будет общая, то нам придется заставлять юзеров писать очень подробное название каждой ссылки, чтобы "тротил" из одного проекта случайно не вывел на "тротил" другого и не возникло путаницы. Короче, расшифрую идею на встрече.
Страница описания проекта (помимо обязательных полей) является вики страницей.
//У каждой страницы вики должна быть возможность добавления тэгов.
[править] Форум
Несколько форумов могут быть объединены в группу форумов. Блог по сути — одиночный форум с ограниченными правами.
Как вариант система-смесь блога и форума. Имеется ввиду ресурс режим просмотра которого можно переключать из форума(разветвленный по категориям, темы поднимаютс наверх в зависимости от последнего поста в теме) в режим блога(линейный, темы идут линейно, по мере их создания). Где-то в сети про такое писали.
[править] Блог
Блог позволяет публиковать информацию (новости) и обсуждать эти новости в виде линейном, либо древовидном (возможно, в первой версии достаточно будет только линейного варианта). Блоги можно добавлять в свою «френдленту». При входе в рабочую группу проекта системой должен быть задан вопрос о желании добавить блог этого проекта во френдленту.
У участника, группы участников, проекта, группы проектов, ресурса, группы ресурсов есть свои блоги.
[править] Комментирование
Комменты древовидные.
У участника, группы участников, проекта, группы проектов, ресурса, группы ресурсов есть свои Стены с комментами.
[править] Файловое хранилище
Онлайн файл менеджер участника (?). Есть готовые, прикрутить(?)
Файлы имеют возможность присоединения к
- сообщению форума,
- странице Wiki,
- сообщению блога,
- описанию внешней задачи
- и т. п. (то есть к любой текстовой информации).
Один файл может быть присоединён к нескольким текстам. При этом должно быть реализовано централизованное хранилище данных в иерархическом виде, и также должна быть «свалка» для того, чтобы не думать, куда положить «случайный» файл. «Свалка» для просмотра простым смертным не доступна, доступ к ней имеется только у системы и админов. Все файлы, относящиеся к проекту, должны быть размещены на сервере в одной директории, доступ к которой осуществляется через веб-интерфейс (желательно дублирование доступа по FTP, админы при интранет-размещении системы могут продублировать доступ по самбе). Файл может быть перезалит, в этом случае старая версия не сохраняется, но в тексте появляется надпись «после последнего редактирования сообщения файл был обновлён» + дата последнего обновления. Если файл был удалён, появляется соответствующая надпись. При этом есть техническая тонкость: файл может быть удалён через FTP, и система об этом сразу не узнает. Для предотвращения битых ссылок проводится периодическое сканирование ресурсов + возможность провести сканирование срочно, вне расписания (разумеется, для общественных серверов эта возможность будет иметь ограничения). Должен быть реализован поиск файлов по имени, опциональному описанию, а также поиск самых больших файлов (для очистки места на диске). Разумеется, всё это предусматривает наличие интерфейса суперадминистратора, раздающего дисковые квоты + (потенциально) перевод файлового сервера на отдельную архивную машину. Сразу кидаться в идеализм не надо, но код должен быть на это рассчитан.
Руслан: Имхо есть смысл использовать внешние хранилища. Для картинок - например фликр. Для видео - ютуб. И т.п.
[править] Система управления проектами
ИМХО, пока достатчно вики, аськи, скайпа, ирка... В первой версии мы вряд ли будем делать Ганта и прочее подобное, думаю, можно ограничиться функционалом в Кабинете Участника и на странице Проекта
Идеи:
Планирование проекта (определение этапов и списка задач по каждому этапу).
Создание задач «на лету», то есть вне основного списка «плановых» задач (кстати, очень похоже на файловый каталог + свалку (см. выше) — можно проследить аналогии и подумать о методах реализации интерфейса).
Назначение задач с приоритетами и сроками исполнения.
Категории задач.
Граппировка (не путать с сортировкой!) списка задач по разным всяким параметрам.
Возможность введение доп. полей, причём отдельных для каждой категории. (Хорошо придумалось. Хочу. Аналогов нет.)
Внешние сообщения об ошибках.
Возможность настройки: обязательность назначения зачач или разрешение подвешенных к воздуху задач.
Кстати, на подумать. А не является ли «приоритет» избыточным свойством при обязательности назначения дедлайна? И не будет ли эта обязательность напрягать пользователей? Мне, вроде, удобно было бы. Хм. Например, можно ввести аналог приоритетов, но уже календарный: «сегодня», «в течение часа», «в течение недели».
Руслан: Собственно я вижу все кольцо, как такую систему управления задачами планирования и т.п. Причем, можно предложить людям планировать их личные ресурсы время, деньги и т.п. в контексте общих. Таким образом личные задачи могут быть подзадачами общественных и т.п.
[править] Коммьюнити/Ассоциации
Ассоциация - не отдельный класс, а выделенная "площадка общения" для определенных участников. Имеет логин, название, самоописание, ключевые слова.
На главную страницу ассоциации выводится список участников и друзей (читателей).
Создавать ассоциацию может один участник; далее он может управлять правами на подключение, чтение, запись в блоговую ленту, изменение лицевой информации.
[править] Сквозные сервисы
[править] Поиск
Должна быть реализована возможность поиска открытых проектов по названию и ключевым словам.
Строковое поле и выпадающее меню для поиска простых категорий: логинов, интересов
Окно поиска участников по местонахождению, интересам (ключевым словам), предметной области деятельности и возрасту
Окно однократного поиска по проектам (внешним задачам) по критерию предметной области или ключевых слов, работает аналогично сценарию установки нового фильтра на интересуемые проекты, выбор проекта или внешней задачи производится путем выбора в радиокнопке. Можно также галочками отмечать необходимость поиска будущих, текущих и завершенных проектов (внешних задач)
Окно контекстного поиска по всей базе, слабоструктурированный запрос (может подключаться дополнительный фильтр по местонахождению)
- полнотекстовый поиск
- участники
- по логинам
- по тэгам/интересам (облако тэгов)
- по географическому местоположению
- по специализации
- по опыту работы
- коммьюнити
- по логинам
- по тэгам/интересам (облако тэгов)
- по географическому местоположению
- ресурсы
- по логинам
- по тэгам/интересам (облако тэгов)
- по лицензиям
- по географическому местоположению
- проекты
- по логинам
- по тэгам/интересам (облако тэгов)
- по лицензиям
- по географическому местоположению
[править] Статистика
- кол-во участников
- кол-во коммьюнити
- кол-во ресурсов
- кол-во проектов
- кол-во комментов и постов в форумах и блогах
- статистика посещения
- всего по системе
- по каждому из компонентов
- по каждому из объектов
[править] Система уведомлений
Напоминание о задачах, которые необходимо делать участнику, с краткой информацией о ходе выполнения (конечный срок), у каждой задачи также небольшое строковое окно, куда необходимо внести процентный ход реализации на данный момент и кнопка отправки данных под столбцом задач; а также к которым необходимо приступить в ближайшее время (с информацией о возможности начать выполнение, исходя из выполнения задач, которые являются необходимыми условиями для начала выполнения данной - "красный", "желтый", "зеленый" режим)
Информирование о планируемых задачах, которые предварительно предлагается возложить на участника
- почтовый модуль
- ICQ (mICQ для PHP - http://destym.livejournal.com/26561.html)
- рассылка общих новостей
- статистики
- подписка на блоги участников, проектов, коммьюнити, ресурсов
- напоминания и текущее положение вещей в проектах девелопера и/или автора проекта
- восстановление пароля
- подтверждение пароля при регистрации
[править] Свойства
Список свойств каждого компонента. Будет изображено графически в class diagram
[править] Действия
Список прецедентов, действий, которые могут осуществляться над каждым компонентом системы или (для сервисов) подробное описание возможностей. Сюда же — use case diagram.
[править] Страницы
Постраничное описание с указанием типов используемых URI-адресов (конкретные примеры). Сюда же — state chart diagram.
[править] Права
Дерево прав, необходимых каждому компоненту системы.
[править] Термины и сокращения
Под «администрированием» мы понимаем редактирование данных администраторами системы (людьми, имеющими, как правило, root-доступ ко всей системе). Администрирование обычно осуществляется из бэк-офиса со своим, недоступным обычным пользователям, интерфейсом. Администрирование далее отмечается сокращением «адм.»
Под «модерированием» мы понимаем редактирование данных людьми, имеющими определённые (не обязательно полные) права на систему. Модерирование осуществляется из фронт-офиса. Элементы модерации являются неотъемлемой частью пользовательского дизайна для модераторов.
Модерирование далее отмечается сокращением «мод.»
Модератор — тот, кто имеет право на модерирование.
Координатор также имеет права на модерирование, но права координатора обычно шире. Вообще, разделение модератора и координатора очень условное и противоречит некоторым другим источникам в рамках полностью персонального назначения прав. Надо будет ещё подумать над этим.
Вопросы по ходу описания отмечены сокращением «QQ» (от англ. Question).
[править] Remember. Мелочи
- На каждой странице каждого компонента - ссылка "Послать другу".
- Сделать подтверждение мэйла при регистрации
- Метод работы с датой (часовые пояса)
- На главной странице рэндомно выводить проекты
- Обсудить статусы
- Сложность проекта?
- Как проверить качество и сам факт реализации проекта?
- Степень завершенности
- Рейтинги (активность, востребованность и т. д.)
[править] Диаграммы Кольца
[править] Описания Кольца
[[1]]

