search

golang-standards / project-layout

Standard Go Project Layout
Other
49.02k stars 5.11k forks source link

#117 must be closed and locked #119

Open quenbyako opened 3 years ago

quenbyako commented 3 years ago

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:

cons:

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:

@flowchartsman share these pretty useful posts:

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

@itsjamie shared this post:

So #117 must be stopped. For community health.

xxbtwxx commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

I made a long comment in issue https://github.com/golang-standards/project-layout/issues/117#issuecomment-830039460 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 commented 3 years ago

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 commented 3 years ago

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

souryogurt commented 3 years ago

@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 commented 2 years ago

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 commented 1 year ago

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