20 ms·

> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing

• aprdm 7y ago
  Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?
  • NewsAware 7y ago
    Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Readme.
    • AlchemistCamp 7y ago
      I'm not sure the practice is that common when the maintainer works for one of the largest 5 software companies in the world and that company is using the code.
    • aspaceman 7y ago
      This isn’t true at all. Many projects even say “we won’t accept PRs” in their README. When the code is being used internally at Microsoft, it makes even more sense they wouldn’t take PRs.
      • NewsAware 7y ago
        Which is exactly what I suggested - avoid strife over mismatched expectations with a one liner. I would take your first paragraph to actually strengthen my assumption that Kinder treatment of PRs is the norm and that's why the many projects you mention add that line.
      • mroche 7y ago
        There's been a request going for several years now to disable Pull Requests on GitHub[0]. They allow project maintainers to disable Issues, they should also be allowed to disable PRs rather than use automation to close any opened PR. Other SCM products (e.g. GitLab) offer the ability to make PRs available only to project members, or disable them completely. [0] https://github.com/dear-github/dear-github/issues/84 https://github.com/dear-github/dear-github/issues/84
    • virtue3 7y ago
      It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time. If you don't like the way a project is being run, fork it and own it yourself. I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.
      • mratsim 7y ago
        The PR contributor was not paid either to investigate the bug, reproduce it, write a patch and test it. However instead of raising a "don't work, please fix" bug s/he took the time to do all that. Anyone that went to such length deserve basic courtesy, whether the code is accepted or refused. Refusing a patch because it is "boring" is not respecting the time people dedicated to your project. I would understand refusing because the patch makes an unwanted compromise on performance and the maintainer considers performance regressions as bug.
        • cerberusss 7y ago
          These are merely your expectations, and this will probably disappoint you in the future. I have replied to logged issues with the question: "I don't work on this, unless you have set aside a budget that pays my hourly rate".
      • jhall1468 7y ago
        And when maintainers respond to a significant amount of work involved in a PR for a bug with a note that they aren't interested because it's "boring" then they can be critiqued for being a jerk, because they decided to be a jerk. If the maintainer had said, "Hey, I don't have the time to review/test/verify this PR so I'm closing it for now," the backlash probably wouldn't have been quite so severe.
    • iudqnolq 7y ago
      I thought basic etiquette was issue to discuss before PR? Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better". Is that wrong?
      • aprdm 7y ago
        For what its worth I agree with you
      • jlokier 7y ago
        I agree that should be the basic etiquette. Perhaps it needs to be said more clearly on project pages and codes of conduct and participation. (Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales. Luckily, if you don't get the response you wanted, you can fork and hire someone else or do it yourself, and keep your fixes in the queue for others to review eventually, if they want, at whatever timescale suits them.) Unfortunately, there seem to be quite a lot of people who would, rather than discussing ideas respectfully, instead prefer to bully and shame the maintainer. Such as, for example, calling out perceived issues in the code publically (sometimes incorrectly), and making out how unskilled the maintainer must be, in order to put pressure on the maintainer to sacrifice their personal life and do what the bully wants.
        • iudqnolq 7y ago
          > Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales I absolutely didn't mean to imply that. I also think that a pre-PR discussion can be useful because if the maintainer doesn't have time to say they want a PR that's a decent hint they won't have time to handle the PR.
          • jlokier 7y ago
    • aprdm 7y ago
      I worked with a person who happens to have one of the most popular OSS Packages of my industry. He has a kid and works 8hs a day like all of us... some merge requests are two years old, he doesn't have time for all the feedback / suggestions he receives and just keeps coding in his very limited time because is what he is passionate about... people keep using it.
• meesles 7y ago
  > Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs written, _anyone_ on the internet can apply them and use them in their software. I agree with GP, you aren't owed anything, and that extends to any form of social behaviors online. And let's not forget that even the most 'perfect' maintainer still deals with shit on a regular basis from the masses of people demanding features as if they got paid to write the free software people are using. This expectation of being served high-quality open-source software for free, and then outrage when it isn't, is absolutely ridiculous and will make people not want to maintain software.
  • rckoepke 7y ago
    > it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illegal or anything. They can choose to be irresponsible, yes. But personally, I think that maintaining the repo is the maintainer's responsibility. And I think the responsible way to do that involves "following best-practices, responding to feedback/PRs, or responding in any coherent way to anything asked of them." I'm NOT saying a maintainer should have to add features to satiate the masses. I'm merely saying that a "maintainer" has some small duty to "maintain" a product, and also acknowledging that they have a legal right to abdicate that responsibility. I'm not sure anyone should be immune from social criticism. They can always make someone else the maintainer and avoid any future work/limelight/criticism. I won't touch the childish vs. adult debate as it pertains to abdicating one's responsibilities. I am also NOT saying that people should "expect to be be served high-quality open-source software for free, and then outrage when it isn't." But it seems like it's a maintainer's responsibility to allow (and maybe even facilitate) competent, motivated individuals to contribute to their open-source project. I also don't know exactly what the reddit brigading involved, this is the first time I've heard of this story. Harassment obviously is not okay and, not coincidentally, is illegal.
• jakear 7y ago
  Did the patches obviously maintain the exact same behavior? If so, why should the author care about them? If not, it’s not the author’s responsibility to ensure they’re correct patches, but it is the author’s responsibility to ensure their package is correct. If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well), they have no responsibility to vet incoming patches that do nothing besides change internal workings for the sake of changing internal workings. I don’t write Rust, I write TS. If I produced a package that was had a clean and correct TS interface, but internally was filled with dirty dirty `any`s, I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.
  • eropple 7y ago
    > I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s. Why would you possibly not? Increased correctness, no change in runtime behavior, and a resistance to code rot and mistakes on your next concrete change. Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.
    • flatline 7y ago
      > no change in runtime behavior That's the problem: how does the maintainer guarantee this? And when flooded with multiple such PRs, the task rapidly becomes overwhelming. If you have a robust suite of unit tests and a CI system you have better guarantees but still about as much work to ensure the new functionality is properly tested. That's not to say the maintainer's attitude in this case was excusable, but it's his project and this style of maintenance is definitely not for the feint of heart.
      • eropple 7y ago
        In many cases, you're right. But here, specifically? If somebody goes through your code and annotates it with types, TypeScript is gonna scream if it doesn't build clean and is going to emit the same code it did in the first place. This is literally complaining that somebody might write helpful documentation for your system and that you'd refuse to merge it. It's a pathologically bad statement.
• biesnecker 7y ago
  > 2. Open source participants are volunteers and owe you nothing. The two rules work in concert.
• lostmyoldone 7y ago
  It's his project. If he wants to act in a way you call "childish" - not that I agree with the characterization - neither I, you, or anyone else has much of anything to complain about. If he says it's production ready, I have to assume he thinks it is. If you don't think so, you don't use it. Open source projects dependent on a single person goes away all the time. If you aren't prepared to maintain it yourself for your use, don't use it. Honesty is something we should expect, as well as some amount of mutual respect. It's abundantly clear that anyone expecting him to dance to their tune was clearly lacking in respect. If you do a patch that isn't accepted you haven't lost anything, and have no grounds to complain, unless possibly if you had a prior agreement between you about you making that particular patch. Many maintainers are absolutely inhumanly awesome, but that doesn't give us the right to expect anything at all from those who is "only" giving us tons of more or less awesome code!
• mynegation 7y ago
  You cannot change other people, you can only change how _you_ react to other people and the world around you. If Actix is that important to so many people, eventually there will be a person and/or organization that will step up, fork the projects, apply the patches, set the principles and code of conduct (or not), keep as much "unsafe" code as they deem necessary and try to rally the community around it. The open source creators and maintainers gave you something and asked for nothing. They are people with their weaknesses, faults, insecurities, and other passions and commitments, like we all are. Get the best of what they are willing to give, give them the best you are willing to give and they are willing to accept, and move on.
• munificent 7y ago
  > they had likely invested considerable time at least using, if not more. I think your choice of the verb "invest" implies a highly flawed mindset about the incentive structure of open source. A lot of open source consumers have a mindset that by using someone's open source project you're giving them something or doing them some kind of favor. "Hey, I'm investing in your project!" You aren't. From a maintainer's perspective, simply using a project is likely either a zero or net negative. You are not investing your time, you are using their code. You may be asking questions which consume their time. You may be filing bugs which are on code paths they personally don't hit and fixing those uses up their time. For open source projects that pay for hosting things like their repo and issue tracker, you're consuming network resources. We have a finite time on Earth, and supporting users is time the maintainer cannot spend with their friends and family, relaxing on a beach, taking a stroll, etc. A consumer of an open source project may cancel out that drain by offering other things in return: popularity, kind words, the feeling that the maintainer has created something that benefits other humans. Filing issues can help a maintainer fix bugs and feel good about the improved quality of their code. Pull requests can add functionality they want. But none of that is a given and often does not happen. In my open source projects, I have certainly receive kind words, but also many angry words in bug reports. I've had demands to spend huge amounts of time making sweeping changes, pull requests that needed be basically be rewritten, the feeling that I'm letting people down by not replying to issues quickly enough, etc. I believe the right mental model is that if you use someone's open source project, you are in their debt by default. They have used their labor to create an artifact that provides clear material value to you. They did work. You got personal value. They clearly owe you absolutely nothing and you reasonably owe them something approaching the material value you get from their code. This doesn't mean you need to pay them, but it should inform how you interact with them. Filing issues and sending pull requests may pay off that debt, but even then it is not a given that every issue and PR is a net help to them. Maintaining an open source project can be gratifying, but it can also be hugely draining. It would be less so if consumers were more sensitive to that fact.