Pre-Launch Checklist for Publishing Go Projects

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.

follow us in feedly

No comments :

Post a Comment


None of the content contained herein represents the views of my employer nor should it be construed in such a manner. . All content is copyright Matt T. Proud and may not be reproduced in whole or part without expressed permission.