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! _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
