О todo. Поделитесь опытом.

я вот это юзаю - http://sourceforge.net/projects/stickwiki/ - удобно и софт никакой дополнительный кроме браузера в памяти не висит.

У Вас так много программ?

> gtodo - GNOME to-do list manager

Воткнут в Evolution, что может быть расценено как удобство.

> верное направление

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

Гуглить по всем вопросам, даже если ответ кажется очевидным.

а это смотря для чего использовать. если исключительно для себя, то ничего лучшего чем plain text еще не придумали.

>я вот это юзаю - http://sourceforge.net/projects/stickwiki/ - удобно и софт никакой дополнительный кроме браузера в памяти не висит.

спасибо, посмотрел. Удобно. Единственный минус (может, плохо смотрел) - куцая справка по синтаксису. Еще хотелось бы выделенный preformatted text простым отступом, чего нет. И обводить в рамочку, ;-) как на википедии. Думаю, Wiki - хорошая идея. Все проекты (их названия) расположенны рядом в виде списка. Под названием ссылка (sub item) на список todo.

Можно еще задействовать subversion....

>а это смотря для чего использовать. если исключительно для себя, то ничего лучшего чем plain text еще не придумали.

Меня интересует всё. ;-) И оформление списка todo для отдельной программы, и ведение набора таких списков. Цель - ясность, доступность и скорость обработки todo. Такой центр управления разнородными проектами под разные ЯП и даже разные OC.

wiki - по сути тот же текст. Plain text - это тру, только ведь лежат обычно todo.txt в разных местах (диска, сети), пока доберешься...Время ресурс невосполнимый.

> думаю, Wiki - хорошая идея. Все проекты (их названия) расположенны рядом в виде списка.

тогда может быть Zim подойдет? http://pardus-larus.student.utwente.nl/~pardus/projects/zim/

- All pages you create in zim are saved as plain text files with wiki formatting.
- You can use wiki syntax to type formatting
- You can export your notes to Html if you want to publish them

buzilla, просто и легко.

тьфу, bugzilla http://www.bugzilla.org/

wiki: TiddlyWiki, DokuWiki.

WikidPad: http://wikidpad.python-hosting.com/wiki/InstallLinux http://www.jhorman.org/wikidPad/#download

Кроссплатформный, GUI приложение на Питоне, есть "дерево" разделов. Сами Wiki можно экспортировать в .txt / .xml

Из того, что интегрировано в IDE: есть в CodeBlocks, Eclipse

В виках удобно писать сам план, как "процесс обдумывания". А ToDo-списки наоборот должны быть короткие, ориентированные на следующее конкретное действие, чтобы лишний раз над ним не задумываться. А так получается что-то двухуровневое, какой-то десктопный список первого уровня по всем проектам, с календарями итп (например, Rainlendar) , и далее -- отдельные ToDo-списки по каждому проекту. Или вики.

Из методологий, как эти списки составлять: были статьи с lifehack чего-то там, стивапавлины про продуктивность, improvement.ru, timemanagement.ru, etc кажись про составление чеклистов и более идейное, Get Things Done, Goal Голдратта (ЕМНИП), ещё есть типа концепт praxos.ru . Это типа философстваний на тему таймменеджмента, а нам программистам скорее нужны краткие ответы на вопросы (гуглятся) "как составить чеклист", как составить ToDO -список (про "следущие конкретные действия"). Все эти методологии можно почитать для общего развития, но там много не нужного нам -- например, в GTD чуть ли не основная идея "делегируйте, делегируйте, делегируйте", а нам -- самим делать надо =)

trac как-то понятнее :) и вики-разметка есть

http://ru.wikipedia.org/wiki/Trac http://trac.edgewall.org/

могу посоветовать поглядеть в сторону Trac - http://trac.edgewall.org/

интеграция с системами контроля версий, вики, расширение с помощью плагинов и много другого.

конкретно для todos - можно создавать roadmap, где и расписывать пункты относительно версий программ(ы).

опередил :)

Только не Trac. То ещё тормозное и страшненькое глюкалово, не понимаю, за что его так все любят.

Вариант-минимум - todo.sh http://todotxt.com/

Cпасибо за дельные советы. Пока я остановился на wiki on a stick из-за субъективных причин. Почему?

1. Платформонезависимость. Сегодня я тут, а завтра за 600 км, бог знает за какой машиной.
2. Минимальные требования: браузер, понимающий js, т.е. экономия времени. Воткнул и работай.
3. Гибкость. Как гибка любая wiki.
4. Доступность проектов. В wiki хранить можно всё рядом: названия и описание проектов, ссылки на них, списки todo, списки системных требованимй, списки багав, вывод програм, документацию или ссылки на неё, ссылки на код или сам код и прочее.
5. Достаточно удобная,настраиваемая навигация,по всему,что указано в 4, что превращает её в центр управления пол...проектами.
6. Наличие инструментов экспорта и импорта статей.

Короче, все проекты рядом, документация рядом, todo тут же. Работай, не хочу.

Недостатки:

1. Баг. Не умеет работь с русскими именами директорий. Например, /home/user/копия/mywoas.htm При сохранении возникает /home/user/копия/mywoas.htm Примерно также и под оффтопиком.
2. Куций wiki-синтаксис
3. Сомнение в нормальной работе, когда wiki разрастется до нескольких тысяч статей. Все ж в одном файле.
4. Работа со списками todo примитивна. (например, нет обработки назначенного времени)

Bugzilla.

> 4. Работа со списками todo примитивна. (например, нет обработки назначенного времени)

"назначенное время" -- это что? тут уже нормальное планирование, управление проектами и ресурсами с временем вырастает.

По идее, время можно считать с багтрекера, фактически затраченное на фичу. Еще кстати как аналог Bugzilla, Trac, можно посмотреть JIRA, Mantis

по идее, какой-то десктопный ToDo должен быть с таймером-хронометражем с кнопками "начать хронометраж/окончить" для например вот этого: http://improvement.ru/bibliot/altshull.shtm

к Емаксу есть org-mode http://dto.mamalala.org/notebook/orgtutorial.html

+ Emacs-MUSE, Emacs-wiki для редактирования wiki

> 1. Платформонезависимость.

А у меня конк отказался исполнять евоный вижуал-васик. Чо я делаю не так?

wiki on a stick старые версии страниц не хранит, и это большой минус.