6 ms·

Reporting issues to a vendor takes a hell of a lot of effort and time compared to idly posting them in a comment thread. This is like those remarks along the l

Reporting issues to a vendor takes a hell of a lot of effort and time compared to idly posting them in a comment thread. This is like those remarks along the lines of "it only takes 5 minutes to submit a patch to the documentation". No, it doesn't - it takes 5 minutes to write it and create a PR, and usually two hours to defend it from the maintainer's criticisms.

iamatworknow 10y ago
>usually two hours to defend it from the maintainer's criticisms Isn't that what we want, though? Discussion and review, particularly with the people who are most familiar with the project (the maintainers) is what makes software better, not worse. If you're not willing to do that then why comment on issues you find in open source projects at all, other than to stroke your own ego?
- joepie91_ 10y ago
  No, it's not. Legitimate discussion and review, sure - but that doesn't take two hours. The problem is with maintainers arguing over small changes, trying to trivialize them, finding reasons to reject them, asking contributors to do more work first... It's pretty much impossible to just leave a contribution and move on. This is something I encounter constantly. It's why I've stopped bothering submitting documentation fixes in most cases, and now resort to writing and publishing my own documentation. It makes one-off contributions to open-source unreasonably costly and non-viable. I know many others who feel the same. If maintainers want more contributions to their open-source projects, they need to start recognizing that the contributor's time and skills are valuable as well - that means not second-guessing contributions unless there's a concrete reason to do so, and making an effort to write a comprehensive response to a contribution (especially if it's a rejection). And most of all, being clear about this policy. It's easy to say "why don't you submit it to the project?" from the sidelines, but the reality is that 'formal' contributions nearly always come with an expectation of dedicating your time and attention towards them on a more-or-less ongoing basis. Many people cannot afford that, and as such publish them elsewhere. Changing that starts with maintainers, not with contributors.
- CiPHPerCoder 10y ago
  > Isn't that what we want, though? Generally. But on the other hand, no, this isn't a monoculture, where everyone wants the same exact thing. > Discussion and review, particularly with the people who are most familiar with the project (the maintainers) is what makes software better, not worse. Tell that to vim: https://github.com/vim/vim/issues/638 https://github.com/vim/vim/issues/638 Tell that to node.js: https://github.com/nodejs/node/issues/5798 https://github.com/nodejs/node/issues/5798 Tell that to WordPress: https://core.trac.wordpress.org/ticket/21022 https://core.trac.wordpress.org/ticket/21022 https://core.trac.wordpress.org/ticket/25052 https://core.trac.wordpress.org/ticket/25052 etc. Despite all of the time that industry experts have contributed towards identifying and discussing security problems, these projects have severe inertia in the security realm. How much more time do you want us to carve out of our lives for projects that won't fix their problems? > If you're not willing to do that then why comment on issues you find in open source projects at all, other than to stroke your own ego? I don't like the way this is framed. It's a hidden false dichotomy.
  - iamatworknow 10y ago
    I don't disagree with your or joepie91_'s points in that many (maybe most) open source project maintainers are perhaps more guarded and difficult in accepting contributions than they should be. That said, even if you submit a pull request or an issue ticket and the maintainer doesn't follow up, or is making the issue unnecessarily complicated to resolve formally and merge into the main branch, at least the record of your findings is there attached to the repo as a rejected pull request or a closed issue ticket, and that can help someone who comes along after the fact who maybe experienced the same issue you did and can benefit from your comments. Maybe that same person who comes along later will have the time to fight for having the changes merged, and can use your comments as further evidence that the issue is worth reconsidering. I stand by the idea that finding the issue, but posting it on an unrelated forum (like HN) instead of attaching it to the project itself serves no purpose than to tell others who are probably not even users of the open source code "look at this problem I found/solved, aren't I great?"
    - CiPHPerCoder 10y ago

iamatworknow 10y ago

>usually two hours to defend it from the maintainer's criticisms Isn't that what we want, though? Discussion and review, particularly with the people who are most familiar with the project (the maintainers) is what makes software better, not worse. If you're not willing to do that then why comment on issues you find in open source projects at all, other than to stroke your own ego?

joepie91_ 10y ago
No, it's not. Legitimate discussion and review, sure - but that doesn't take two hours. The problem is with maintainers arguing over small changes, trying to trivialize them, finding reasons to reject them, asking contributors to do more work first... It's pretty much impossible to just leave a contribution and move on. This is something I encounter constantly. It's why I've stopped bothering submitting documentation fixes in most cases, and now resort to writing and publishing my own documentation. It makes one-off contributions to open-source unreasonably costly and non-viable. I know many others who feel the same. If maintainers want more contributions to their open-source projects, they need to start recognizing that the contributor's time and skills are valuable as well - that means not second-guessing contributions unless there's a concrete reason to do so, and making an effort to write a comprehensive response to a contribution (especially if it's a rejection). And most of all, being clear about this policy. It's easy to say "why don't you submit it to the project?" from the sidelines, but the reality is that 'formal' contributions nearly always come with an expectation of dedicating your time and attention towards them on a more-or-less ongoing basis. Many people cannot afford that, and as such publish them elsewhere. Changing that starts with maintainers, not with contributors.
CiPHPerCoder 10y ago
> Isn't that what we want, though? Generally. But on the other hand, no, this isn't a monoculture, where everyone wants the same exact thing. > Discussion and review, particularly with the people who are most familiar with the project (the maintainers) is what makes software better, not worse. Tell that to vim: https://github.com/vim/vim/issues/638 https://github.com/vim/vim/issues/638 Tell that to node.js: https://github.com/nodejs/node/issues/5798 https://github.com/nodejs/node/issues/5798 Tell that to WordPress: https://core.trac.wordpress.org/ticket/21022 https://core.trac.wordpress.org/ticket/21022 https://core.trac.wordpress.org/ticket/25052 https://core.trac.wordpress.org/ticket/25052 etc. Despite all of the time that industry experts have contributed towards identifying and discussing security problems, these projects have severe inertia in the security realm. How much more time do you want us to carve out of our lives for projects that won't fix their problems? > If you're not willing to do that then why comment on issues you find in open source projects at all, other than to stroke your own ego? I don't like the way this is framed. It's a hidden false dichotomy.
- iamatworknow 10y ago
  I don't disagree with your or joepie91_'s points in that many (maybe most) open source project maintainers are perhaps more guarded and difficult in accepting contributions than they should be. That said, even if you submit a pull request or an issue ticket and the maintainer doesn't follow up, or is making the issue unnecessarily complicated to resolve formally and merge into the main branch, at least the record of your findings is there attached to the repo as a rejected pull request or a closed issue ticket, and that can help someone who comes along after the fact who maybe experienced the same issue you did and can benefit from your comments. Maybe that same person who comes along later will have the time to fight for having the changes merged, and can use your comments as further evidence that the issue is worth reconsidering. I stand by the idea that finding the issue, but posting it on an unrelated forum (like HN) instead of attaching it to the project itself serves no purpose than to tell others who are probably not even users of the open source code "look at this problem I found/solved, aren't I great?"
  - CiPHPerCoder 10y ago