First, a big thank you to our BETA testers and our partners at SeedCode! We've been getting excellent feedback and bug reports, and fmSpark will be a much better product for it.

So, where do these bug reports go and how do we handle them?

Here's a quick look behind scenes. From the get go, one of the things we wanted to make sure we took seriously at Proof was the business of tracking defects and issues. At Proof, our issue tracking software is at the center of our development universe. There are lots of different tools out there, but we use Jira by Atlassian Software.

The attitude here is if it is not logged in Jira, it ain't an issue.

And you know what? While it took some getting used to at first, I don't know how we got by without it. One cool thing about using an issue tracker is that you get lots of self-generated documentation for just being disciplined. Want to know what changed between build 204 and build 407? Well, guess what, no more guessing.

The recipe for success with issue-tracking software is this: (1) the tool needs to be institutionlized and become part of everyday practice, (2) no-one gets a free-pass--if you are part of the project you need to participate and use the tool. I have found that it simply works best when no one is too important to be exempt from logging issues or following the rules; and the rules are simple;) (3) if you are working on an issue, make sure you comment the ticket; if you log an issue, put some effort into it!

Here's a screenshot of what fmSpark looks like from the perspective of our issue tracker.