Jade, seen the direction the discussion took this seems the way to go indeed.
Still, Lars may have a point imho when he says "all these core facilities fall under the dotWRK hat from a "use case" and "push" perspective". While defining the requirements for the various applications I guess the dependencies to (currently) dotLRN related stuff will become clear. By that time we can signal this to the relevant group (Don - do you represent the 'relevant group' in this case?)
So the new question-of-the-day seems to be - what applications, in what order and who's gonna do what?
For sanity sake - let's start with 'what applications'?
In the doc I posted I'd already listed a couple of apps that seemed to be wanted, based on the various forum posts.
Giving the 'people' list another look shows that project mgmt. type of stuff is firmly on the number one spot.
In this category I think of applications like:
* project repository (i.e. CR for projects)
* project scheduling & reporting
* collaborative todo-list/task tracking
* resource management
* timekeeping (linked with scheduling and task-tracking)
* holiday booking (idem)
* expenses (idem, budgets)
* calendaring
* messaging (chat, im, mail)
* wiki (i.e. general purpose information sharing)
* document storage
Some things may already be available - I guess.
I wouldn't mind working on wiki (currently playing with dave's code) <off-topic> - on the wiki topic, what is is your [Jade] opinion? I saw in the wiki-thread that you were in doubt whether to adopt Dave's code or the extend some other wiki package? </off-topic>
Anyway, From a logical point of view, if we like Nick's 'project repository idea' (do we?) it would be most sensible to implement that one first before project scheduling and task-lists (in fact - if you define a project to be a collection of tasks and people tied together by a schedule, then a collaborative task list is just a project without a strict schedule, isn't it?)
But I'm losing focus: lets first see what applications we want.
