Had a long discussion with Stew, Greg and David, and latterly Scott, about how to handle a number of issues in our customization and usage of the blog tool. Outcomes:

• Tracking of CTO and vacation days will be carried out in a separate simple PHP/mySQL database that we build. Building it into the blog is going to be too complicated, while creating a dedicated tool shouldn't be too onerous. This might get going in the New Year.
• All projects worthy of the name will get their own blogs.
• All projects deemed by their owners/administrators to be moribund can be hidden using their property settings; the blog would still be accessible, e.g. via a link from the project home page, but it would not appear in the list of blogs on the blog site. Any project blog could be re-activated by unhiding it. This manual control is deemed preferable to any kind of system we could imagine for detecting moribundity algorithmically.
• All project blogs will have, at some level in their category system, at least one (possibly more) instance of each of the following: "Activity log", "Announcements", and "Tasks". These categories will all be distinct records in the db category table, but can nonetheless be used for filtering records for reports using the category names (hence they must be precisely as shown above).
• Any post which includes "Activity log" as one of its categories should include a value for "Minute worked". I need to find an efficient way of adding a check for that in the posting interface. This will be added as a task.
• Where necessary, an "Academic" category will be added to a project blog to accommodate conference presentations, authoring of papers, etc.

• The following blogs will be added to handle more general and non-project work:

  • Maint (already added): covers HW and SW maintenance and updating.
  • Depts: will cover simple support for departments, website updates and so on.
  • Admin: will cover bureaucratic work, general meetings, and so on.