> Here's the root of your misunderstanding. “Broken” is subjective, relative only to you.
This is not a misunderstanding. I want to know what other people subjectively think is broken, and their proposed fixes. So, if I agree with them, I can opt to use their fixes. A lot of time the developer does not want to maintain the added complexity, or does not agree with architectural or design decisions by the contributor, and that's fine. But I, as a user might agree with the contributor. it costs you, as the maintainer nothing to let people propose changes. nothing at all. as others have repeated many times on this thread, you're not even obliged to respond to PRs, it won't even cost you appearance or reputation. You're just annoyed, that's it, and instead of ignoring the thing that annoys you, the solution is hostility.
> That's marketing-speak. It is absolutely a demand.
If you have a contributor policy clearly defined, it isn't. When you publish a project for the public, people will use it, that's the expectation.
Perhaps if github linked your contributor policy that might help. You can also setup an action that will auto-close all PRs, commenting your contributor policy for everyone to see the reason. There are many ways to handle this, but people on this thread are choosing the lazy option that harms users the most. I think part of it might be that many of you have not dealt with projects that benefit heavily from PRs.
> I want to know what other people subjectively think is broken
And I do not. In fact I don't want to hear from anyone who uses my software at all, in any way. My software is for me, not for you, and not for them. If you think it's broken, make your own that isn't.
If your software is only for you, keep it private. Period.
When you make it public, the public have the right to fix it and share their fixes with each other. They can do it on another repo, but they discovered the code through your repo, so the easiest way is by linking it to your repo. If you don't want to hear from people at all, just publish the source without giving anyone access to the repo, or send notifications to junk folder, or use a lockdown bot like in the other post, host it on your own server and publish it on your own site, the solutions for you are endless. For the public, which you've exposed your software to, not so much. and that's the problem.
You should understand that this line of thinking is exactly why everyone is trying to require developers to identify themselves, sign their code,etc... We're depending on software too much to be tolerant of willful sabotage and reckless endangerment (e.g.: security patches).
This is not a misunderstanding. I want to know what other people subjectively think is broken, and their proposed fixes. So, if I agree with them, I can opt to use their fixes. A lot of time the developer does not want to maintain the added complexity, or does not agree with architectural or design decisions by the contributor, and that's fine. But I, as a user might agree with the contributor. it costs you, as the maintainer nothing to let people propose changes. nothing at all. as others have repeated many times on this thread, you're not even obliged to respond to PRs, it won't even cost you appearance or reputation. You're just annoyed, that's it, and instead of ignoring the thing that annoys you, the solution is hostility.
> That's marketing-speak. It is absolutely a demand.
If you have a contributor policy clearly defined, it isn't. When you publish a project for the public, people will use it, that's the expectation.
Perhaps if github linked your contributor policy that might help. You can also setup an action that will auto-close all PRs, commenting your contributor policy for everyone to see the reason. There are many ways to handle this, but people on this thread are choosing the lazy option that harms users the most. I think part of it might be that many of you have not dealt with projects that benefit heavily from PRs.