this is not a standard Go project layout
rsc opened this issue · comments
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.
@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.
@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!
@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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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.
@rsc Does the Go team have an official project layout pattern?
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.
@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.
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.
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.
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.
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.
As a young gopher, I prefer simplicity,i like the layout list :
Yeahh, let's delete this missguided repo
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.
@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.
@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.
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.
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?
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.
There are two problems with this GitHub repo:
- it claims to host Go standards and does not, in the sense that these are in no way official standards
- 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".
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.
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)
@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
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.
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 #41
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.
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.
great to see @rsc chiming in here. my two cents:
/docs/pkg/cmdor alike are useful for separation of application, domain, infra code and module level metadata/deployment/testI see this a lot too, and also makes sense to put Docker and build related files and integration and E2E tests/third_partyI haven't seen anywhere expect my projects where I used submodules and followed C++ style
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.
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 fitThat'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.
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.
@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.
@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
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 :-)
@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 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 :-)
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.
@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:
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)
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.
@kcq I don't think you are clearly interpreting the direct and actionable feedback being given to you by the community here.
The gotcha here is that it's not the community... It's a few people who pretty vocal in their dislikes and that's totally fine.
@kcq Would you like me to ask folks from the Slack space to dogpile on this issue so that you get an idea of the breadth of this problem? I didn't think that would be helpful, and figured a conversation where you try to understand our perspective (instead of immediately dismissing, and blaming others) would be more constructive.
Would you like me to ask folks from the Slack space to dogpile on this issue so that you get an idea of the breadth of this problem?
If you do, I'd suggest linking to a single comment and asking simply for a thumbs up (I misunderstood this repo) or thumbs down (it was perfectly clear to me that this wasn't official at all), rather than exploding the thread.
@flowchartsman Ahhhh, good thinking! I would have made a real mess of things otherwise. 😅 I appreciate you sharing that idea.
I've been working with Go for over six years. During this time, repeatedly, many people with multiple backgrounds (that I know in person, from the web, or witnessed on Go chats) would suggest to me they were following Go standards, when, in fact, they were adopting some random ideas and concepts shared on this repo.
The name of this repo is no different than false advertising. Sorry, but it got to go. Please reconsider your decision.
This would be fine if you shared it under your name or in any other way. However, you're benefiting from people confusing things due to naming, and this is not fair. We're a community. Please don't treat us as SEO assets.
@kcq Would you like me to ask folks from the Slack space to dogpile on this issue so that you get an idea of the breadth of this problem? I didn't think that would be helpful, and figured a conversation where you try to understand our perspective (instead of immediately dismissing, and blaming others) would be more constructive.
It's actually a good idea to have more voices if we can move beyond, i don't like the repo name phase of the discussion :-) Let's talk about the project layout patterns and what alternative layout patterns work for different types of applications and for different application sizes including the applications with multiple binaries, different types of interfaces and deployment environments.
Strictly speaking community is tens of thousands engineers (from different companies, different countries and different cultures). Not 100 of them nor 1000 can represent the whole community. There should be at least 23k votes against this repo so it will be comparable with repository stars. Otherwise it looks like small group of people decide what is right and what is wrong which is inappropriate in free community.
@kcq that's a separate issue, and an important one. This issue is about the harm your project is doing to the larger Go community, and is unrelated to the overall desire that people have for guidance.
I'd encourage you to file an issue to track that other (unrelated) request in the Go issue tracker, to gauge the interest of an official set of guidance around structure from the Go project itself. Your project is not the right place to have this conversation.
@kcq why bother with the effort to add a disclaimer to a README when it could be resolved by not calling it "golang-standards" in the first place?
This sounds kind of blunt, but I think it's the most direct question that can be asked to get an understanding from you on that specific reasoning that relates most to this issue.
@kcq why bother with the effort to add a disclaimer to a README when it could be resolved by not calling it "golang-standards" in the first place?
This sounds kind of blunt, but I think it's the most direct question that can be asked to get an understanding from you on that specific reasoning that relates most to this issue.
@SteelPhase This is pretty simple... You are talking about your personal preferences in terms of how to communicate something and you are wondering why somebody else has a difference preference. It's ok to have differences in preferences.
@kcq Hi, I am a Go programmer that has largely changed over a lot of their personal projects to Rust, but I feel that I have some feedback as to why this seems to be confusing. Full disclaimer, I have made my own thoughts on repo layout on my blog, but I do not feel it useful to link it here as to avoid cluttering this thread too much.
Through events and circumstances this repo is the top hit on Google for "golang standard project layout". At some level this is quite an impressive feat. Getting to the top slot on Google is no small feat. However this also makes it seem like it has some level of "officialness" to well-intentioned people that may not be the most attentive when it comes to understanding the source of things.
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.
To me this reads like victim blaming a-la the "you're holding it wrong" saga of iPhone marketing. This feels like citing human error as a root cause in an incident. Human error is a symptom, but it feels very wrong to say "well you're holding it wrong" and stop there. This project has a repo that says "golang standards" in it. Even if it is not an authentic creation of the Go team, it gives this project the air of authenticity. It looks authentic enough and has a lot of detail to its proposal that it could pass off as something "official".
This is pretty simple... You are talking about your personal preferences in terms of how to communicate something and you are wondering why somebody else has a difference preference. It's ok to have differences in preferences.
This really feels like a case of accidental deception and is a case study of the unfortunate subjectivity of human language. The intent of this was likely to put a stick in the sand and document a standard for how to do this (something that either was modeled after or adopted by projects like Docker and Kubernetes) however it looks like the standard for how to do this.
This is what can make it feel deceptive to more seasoned experts (and I am sure is a good part of the root of the disconnect here). I've had several cases where coworkers that were new to Go start using this repo as if it was The Only Way to do things and ended up accidentally creating things that were very confusing (one of them had an internal/pkg folder for some reason).
The reason that people are saying "this should not be called golang-standards" is because doing that change is a very minimal, focused and effective way to solve the issue that is at the core of this issue. Studies of practical anthropology have shown that people do not read disclaimers (EULAs have trained people to tune them out
I hope this can shed some light on the issue and help you to understand the other side of the coin.
@kcq I don't think we're talking about personal preferences here. Whether or not I think what this repository recommends is a good idea is absolutely a personal preference. Whether or not a GItHub repo is the best medium to share this information is also a personal preference.
People new to Go and the community, in fairly large numbers, are interpreting your repo to be an official standard because of the name. That statement isn't me sharing a personal preference, it's an indisputable fact based on real experiences interacting with people in the community.
So far you've yet to offer competing factual statements, and instead have only shared your personal beliefs.
@kcq Hi, I am a Go programmer that has largely changed over a lot of their personal projects to Rust, but I feel that I have some feedback as to why this seems to be confusing. Full disclaimer, I have made my own thoughts on repo layout on my blog, but I do not feel it useful to link it here as to avoid cluttering this thread too much.
@Xe Thank you for your pretty big and well thought out comment! You do make good points, but I think the sample data set doesn't really reflect the full picture.
Line 2 of the search result says that it's not an official standard, so you don't even need to read the full description. If the first line all we can read then there's no hope for humanity :-)
P.S.
Please do include your blog post! It'll definitely help others when they are making their decision even if it's against everything in this repo.
@kcq I realize you're trying to pretend this isn't really about you protecting your absolutely amazing SEO on this repo, but this is a bad take:
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.
This is no different than saying that the elderly people who get tricked by fake Microsoft tech support are at fault for falling for the scam.
You had a better position when you were ignoring the thread and not doubling down.
@Xe Thank you for your pretty big and well thought out comment! You do make good points, but I think the sample data set doesn't really reflect the full picture.
Line 2 of the search result says that it's not an official standard, so you don't even need to read the full description. If the first line all we can read then there's no hope for humanity :-)
I hate to be blunt, but please re-read the bolded portion of my response.
The reason that people are saying "this should not be called golang-standards" is because doing that change is a very minimal, focused and effective way to solve the issue that is at the core of this issue. Studies of practical anthropology have shown that people do not read disclaimers (EULAs have trained people to tune them out frowning_face) so just adding a "hey this isn't official from the Go team" disclaimer is not an effective action.
Please do include your blog post! It'll definitely help others when they are making their decision even if it's against everything in this repo.
I do not want this comment to become advertisement. I can email you a link to it if you would be okay with that.
Your statement does not appear in all google searches.
Studies of practical anthropology have shown that people do not read disclaimers (EULAs have trained people to tune them out frowning_face) so just adding a "hey this isn't official from the Go team" disclaimer is not an effective action.
Thank you for the follow up @Xe ! It's an interesting analogy, but it's flawed because this repo is not a piece of software that you just use and where you click through a EULA you don't read. If you actually use the repo you'll see the first paragraph in the readme file.
It's an interesting analogy, but it's flawed because this repo is not a piece of software that you just use and where you click through a EULA you don't read. If you actually use the repo you'll see the first paragraph in the readme file.
I feel that there is some kind of disconnect preventing my point from getting across. My intention there was more of "that is a disclaimer, people skip over disclaimers" and used EULAs as an example for the kind of thing people skip over. Your disclaimer is NOT a EULA, however it seems that based on observable evidence is getting skipped over as if it was one.
This is why people are saying you should rename the org.
This discussion is absolutely useless.
The person who made this repository (@kcq, btw) most likely looked at a lot of golang projects and thought "hmm, usually gophers put assets in the /assets directory, and the main package is usually stored in the /cmd, so I'll create a repository as sort of template that stores an EXAMPLE project structure". This is all th appointment of the repository! (@kcq correct me, please, if i am wrong, but it seems to me, it's absolutely obvious that this page is just a collection of variations and visual example where to put some code, and not a mandatory project structure, as in rust) Here people say that, "ooga booga, you see, /deployments not always needed, because it is not required for all projects". Seriously? Are you guys really arguing about this?
Yes, the organization is called golang-standards, so what? This is the part of the open source, everyone can call their projects what they want and upload to public what they want. I have a lot of respect for the participants in this discussion (no, I'm serious, there are many respected people in the golang community, not only @rsc, and that's amazing, I respect work of all guys here), but cmon, seriously? this issue already contains 70+ comments, 1000+ reactions and uncountable quotes in different blogs. For what purpose? For deleting this repo? for renaming org to golang-standards-but-its-not-cuz-community-againsted-about-it? Or what this discussion about? Isn't it more reasonable to offer a set of links to good articles (which, by the way, has already been done in this issue and this is amazing, half done 💪) and leave this project alone? this layout, if you haven't noticed, is supposed to be used in services, applications, but not in libraries. It is more likely to be applied to any application written in any language. it is still not necessary to fit every lib to this layout (and it is still more harmful to libs, instead apps and services)
And, btw here i collected links for good blog posts from these issue comments which explain how to avoid this repo and store code better:
Most good articles from @henvic:
- https://golang.org/doc/effective_go
- https://github.com/golang/go/wiki/CodeReviewComments
- https://github.com/golang/go/wiki
- https://golang.org/ref/spec
@flowchartsman share these pretty useful posts:
- https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/
- https://blog.golang.org/organizing-go-code
- https://rakyll.org/style-packages/
- https://peter.bourgon.org/go-best-practices-2016/#repository-structure
@xhit is first who wrote good argument about standard layout of stdlib (which is well organized too btw):
@higker noted this go blog post:
@xxbtwxx shared amazingly bad structured repo (read as, how not to layout your code, and why use this is really bad):
- https://github.com/Shopify/sarama (too funny and too sad lib at the same time, unfortunately)
@itsjamie shared this post:
(i'll try to update this list until this issue will be closed with no org changing, lol)
For what purpose? For deleting this repo? for renaming org to
golang-standards-but-its-not-cuz-community-againsted-about-it? Or what this discussion about?
@quenbyako I don't believe the request has been to delete the repo. So far, it's been requested that things be renamed in a way that make clear to everyone that it's not trying to assert itself as a standard.
That's it. That's the "standard".
I think what we're witnessing here, in the broad strokes, is that this isn't enough.
at some point, you must make decisions for your own code. beware anyone that tells you how to do something they've never done.
do what's right for your own code, if there is even a right or wrong way to organize your code.
the amount of time that people spend discussing things that do not matter is absolutely staggering, to me.
@theckman if so, let's create same issue to github.com/lib/pq, or naaah, there is the better project: github.com/pkg/errors. I heard a lot of comments that pkg/errors is official github package and everyone must use it instead stdlib errors cuz package name looks like golang.org/x (not kidding).
Let's also cancel https://github.com/go-kit/kit, cause it has standard word in description, literaly:
A standard library for microservices.
As an alternative style, I present https://christine.website/blog/within-go-repo-layout-2020-09-07
This aligns with my understanding of the few pieces that I did see as "normal" setups for Go repositories out of the gate. It recommends and makes use of the internal enforced folder. It also showcases how to set up a multi-binary repository, with easy naming of the output binaries. It also provides a few guidelines on package structure by usage rather than the pkg folder being an unenforced "public API" code folder that if I recall correctly came about because of Kubernetes early on taking that stance.
It's disingenuous to say that this repo isn't positioned as a one-size-fits-all model when people are building things like #111, trying to make commands that automatically populate new projects with this repo's folder structure (à la rails new or yeoman).
The point of this issue isn't what the "standard" should be, it's that this org's name is actively misleading for beginning go developers.
Through events and circumstances this repo is the top hit on Google for "golang standard project layout". At some level this is quite an impressive feat. Getting to the top slot on Google is no small feat.
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.
To me this reads like victim blaming a-la the "you're holding it wrong" saga of iPhone marketing. This feels like citing human error as a root cause in an incident.
It also feels like we are also doing the same thing to the owner of this repository that we are also accusing him of: victim blaming.
Their repo didn't become the number one result on google just because they titled it Golang standards layout, just like my blog wouldn't become the number one blog post on google if I titled it the standard way to climb Mt. Everest.
This repo has climbed upto the top of search results based on a lot more signals than just its name. People who use Go(or who intend to use Go) are giving a very strong signal to google(search engines) that they desire to know what is the right way to structure a Go project. And google on their part, lacking a more official page where they can point people to; have to fall back to the next best possible alternative.
The fact that this repo is the next best possible alternative is not a failing on the part of the repo owner; that blame lays elsewhere.
The way this community will move forward is for more official resources to be created where the community has shown a need for such to exist. It may be in project layout as the case here, or in Go modules etc.
Where official resources are missing or lacking, someone else will always step forward to create something to satisfy that need; and what they create may not end up being to your/our liking. But we can't then turn around and point fingers at them.
So let me take this opportunity to thank @kcq for having stepped in to fill this void.
I do not like the recommendations in this repo. I do not agree with them. I think they are wrong on so many fronts.
But google with its mighty AI brain seems to think otherwise. And it will do so until a more official standard is created.
There is no escaping the great algorithm. The AI overlords are here, let me get some tea.
As somebody that started coding in Go the last two week,
I read so much hatred, complaining, pointing fingers in this thread against a person that took ownership of trying to obviously improve the community, that it is quite disappointing and disgusting.
Your "it depends", and "I think X", or "my opinion Y" solves no problem, suggest no solutions, and rarely have any value compared to what the person took upon himself by maintaining this repo.
Disappointing.
As somebody that started coding in Go for a month
I find this kind of structure is annoying when come to middle-to-big project
We can always go with Flat Structure, but my coworker choose this layout, It's really pain in the *ss maintaining a project with this layout tho
People new to Go and the community, in fairly large numbers, are interpreting your repo to be an official standard because of the name. That statement isn't me sharing a personal preference, it's an indisputable fact based on real experiences interacting with people in the community.
@theckman That statement is absolutely personal opinion. To make it indisputable fact you should provide specific numbers (not abstract one) with evidence.
Here is some indisputable facts (All those facts is easy to check):
- @theckman is Netflix employee
- @rakyll is Amazon employee
- @rsc is Google employee
- @eliben is Google employee
- @peterbourgon is a member of https://github.com/golang
Other indisputable facts:
- Those people have thousands of followers and they are significant influencers in the Go community (I personally really appreciate all good things you are doing).
- Some of those people are "rock-stars" and even creators of Go (Thank you for that. You made awesome job).
- Some of people against this repo are their followers (It's absolutely fine. It's ok to have different positions).
And here is disputable part and personal opinion:
- Small group of FAANG employees (even if they rock-stars and significant influencers) can not represent whole Go community of tens thousands of developers around the whole world.
- These people have huge power and a lot of resources to make their own repository and make it 1st in Google search
- Instead of this (during last 3 years) some of them and their subscribers (time to time) try to force their own opinion on things described in this repository and rename this repo or change some things inside this repo.
- I have no idea WHY, but it's absolutely harmful for the community.
- It's bad thing and it's an example of how people use their power and influence to dictate other people what they should do.
- People who do that should be censured for that regardless of their status and their contribution.
- If it's real Go community, I'm really disappointed about that community... 😞
@idexter i agree, so maybe these facts need to be shared with wide go community
I'm speechless
@rsc and the guys should create internal vote about action that may harm/misuse Go Language trademark
I feel bad for the Go core's maintainer which maintaining Go since the day 1, they know better & more capable maintaining the Go Project & It's community since the day 1
but, some stranger just come up and use the "standards" word with Go's Language Trademark
man, what kind of this victim-blaming nonsense
@idexter I don't involve myself in the Go community on behalf of Netflix. It's on my personal time. I'd prefer if you didn't involve my employer on my own personal opinions. 😄 I don't even personally often use Go at work.
@theckman Could you please show where exactly did I say you involve yourself in Go community on behalf of Netflix?
Looks like It's you personal interpretation. I just shown some facts and some personal opinions to show the differences between them. I'm sorry but it looks like you thought up and interpreted my words in your own way.
I feel bad for the Go core's maintainer which maintaining Go since the day 1, they know better & more capable maintaining the Go Project & It's community since the day 1
@batara666 Community it's not just people who make Golang and who maintain Go as a Project. Community it's all people who develop their applications with Go. If there is no developers who make their programs with some programming language, the language is useless. Btw I'm really respect all job Go team have done.
@batara666 did you just fastcoded thumbs down spam bot? Seriously, and you talking about community and its harm?
@idexter what?, why this getting personal? and who are you comparing people's contribution??
Community it's not just people who make Golang and who maintain Go as a Project. Community it's all people who develop their applications with Go. If there is no developers who make their programs with some programming language, the language is useless. Btw I'm really respect all job Go team have done.
yeah, keep victim-blaming "Go Community" for the sake of 22k stars & good harmful SEO Keyword
🍿
@batara666 uh-huh, good idea to blame "Go Community" instead real gophers, that's a good point, agree with you
So is there a reason why the org's name cannot be changed? Because this issue has become more of an argument and it would be nice to see it get resolved rather than dismissed due to the childish behavior.
yeah, keep victim-blaming "Go Community" for the sake of 22k stars & good harmful SEO Keyword
@batara666 My point is:
We all the community. @kcq also part of the community. I'm also part of the community and every person who disagree that this repo should be renamed also part of the community. And yes, every person who want to rename this repo also part of the community.
If you don't like some name, make your own repository and make it 1st in Google Search (Pretty simple, no?). We are in a free OpenSource environment. No one can force other people do something just because they don't like it. If this repository is breaks the law, ok. Where is the lawers? If not, it's not up to any of us force author to change ogr. name or repository.
Community it's not a lawyer, not a judge and not an war alliance. One part of community should not force other members of community to change their mind or force people to do what they want.
That is my PERSONAL OPINION and PERSONAL POSITION.
I've been undoing the cruft caused by this golang-standards/project-layout repository for years now. This isn't the origin of github.com/user/repo/pkg because it predates some of the earlier blog posts I've located while trying to track down its root cause, but it seems to have proliferated the practice significantly, especially for new users in the last five years.
I've actually considered creating this exact same type of issue in this repository before. My $0.02.
I've been quietly following this thread, and I agree with Russ that this repository as presented causes confusion, good intentions aside. And I do believe this project was created with the intent to help newcomers, even though I disagree with most of its advice.
The owner of the organisation and Russ haven't exchanged many comments yet, so I'd encourage the rest of us to simply wait for now. More discussion from people not involved in this repository is unlikely to get us closer to a good solution. And we all know how badly GitHub deals with very long issue threads :)
I think the discussion went off the rails a bit. It looks like three different topics are being discussed right now:
golang-standardsas a name creating a false sense of affiliation with Go itself and doing harm in the community- the need for some guidance on Go application project layout
- some debate about the people raising concern about the name
As far as I can tell, noone is questioning 2. (I'm not gonna comment on 3.)
I think the original question is whether the golang-standards name serves the community's interests or not. The name obviously has a great marketing value, so it's easy to find. Some (I'd say prominent) Go community members are claiming that it causes more harm than does good, especially for those who are new to Go (despite the disclaimers in place).
I think that's what the owners have to decide. A responsible answer would be (given the above claim is hard to accept) that some reasearch needs to be done whether that's the case. I'm inclined to believe it is, but that's my opinion.
This discussion reminds me of golang/go#29639 about @gofrs being called "The Go Community". (It was renamed in the end for the benefit of the community)
Any resolution yet 🍿
It's disingenuous to say that this repo isn't positioned as a one-size-fits-all model when people are building things like #111, trying to make commands that automatically populate new projects with this repo's folder structure (à la
rails neworyeoman).The point of this issue isn't what the "standard" should be, it's that this org's name is actively misleading for beginning go developers.
If your watch #111 with comment and watch original repo with documentation, you'll see some information)
I've taken this "layout" like "base", cause it just useful for small, tiny projects. And provide possibility for everyone to redefine structure and files like they want, just write plugin.
And last: this project was written with first aim for personal purposes - to bootstrap new projects faster (you said earlier like rails new), but later i've decided to publish it.
I've taken this "layout" like "base", cause it just useful for small, tiny projects. And provide possibility for everyone to redefine structure and files like they want, just write plugin.
The issue is that it's kinda redundant. With the guarantees provided by SIV, semantic versioning and go.mod every package is fair game to be consumed by an external client. Hiding the "external" API under some extra folder doesn't make sense as that's not really how Go works. If you want to limit the surface area of your externally available API, there are already tools for that (internal / package security via name casing).
If it's a small project, having everything in a single folder works well. If it's a medium one, splitting by components/functionality/time of day the last commit works well. This is all reflected in the actual official advice IIRC.
If this repo reflected said advice instead of advocating against go.mod's best practices, I'm not sure as many people would be complaining.
Starting a project using the structure recommended by this repo is harmful because the maintainers can not look at the package root directory and guess the behavior. Also it's more to type, yes it's only 3-5 seconds added to type pkg/ everywhere but you need to multiply that by dozens or hundreds of maintainers, thousands of commits, and multiple years. As someone asked for an alternative, here's how I recommend authors organize their go projects:
start with main.go, main_test.go
if insufficient, move things into other files person.go, person_test.go adjacent to main
if insufficient, move things into package person in another folder
if insufficient, move things into new repo
Regarding the pkg:
The situation is even worse, because lots of projects actually don't follow the pkg convention and just using this directory as easy way to avoid placing all packages in root. I've followed some examples and was terrified by two things (1) people are giving incorrect examples without actually reading the code / fact-checking and (2) people are using pkg just for decoration, without any "you can import this" semantic.
The syncting project does not use internal, lib contains fairly big amount of packages that are not intended for general consumption or to be imported outside of projects. Same is valid (for some extent) for jaeger, istio, kaniko, prometheus, and many others, even for docker-slim from @kcq.
So, even examples are invalid and misleading in multiple ways:
- They place every package to
liborpkg, but it is highly unlikely that every package is intended to be exported (and even subject for backward compatiblity), breaking convention - Some packages from
pkgare using packages outside thepkg, effectively breaking convention - They are not using
internalat all, ignoring a really standard way to split exportable packages from non-exportable - Lots of
pkg/*packages have no package comment, so user can't really learn the package purpose, which makes semantic even more questionable
Now we are in situation when "standard" says that packages are placed in pkg to be exported by others, but in reality most projects are using pkg just as a src directory equivalent, placing semantically internal packages into pkg, this is a totally broken, inconsistent mess. Currently the pkg directory means nothing without context!
Speaking for myself, my sole and singular concern is the appropriation of the term "golang-standards".
I would suggest ceasing all discussion about what a repo should look like in this issue, since it is obvious it isn't going to have any effect here. There are other mechanisms for having that discussion in a place that might produce results; after all, what are the odds @kcq is going to accept a PR on this repo for what the community actually does?
If, perchance, you still don't understand why the hostility, @kcq, this is why: It is a socially-hostile move to claim such a term while at the same time visibly not having that level of support for it from the community. It is basically claiming a leadership position unilaterally. Anyone can claim whatever they like about how Go packages can be organized, I don't care, what matters is the confusion with it being "the official standard".
You are claiming to be a community leader by this naming scheme, and we are rejecting that claim en masse.
Personally, I don't think you are unaware of this. But it is possible you are unaware.
I will give you one last warning, though, in the spirit of "I have no power to do this myself so this can't be a threat from me". It is obligatory for trademarks to be defended, lest they be lost. Corporate America has learned to take this seriously. If this thread ever makes it to a Google lawyer, through whatever mechanism, it is going to be obvious to them what they need to do next.
You're really going to make life easier on yourself if, having had your fun, you change your organization's name now.
And not be cute about it either, like changing it to "not-golang-standards" or something equally obviously a finger in Google's eye, but to something that genuinely doesn't involve either the word or the concept of "standard" next to "golang", or any other way in which it looks like an official endorsement.
(This would be a genuinely bad idea. Programmers often mistake law for just another sort of code. It's not. Humans are involved. Things you feel like are cute tricks to get past a very coding-oriented viewpoint of the law will deeply fail to impress a human judge, who will call it bad faith. You'll turn a cease and desist that you can comply with for free into an actual suit for damages that you'll find much less enjoyable.)
You are in more danger here than you seem to realize.
If this repo were named https://github.com/kcq/project-layout with no further changes I think many fewer people would care about its existence at all, because it would be so much clearer that it's an individual and not "the go standards body". It's purely the organization name that people find so problematic.
I'm interested. 🤔 If @kcq move that repository, but will not remove or transfer the rights to golang-standards organization to other hands. Will it be a solution for community members who don't like this repository?
What do you think? @rsc @theckman @peterbourgon
@idexter Most of these people already posted what they thought on the idea of moving the repo to a new org. Did you miss these posts?
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.
#117 (comment)