#117 must be closed and locked

[quenbyako]

I think I will take responsibility for this issue and propose to close #117, as it became as unhealthy cancelling and persecution of people who disagree with the author.

In order not to be unfounded, I will try to express as neutral as possible all the pros and cons of this decision:

pros:

• this repository mimics to golang officially standards, however golang has not any standards for the architecture of the code (which is a lie, since much parts of this repository is generally accepted in community)
• repository name confuses newbies trying to apply knowledge from django, rust, flutter, etc to go (which has not been proven by any contributor, even @rsc)
• layout is bloated, which is actually true
• layout tries to be universal to any go project
• readme warranty doesn't look helpful
• layout pretends that it is the only true layout in the world (which is even a big lie)
• at this moment only two guys thumbs down 117 issue, "everyone" agree with Russ

cons:

• THIS IS THE MOST IMPORTANT: the discussion spills out from slack and github, and I noticed at least 4 chats in telegram, and one discord server insults the participants because they disagree with @rsc. Unlike YouTube, github has a list of the first 6 people who responded to a post, so members are just afraid to put their thumbs down. such behavior is unacceptable not only in the go community, but in any other.
• term "standard" does not mean an officially accepted document, even the Cambridge Dictionary defines a 'standard' primarily as a pattern or model that is generally accepted, accepted in our community.
• the statement that the README warranty is not obvious is simply stupid: the READ_ME is created in order to read it before using the software. Those people who agree with this argument mostly agree that the readme should be refactored in order to improve the understanding by golang newbies the purpose of this repository.
• To demand from the author in an ultimatum form to rename the repository is at best uncivilized, at worst it is pure persecution. if this project bothers you, scold those who impose it on you, not the authors of the project.
• at the moment this is the most popular project, and instead of renaming it would be more logical to call @rsc @rakyll @spf13 @avelino @muesli @valyala (me? jk) and other famous faces of golang community and discuss how this project can be improved. This layout is important for the community, despite the fact that it is not of the highest quality. Agree with it or not, there are lots of people who see this repo useful.

At the same time, I would want to remind you about the story with @kataras who does not accept criticism at all (still not, yeah). Now an identical situation is became right here, but in the different direction: now people are starting to hound the author who didn't anything bad, and they also hound people who disagree with @rsc's position. and all this holywar for the sake of the "concerns they are raising"

---

I would also want to remind you that it is more logical to offer alternatives if you do not agree with someone's opinion. In №117 i already made this list of alternative best practices, but I will copy it here too, maybe it will help someone:

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 was the first who wrote good argument about standard layout of stdlib (which is well organized btw):

• https://github.com/golang/go/tree/master/src

@higker noted this go blog post:

• https://blog.golang.org/package-names

@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:

• https://christine.website/blog/within-go-repo-layout-2020-09-07

---

So #117 must be stopped. For community health.

[htemelski]

You couldn't misinterpet my words in a worse way, eh?

There's no idiomatic way for structuring your go repository, and that's a good thing.
As I said, start with a main package and let it grow in a natural way.

I'll refer to one of the Go Proverbs by Rob Pike Design the architecture, name the components, document the details.

I would say if you decide to have different packages, their names should be descriptive and give you insight to what the package is doing, and not some arbitrary names like api, datasource or repository.

[quenbyako]

@xxbtwxx you misunderstood the purpose, why this issue should be locked: one of the biggest problems of this holywar is unbelievable level of toxicity and abuse of go rockstars audience. The main reason to lock the discussion is that toxic judges like @batara666 who came here and fucking up all constructive discussion and arguments of both parties.

[flowchartsman]

While I agree that the discussion in the other issue has gone past the point of usefulness, I think this issue is even less helpful. It comes off as snide and mocking, neither of which are very professional, both of which tend only to upset people and make things worse. I won't presume that that's your goal, but that is definitely how it reads. I understand the impulse to lash out at something you perceive as frivolous, ridiculous or overly-pedantic, but it is never productive.

Instead of the impassioned defense you may have imagined, a backlash issue like this comes off as disingenuous, and a self-serving attempt to signpost your own views and further clutter the original with references. There doesn't need to be another issue. A maintainer will lock/close/comment/resolve the original as they see fit.

[avelino]

I made a long comment in issue #117 (comment) sharing my point of view, I hope I made myself understood - I hope it helps.

@quenbyako thanks for mentioning me in the issue, as I commented in the other issue I am available to help the project.

[souryogurt]

So #117 must be stopped. For community health.

For community health, you should stop name it golang-standards.

You do not even realize how much time and money are spent in every team worldwide to explain to every noob that this repo is not standard and it is not required to overcomplicate the project structure, and it is better to start just with a single file. And that this repo is just the opinion of one unknown guy not affiliated to golang at all.

This is unhealthy. Not a discussion around it.

[quenbyako]

@souryogurt you didn't get the idea...

[souryogurt]

@quenbyako you should be more clear then. Otherwise, you spliting the discussion into one more issue instead of finding true and going to some conclusion in #117 .

[Elara6331]

If someone went to a project you're the number 1 maintainer of, made up a standard for it, and then published it under the name <project>-standards, you'd be upset, and rightfully so, because it's NOT a standard. You're trying to argue that there is a holy war, but there is no war to be had, because this is OBJECTIVELY not a standard. You cannot have an opinion about it because no matter what you believe or how much you like it, it's simply not a standard. If you like the layout, you are entitled to that opinion, but you cannot argue that this is a standard, because it simply, objectively, is not. Did I explain it clearly enough? Personally, I'd like to see this repo deleted entirely, but most people here just want the organization renamed, which I'd be fine with, though it would not be the optimal solution.

[kcq]

@quenbyako thank for sharing your opinion and trying to be neutral. There's been enough said about repo name. There's enough context in this and other issues, so people should be able to make their own decision after reading what's in these issues. Locking this discussion.