So, here's the spreadsheet we used in trying to pick a name for Dean. We went through a lot of choices until we narrowed it down to just a few.

Then, at the hospital, we just picked a name that hadn't even made it to the final round. Awesome.

So, I've finally gone to an all Linux workflow for photo editing. Here's my (current) process. It'll still need some fine tuning as I've only been using this system for a couple weeks. I'm sure my workflow will either be abandoned entirely or greatly tested in the coming months.
I shoot a Canon 20D, and I'm only shooting RAW now. I figure I can convert to JPG easily on the computer, so for the times I'm just doing snapshots, it's not that much more difficult than having them from the camera. The tools I use are Digikam, RawTherapee, Raw Studio, and The GIMP.

My process is, I connect the camera to the computer, and have it set to open them in Digikam's importer. Usually I set up a folder for each date, unless I'm working on a specific project, then I use the project name. I import all the images and then then go through them using Page Down and ctrl+n to rate them. My system is:

• 1 Star: Crap. Delete.
• 2 Stars: Snapshot at best. Just convert to JPG and delete the RAW
• 3 Stars: Possibly Salvageable, worth exploring
• 4 Stars: Good. Clean up and post
• 5 Stars: Amazing. Who was using my camera when this got taken?

Then I sort by rating. 1s get deleted, 2's get sent to Raw Studio and batch converted to JPG, then the RAW files are deleted. Then I open the 3s in RawTherapee and see if playing with exposure/saturation/contrast/etc. helps them. If yes, I'll up them to a 4, if no, drop them to a 2. 4s get the Raw Therapee treatment. If I'm happy with them as taken I'll convert them to JPG for uploading to flickr, if I think they need more work, I'll convert them to PNG to play with in GIMP. 5's get the same treatment as 4s.

I'm not (yet) using the tagging features and such in Digikam, but I think I will start to soon.

So, that's my work flow for now.

or "How to Code When You Don't Write Code"

The idea of "Document Driven Development" was brought up today in the Habari IRC
channel. One of the things that the Habari Community has held as a core ideal is that users, developers, and designers are all equally important to the long-term health of the project. Also, it would be foolish of us to believe that all of the great ideas for how our software should work are in the heads of the people with the skills to translate those ideas to code. However, anyone can write a description of how they feel something should work. By documenting processes or structures a framework can be drawn up that allows the coders to have a well-developed jumping off point.

One example of this is that many of our coders don't do podcasting, but it is a feature that we really want to support. This is a great opportunity for someone who does podcasting to create a document on the wiki describing the ideal process for creating and distributing a podcast from within the Habari admin interface. This allows the people working on the background code to have specific goals to work towards. By using this document driven method, we're able to take advantage of both the podcaster's experience and the coders skills to the greatest effect.

Hopefully we can work out a streamlined method of connecting experience and skills in this fashion so that Habari continues to take advantage of the strong community we've built.