1. 31
  1. 12

    There’s one category of users that really annoys me: those that request something to be added/fixed, and then never respond when you ask them to test a beta build with the code they were so vocal about wanting it.

    Those that come to say “me too” in a thread are not behaving in a self-contradictory way at least. ;)

    1. 9

      Regarding not testing a beta build, there’s many good reasons that could happen:

      • They legitimately never saw your update. Accounts get dropped, email addresses change, life gets in the way.
      • They might have no idea how to do that. If they clicked an icon to install your software, or, even worse, asked IT to do it for them, installation instructions are going to be so much line noise.
      • Their case might not be easily reproducible, and they have no idea how to write a test script to verify that the change is indeed what they wanted.
      • The feature/fix might be considered a step in the wrong direction. Users might feel too intimidated to engage with the developer at that point to course correct. Certainly a lot of developers and communities have abrasive personalities.
      • They’ve moved on and implemented their own fix or started using a different piece of software. Issues usually don’t come with a time horizon. Usually the end user will (ask someone local to) implement it or, more likely, swap to something else if the time horizon is passed. This could be anywhere from hours (consider an artist or developer with a deadline) to days, rarely weeks, and I’m struggling to think of a situation where months would be reasonable.

      Of course, responding with “I can’t/won’t test this because X” would be helpful, but again there might be good reasons why they don’t.

      1. 2

        I’m struggling to think of a situation where months would be reasonable.

        That can be the case when the issue is a nuisance but not a showstopper. After several of such, people may decide that the project in question might not be the best fit for them and look into alternatives. Or maybe after a year of struggling, a viable alternative is finally announced (or developed in-house) and people can finally jump ship.

        Also sometimes issues become more pressing over time, at which point a fine-but-not-fantastic solution becomes a big bottleneck and forces your hand to switch.

      2. 9

        I would agree that they’re not self-contradictory, but as a maintainer, they are still noise (which doesn’t belong or need to be there) when voting/reacting accomplishes the exact same thing. I don’t want to have to sift through 20 comments of “+1” in order to find the bits of the conversation which actually provide more information or context.

        A somewhat fun side anecdote - when I worked on bitbucket.org, the frontend team added a pop-up which encouraged people to vote on issues rather than comment with “+1”. Some people used it, and that was great, but a frustrating percentage just clicked out of the modal, changed the wording and submitted a different “me too” comment, seemingly missing the point entirely.

        1. 8

          On that note: I think the notification-less +1 reactions on github are a great addition. That way you can show that you’re affected or sympathizing with something (feature) without generating alerts. And if somebody should look at the issue, they can see that X users also had this problem or found something helpful etc.

        2. 5

          As a user I am equally annoyed by the lack of responses on bug reports. If you don’t want them, then turn that feature off in github or at least put it in the README. My time is valuable too, you know. If I write a bug report or a feature request, at least say “sorry, not interested”…

          1. 3

            I disagree about just disabling the feature.

            It is better to have them open, even if you are not very responsive. Once you got time, you got more data what is important to you.

            Even as a user I often look at open bug reports to get an idea of responsiveness - that is a good metric to consider when adopting a project or not.

            Maybe a note in the standard bug reporting text about to be expected responsiveness is a good compromise - especially if you don’t have much time.

            1. 3

              The only thing that really bothers me from a user’s perspective is when a maintainer of a very popular library effectively abandons it without a word leaving the whole community that has built up around it confused, wasting time and energy on reporting issues or submitting pull requests that will never lead anywhere and not sure whether to move on and fork because maybe the maintainer will return at some point. And it’s clear from their contributions to other projects that they’re still active, they didn’t just fall off the face of the earth. I get it, technically they don’t owe us anything and they’ve already given a lot, but if all it takes is a single note at the top of their README, or even a comment on one of the backlog issues to say that they no longer have time to maintain the project so that everyone can adjust their expectations and plan a path forward, then I kind of feel justified in being frustrated by the situation.

              I also understand that often the maintainer might not have actually made a conscious decision to abandon a project, and they may full well intend to come back to it, even if that doesn’t eventuate. But at some point, surely you can at least hop onto a comment thread and give some kind of indication of your intentions, even if it’s just to say you don’t know. At least it’s something and shows respect for the community.

              1. 1

                This doom scenario happened with pyppeteer (a replication of the puppeteer protocol for chrome in python). Community fork came in way too late and was unusable after a few months.

          2. 6

            When a bug/missing feature is a show-stopper for me, i often find myself creating a PR addressing the issue. However, many of these PRs have yet to be merged, usually due to general inactivity upstream. As a result i often end up using my own forks. Thankfully most language-specific package managers support fetching from Github.

            1. 1

              That’s the great part about open source – you can always just fork and provide a patchset/PR for upstream to merge back.

              It’s how I got into programming in the first place (doing that with Quassel/Quasseldroid) and it’s what I’m doing now with pretty much everything I use. In fact, this very day I worked on a PR to add postgres support into Seafile.

            2. 4

              Open source software (or free software, as I prefer to call it) is not necessarily free, contrary to what the author suggests. There are many examples of free software that is not free: Conversations (XMPP client), ZorinOS (paid versions), Ardour (DAW), Threema (only clients are free software), etc, etc, etc, etc, etc, etc.

              The post was great, until you mentioned that bit of misinformation.

              1. 6

                This is why we need “gratis” and “libre” terms… ;)

                Anyway, the point still stands. By paying for the pre-built Ardour binaries you are buying access to binaries, which saves you time compared to building it from source. You aren’t buying developer time required to honor your requests.

                Of course, that’s also true for proprietary software. Unless you are paying for custom development, you aren’t entitles to anything except what the EULA says. But the ironic part is that when people use proprietary software, they usually understand it. Or so it seems.

                1. 1

                  Open source software (or free software, as I prefer to call it) is not necessarily free

                  Hello Richard! :)

                  1. 2