The `pkg` package is a horrible convention. Having a `cmd` directory makes sense, as each binary needs to be a separate package, but putting all your libraries under a `pkg` directory is unneeded.
I hate the pattern primarily because it overloads the name "pkg" which is already used in your go workspace at least one directory up to store compiled library files.
The word "lib" makes more sense. But, also, its unnecessary.
Some projects dump everything in the root of the repo. I find that to be annoyingly messy.
Comingling non-Go dirs with Go code makes it hard to navigate, since some dirs will be Go packages, and some won't. You may want to have documentation (/docs, perhaps), test data (/test?), build output dirs (/build or /dist), Docker/Kubernetes/Helm dirs (/docker, /k8s, etc.), Protobuf files (/proto), and so on, usually all in the root of the project.
Secondly, these directories might conflict with Go package names. We have a project that has a package called "documents", which is about persistent documents, which we'd have preferred to call "docs", but the root already had a /docs folder for actual documentation.
More fundamentally, it feels a bit screwy for a multi-faceted 'project' to live wholly inside $GOPATH in the first place. But at the same time, it's natural.
Typically, unless I'm writing a shared library, I find myself putting everything under a `internal` folder. It keeps people from importing possibly unstable code until it's exposed.
