Part of the problem we encounter when trying to implement a new policy, procedure, or even software architecture is that the people making the rules are seldom the ones that have to live with the consequences. That is not the case with the Ratcheting project. We are all, first and foremost, programmers here and will very much feel the pain of eating our own dogfood. That being said, it is in our best interest to ensure Ratcheting really does provide quality and does not end up burdening our fellow developers.
As we continue to define and refine exactly what Ratcheting is, an idea of how it might be used starts to emerge. Here is what a developer's workflow might look like during her day-to-day activities.
Most of the things on this list we are already doing anyway, the addition of Ratcheting provides rapid feedback of code quality and risk around the time of commit, not during a post-mortem of the project done long after the project has been completed.