You know, that thought occurred to me a lot over the last couple of days, but I thought i'd save it for another post. I think it'd be hugely useful in terms of adding functionality that is more esoteric, but I don't know if that's ultimately in keeping in with the goals of the project. My sense is that the Tracks community would prefer to keep Tracks as a simple, focused, GTD application, rather than an application platform. It'd also be a pretty big piece of work to redesign the existing infrastructure to use a plugin API (assuming, of course, you'd want to rewrite the current design in terms of a set of core plugins, which makes sense to me).
On Tue, Dec 30, 2008 at 8:08 AM, Nicholas Van Weerdenburg < [email protected]> wrote: > Has there been any thought of a plug-in and event architecture for > extensions off the beaten path? > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Keith Gaddis > *Sent:* December 29, 2008 9:55 PM > *Cc:* tracks-discuss > *Subject:* Re: [Tracks-discuss] subprojects, multi-user, and delegation > functionality > > > > Hello everyone, > Sorry to go awol after my original post, but holiday travel gets in > the way of my communications sometimes... > > I agree completely that the features I brought up should be done with > careful forethought, which is part of the reason I brought them up here. > Obviously there would need to be some modifications to the UI, which > should be unobtrusive and ignorable, yet easily accessible. > > I'm planning on mocking up some UI changes to reflect the proposed > changes I've brought up, but I haven't gotten to that yet. Briefly, I > find the number of boxes on the project page to be somewhat distracting, > so I'd like to consolidate all of the existing information into a single > box, and use lists to display the different information, adding to that > a list of child projects within the project, if any. Actions for a > project include only immediate child actions, not all descendant actions > (though each child project should be listed with a count of its own > actions.) At the top of the project page, I'd remove the navigation link > for next and previous actions, replacing it with a breadcrumb that > traces back to the top-level project. > > Regarding task dependencies, I realize that may have different > meanings to different people, so here's the user scenario I had in mind > when I brought it up: sometimes a task or project stalls until another > task or project is complete, so the idea is that you can link those > tasks so that when the independent project/task is completed, the > dependent task becomes a next-action automatically, or moves from a > deferred to an active state. This would be really useful with > multi-user interaction, where i can delegate a specific task to another > user in the system, and when that user marks it as done my task is > automatically flagged as active. Obviously multi-user capability isn't > there yet, and the dependency feature will require a model and UI for > notifications and/or watching other tasks and projects. > > I've started working on some subproject functionality and UI changes, > using better_nested_set to replace acts_as_list. I'll post my code to my > github when I've got it working well enough to have others take a look > at it. > > --keith > > On Mon, Dec 29, 2008 at 3:54 AM, Reinier Balt <[email protected]> wrote: > > For task dependencies on the homepage, you can consider using a tree like > view. Todos with decedents show a plus which you can use to show all > descendants. Todos without decedents have the same look as current tracks. > This won't easily work for todos with multiple parents (depending on > multiple todos), because tracks currently can't handle multiple instances of > the same todo on the home page. > > > > Using the tree like view, the user has the choice what to see. > > > > Reinier > > > > > > *Van:* [email protected] [mailto: > [email protected]] *Namens *Eric Allen > *Verzonden:* vrijdag 26 december 2008 22:29 > *Aan:* tracks-discuss > *Onderwerp:* Re: [Tracks-discuss] subprojects, multi-user, and delegation > functionality > > > > I agree strongly with Reiner that this new functionality would need to be > discreet. From what I'm seeing it sounds very un-GTD, so it's outside the > scope of what I see Tracks as. The great thing about open source is that you > can add it, though! As long as we can work in the functionality without > complicating Tracks for the rest of us, it seems fine to me. > > > > As for task dependencies, that stalled for a few months. I've still got > some code, but I never came up with a good UI for how to deal with arbitrary > dependencies. I was mostly sketching out the infrastructure for it to be as > general as possible, but the only manifestation would be setting projects to > only show one action at a time (complete tasks in order). > > > > On Dec 23, 2008, at 11:37 PM, Reinier Balt wrote: > > > > Hi Keith, > > > > I remember a discussion about being able to see another users todos with > Joseph Method (tristil @ g mail dot com) but I don't know if that resulted > in any code. > > > > 1) I think we could combine subprojects with the goals request. In a > way it's the same (as responsibilities can be considered a goal). Personally > I manage subprojects using tags and use the tag view to see all todos > related to the complete project. I agree on what you say about sub-actions. > I think implementing convert-todo-to-project will help people who run into > these use cases > > 2) I don't know what you mean with dependencies. Eric Allen is working > on todo-dependencies. You really need to think this one through as there are > a lot of infrastructure items to this. Like a notification system. Also the > gui part seem tricky to me. But then again, who doesn't like a challenge :-) > > > > I think that for both 1) and 2) we need to be carefull on the gui side. > Tracks is all about being simple and flexible so you can use it the way you > want (and not dictated by some strict workflow). Also, the gui currently is > getting really crowded and is in need of simplification. I think that it is > important that new functions like these should only be noticed if you use > them, i.e. if you don't use them, you don't see anything of it. > > > > Reinier > > > > *Van:* [email protected] [ > mailto:[email protected]<[email protected]> > ette.org.uk] *Namens *Keith Gaddis > *Verzonden:* zaterdag 20 december 2008 21:43 > *Aan:* [email protected] > *Onderwerp:* [Tracks-discuss] subprojects, multi-user, and delegation > functionality > > > > Is anyone actively working on functionality to cover subprojects or > multi-user interaction along the lines of delegation and watching someone > else's actions/projects? These are high-priority items for me, and if no > one else is working on them, I'd like to take a crack at it, or work with > someone to avoid duplication of effort. I've seen tickets in Trac for these > functions, but they don't seem to be updated recently (there's also multiple > tickets covering each, so i may be missing the active ticket). > > Here are my implementation thoughts: > > 1) subprojects: this can be really simple. All that really needs to be > done is add a 'parent' field to the project model and make some UI updates. > Projects with null parents correspond to top-level projects, which can be > thought of as areas of responsibility. subprojects have another projectid > assigned to them for a parent. hiding a project cascades down the tree, > marking it visible flows up the tree. One of the tickets mentions > sub-actions, which i think is kind of a corruption of the metaphor--actions > should by definition be discrete pieces of work or steps to be taken, not > aggregations of them. > > this would also make it really easy to implement conversion of an action to > a project, setting the parent id to the original action's project, which is > also something I'd really like to see, though its far lower on my priority > list. > > 2) multi-user functions > first i'd like to implement 'watches', which would allow one user to view > the projects, actions, and notes of another user. further down the line it > could be used to implement notifications and dependencies. The watch UI > would allow a watching user to copy a project definition to his own list of > projects, and optionally its child actions/projects. > > second step in this would be to allow a user to delegate an action or > project to another user. To do so, it would seem like all you would need to > do is reassign the user_id. As a first go-round it would fit my purposes > merely to allow any user to delegate to any other, but it could be > implemented in such a way as to allow a delegation to follow a > request/accept model. > > So now that I've laid out what I'd like to work on, does anyone have any > thoughts about it? Is anyone else working on this or similar functionality, > or in a different direction? > > Best regards, > > Keith > > _______________________________________________ > Tracks-discuss mailing list > [email protected] > http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss > > > > > _______________________________________________ > Tracks-discuss mailing list > [email protected] > http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss > > > > _______________________________________________ > Tracks-discuss mailing list > [email protected] > http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss > >
_______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
