I thought the music was cool too. I'd kinda like to see it in more project READMEs. Obviously not half the page, but a nice little section of mentions. Could be a cool way to find new music.

Years ago when I worked on a team of folks with similar music tastes, I'd put the album link in PRs for feature branches. Just a way of saying, "this week, while working on this feature, I was listening to this". It was just a fun thing to do.

Maybe in addition to README, LICENSE, CONTRIBUTING, and so on, MUSIC should be standard practice for repositories. :)

Of course, I do all my serious coding while listening to the fine music of MASTER BOOT RECORD.

That was probably from back in the day. Hardcore Goland user now! The music was more to promote bands that some people would never have heard of.

I disagree and maybe I'm not 'fun', but to me there's a lot of garbage in this README. Scrolling through the plaintext document with lists of badges, manually managed table of contents, photos of contributors, miscellaneous HTML, you can see that there's so much content that isn't helping you understand the project—things that should be I a homepage or separate dedicated file. I can't read this without rendering it. The music while somewhat interesting, I don't think has a place in this document—especially linking out a proprietary music streaming platform.

Ease up on the high expectations. It's just a fun project on github, not a publication in an academic journal.

People love shitting on OSS projects. Tech choices, docs, tooling, testing, number of contributors (both "Too many!" and "Bus factor!"), choice of license, there is already X, why not use Y, we already did that in the 80's... Basically anything.

As if other people writing and sharing code freely is a huge problem.

I think it is different when a project is part of a commercial offering, or funded by something you participate in.

> People love shitting on OSS projects

People love shitting on closed source projects too, but the circle of people you can reasonably do that in is fairly limited.

Everyone can see this code, so you can shout it to the world.

Why does being closed source limit anything? People on hear openly shit on Apple, Google, M$, blah blah without limitations. Sure, with OSS you can leave shit comments directly on the project page, it's not like people are not screaming on Twitter or other socials about closed source stuff which I'd imagine has a lot larger of an audience than the smaller tech people looking at OSS project pages

Not only that, but it comes at a personal cost. Few OSS project maintainers will tell you this but time spent on the project is time not spent with family and friends. They invest in these projects too.

They did put it at the bottom of the README. I would understand your frustration if it was at the top or in-between important content.

.vscode committed to a repository is a bit of a warning flag to me. It tells me this repo is doing some non-standard stuff that needs special IDE configuration to account for.

Or it just includes some conveniences. A lot of my projects include a .vscode folder so that anyone who uses VS Code can debug the application right away. If you want to use your own IDE or even just run everything from the terminal, it all still works.

You can open the files in it and see what it does. It's absolutely nothing standard that you couldn't do without it. But having it committed will help others to use the same workflows more easily.

It contains some useful debug launch configs that would take time to work out otherwise, and also some settings that appear to make the Node part and Go part work it bit more nicely together.

I don't think there are any red flags there IMHO.

Sufficiently complex projects are going to need some IDE config to get everything running and integrated with IDE tooling.

No, they don't. At least nothing IDE specific. Most languages come with a way to configure dependencies and build configuration independently from IDEs. If your IDE is incapable of picking those up, your IDE is crap. If you want to keep your developers from having to muck about with IDE settings, put those settings into an independent repo. If your IDE is incapable of picking up configuration from a specific directory, again, your IDE is crap.

Does your CI read IDE settings or language specific settings? If you're depending on IDE specific settings in your pipeline, your entire pipeline is brittle.

So, no "sufficiently complex project" should need any IDE specific config in the project repo.

Did you actually read the files? It’s launch configs and an eslint config. So you’re saying an IDE is crap if it can’t discover all of the commands of your project? Your saying it’s crap because in a split go and typescript codebase it’s supposed to know you want eslint triggered on JS code only during save?

Using your logic, any IDE with a settings dialog is crap…

See how ridiculous this sounds? It sounds more so like you hate VSCode

> Using your logic, any IDE with a settings dialog is crap…

You are reading things into my comment that aren't there. Maybe you should reread it. Especially the part where I talk about the separation of project specific configs and general IDE configs. Or how your CI should be able to pick these things up.

> It sounds more so like you hate VSCode

What else are you seeing down there in the tea leaves? Did I say anything about VSCode?

Perhaps you misread mine. What common structure exists to define what commands, sub commands, and tests exist in a project? If I were to write a CLI app, can any of the jetbrains or other IDEs automatically detect what the sub commands are within my CLI? What structure would it read this from?

Golang certainly has no such file, so you’d have to read from the main package and understand every CLI framework out there to parse out the sub commands to build your launch configuration. Sounds real easy right?

Now if we’re talking about nodejs, where the package.json can hold your run configurations within the script section, then ok. But we’re talking about golang.

Nope. Just an old directory that made it in there at some point.

or using codespaces for development