Flint: lint your project for sources of contributor friction

I wrote previously on the benefits of bootstrapping consistency. Predictable scripts for automating setup and running tests greatly reduce the friction for newcomers to a project.

Recently, I've jumped back into some of my older projects and immediately felt the pain of not having bootstrap or test scripts to get up and running. Wanting a way to quickly check a project for these missing scripts and (other items that help reduce contributor friction), I wrote Flint as a small Bash script. Here's what it does:

While Bash was a good fit for the initial version, I have some ideas for Flint that really demand a higher level language:

• Open an issue in a GitHub repository. I'd like to run Flint in a project and just have it open an issue in the repo with each of the lint errors as TODO tasks in the issue body.
• Add missing files based on templates. I want to ship some default licenses (or pull them from choosealicense.com), and just add them to the project automatically. Boilerplate README, and CONTRIBUTING guides would be a logical addition, too.

Rewriting in Go

Ruby is my primary language, and I've written plenty of CLI apps in Ruby, but I thought I'd give Go a shot for this one, primarily for the reasons Mitchell Hashimoto and Jeremy Saenz have written about.

It's still early, but I've enjoyed writing a command line app in Go. Jeremy's cli.go project has captured much of the declarative expressiveness I like about David Copeland's gli CLI framework for Ruby.

Special thanks to Owen and Jeffrey for some helpful code review.

See Flint on GitHub.