1. 27
  1. 13

    It depresses me that people are so rude and condescending. In this case, the author (very charitably) guesses that many of the people asking for things rudely are not programmers. (I.e., they can’t submit patches.) But, obviously, programmers are also awful to each other though you would think that they would know better. (To be clear, even non-programmers should know better than to ask rudely or condescendingly, but…)

    A recent case that has been on my nerves since yesterday. I contribute a little to a go tool, so I follow the repo. As a result, I see all new issues. Three weeks ago, the main developer posted an issue themselves explaining that the tool does not yet support code with generics and that there was a significant blocker. The tool relies on a library whose maintainer explained at the end of last year that they won’t get to generics for a while because (literally) they will be away hiking from December 2021 until April or May of 2022. (Nice for them, yeah?)

    Yesterday, a user on Github writes in to nudge the tool’s maintainer. They post on the same thread where the maintainer explained very clearly “This tool relies on library X, and library X won’t be updated until it’s maintainer returns from a multi-month hike in the Amazon.” The nudge? “Bump, this renders <tool’s name> unusable on any codebase that uses generics.”

    Who does that possibly help? Does the complainer imagine that the repo’s maintainer doesn’t understand the problem? The maintainer’s thread is titled “Generic type parameters are stripped.”

    Anyhow, thanks for coming to my TED rant.

    1. 3

      I think it looks much better with quantitatives: some people are consistently rude, and most people are rude sometimes, but, at least for OSS projects I participate in, this happens exceedingly rarely (but does require disproportional mental effort to deal with, yeah).

      1. 4

        This matches my experience. There will also be a small number of people who like being rude, but most people are aren’t like that. However, some communities (not naming any names) seem to have more rude people in them, for unknown reasons. Other than that…

        I was excited when I received the first patches from a complete stranger and pulled them in, thinking how amazing this was. However this person was very opinionated how things should work, which bothered me a bit.

        I still find it the hardest part of maintaining FOSS projects: rejecting code that is perfectly good on its own, but doesn’t align with the long-term goals of the project, or, worse, break existing functionality that the patch author didn’t use or even didn’t know about so they never noticed the problem. Some people do agree to rework their code when I point at those issues, other do not. I try to always fix my patch when I’m the one who made an unfortunately-opinionated patch.

        1. 7

          I still find it the hardest part of maintaining FOSS projects: rejecting code that is perfectly good on its own, but doesn’t align with the long-term goals of the project

          Yeah… Some assorted thoughts:

          Although “I don’t like this” and “this doesn’t align with the goals of the project” are, in the end of the day, similar (“I” is who set project’s goals in the first place), the latter formulation I think is much better for humans, as it moves the conflict from interpersonal to person-vs-institution. I’ve first heard about this effect from https://github.com/edunham – if a maintainer nitpicks code formatting, it’s a picky maintainer. If the CI bot rejects formatting, maintainer and contributor collaborate to foil the pesky robot.

          For the second to work, one needs to spell out the project goals and values. That’s tricky, as it’s pretty hard to compress maintainer’s vision into a short document. Often times you immediately understand that the code doesn’t align with the vision, but it might be hard to attribute that to any particular written rule. It might even be hard to verbalize your gut feeling. Two tips here:

          • Treat “goal of a project” as a living document. If, during review, you spend time putting some bit of rationale to words, write it down and commit it to the repository.
          • “Precedent” is a good alternative way to legalize the rules. If, during rejecting review, you point out another PR which was rejected for a similar reason, you are making it clear that this is a policy, rather than a prejudice against this particular contribution.

          Another tricky case here is goal misalignment – if the contributor just have different goals, they won’t be happy about reworking the PR. For smaller bits of code, I think a good way out is encouragement of forking. For many of my smaller things, I say something “this is more of a pattern than a library, if you want to tweak it – fork the code and go ahead”.

          1. 4

            Sometimes misalignment is more practical than philosophical. For example, suppose there’s a feature whose design turns out to prevent implementing certain new functionality. The maintainer is planning to rewrite it from scratch to fix that design mistake. A contributor sends a patch that adds a lot of code that relies on the old design and will also have to be rewritten, so merging it will increase the amount of work the maintainer has to do.

            I’m not sure what’s the best way to prevent that. Add comments to every part of the code considered technical debt, perhaps?

            It’s also a manifestation of an unspoken conflict between the user and the maintainer. User who make patches usually want a missing feature of a bug fix now. Relatively few contributors become regulars (and that’s normal—no one can possibly have enough time to contribute to every project they are using). Maintainers, however, always need to think how certain code will afffect their ability to modify and extend the code in the future.

            I didn’t understand that conflict or even thought about it before I became a maintainer of a large project. Maybe it should be articulated more often.

    2. 7

      The lessons listed here scale well.

      • Opinions: Decide what opinions and design goals matter for your project, list what they are, and stick to them. Don’t be afraid to change them if you decide they’re not counterproductive, but don’t do it lightly.
      • Audience: If you are aiming at beginners, expect dumb questions from people who barely know what they’re doing. If you’re aiming at experts, expect super intricate and detailed questions about weird situations you never intended to handle. Either way, take it gracefully, be nice, and be willing to say “That makes sense but would take a major redesign”, or “yes this feature would be nice but I just don’t have the time and energy right now”, or “this might not be the tool you want” when necessary.
      • Looking at your own code: So, so true. If you think you’re going to have to come back and modify a project more than a few weeks after starting it, write everything as if it has to be learned by some idiot who doesn’t know what the hell is going on. Invariably that idiot is you, six months from now.\
      1. 3

        Very enjoyable little read. Clearly written and very information dense.

        I love the philosophy of the project. Just little set of PHP scripts doing one thing in an uncomplicated way. I too am allergic to pulling hundreds of files as dependencies. This is what PHP was designed for and it still where it excels.

        About the rest of the post: I think there should be more awareness that code is code and a fork is a single command or click of a button. People should focus more on scratching their own itch on their own forks, then making it available for others if others feel like the development is useful for them. I own my own branches, I certainly won’t have any obligation towards strangers because I make my code available for free on GitHub. Heck, most free licenses even state this textually.

        1. 2

          I have NO idea how people find Cruddiy: there is no Google analytics. Do they find my blog first and then GitHub or the other way around? I would have like a bit more insight into this.

          I remember stumbling onto Insights > Traffic on my repo!

          1. 1

            It’s weird how Github became a social network.

            1. 2

              Not really, that’s inherent in having a site where people can communicate with each other.