4 ms·

You just showed the poster-child of gatekeeping that is harming Open Source. Every contributor is valuable, it's in the name, the definition of "contribute".

by berkes 1y ago

You just showed the poster-child of gatekeeping that is harming Open Source. Every contributor is valuable, it's in the name, the definition of "contribute". Any bar to entry is bad, it certainly never is the solution to a different problem (not being able to manage all contributions). If anything, in the longer run, it will only make it worse. Now, to be clear, while I do think GitHub is currently the "solution" to lower barriers, allow more people to contribute and as such improve your Open Source Project, the fact this is so, is a different and other problem - there isn't any good alternative to Github (with broad definitions of "good") why is that and what can we do to fix that, if at all?

sneak 1y ago
Not all PRs are created equal.
- berkes 1y ago
  And that is good. Diversity, here too, is of crucial importance. It's why some Open Source software has sublime documentation and impeccible translations, while the other is technically perfect but undecipherable. It's why some Open Source software has cute logos or appeals to professionals, while the other remains this hobby-project that no-one ever takes serious despite its' technical brilliance.
- myfonj 1y ago
  Also don't forget that not all contributions are done through PRs or are actual code changes. There are folks that do tests, make MREs, organise issue reports, participate in forums … they all are also contributing: their time and efforts.
int_19h 1y ago
This is just blatantly wrong on so many levels. Proposed contributions can in fact have negative value, if the contributor implements some feature or bug fix in a way that makes it more difficult to maintain in the long term or introduces bugs in other code. And even if such contribution is ultimately rejected, someone knowledgeable has to spend time and effort reviewing such code first - time and effort that could have been spend on another, more useful PR.
- nicman23 1y ago
  lol go closed then
- deleted 1y ago
  [deleted]
- lpln3452 1y ago
  This isn't a platform issue — it's a problem with the PR system, and arguably with open source itself. If you're unwilling to spend time on anything beyond writing code, maybe keep the project closed-source.
  - majewsky 1y ago
    Or, more obviously, make it open-source, and make a big fat note in the README of "I will not accept PRs, this repo is just for your consumption, fork it if you want to change it".
    - int_19h 1y ago
      It's not a binary. Many projects do want PRs, but it doesn't mean they have to accept any random PR, or fawn over every contributor who creates an obviously low-effort one. It's perfectly fine to "gatekeep" on quality matters, and that does mean acknowledging the fact that not all contributors are equally valuable.
      - matheusmoreira 1y ago
        > fawn over every contributor who creates an obviously low-effort one It's that sense of superiority that pisses me off. Many maintainers condescendingly reply "contributions welcome" in response to user complaints. People like that had better accept whatever they get. They could have easily done it themselves in all their "high quality" ways. They could have said "I don't have time for this" or even "I don't want to work on this". No, they went and challenged people to contribute instead. Then when they get what they wanted they suddenly decide they don't want it anymore? Bullshit. You're making the assumption that these are "high quality" projects, that someone poured their very soul into every single line of code in the repository. Chances are it's just someone else's own low effort implementation. Maybe someone else's hobby project. Maybe it's some legacy stuff that's too useful to delete but too complex to fully rewrite. When you dive in, you discover that "doing it properly" very well means putting way too much effort into paying off the technical debts of others. So who's signing up to do that for ungrateful maintainers for free? Who wants to risk doing all that work only to end up ignored and rejected? Lol. Just slap things together until they work. As long as your problem's fixed, it's fine. It's not your baby you're taking care of. They should be grateful you even sent the patches in. If they don't like it, just keep your commits and rebase, maybe make a custom package that overrides the official one from the Linux distribution. No need to worry about it, after all your version's fixed and theirs isn't. Best part is this tends to get these maintainers to wake up and "properly" implement things on their side... Which is exactly what users wanted in the first place! Wow!
fhd2 1y ago
In spirit, I agree. In practice, if you get dozens of PRs from people who clearly did it to bolster up their CV, because their professor asked them or something like that, it just takes a toll. It's more effort than writing the same code yourself. Of course I love to mentor people, if I have the capacity. But a good chunk of the GitHub contributions I've worked on were pretty careless, not even tested, that kind of thing. I haven't done the maintainer job in a while, I'm pretty terrified by the idea of what effect the advent of vibe coding had on PR quality. I feel pretty smug the way I'm talking about "PR quality", but if the volume of PRs that take a lot of effort to review and merge is high enough, it can be pretty daunting. From a maintainer perspective, the best thing to have are thoughtful people that genuinely use and like the software and want to make it better with a few contributions. That is unfortunately, in my experience, not the most common case, especially on GitHub.
- arp242 1y ago
  In my experience low-quality PRs aren't that common, but I do agree dealing with them is annoying. You can't just tell people to go away because they did spend their spare time on it. On the other hand it's also garbage. Sometimes it's garbage by people who really ought to know better. IMHO low-quality issues are the bigger problem by the way, a problem that existed well before GitHub. But I just don't see how GitHub or a PR-style workflow relates. Like I said in my own reply: I think it's just because you'll receive less contributions overall. That's a completely fair and reasonable trade-off to make, as long as you realise that is the trade-off you're making.
matkoniecz 1y ago
> Every contributor is valuable, it's in the name, the definition of "contribute". No. I definitely seen people who created multitude of misleading bug reports, flood of stupid feature requests. I personally did a bit of both. There are people who do both repetitively, fill issue reports without filling requested fields. Or open issue again when their previous report was closed. I got once bug report where someone was ranting that app is breaking data. Turned out (after wasting my time on investigating it) that user broke data on their own with different software, through its misuse. There were PRs adding backdoors. This is not a valuable contribution. There were PRs done to foment useless harmful political mess. Some people pretend to be multiple people and argue with themselves in pull requests or issues (using multiple accounts or in more bizarre cases using one). Or try to be listed multiple times as contributor. Some people try to sneak in some intentionally harmful content one way or another. Some contributors are NOT valuable. Some should be banned or educated (see https://www.chiark.greenend.org.uk/~sgtatham/bugs.html https://www.chiark.greenend.org.uk/~sgtatham/bugs.html ).
- berkes 1y ago
  This can be categorized as "spam". Fighting spam isn't done by using unfamiliar tech, but by actually fighting the spam. With good contributor guidelines, workflows, filters, etc. Contributions that don't adhere to the guidelines, or cannot fit in the workflow can be dismissed or handed back. Two random examples of things I came across in PRS recently: "Sorry, this isn't on our roadmap and we only work on issues related to the roadmap as per the CONTRIBUTION-GUIDELINES.md and the ROADMAP.md" "Before we can consider your work, please ensure all CI/CD passes, and the coding style is according to our guidelines. Once you have fixed this, please re-open this ticket" That is fine, a solved problem. Using high barrier tech won't keep intentionally harmful contributions away. It won't prevent political mess or flamewars. It won't keep ranters away. It won't help with contributors feelings of rejection and so on. Good review procedures with enough resources, help prevent harmful changes. Guidelines and codes of conduct and resources and tech to enforce, help against rants, bullying or flamewars, not "hg vs git". Good up-front communication on expectation is the solution to people demanding or making changes that can never be accepted.

by berkes 1y ago

sneak 1y ago

Not all PRs are created equal.

berkes 1y ago
And that is good. Diversity, here too, is of crucial importance. It's why some Open Source software has sublime documentation and impeccible translations, while the other is technically perfect but undecipherable. It's why some Open Source software has cute logos or appeals to professionals, while the other remains this hobby-project that no-one ever takes serious despite its' technical brilliance.
myfonj 1y ago
Also don't forget that not all contributions are done through PRs or are actual code changes. There are folks that do tests, make MREs, organise issue reports, participate in forums … they all are also contributing: their time and efforts.

int_19h 1y ago

This is just blatantly wrong on so many levels. Proposed contributions can in fact have negative value, if the contributor implements some feature or bug fix in a way that makes it more difficult to maintain in the long term or introduces bugs in other code. And even if such contribution is ultimately rejected, someone knowledgeable has to spend time and effort reviewing such code first - time and effort that could have been spend on another, more useful PR.

nicman23 1y ago
lol go closed then
deleted 1y ago
[deleted]
lpln3452 1y ago
This isn't a platform issue — it's a problem with the PR system, and arguably with open source itself. If you're unwilling to spend time on anything beyond writing code, maybe keep the project closed-source.
- majewsky 1y ago
  Or, more obviously, make it open-source, and make a big fat note in the README of "I will not accept PRs, this repo is just for your consumption, fork it if you want to change it".
  - int_19h 1y ago
    It's not a binary. Many projects do want PRs, but it doesn't mean they have to accept any random PR, or fawn over every contributor who creates an obviously low-effort one. It's perfectly fine to "gatekeep" on quality matters, and that does mean acknowledging the fact that not all contributors are equally valuable.
    - matheusmoreira 1y ago
      > fawn over every contributor who creates an obviously low-effort one It's that sense of superiority that pisses me off. Many maintainers condescendingly reply "contributions welcome" in response to user complaints. People like that had better accept whatever they get. They could have easily done it themselves in all their "high quality" ways. They could have said "I don't have time for this" or even "I don't want to work on this". No, they went and challenged people to contribute instead. Then when they get what they wanted they suddenly decide they don't want it anymore? Bullshit. You're making the assumption that these are "high quality" projects, that someone poured their very soul into every single line of code in the repository. Chances are it's just someone else's own low effort implementation. Maybe someone else's hobby project. Maybe it's some legacy stuff that's too useful to delete but too complex to fully rewrite. When you dive in, you discover that "doing it properly" very well means putting way too much effort into paying off the technical debts of others. So who's signing up to do that for ungrateful maintainers for free? Who wants to risk doing all that work only to end up ignored and rejected? Lol. Just slap things together until they work. As long as your problem's fixed, it's fine. It's not your baby you're taking care of. They should be grateful you even sent the patches in. If they don't like it, just keep your commits and rebase, maybe make a custom package that overrides the official one from the Linux distribution. No need to worry about it, after all your version's fixed and theirs isn't. Best part is this tends to get these maintainers to wake up and "properly" implement things on their side... Which is exactly what users wanted in the first place! Wow!

fhd2 1y ago

In spirit, I agree. In practice, if you get dozens of PRs from people who clearly did it to bolster up their CV, because their professor asked them or something like that, it just takes a toll. It's more effort than writing the same code yourself. Of course I love to mentor people, if I have the capacity. But a good chunk of the GitHub contributions I've worked on were pretty careless, not even tested, that kind of thing. I haven't done the maintainer job in a while, I'm pretty terrified by the idea of what effect the advent of vibe coding had on PR quality. I feel pretty smug the way I'm talking about "PR quality", but if the volume of PRs that take a lot of effort to review and merge is high enough, it can be pretty daunting. From a maintainer perspective, the best thing to have are thoughtful people that genuinely use and like the software and want to make it better with a few contributions. That is unfortunately, in my experience, not the most common case, especially on GitHub.

arp242 1y ago
In my experience low-quality PRs aren't that common, but I do agree dealing with them is annoying. You can't just tell people to go away because they did spend their spare time on it. On the other hand it's also garbage. Sometimes it's garbage by people who really ought to know better. IMHO low-quality issues are the bigger problem by the way, a problem that existed well before GitHub. But I just don't see how GitHub or a PR-style workflow relates. Like I said in my own reply: I think it's just because you'll receive less contributions overall. That's a completely fair and reasonable trade-off to make, as long as you realise that is the trade-off you're making.

matkoniecz 1y ago

> Every contributor is valuable, it's in the name, the definition of "contribute". No. I definitely seen people who created multitude of misleading bug reports, flood of stupid feature requests. I personally did a bit of both. There are people who do both repetitively, fill issue reports without filling requested fields. Or open issue again when their previous report was closed. I got once bug report where someone was ranting that app is breaking data. Turned out (after wasting my time on investigating it) that user broke data on their own with different software, through its misuse. There were PRs adding backdoors. This is not a valuable contribution. There were PRs done to foment useless harmful political mess. Some people pretend to be multiple people and argue with themselves in pull requests or issues (using multiple accounts or in more bizarre cases using one). Or try to be listed multiple times as contributor. Some people try to sneak in some intentionally harmful content one way or another. Some contributors are NOT valuable. Some should be banned or educated (see https://www.chiark.greenend.org.uk/~sgtatham/bugs.html https://www.chiark.greenend.org.uk/~sgtatham/bugs.html ).

berkes 1y ago
This can be categorized as "spam". Fighting spam isn't done by using unfamiliar tech, but by actually fighting the spam. With good contributor guidelines, workflows, filters, etc. Contributions that don't adhere to the guidelines, or cannot fit in the workflow can be dismissed or handed back. Two random examples of things I came across in PRS recently: "Sorry, this isn't on our roadmap and we only work on issues related to the roadmap as per the CONTRIBUTION-GUIDELINES.md and the ROADMAP.md" "Before we can consider your work, please ensure all CI/CD passes, and the coding style is according to our guidelines. Once you have fixed this, please re-open this ticket" That is fine, a solved problem. Using high barrier tech won't keep intentionally harmful contributions away. It won't prevent political mess or flamewars. It won't keep ranters away. It won't help with contributors feelings of rejection and so on. Good review procedures with enough resources, help prevent harmful changes. Guidelines and codes of conduct and resources and tech to enforce, help against rants, bullying or flamewars, not "hg vs git". Good up-front communication on expectation is the solution to people demanding or making changes that can never be accepted.