This document contains my interpretation of the various discussions, e-mails etc. around the dotWRK initiative. During the past two weeks I think I've read most of the currently available material on this topic. This document is not meant to define what dotWRK is, should or should not be - it's just my registration of the state of affairs so far and is meant to act as a firestarter, in order to eventually get to a proper requirements document.
For discussion of this document, please feel free to post in the
development forum
Having said that, I don't think there is one definition for dotWRK at the moment. The term means different, though strongly related, things to the various people involved. Roughly the whole thing seems to fall apart in three:
- One part that is meant to provide generic 'portal-like' services, leveraging existing oacs functionality as much as possible, i.e. a generalized dotLRN;
- A number of fairly specific, problem-targeted, applications that would leverage the environment mentioned in pt. 1. E.g. a project schedular, an FAQ manager, a webmail client, etc, ...
- A number of 'portal-templates' that combine a number of applications mentioned in pt 2. in a specific, pre-configured way, to become a complete out-of-the-box end solution for a particular vertical.
The last point I guess ensembles more or less Lars's first idea when he said:
" We're really keen on putting together an intranet-in-a-box thingie
called .WRK.
I'm picturing a system that pulls together the best from OpenACS
and .LRN, configured for intranet and extranet out of the box, with
all the relevant applications added and portletized, with some
groups setup for employees, partners, customers, with default portal
layouts, with a setup wizard that guides you through creating users,
uploading your company logo, etc. And administrator and end-user
documentation"
Lars's is also very right when he says 'it's not something we can do overnight'. That's the reason I'm eager to split the whole thing up into a number of smaller parts. As a PM, divide and conquer is my game :-)
In the next sections I'll first summarize what I've picked up with respect to the above mentioned parts. Then in the last section there's a proposal for the next step.
dotUmbrella should offer functionality such as:
- portal pages
- a standard way to 'portletize' oacs applications
- solid generic group management
- a generalized version of the 'community'-thing in dotLRN
- perhaps role-based access control
- a way to define 'portal templates'
- i8n support? (perhaps more oacs's task?)
To cut a potentially long list short: dotLRN without any problem-specific applications.
Applications that seem to be wanted:
- project management tools, e.g.
- project repository
- project scheduling
- collaborative todo-list/task tracking
- resource management
- crm like stuff, e.g.
- hr, e.g.
- timekeeping
- holiday booking
- expenses
- other
- company library manager (where's that damn book?)
- healthcare related apps (Stan Kaufman - knock, knock: still there?)
- calendaring
- messaging (chat, im, mail)
Project management related tools seem to be on almost everybodies wishlist - as a PM I can imagine why - though I don't want to start a non-constructive flame-war on pm-tools here :).
Furthermore, written in between the lines, I read a desire for tight integration. Both between the various applications as well as between those applications and 'the rest of the world'.
An example of good thinking in that direction (sorry, in the pm area again) by Nick Carrol is an application that resembles a project repository - its only task is to define a common datamodel for projects, an api to deal with them and just sit on the data. Other applications (e.g. a scheduler) then can easily work together, as long as they use the common datmodel. By using an existing and often used datamodel, also coupling with 3rd party applications becomes easier.
Verticals I've seen mentioned currently are:
- companies in general
- IT related, project-centric companies in particular
- travel agencies
- learning environments, american style universities in particular (dotLRN)
- medical environments
If we reach agreement on the above vision, I propose that we first work on a requirements document for the dotUmbrella part. I realize that most people are most likely to be more interested in coding, and then in particular for their specific problem area, however having a solid foundation is IMHO very important and will benefit us all for some time to come.
Lets first discuss this vision statement a bit, then in the mean time I'll prepare a basic requirements document.
