this is not a standard Go project layout

[rsc]

The README makes clear that this is not official, but even the claim "it is a set of common historical and emerging project layout patterns in the Go ecosystem" is not accurate.

For example, the vast majority of packages in the Go ecosystem do not put the importable packages in a pkg subdirectory. More generally what is described here is just very complex, and Go repos tend to be much simpler.

It is unfortunate that this is being put forth as "golang-standards" when it really is not. I'm commenting here because I am starting to see people say things like "you are not using the standard Go project layout" and linking to this repo.

[binaryslav]

@rsc could you please share a few links to some trustworthy (from your point of view) resources to learn more about the best practices for writing "idiomatic " Go code? Thank you in advance.

[henvic]

@iarosb, I always recommend anyone starting with Go to read

https://golang.org/doc/effective_go https://github.com/golang/go/wiki/CodeReviewComments https://github.com/golang/go/wiki https://golang.org/ref/spec

I feel relieved to see Russ Cox opening this issue! I always hated how this repository sells the idea of being something official and how inaccurate it is.

Quite a few times, I had a hard time because of its "official-ish" appearance – it makes developers, especially people starting with Go, blindly follow whatever recommendation is here. Awful!

[binaryslav]

@henvic the reason I ended up here asking for links is that I've seen many developers referring to this repo as if it has some official status, but it seems to be very questionable in a way it relates to the core ideas behind Go's creation. I'll go through those resources and your help is much appreciated.

[rakyll]

What @rsc describes here is a problem I observed many times. I saw many projects trying to "fix" their layout based on what's provided as a reference here. It creates confusion and conflict among contributors. The project is doing a good job having a disclaimer in the README, but it doesn't seem to be effective because many people don't read the text and assume this is an officially endorsed project.

[theckman]

I am 100% aligned with both @rsc and @rakyll on their comments. We experience the same misconception about the status of this repository in the Slack workspace, especially for those who are new to the language and are trying to figure out how to do things "right". I am not sure that I get a sense, at least in our space, that it's getting any worse, but it's frequent enough that I would be comfortable classifying it as a problem.

Considering the feedback being given in this issue, @kcq how would you feel about moving this repository out of the current Organization and onto a different one (or your username) to benefit the larger Go community? I'd actually be happy to provide your repo as a resource for Gophers if it wasn't asserting itself as a standard.

Edit: I had forgotten I filed this awhile back, regarding the pkg/ directory: #10

[flowchartsman]

I usually point people to https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/, and have done so in several issues in this very repo.

You've had several long-time gophers and a couple of go maintainers chime in now. It would be really great if you could archive this repo or, at the very least, move it to a less-misleading org. I don't like saying it, but overall community impact is negative at this point. It's hurting more than helping.

[MrTravisB]

The issue is the different requirements between a simple system package (which I tend to think the Go team over optimizes for) and more complex apps and services. Every company I've worked at that had larger apps written in Go has a repo that looks very similar to this. Even the pkgsite repo uses some of the structure that this repo recommends. Obviously I would not use this structure for a small system library that isn't meant to be used in a standalone way but in my experience a lot of what this repo recommends is very valid and preferred for large apps.

[flowchartsman]

I think the primary issue is that the org is titled golang-standards which, combined with its age, lends it a certain credibility (not to mention SEO) that is unwarranted and has long been a source of confusion for new developers.

Differing requirements is certainly a thing to be aware of, but they're impossible to capture in a single directory hierarchy, and that's part of the problem. This repo is complex and, despite periodically stating that features are optional in documentation, has a monolithic structure which comes across as prescriptive. This is at odds with the language, IMO. Go is a relatively simple language to get started with, and this is not a good jumping off point. I've personally helped several developers rekindle their waning interest by showing them a simpler way to lay out their code. I'm sure many other folks in community forums have had similar experiences.

For those that do persist, as mentioned above, they often cause further confusion by directing others to follow these guidelines in the form of PRs, issues, or just well-intentioned advice the recipient doesn't know any better about.

It would be really great if at the very least the org name could change. For the reasons discussed above, this is not a very good standard, much less the standard.

[SteelPhase]

I am in support of the idea this project represents, but these conversations bring up one thing to me. Why doesn't something like this get published by the Go team. It doesn't have to be complex, but I feel like there is a gap in the documentation that this repo partially fills. I stumbled on this when I was in search of this information, and it was extremely helpful. I'm well past this point in my learning of Go, but I have to assume others could benefit from an official version of sorts of this type of information.

[ivarec]

I am in support of the idea this project represents, but these conversations bring up one thing to me. Why doesn't something like this get published by the Go team. It doesn't have to be complex, but I feel like there is a gap in the documentation that this repo partially fills. I stumbled on this when I was in search of this information, and it was extremely helpful. I'm well past this point in my learning of Go, but I have to assume others could benefit from an official version of sorts of this type of information.

Because the Go team cannot know all uses of Go and what project layout each type of project would benefit the most. In general, just tossing a few .go files in the same dir will take you very far.

[SteelPhase]

I think I missed something in my original comment. This was at a time when I was moving from small one off projects, to something significantly larger at work while I was still learning an uncertain about what I was doing. I don't know the best solution, but it seems like there could be at least a bit more in that regard. Honestly even if it was a wiki page with some "hey this could be useful" comments regarding laying things out when the time comes.

[flowchartsman]

This blog post has always been a great place to start, and it's worth noting that @eliben, whose article I posted above is in the Golang organization. There's also this post by @rakyll (former Go Team member) and this one by @peterbourgon. These articles may not be quite as specific or official as some people might want, but like our earlier poster mentioned, everyone's needs are different, and the official guidelines have had a correspondingly broader scope.

Should is a tough concept in software engineering, and once you say things should be done a particular way, it's tougher to evolve and to develop new best practices. The more specific and proscriptive you are, the tougher it becomes, from my experience. Far better to have clear, philosophical guidelines describing the guiding principles of the language and how those can shape the reusable components you write. And I do think we have that.

Put another way: "it depends", and giving it a proper treatment involves, ideally, multiple case studies on "well structured" packages that take design, intent and API footprint into consideration, along with how those decisions were arrived at, why, and how they may have evolved through the life of the project. Perhaps theres some room for this in the Go Blog, but even then the answer is still "it depends", and what works for one package might not work well for another, even if the guiding principles are the same.

And, of course, when I google "structure golang programs", this repo is still on top, which is the crux of #117

[cep21]

22k stars shows there is a community need for something like this. I understand the "it depends" camp for complex projects, but there are guidelines that most people can agree with. For example, the vast majority of simple go projects, when they are starting out, have a go.mod at the root path with a package that probably matches the github repository. There's probably a LICENSE file and README file. They probably should check in their go.sum file. There should probably be a package_test.go file.

There are other best practices where their existence is important, even if the details are not. For example, almost all have CI, but we don't have to make a decision on which CI is best.

With 22k stars, the community is signaling a strong need for guidance on how to structure go projects. I believe it would be high leverage for an official voice, more recent than 2012, with access to golang.org, to guide people here.

[theckman]

I am not sure we can assume the user's intent when they star a project. I know for many it signals an interest to understand or explore a project later. It does not mean that they have a need for it. I star some projects I never use, nor ever have a need for.

[masakatsu-corp]

@rsc Does the Go team have an official project layout pattern?

[xhit]

Go doesn't have an official project layout.

I always use the layout like here: https://github.com/golang/go/tree/master/src and itś simple: a folder with that package and all related.

Go is simple, I don't know why developers want to use patterns of others languages here.

[theckman]

@xhit considering we have go fmt to consistently style source code, I could see some then wanting or even expecting to find a style to use consistently to structure their project. I think there are some patterns we've discovered over the years that can help projects be more easily maintained, but I think that's much different that some sort of one-size-fits-all "standard" layout.

[SteelPhase]

I think an excellent start to anything even remotely like this could just be to point out the resources you've all been dumping as alternatives. There's all this great info spread all over. Should be enough to at least have a wiki page that you can point people to, when they've been mislead. It's also a good option incase this org sticks around longer.

[clausecker]

I think discussions about a standardised project layout miss the point. Go encourages you to derive package names from the last path component. When importing multiple packages, you want the names of the packages you import to be unique to avoid naming collisions. A standard layout would mean that it's very likely that many of the packages have the same, standard names and hence collide. This is to be avoided. So in order to make for a good programmer experience, the layout must not be standard but rather custom and different for each project.

I believe that people overthink this way too much. Just let your projects grow organically. Except for a few hard coded directory and file names (like vendor, testdata, and go.mod) you are free to chose whatever directory names you like. You should make full use of this freedom and put your stuff into whatever directory name seems most appropriate for the problem at hand. And if this choice turns out to be a poor one, you can always refactor later.

[krak3n]

I think that this stems from new people coming to the language looking for guidance on best practices for project layout out. This is especially true if you come from a very well structured world like Django, Flask or Rails and so on where project structure is defined for you, this is where you put your handlers and your models go here etc etc.

Coming to go where that safety net does not exist can be a little daunting for new comers, for myself coming to go from the Django world I struggled with how to layout projects, "I was always asking myself am I doing it right?" and while the correct answer is that there is no right way, only the way makes sense for what you are building, the golang-standards/project-layout gives a guide to how you might start and grow from there.

I've long stopped laying out my projects specifically like this because I've grown in experience and naturally figure out project layout on the fly and it's naturally evolving as the codebase grows and evolves, things will move around a bit and thats ok.

Perhaps the issue is that this project aims to be THE way to layout a go project when really it's more like a here is a place to start to inspire you. It's certainly not the standard way though.

[lyonnee]

Not long ago, I also encountered such a problem. I used to be engaged in the development of other languages ​​and have certain development experience. When I want to use golang to develop a project, and for this to establish a good code directory structure, I am confused. Later, after looking at this project and understanding the compilation rules of golang, I developed a "standard layout" of my own project.

[auula]

As a young gopher, I prefer simplicity,i like the layout list :

• https://github.com/golang/go/tree/master/src
• https://blog.golang.org/package-names
• https://golang.org/doc/effective_go

[batara666]

Yeahh, let's delete this missguided repo

[bitfield]

I have some sympathy with @rsc about this (OK, a lot of sympathy). I don't think the layout shown in this repo represents either the best way to structure Go projects, or even the most common way (those are quite different things, as you'll appreciate).

That said, though, I guess the author of this repo can publish whatever he wants, even describing it as a "standard", and no one can say boo about it—not even Russ. That's the joy and the hurt of open source. No one is obliged to pay any attention to the maintainer's ideas about Go project structure, and the flipside of that is that he's not obliged to pay any attention to us. If someone thinks they can do better (and the Go team would seem to be an obvious candidate for this), let them go ahead and do so.

I read about a dozen blog posts a day about Go which are (in my opinion) at best misguided, and at worst positively harmful. It would be a full-time job for me to try to get the authors to change their minds, and posts, and it's none of my business anyway. Instead, I publish my own opinions, and let Gophers decide whose ideas they like best. That seems to me a sensible way of going about things.

[batara666]

@bitfield The org should be renamed. It's that simple.

It's misleading, it harms devs new to Go.

It's ok that Go doesn't have a standard project structure. Any given project's structure is a function of its size, complexity and type.

Go is versatile, so it makes sense that there would be a bunch of different structure choices depending on what exactly your project is.

It also fits that new devs would be looking to better organise their code once the single main.go starts to get a bit out of hand, especially when coming from a file per class language. They search Google, they find this repo. Because of its name not its readme.

It's very easy to miss that comment in the readme. It's by no means a sufficient disclaimer. That comment is a massive copout from the owners because they know they'll get no further traction if they renamed the org. Maybe they should instead focus on demonstrating how different potential project layouts could fit different use cases, and make it actually useful to new Gophers with some signposting of that nature. "Start here with a basic layout", "here's one with a bit more organisation", etc.

[clausecker]

@m2q The standard opiniated directory structure for Go is no directory structure. Name every package according to its function. Chose unique names, not names everybody else uses. No fun programming if you import 10 packages named util. And do not add boilerplate path components like src, util, or pkg. Nobody needs that.

Perhaps the only thing resembling a convention is having cmd for main packages as the second-to-last path component. And of course the few hard-coded directory and file names.

[colin-p-hill]

It's fine to put out a recommended layout, even one that may be imperfect. @bitfield is right to point out that there are plenty of blog posts with questionable suggestions out there. I'm not sure this can be put into that bucket, as blogs published under the names of individuals or organizations will be generally understood as reflecting only the author's perspective. Who would have the audacity to call their organization "golang-standards" if they have neither the authority to set standards nor consensus from the community that what they are promoting is a best practice? It's not uncommon for new gophers to make the fairly sensible assumption that the answer to this question is "nobody", and rather than pursuing further perspectives, they take this repo to be the final answer that its name implies it to be. (No, a disclaimer in the readme does not adequately mitigate that. How often do you read a readme from top to bottom?) It's a fine project, but an irresponsible name, and it would be tremendously helpful to the community if the name were changed to convey the humility which I'm sure the author intended to bring to this project.

[quenbyako]

Lol, i have a great idea:

If this layout is not official (yet, maybe), instead of renaming, why not to work on it? 🤔 I mean, go still doesn't have best practices of directory layout (unlike rust, dart, etc. note that they have recommendations, not restrictions), why not create a recommended only standard of layout (only as recommendation, like effective go, gofmt, etc.) that suits most of gophers tasks including language core developers?

People say here right thing (like @flowchartsman): go is so simple that you can write the code as you feel it and it looks good. Honestly, this repository is not needed at all in current status 😂 but despite this, some kind of agreement is still needed where long-time gophers where to find specific logic with unknown project to them (for example, Kubernetes and Prometheus are rather complex sources, but at the same time coode looks slightly similar, I do not want to be tied to this particular projects or this repository at all, so with such recommendations it is easier to understand where someone else's code stores and how it relates to each other.)

The question is not so much in standardizing the layout, but in explaining to newbies how long-time gophers are storing their code by functionality

guys how dislike it: instead of being toxic, explain your opinion. I look at your thumbs down and not fully understanding whats wrong with my comment, why not to explain your position?

[SteelPhase]

It seems that there is some confusion around suggestions about project layouts, and the resulting rigid package naming that would be involved. If you take this repo without the golang-standards name, and remove the pkg idea, a lot of these folder suggestions aren't inherently bad. Most of them are related to supporting pieces for a project that aren't specifically go code, but which may live with it. If something official were to surface, it can certainly be presented in a way that avoids most of this confusion. The key thing to it is to start simple, and know that the layout is free form. If a project does start to grow, it's not bad to have some suggestions further on in the documentation that can offer guidance if wanted.

[rsc]

There are two problems with this GitHub repo:

1. it claims to host Go standards and does not, in the sense that these are in no way official standards
2. the project-layout standard it puts forth is far too complex and not a standard

Regarding "why not tell us the standard Go project layout and we'll update the doc?", that only addresses point 2. If there really were standards, they would be in the main Go project doc tree. The standard for project layout would also be a lot shorter. I appreciate your trying to provide a useful resource, but calling it 'golang-standards' is claiming more than it is.

But for the record, the minimal standard layout for an importable Go repo is really:

• Put a LICENSE file in your root
• Put a go.mod file in your root
• Put Go code in your repo, in the root or organized into a directory tree as you see fit

That's it. That's the "standard".

In particular:

It is not required to put commands in cmd/. It is not required to put packages in pkg/. It is not required to put web stuff in web/. It is not required to put APIs in api/. It is not required to put web stuff in web/. It is not required to put configurations in configs/. It is not required to put systemd scripts in init/. It is not required to put shell scripts in scripts/. It is not required to put Docker files in build/package/. It is not required to put CI configs in build/ci/. It is not required to put deployment configs in deployments/. It is not required to put test support in test/. It is not required to put documentation in docs/. It is not required to put supporting tools in tools/. It is not required to put examples in examples/. It is not required to put third_party code in third_party/. It is not required to put git hooks in githooks/ It is not required to put static assets in assets/. It is not required to put website data in website/.

The importable golang.org/x repos break every one of these "rules".

[deltamualpha]

I suppose we can just chat away in this issue all we like, but clearly, the owner of this organization is @kcq, who seems to be studiously ignoring the concerns that have been repeatedly expressed about the positioning of this repository to newcomers (and experienced gophers) who see it as actively harmful to the language. Unless he changes his mind, I doubt anything anyone says here (or any further disclaimers added in PRs to the README) will help.

[batara666]

This the exact project which lured me in and led me astray a while back. It has the outward appearance of being a sensible proposal for a standard, but in practice only made things hard.

We need to take this problem seriously, I don't want Go Newcomer misguided using this layout for their project* (which can be easier to do in a flat format or other simpler format)

[Integralist]

@rsc I'm curious, if there is no response from the actual owner of this organisation (†), is the next step for Google to approach GitHub and express all the concerns this issue raises? Or would that be frowned upon (i.e. consider bad form)? At the very least this org is very misleading and from that perspective alone I feel a rename would be justified.

† which it seems there has been none for over three weeks from what I understand

[komuw]

I don't support the layout proposed by this repository.

However, the way to combat flat-earthers is not to hound them out of town. Rather it is to avail science education far and wide and then hope people will come to the right conclusions on their own.

There is clearly a need for documentation on how to layout a Go project. Maybe it is from people who are coming from languages where this is mandated, but the need is there as relevance/SEP of this repo shows.

Whereas, many be of the opinion that we do not need an official Go layout. Maybe it is time the Go project did create one somewhere on blog.golang.org, or pkg.dev, or github or wherever. That documentation could start with a disclaimer like;
It is not required or expected for anyone/any-project to follow this layout ......

Do not hound out flat-earthers.

[vk-rv]

This made my day because a lot of well-known people in the community finally paid attention to this repo which is obviously overrated. This might be hard to believe, but a lot of engineering teams just insist on this structure without a reason.

Newcomers need a mental model, not an overwhelming amount of arbitrarily-designed empty folders.

Still relevant https://github.com/golang-standards/project-layout/issues/41

[thejerf]

Some others are dancing around this, but I don't have a need to personally, so I won't. @kcq, Google owns a trademark on "Go". @rsc may not even be remotely considering action in his personal capacity, but you, @kcq, would still be well-advised not to just to ignore this hoping it goes away, because you have no way of knowing that. You need to treat this as something worth worrying about. I have personally witnessed exactly the sort of confusion around this repository that is exactly the sort of things trademarks are designed to prevent.

I mean this as helpful advice, @kcq, not a threat, because I am unassociated with Google and I, personally, have no capacity or desire to harm you. I'm giving you friendly advice that just ignoring this and hoping it goes away is a bad plan.

[nomad-software]

This repo should be removed because I have seen people shoving this layout as 'standard' when of course it isn't. This is exactly the reason Go was created, to avoid this boilerplate nonsense.

[nikolaydubina]

great to see @rsc chiming in here. my two cents:

• /docs /pkg /cmd or alike are useful for separation of application, domain, infra code and module level metadata
• /deployment /test I see this a lot too, and also makes sense to put Docker and build related files and integration and E2E tests
• /third_party I haven't seen anywhere expect my projects where I used submodules and followed C++ style

[biorisk]

Open source is great because the threat of forking encourages lead developers to be responsive (or gives the community an out, e.g., Gogs vs Gitea).

Open trademark is NOT a thing for good reason too. Lot's of open source projects forbid the use of the name, logos, etc. because it would be confusing, just like the name of this org/repository. Can you imagine someone slapping a GPL "open-source" license on a bunch of widely used code where GPL stands for "Generally Pay me Lots"? If someone did, I would hope that the FSF or GNU would go after them hard for trademark infringement to avoid lots of people getting burned by confusion.

Personally, I hope the Go team will use trademark law the way it is intended to clean up this persistent problem in the Go community. I have to point out to every new team member at my company that our policy is to forbid this repository as a reference point for our code base.

[peterbourgon]

@rsc

The minimal standard layout for an importable Go repo is really:

Put a LICENSE file in your root Put a go.mod file in your root Put Go code in your repo, in the root or organized into a directory tree as you see fit

That's it. That's the "standard".

I think what we're witnessing here, in the broad strokes, is that this isn't enough.

Saying that we don't have to follow this or that guide, and that more or less everything is permissible, isn't helpful to the Gophers who are asking these questions. They, the community, is pretty clearly expressing a need for more guidance. And have been for a long time, for the record — a substantial portion of the questions that hit /r/golang, the Gophers Slack #newbies channel, etc. are related to project and repository structure.

Not necessarily a set of inviolable rules. Not necessarily something codified as the One True Standard for all projects. But something with specific, proactive suggestions about structure and layout that's useful for most projects. Most languages offer something like this, and most developers expect it. Until and unless Go blesses something as the recommendation, we're going to keep seeing land grabs like this.

[xxbtwxx]

@rsc

The minimal standard layout for an importable Go repo is really: Put a LICENSE file in your root Put a go.mod file in your root Put Go code in your repo, in the root or organized into a directory tree as you see fit That's it. That's the "standard".

I think what we're witnessing here, in the broad strokes, is that this isn't enough.

Saying that we don't have to follow this or that guide, and that more or less everything is permissible, isn't helpful to the Gophers who are asking these questions. They, the community, is pretty clearly expressing a need for more guidance. And have been for a long time, for the record — a substantial portion of the questions that hit /r/golang, the Gophers Slack #newbies channel, etc. are related to project and repository structure.

Not necessarily a set of inviolable rules. Not necessarily something codified as the One True Standard for all projects. But something with specific, proactive suggestions about structure and layout that's useful for most projects. Most languages offer something like this, and most developers expect it.

Here's a detailed guide to repository structures. Start with a main package. As your project grows split it into packages that feel natural or maybe don't and keep everything inside the main package.

[theckman]

@biorisk I'd rather we not pursue the thermonuclear approach, as that could create further divisions within the community. We should work together and align on the best path forward, instead of dealing with lawyers. Seeing that happen would drastically change my opinion on things.

Also, is "Golang" trademarked? They are very clear that the name is Go not Golang, and that go.org wasn't available at launch so they chose golang.org.

[dist1ll]

@peterbourgon absolutely hit the nail in the coffin.

The answer just isn't satisfying. Some (especially new) developers don't want to "find their own way" - often out of fear of maybe creating bad habits. Giving proactive suggestions with a few examples is all it takes to satisfy these worries.

I feel like deleting this repo until some solid alternative exists is a bit premature

[theckman]

@m2q this can be moved to another GitHub organization, or onto @kcq's user, without impact. GitHub would redirect anyone to the new location. I think that would be preferable instead of a full-blown deletion.

[kcq]

Great to see @rsc starting this discussion here. Thank you! Would be nice if it was a bit more balanced, but people who are happy users are less likely to comment :-) I'd second what @peterbourgon said and add a couple of comments...

what is described here is just very complex <- None of the patterns are prescribed and required. It's explicitly stated (multiple times) that you should take what works for you and leave the rest. A .go file with your app code and go.mod is all you need when you get started. However, eventually you outgrow that...

There are enough disclaimers about the nature of this repo and its intended goals. If a few misguided people (who didn't read the description or who do it intentionally) misrepresent it as the official Go language standard then it's a problem with those people.

It's really an opportunity to have a discussion about what makes sense for your team, your environment and your application. It might end up something completely different. It's a starting point to kick off the discussion and that discussion can be, here's everything we don't want to do :-)

[SteelPhase]

@kcq As you really didn't touch on it, I don't think there's anything in your comment that provides a reason for keeping the organization name as it is.

[kcq]

@kcq As you really didn't touch on it, I don't think there's anything in your comment that provides a reason for keeping the organization name as it is.

Thank you for your comments @SteelPhase ! You are absolutely entitled to your opinion and it's great you are sharing it. I'd say the 3rd paragraph covers it :-)

[theckman]

If a few misguided people (who didn't read the description or who do it intentionally) misrepresent it as the official Go language standard then it's a problem with those people.

@kcq I don't think you are clearly interpreting the direct and actionable feedback being given to you by the community here. There aren't folks who are misrepresenting it as a standard and communicating it as such, there are many folks who are misinterpreting the purpose of this repository because of the name you've chosen to give it. The only way we can solve that is by moving the repository, so that you are no longer even hinting at you being some sort of Go standards body.

I'd like to strongly encourage you to come hang out more in the Slack space, especially the #newbies channel, where a substantial number (not few) believe this to be a standard repository because of the name (and solely the name). I think that would greatly change your perception of the impact you're having on the community.

Edit: I've just taken a look, and I see that you are a member of the Slack space but have seemingly never engaged.

[idexter]

@rsc @rakyll @peterbourgon Why it's impossible to create https://github.com/golang/standards or https://github.com/golang/golang-standards repository and propose more "official" or more appropriate "community" point of view. Some of community members have thousands followers and huge influence to do that. Why is it so important to rename (or maybe get rid of) exactly this repository?

I read all related issues:

• https://github.com/golang-standards/project-layout/issues/52
• https://github.com/golang-standards/project-layout/issues/41
• https://github.com/golang-standards/project-layout/issues/38
• https://github.com/golang-standards/project-layout/issues/36
• https://github.com/golang-standards/project-layout/issues/10

To me personally it looks like a small group of people is using their power and influence to force their personal opinion like "community". And that group of people use their followers and their power to force that opinion but not to solve an real issue. (It's my value judjment, I can be wrong. I'm person from different culture. I'm not from US)

[peterbourgon]

@kcq

There are enough disclaimers about the nature of this repo and its intended goals. If a few misguided people (who didn't read the description or who do it intentionally) misrepresent it as the official Go language standard then it's a problem with those people.

If a few people occasionally misunderstand the scope and goals of this repo, it might be an issue with those people. But if many or most people consistently misunderstand this repo, it's an issue with the repo. And we've been trying to communicate to you, for a long time, that this is the case.