Hacker News new | ask | show | jobs
by Dayshine 2247 days ago
The problem of course is that if you have

- an open source project which you advertise as collaborative open source

- a personal vision for what you want in your project

- and hence, a secret list of requests you will turn down

Then frequently people might spend 10, 20, 30, 60 minutes trying to do something with your project then writing up an issue. You then immediately shoot it down, because it doesn't match your vision, and that person gets burned.

If you have MIT license and no guidance on contribution, that's user error. But if your project has a PR workflow or has that "Imposter syndrome" line about contributions, well, maybe it's partly your fault.

I'm not saying all open source projects should have guidance. But perhaps all projects with a CONTRIBUTING.md and ISSUE_TEMPLATE.md really should have a clear list of features they will outright reject.

1 comments

One thing that I’ve learned from the Kubernetes community is to have a list of “Non-Goals” right next to every list of “Goals” in documentation, and of course to have a list of “Goals” at all.