1. 24
  1. 11

    I can relate to this to some degree. But this is a very good lesson to learn: you don’t owe anything to any of those people. You shouldn’t really feel guilty. If they don’t put the effort to create a proper bug report, why should you put the effort to fix it? More mitigations include: issue templates, labels “can’t reproduce”, “question” or “help wanted”, a more strict policy clearly laid down in the README, or even just… disable the issues section. Just make it clear that it is your project and won’t generally work on other people issues, but may accept pull requests.

    I still think it’s worth it to publish the code, even if it only “works for you”. Others, who care, may find it valuable. I don’t know what project’s author talks about, how popular they are, or what community uses them (e.g. the entry barrier for Python is a lot lower than it is for other languages, so expect more poorly written complaints here), but I haven’t encountered this situation to the same degree. The compliments are really nice, even if rare (they wouldn’t feel special otherwise).

    1. 3

      shouldn’t really feel guilty

      I still just do though. This is a personal issue, but I can’t help feeling that way.
      I’ll probably just start disabling issues on my GH projects.

    2. 3

      I’m making assumptions that are almost certainly wrong about the author here, because I’m tired. This is what the coddling of the youth has led to. If somebody opens an issue in your project consisting entirely of “doesn’t work”, you don’t need start a dialog with in ticket to extract the information and teach x_anon_x6x how to have conversations. Nor should feel driven to feel diminished by this person’s actions. You delete the ticket without mercy, and never give it another thought. The internet is far too big and full of far too many dickheads to try and bootstrap them up to civility. Everybody should set a minimal bar for themselves, and anything that comes short is gone. Don’t try and punish them, don’t try and teach them basic manners their parents should have, but also don’t start a witchhunt, don’t spend a week trying to get them deplatformed. Just remove their effects and go about your business. If you do anything else, responding to dickheads will slowly grow to be a bigger and bigger part of your life until you’re climbing a metaphorical clock tower and deleting all your git accounts.

      Edited do update: “don’t feed the trolls” isn’t a warning about the effects of feeding on trolls, it’s about the effects of feeding them on you.

      1. 3

        I don’t know” and “I don’t care” would be honest answers. The former is not a valid justification for closing the issue. The latter would backfire.

        would it backfire? I find these posts on the “people want too much from free software” theme to be kind of confusing. you can just say “sorry out of scope”, or even not reply and lock the issue. What are they gonna do, fire you?

        1. 3

          I tend to agree with you though some folks are just wired that way. If my wife worked on open source in her spare time, she’d probably react the same way as the author.

          I tend to be quite picky about my time and I generally don’t allow others to dictate how I spend it. I don’t have much open source but what I do have has, at best, a weekly turnaround on responses about issues.

          In other cases, I have software that I’ve open sourced that I simply don’t take issues/requests for. I open sourced it in case someone finds it useful but the core repo is for my purposes. I don’t care about anyone else’s use case - if they have one they can fork it and propose a PR.

        2. 2

          Thanks for the small Octobox shout out!

          1. 2

            Just checked on Github and it looks like you actually can’t remove or make private the issue tracker, at least as far as I can find. Never thought that would be a misfeature, but here we are.

            1. 1

              The problem is that the tools we use don’t really support a proper distinction of how you want to run your project.

              • project by one person - I am trying really hard not to annoy them and wishlist weird things
              • distribution bugtracker with a bug with 20 “me too” comments that gets auto-closed every 6 months and reopened because nobody bothered to merge the upstream fix that is linked in the very same bug - infuriating and people are rightfully mad