More Fiddling with Project Management

It should come as no surprise that I'm still fiddling with project management solutions via "Zope". I've started down a new path, but before I explain it, I want to explain the current situation.

General Requirements

We're a very small organization (two people, with loose associations to other very small organizations). As such, we're constantly busy (thankfully) and don't have too much overhead to worry about in regards to project management. But having a to-do list of any sort is always helpful, and having a place to dump notes and flesh out ideas is always good too. Plus, we're decentralized - we work as much from home as we do from the office, and are often working from multiple machines in either location. Sometimes we need to communicate progress with each other, sometimes it's nice just to have a list for our own uses.

Ideally, content (which could be proposals, notes, software configuration requirements, etc) and issues should be managed by the same system - or at the very least be close to each other. And projects need to be easy to add in to the system by either main user, from wherever they may be. And most of all - it should offer only just-enough project content management features.

What we've used

Last year, we experimented with a couple of home-grown systems. One was a Zope based SQL backed project / task / contact tracking system. Data went derelict rather quickly. I was working on a much more thorough CMF based system with detailed workflows, nested tasks, role assignment, and more. There were a few key features that were difficult to do to meet our requirements, particularly in the non-containment object relation area, an area where Zope has typically struggled (but should be dealt with in Zope 3).

We gave the Roundup (0.4.2) issue tracker a try. While fast, it was still a young product. Too much command line work was involved to set up a Roundup instance, and while there is a Zope-Roundup Gateway available, it didn't integrate too well with Zope based content. I really like Roundup and think it has a lot of potential, but it didn't satisfy our requirements.

Ultimately, we landed in the ZWiki 0.7 + Tracker situation. Each project was their own folder or wiki, and usually had a tracker in it. This approach succeeded on the simplicity category and has been used for almost half a year. But it suffers from a couple of problems. The first is that Tracker is an aging old beast. It's generally pretty thorough, but has some rough edges. It's no longer supported, and I've heard claims that it doesn't work with the latest "Zope" release family (2.6.x).

The second problem is that I'm no big fan of Wiki's. I never have been. They've been useful, but we don't need whatever supposed collaborative effects Wikis are supposed to have. I don't like Wiki names - they either end up looking funny (with words like OneDotOh or ZoPe) or kick in when you don't want them to. Now that I've done some work with reStructuredText, I've come to loath working with Zope's normal StructuredText. It just doesn't work well with TextAreas. If you're used to Zope's StructuredText and have a good editor on your side, it's not too bad. But StructuredText and DTML (outside of SQL methods and occasional small non-HTML uses) are two Zope technologies I'm happy to leave to the past. Finally, we needed a stronger content management system than a pool of individual wiki's provided.

We did (briefly) try out ZWiki 0.12 with setting up the ZWiki based Issue Tracker, but it was a beast to set up and configure (loosing out on the 'easy-to-add-new-project' requirement) and too dependant on DTML for me to debug and make work for us on short notice. I liked the integration of Issue Tracking with the Wiki (gaining points on the keeping-issues-close-to-content) but there was too much pain involved, and too much inolvement with the technologies I wanted to leave behind.

And I know Wiki's really really work well for some, but I've never really been able to get comfortable with the Wiki way (ask anyone that I used to work with). I've been able to get by, but that's about it.

The new attempt

Facing the problem of trying to support the Trackers onto post-Zope 2.5.1 software, and facing other issues that stemmed from the basic folder/wiki layout of the site (no intra-project search abilities, poor navigation), it was time to look for something new. That new thing is Plone - a realized content management system built upon Zope's CMF (Content Management Framework). With my knowledge of the CMF (I used to be on the content management team at Zope Corp), I was able to start tweaking the system where I needed to - I made a Project Folder content type to distinguish Projects from other content types without putting too much expectations on the content type. It can contain anything, like documents, links, events, and a CMF Collector (a weaker but still fairly usable descendant of the Tracker). I later designed a quick workflow for Projects so that their status would be more meaningful to allow distinction between active, pending, suspended, completed, and cancelled projects. The workflow has a few simple rules, but nothing distracting.

CMFCollector is decent. It has some of its own rough edges, and is missing out on some of the nicer features of Tracker (mainly intra-issue explicit linking). But it has some nice new features, like the ability to automatically assign/accept a new issue. Its interface is a bit more streamlined, particularly in the Plone skin. It uses a very simple plain text markup language it calls WebText. It basically takes plain text, marks up URL's and citations/literal blocks (lines beginning with '>' or white space).

A downside to Plone is that it - for better or worse - just builds upon CMFDefault. And CMFDefault has very basic content objects, particularly the default Document, which is very monolithic. I partly blame myself for the design - I could have proposed a better solution back when I was on the team. In my vaporware compound document project, FDoc, not only are the parts of a document componentized, but so are the text handlers. A separate Handler Registry contains handler objects, which take a chunk of text and turn it into an HTML content body. This could be HTML (taking the content between the BODY tags), Structured Text, Plain Text, etc.

So today, wanting reStructuredText support, I tried to think of how to deal with this. I had a couple of options: either take the existing FDoc work, which is half baked (the most complete work is in a customer specific project and hasn't been backported yet due to time constraints) and add a reStructuredText handler (and also make a Plone friendly user interface), or make a subclass of CMFDefault's Document class, add in the ability to manage reStructuredText somehow and make it a new Content Type or replace the Document document type (this too would involve some Plone UI work, but it would only be a tweak of the Document's edit form).

Neither situation was quite what I wanted - there were too many existing dependencies on the default CMF Document behavior, and I haven't had the time to really learn how to make my own Plone UI pages work. So, I decided to do a hybrid of my original ideas. I made some new FDoc handlers that handled Zope's StructuredText and the reStructuredText formats. Then I made a subclass of the CMFDefault Document and started wiring in knowledge of the handlers and handler registry (based on the FDoc Text Part component, but made to match the default Document's interface). Then, out of some act of devilry, I decided to monkey-patch document by doing some good old fashioned Pythonic class __dict__ comparisons and substitutions. After a few tweaks to the document edit form to list the available text formats dynamically instead of statically, I had it working (aside from one infinite recursion bug my __dict__ tweaking introduced).

So now, it's mostly working. We have a decent looking project site that's navigation friendly. It's easy to add new content and to decide its form and format with very little restriction. And I'm finally away from StructuredText (although it still exists as an option). With other CMF and Plone options available from the likes of the CMF Collective, there's a lot of potential expansion if required.