Since first launching Deki Wiki Hayes in July 2007, we’re on track to deliver three major releases by July 2008: Itasca (1.9.x, December 2007), Jay Cooke (8.05, May 2007) and Killen Woods (8.07 expected July 2008).

One of our internal development goals since the launch of Hayes back in July was to get into steady releases. And to our credit, we did that pretty successfully! Deki Wiki 1.8.2 and Deki Wiki 1.8.3 followed the initial July release in three-month increments. And we’ve gotten better - we’ve cut down our 3-month release cycle down to a two month release cycle (Jay Cooke shipped two months after Itasca, while Killen Woods will ship in July).

From a product standpoint, our goal is to ship a minor release every month, and a major release every two months. This goal of this is to get our latest features and bug fixes into the hands of the community as fast as possible. It seems pretty cruel to make people wait a quarter of the year to get a trivial fix

Of course, every release is a huge learning process for us. We’ve probably had at least a few problems with each release which required the issuing of the “a”, “b”, or “c” releases immediately afterwards. These issues were usually geared around support for unsupported systems, like people installing Deki Wiki on top of WAMP on their PCs. Given that we have one super engineer handling platform compatibility (go, Pete!), it was difficult for us to achieve a perfect release on every platform.

To improve this behavior, we’ve started issuing release candidates roughly a week before the final release. Not only do these release candidates allow people to test upgrading their systems, but it also gives all the localization people a chance to get their updated resource strings into the final release. And this has worked very well for us.

Now that we’ve addressed most of the big issues, we’ve started doing release post-mortems. Our first post-mortem was for the 8.05 (Jay Cooke) release. I’ve captured the notes from the meeting and posted them online. The goal of these post-mortems is to identify weaknesses and strengths in each release. Although these discussions take a decidedly technical engineering slant, we also address other issues. For example, one of the larger failures was the inability for our team to clearly communicate the changes being made in this release. We worked on so many features and improvements, but when it came publish … we drew blanks.

I won’t dive too deeply into all the issues that came up in the post-mortem, but I encourage you to drop by the post-mortem page and offer your own feedback about our previous release. How can we improve the process? What are some mistakes you see us making again that we haven’t addressed? How can we communicate to you more effectively when these changes are available?

The community’s been tremendously helpful so far in helping us identify weaknesses for each release … I hope those of you who haven’t spoken yet will let your voice by heard. Our whole goal with Deki Wiki is to simplify lives … and we can’t do it if we don’t know what’s wrong

So join our community and check out our super-active forums or ping us on IRC!