You’re twisting my argument. I’m not saying maintainers are obligated to make their code production ready. I said their READMEs should accurately represent the state of the project.

If you, or anyone else, thinks that is an unfair assessment or that I should have to pay for a README not to claim to be production ready when it’s a POC, then you had a very weird view on how much effort it takes to write the line “this is an untested beta”

▲

jjav 7 hours ago | parent [-]

> I said their READMEs should accurately represent the state of the project.

The state of expectations is usually in the LICENSE file, not in the README. But it's there in the repository, in most cases.

I do agree that some maintainers forget to include the LICENSE file (or equivalent), which is a mistake. The terms of use are quite important.

	▲	hnlmorg 5 hours ago \| parent [-]
		> The state of expectations is usually in the LICENSE file, not in the README. No it’s not. LICENSE tells you what you can do with the code. It doesn’t tell you the state of code. Again, I need to reiterate my point that I’m talking about whether the code is beta, tested, etc. It costs nothing for a maintainer to specify how complete a code base is. It’s then up to the consumers of that package to decide if they want to use it, contribute back or just fork it. All I’m saying is too many GitHub repos are written for CVs; as if they’re meant to be consumed by Google. If something is a weekend project then just be honest and say “this is a weekend project written to solve my specific use case but PRs are welcome”. Thats better than having long blurbs that refer to the solo developer as “we” and all the other BS people stick into their READMEs to try and make their project sound better than it actually is. All I’m asking for is a little more pragmatism and honesty in READMEs. It’s no extra effort. It’s no extra cost. And I shouldn’t have to donate to projects just to ensure they don’t lie to me.