You've built this awesome doo-dad, and now you want to share it with the world. What do you do?
In the vein of a previous article, this one has been about a year in-the-making as well. This morning, I said, "fuck it," and decided to rip out the draft blog content and place it into a Markdown document on GitHub for everyone to see and contribute to. It feels more conducive to community input in this form now, which is a win. Well, here it is:
So what is it? I've reviewed and authored a lot of Go code over the last few years, both privately and professionally. This got me thinking: what separates a good Go project from a not-so-good one? It dawned on me: one of the deciding factors has been the diligence taken by the project authors. This essentially comes down to process, so I have attempted to document what an author should do before publishing a project—outside of concerns of technical correctness and architecture.
Fulfilling this checklist won't make a fundamentally bad project good, but it will break ties between identical implementations. It certainly helps seed the creative process with the perspective of your users when creating a new project from scratch, however!
This suite of documentation is nascent and deserves detailed writeups outside of the summary document. Any contributions you have would be appreciated.