Posting practices

For the past three years I’ve been writing weekly posts about how the work on Doomsday is progressing. With the exception of a couple of missed weeks and holiday breaks, I’ve managed to stay in schedule and make the post every week. I’ve found this a very healthy exercise, although some weeks have been pretty thin content-wise. However, it might be worthwhile to rethink this arrangement a little.

A weekly post usually consists of a look at what has been done during the previous week and how it relates to the near-term objectives. Some discussion is usually included to provide context for the reader, however as these posts are typically pretty hastily written, there is no opportunity to go very deep into any particular subject.

Perhaps it would better serve myself, developers, and other interested parties, if I saved the in-depth development discussion/notes to the “Plan” posts and then only posted a review of changes when things are merged to the master branch? These reviews could be written entirely from a user perspective, making it easier to compile the release notes for a stable release by simply combining the reviews.

This way I would be free to make as many “thinking out loud” posts as necessary without unduly spamming the Developers news feed on the web site. I would also be freed from the burden of keeping a rigid posting schedule, allowing me to invest time into the writing during suitable coding breaks (of which there are more than one per week!).

The bottom line is that I get more value out of the writing as a tool for organizing my thoughts, developers get a fuller picture of what is involved in the work, and users get a message that is targeted for them when the changes become publicly available.