[pmwiki-users] RFR: XTodo Redux . . .

Sivakatirswami katir at hindu.org
Sun Aug 12 21:06:41 CDT 2007


Ben Wilson wrote:
> All,
> 
> I am about to do a radical overhaul of XToDo, which has not been
> actively developed in nearly two years. Julian Kamil was the previous
> developer. I plan on taking a diverging move and wanted to solicit
> stakeholder requests (features). This change is to scratch my own
> itch, but if a few others can be scratched, more the better. I know
> various users over the months have had problems with XToDo.

Ben, good luck with this.. we used XToDo for one major project.
I wasn't really happy with it... it worked OK for say a 2 man team
but that's about it. The problems were not with its functionality,
it worked pretty much as advertised. But with the "model"
from a GTD point of view...I went ahead and changed the model
and used a ZAP form to generate TO DO pages that were then
tied to wiki pages. It's a simple model and it was working
until a recent  PMwiki upgrade crossed swords with zap.php and
I'm unable to resolve a serious problem there... that's another story.

the issues with XToDo i found were:

1) A trail of pages gets generated with ID numbers that are completely
disconnected from "regular" wiki pages. as the team started to use
XTODO pages for more and more process documentation and development
notes, the knowledge base for the project became an impenetrable maze
and with no integration whatsoever with regular wiki pages.

My solution was that every TO DO had to carry a "returnPage" PTV
that was a link back to the wiki page from when it was created.
I think used PMwiki's page list functions to display these on top of
thewiki pages form which they were generated. This is pretty cool
as every wiki page has it's to do displayed and you can also display
all TO DO's for a given group  etc. the elaboration of TODO's
does not fragment the basic PMwiki group model, PMwiki's
group.name keeps all the "discourse" on a project integrated
and the TODO's ride "on top" of those pages and don't get
fragmented off into yet another "sphere" of information.

Again, if you want to see this I can let you in... email me off list.

2) There was no way to scale up to a larger team. I wanted to
be able to customize, on the fly, staff and team assignments.
XToDo simply does not offer that...

Solution: a custom field in the TODO where a pull down menu
"digs" all the members of the "Team.*" group and displays those.

then on the page "Team.BillWilson"  all of "Bills To Do's appear.
again, it's simple and effective.

3) XToDo is not extensible for a team across multiple projects.
IF we have a XTODO series running for Project A, and another
XTODO series running for Project B, there is no way to assigned
some to do's to Bill in one project and some TODO's to bill in
another project and then have Bill review all those and their priority.
Bill needs to be able to see All his tasks across various projects,
at the same time...and another team member needs to see all his
to do's across all projects and then all team members need
to see all ToDo's for a single project and who they are assigned to.


Since my model was "$Group-*=Project" and each TODO carries
the link to it's "mother" page. It's a simple matter to just
invoke page lists for either team.* or $Group and viola you have
TO DO's all organized.. I was going to add a time stamp,
milestone dates, possible additions to the "status" field and a
"status note" (or call it "follow up" note) and we are getting close to
GTD. I can get both per person view and a per project view.

another important Goal is that the to do system should not cause the team to
start fragmenting plans, specs, process documentation, dev conversations
etc... all of which are best kept contained in PMWIKI's existing
group page structures, where $Group-* (along with Cluster)
is already an excellent container for project info,
just as it is without any other recipes.

...To Do's want to be constrained two ways:

1) user can't create one except from an existing wiki page,
if that is too tough a requirement then at least from inside a group
that becomes a key field in the to do item, with the option to
to connect the TODO to a specific page... later...
2) anything beyond a  short description on the TODO, wants to
written on that wiki page. some char limit will be great, could be set
in a config file if some admins want to allow more data in the TODO object
3) any to do can be tied to it's wikipage.  e.g. if the TO DO had
no child page or mother page, then it might have a "create page" link
which would generate a new page in the group, tied to the TO DO
item.

> The hugest change will be to not use wiki pages to hold XToDo
> metadata. Instead, I will be creating a JSON object stored in a
> directory (e.g. $FarmD/xtodo.d). Presently, when one attempts to view
> an XToDo object by viewing its wiki metadata page, one is greeted with
> blank silence. 

This makes a lot of sense... as I think for TO DOs we need a
more structured and "constrained" data container. This would prevent
the team from using the TODO pages for adding all kinds of screen shots
and important discussions, technical data that then get lost in
the "dungeons" on some XToDo.0000234  page with no link
to the "real wiki world" outside XToDo./

> JSON has the advantage of being a universal standard,
> which allows the todos to be observed by any tool. An added advantage
> is being able to offer the data as a web service (JSON instead of
> XML). However, the user interface will integrate with PmWiki.

Excellent!  Writing CGI for web services
against wiki pages is  too "loose" . We are doing that now... one example
  a CGI parses data on wiki pages and generates very specific kinds of
emails.
But this is way too "breakable" ... JSON is a great container...

> 
> There may also be some GTD behavior, as I am a fan (though not pure devote).
> 
> I will likely take a hiatus from my own Python project to focus on
> this and anticipate something in the ensuing week.
> 

Good luck!





More information about the pmwiki-users mailing list