 So this is a bit of a public service announcement. Software projects are collaborative. They usually encompass many months or years and are touched by several developers along the way. And communication is key to any good software project, strong, well-written commit messages or one way to increase communication and documentation with very little overhead. The project history plus a strong blame engine give us the power to answer future questions about what we were thinking at the time something was added or changed. For some of you, I'm already preaching in the choir. For some of you, I hope I can add some insight that you can bring back to your teams. And for the rest of you, well, I'm going to show some of your bad commit messages on display. Before I start, I should mention this photo. These signs show up in the Commonwealth countries like the UK, Australia, and India. Apparently, they're a way of politely asking people to avoid improper acts in public, specifically to not urinate on the wall. First, some bad examples. I took these examples directly from client projects and from some open source projects. This is a story about a fellow who spent several hours trying to get something to work, obviously had some trouble, but littered the project with some messy history. It starts with this commit, not very useful. Goes to that. Ah, Capistrano. What scripts? Why? How? That looks familiar. What environment file? Why? And for what? Uh-oh. All right, this is getting silly. And now this, this is a great question, right? But it's not a fracking commit message. And this is a letter of the alphabet. Just to give you, this is the rundown. This is actually the history. It was back to back all those commits. The poor guy worked through the night, got some sleep, came back to it, and continued to mess up the history. Here's another story. This is obviously someone who was frustrated at something, but we have no idea why or about what. Now he's indignant. Now he's angry, still angry, and it results in dismay. In fairness, this person was trying to fight through some pains with integrating with OAuth 1 while using some third party service. But unfortunately, afterwards, we're left with a lot of questions. Here's another story about someone who unintentionally made a lot of developers future lives more difficult. Literally, this was thousands of lines of code, no rhyme or reason. Lastly, this one's my favorite. I had taken on a rescue project, and as we know from Jeff's talk, quite a noble effort. And I was trying to get a feel for the code base while trying to add features for an upcoming release. Now keep in mind, the existing developers weren't around anymore. There were very few tests, not to mention most of those tests were read. I found some of the code monkey passion array class, which was kind of curious about it. So I went searching and I found this. And this was painful to find because it had nothing to do with the array monkey patch. Now you might ask, Ryan, why are you being so pedantic about this? Why do you care so much? Well, on this particular project, this in a lot of commits like it cost the client many hours of head scratching wondering whether it was safe to remove unnecessary code, which was a real waste. So let's look at some better examples. I'm going to run it out of time, so I'm going to go through these pretty quick. I'm not claiming they're perfect, but they're out there. Here's a couple of short messages. We know what changed without looking too further into the diff. Here, we know that we fixed a bug, and we know what the underlying problem was. Here's some more detailed examples. Here we know what's changed. We also have some insight into justification why. And then we have this one, which is great because it includes a bunch of different things, but it actually goes into the inside of what was in the mind of the developer at the time. Here's a quick template of what a good commit message might look like. We start with the summary. We finish with some details. The summary, I like to start it with a verb, continue it with a sentence fragment. Optionally include a ticket to your issue tracker. The details I like to specify why something was happened. So here's some verbs for those who have some writers block when they're trying to write a commit message. I pulled these from a project and sorted them by frequency. I'll just give you an idea of what to kind of look for. And lastly, the moral of the story is please don't urinate on your projects with lousy commit messages. I'm Ryan McEary, this is my contact info, along with Jim Garvin, we're the guys behind busyconf. I also do finance consulting under McEary Consulting Group. Feel free to reach out anytime.