Rename the organization

[dominikbraun]

The name organization name golang-standards is misleading for beginners and people new to Go. It implies that the included repositories - which are misleading as well, btw - conclude official standards, which is definitly not the case.

[cwansart]

I disagree. Especially, when you read the README file which states in the second sentence:

It's not an official standard defined by the core Go dev team;

[dominikbraun]

If this isn't a standard by the Go team, why is it called golang-standards?

[frederikhors]

I think we should listen people in open source world. Can we call it "Golang Layouts"?

[koddr]

I think, better name for this project is Golang Layout Best Practice.

[akessner]

golang-best-practices works well to, since I assume there will be more than just layouts.

[koddr]

@akessner yep. Something like this:

Organization: golang-best-practices

Repos:

• project-layout — this repo
• projects-examples — something about real live examples (separated by subject: API, CLI, etc.)
• docker-configs — something about Go + Docker
• ...

And result is https://github.com/golang-best-practices/project-layout
Simple and useful! 👍

[davidpfarrell]

golang-best-practices is growing on me.

In addition to examples mentioned by @koddr I think it would also be useful to host template repositories for various use cases:

• GitHub Blog: Announcing Template Repostories

[kcq]

Great to see this discussion! It brings up a lot of good points and it's true that, in theory, the org name can be a bit confusing, but it's only the case if you don't read or totally ignore the README. If somebody doesn't read it you can't really fix this :-) And even if the org name is changed to golang-best-practices there'll be other people bring up similar arguments and good points against it. The bottom line is that you can't encoding all possible details about the context in the org name itself though it might be fun to see how big the org names can get on Github :)

[ghost]

I'd still say it's misleading. They're not standards and should be named appropriately. — They're opinionated best practices.

golang-best-practices seems best, imo. It describes it very well while remaining on topic.

[kostix]

Another person got tripped by the name :-(

[teghnet]

rename to golang-NON-standards

[peterbourgon]

This GitHub org and this repo especially generate a huge amount of confusion for new Gophers. Nearly every day in the Gophers Slack, people misinterpret this repo's guidelines as being official or recommended practice. The disclaimer on the README doesn't outweigh the name in the URL.

The recommendations here are neither standard, nor best practice, nor even particularly good, for a large number of users and project types — they are one highly opinionated suggestion of many possibilities. By advertising them as standard you're actually making life a lot more difficult for a lot of new users, who struggle to understand and apply rules that generally don't apply to their work. Please consider the harm this org and repo is doing to the community as a function of their names, and please consider changing to something less misleading to new users.

[justinpage]

I've been giving the organization's name some consideration on what an alternative name could be that is less controversial. If we ask ourselves the simple question, as to why we don't like the name, it is because it has the word standards in it --which has tremendous weight in this community.

If we take a moment to look at what this organization offers, it's simply this:

common historical and emerging project layout patterns in the Go ecosystem.

This comes directly from the README in this project. What it illustrates is the authors true intention. That he, and many others that have contributed to this project, have taken a general view of the Go ecosystem, examined historical and emerging patterns, and built a description of what they have seen.

While this process by no means follows an applied methodology, it is a survey done by one of many. And like surveys of today, they evolve and adapt to the viewpoints of those that conduct them.

If we look at this organization in light of the word survey, our perspective changes. It is no longer a project of standards nor best practices. Instead, it is a description of what our community may have seen and would like to describe as they adapt to a changing ecosystem.

Providing a survey is helpful to the community. Especially, when it is aware of its own biases and embraces the idea that many alternative surveys can co-exist in the same world.

[paralin]

Time and time again I see people putting stuff in a pkg subdir unnecessarily or shoving half their code behind an internal package for no reason, after forking this repo. This is not the "standard way"

[ksandvik]

Please rename the project name, this is not a Go language standards official committee.

[brunobarros2093]

Time and time again I see people putting stuff in a pkg subdir unnecessarily or shoving half their code behind an internal package for no reason, after forking this repo. This is not the "standard way"

Yeah, as a new gopher, me and my team fall for that, rs. I mean, we know this is not official, but as people mentioned before, its looks solid. I still think the name of this repo org should change.

[paulwizviz]

I think we should listen people in open source world. Can we call it "Golang Layouts"?

And will this solve the problem?

I doubt it.

If it was called "Golang layouts" someone somewhere is going to complain hey, the layout is not idiomatic Go so you shouldn't call it Golang. If it was called "Common Golang layouts" someone is also going to take issue with the word "common". If it was called "Best practice Golang layout" someone is going to take issue with the phrase "best practice". if it was called "frequently used Golang layout", someone is going to take issue with the word "frequently". So on and so forth. Basically, it seemed the argument against the name is because it is getting more traction and those arguing against the name is they want the content assigned to obscurity and only then will they be satisfied.

The argument that it is going to confuse someone new to Go is also somewhat spurious. There are tonnes of materials not created by members of the core team -- by that I mean people who can influence and have the ultimate say in the direction of the language. Someone new is going to it some of those materials anyway.

Besides the term "standards" by dictionary definition is a level of quality. Not the origins of something.

Why all the fuss over a name when the content itself clearly states what it is?