Two-month plan postmortem

So it’s been two months.  We didn’t complete all the tasks on this list, but we came pretty close.

We got very far with the speed improvements:

* Server switch
* Plone upgrade
* Multiple Zope servers in production
* Changing file attachments’ storage mechanism

Only the first of these is totally done, but the Plone upgrade is going to be deployed very soon, with the load-balancing servers following soon after that.  Ra’s gotten pretty far with the storage work, and it’ll be done well before we actually have a free moment to deploy it, so it’s effectively ahead of schedule.

A pretty good showing on software dependency upgrades:

* Upgrade WordPress on StreetsBlog and StreetFilms

* Upgrade Xinha on StreetsBlog
* Upgrade Xinha on OpenPlans.org and LivableStreets

The first two are done, though it took us quite a while to actually have an opportunity to do them.  The last one is scheduled to happen after the Plone upgrade, so it’s waiting on that.

We hit most of the new feature targets:

* Project wiki backup
* Account deletion
* Project-specific search
* Tagging

The first two are totally done and the last is implemented and functional (which was the only target here; there were no plans for any deployment of a tagging feature).  The project-specific search is the only one we didn’t do, and it’s just a matter of getting around to it and doing a bit of work with a design-savvy individual.

We didn’t actually launch either of the large-scale lingering projects:

* Geotagging of people and projects
* NYC Fix-It Map: Some of the OpenGeo team

The geotagging is almost done, but I’ve been saying that for the entire two months.   And the NYCFIM hasn’t seen any attention since I re-enabled its demo and discovered some bugs that prevent any use.  Both of these could probably have been launched in time if we’d just taken a bit more focused time and attention to finish them up.  (And to be clear, that’s entirely my fault, for not scheduling that focused time and attention.)

So, putting it all together, I think missing the target boils down to two things: the Plone 3 upgrade, and lack of commitment.  Four of the seven missed target projects are blocking on the completion of the Plone upgrade, and the other three we just didn’t really get around to.

I think deadlines are an easy and obvious solution to the second problem.  These objectives sort of qualify as deadlines, but they were a bit vague, not exactly a commitment, and I think most importantly grouped together — nothing has an individual deadline, so the set of projects are naturally prioritized and the ones that are large-ish (particularly those that “just” involve attention more than they do anything else) and/or not urgent priorities just slip to the back.  Those are the sorts of projects that I think would really benefit from deadlines … provided they can be identified.

As for the Plone upgrade, it’s hard to say yet what it really points to.  Maybe it means that our deployments take too much time and effort.  (Which I think they do, but Doug’s been furiously working to improve that as he does deployments to OpenPlans.org, so each one is easier than the last.)  Maybe it means that we don’t have enough sense of how, when and how much to test an upcoming deployment whose changes are very wide-reaching.  (Which I think we don’t, but I have no idea what we could do better.)  Or maybe it just means that upgrading OpenCore from Plone 2.5 to Plone 3 is a uniquely fuzzy and fairly risky thing and that I was just overly optimistic about the effort it would require, and it’s just a one-time mistake with no useful information to mine.  I think the Xinha upgrade and the load-balancing will be pretty decent ways to figure out if there’s a fixable underlying problem here, so I’ll be particularly curious to see how those go.

There’s one other problem I think I see here.  Though we did get around to most of them, the server switches, Streetsblog software upgrades, and Plone upgrade did all _happen_ later than I was expecting, even leaving aside how long they took to finish after they had been started.  In a sense I think they all suffered from a sensible reluctance on the part of the stakeholders (variously, Nick, Aaron, Doug, Bryan and myself) to pull the switch on a major upgrade.  In the case of the server switches and Streetsblog upgrades — the ones we’ve actually managed to pull the switch on — it was even difficult to schedule a time to do it, between regular site traffic levels and planned events on the sites that required high reliability.  Broadly speaking, I think we can improve this with more and more explicit communication with stakeholders: agreeing upon a set of acceptance tests in each case; stakeholders perhaps listing, on a private calendar somewhere, their planned upcoming needs for reliability; the engineering team setting some span of time in which to perform an upgrade; stakeholders picking a date and time.  I’d be curious to experiment with some of these.

At this point I knew I had stayed up too late coding.

>>> viewlet_app
<function viewlet_app at 0xdc6c80>
>>> viewlet_app(app)
<function filter at 0xedb488>
>>> viewlet_app(app)(app)
<class 'footsie.viewlet.ViewletManager'>
>>> viewlet_app(app)(app)(app)
<footsie.viewlet.ViewletManager object at 0xf3c9d0>
>>> viewlet_app(app)(app)(app)(app)
*** TypeError: __call__() takes exactly 3 arguments (2 given)
>>> viewlet_app(app)(app)(app)(app, app)
*** AssertionError: URL fragments must start with / or http:// (you gave 'viewlets')
>>> try:
...   reduce(viewlet_app, [app] * 3)(app, app)?
... except AttributeError:
...   raise AttributeError("Something has no attribute 'app'")
... finally:
...   print app, app(app), (app(app, app), app)