Here's a partial to-do list of things that I've thought of.
First of all, it goes without saying that we're going to include the groupware functionality from dotLRN.
- Configure for intranet use. This includes at a minimum changing text at the level of changing "class" to "project". The extended version would be to factor out the class community into a separate package and have the dotlrn core package not know anything about that community type in particular. Ben said he estimated this at 2 solid hacker-weeks worth of work for someone who knows the stuff intimately. So definitely not trivial.
- Simple CMS: Edit-this-page, ability to attach a directory of static pages to a community, something is needed. Again, we can do something quick for now, then expand later.
- Graphic design: Make it look good. Don't shoot me! I think this would really, really make a difference. The quick solution would be to slap on some templates, for example using those from Sloanspace as a starting point, if they're willing to share. Deeper version would be to find a solution that would work for all of OpenACS, with skins, widgets, site-wide consistent design, etc.
- User interface cleanup: Group admin UI is the classic, but let's walk through the whole UI and clean it up, streamline it.
- And then let's configure it out of the box with an Employee group, departments groups, the ability to invite people to join your project group (extranet?), perhaps there's a default "company" community that spans the whole company, with subcommunities for each department ... I haven't thought this through all that much, but you get the picture.
- Write documentation/online help text for both the administrator user ("Congratulations, you just installed dotWRK, now here's how you get started using it ...") and end-user documentation (for the employees of the company using this intranet).