1. 27

  2. 29

    Alternative perspective: https://www.jwz.org/doc/cadt.html

    Not all issues are equal:

    1. Support: “how do I use feature X?”
    2. Bugs: “it should do X, but it does Y”
    3. Feature requests: “it would be nice if it could do X”

    It’s not always obvious what an issue is from the outset. Especially between support and bugs there is quite some overlap.

    In my experience many issue that are left lingering are unclear, non-issues, confusions, etc.

    Here’s what I did at my last job where the support staff had a tendency to just ramble 3 paragraphs of “description” in the issue title (who needs body text right?) often without a clear example of what went wrong. It worked well enough and made everyone happier; me because I didn’t have to decipher vague issues, support staff because they got better answers faster.

    I haven’t tried it at an open source project yet, but I expect it will work well there too.

    • Try to triage quickly to determine what kind of issue it is.

    • No feedback and unclear? Just close after a few days. It can always be reopened later (but say so in a message! Otherwise people might think closing the issue means “go away”).

    • Support request without easy answer? Direct to more appropriate channel. But please, don’t do it like the maintainers of a certain project which just closes issues with an abrasive “this is not a support forum”. Use a canned message to tell people why this is not an appropriate place to get help and where they actually can get help.

    • Support request with easy answer? Answer concisely, tell people where to get more help if they need it, and close.

    • Add a “confirmed” label to confirmed bugs that really are bugs. IMHO those should remain open until it’s actually fixed. If you’ve got a massive backlog of bugs then chances are that something, somewhere, has gone wrong. Consider it similar to the BUGS section in Unix manpages:

      Our habit of trying to document bugs and limitations visibly was enormously useful to the system. As we put out each edition, the presence of these sections shamed us into fixing innumerable things rather than exhibiting them in public. I remember clearly adding or editing many of these sections, then saying to myself “I can’t write this,” and fixing the code instead.

    • Feature requests: ~10% are either addressing some fundamental shortcoming or well thought out and are useful. The remaining ~90% are trivial and can be closed with “sounds great, I look forward to a PR!” There are always these people with “ideas” but no actual contributions that post these things.

    • Issues without the “confirmed” label can be vacuumed (auto closed) after a few weeks. It’s often not a bug, or if it is, it’s not yet clear. If it’s really important the author can reply and it can be re-opened (say so in the vacuum cleaner message).

    • Closing issues is never fun; we all want to help people, right? But it’s required and canned messages are great because it saves you the effort and time of explaining why you’re closing an issue.

    1. 2

      This seems like a sensible approach, if you can spare the time/energy/whatever to do the work. I believe one of the main issues the article is trying to address is when you don’t have the capacity to do project management work, and it’s more of an emergency measure to deal with a lack of project management resources.

      I’ve experienced this myself, where even just doing the work to review and merge a well-put-together pull request feels a lot more like “I should get paid for this”-work than doing what I feel like on my own time.

      1. 2

        I don’t think it’s that much effort. Essentially, my previous post was just a really verbose way of saying “keep confirmed bugs open, (auto)close most other other things”.

        This should get rid of the issue tracker noise while preventing the closure of real issues that should be fixed.

        1. 1

          I mostly agree with your perspective, but bugs come in different shapes and sizes, and treating them equally is rarely possible (mostly due to resource constraints). I think that major bugs should not be auto-closed, but minor bugs are fair game.

    2. 8

      I am not a fan of auto closing tickets. A bug is still a bug even when it is not getting fixed for a while.

      If one responds just to avoid autoclosing it this does cause noise and thereby takes time from people actively working on fixing it.

      Usually bug reports are a way to start contributing to a project. Closing bug reports just cause time passes seems like a waste of contributions.

      Isn’t it just reducing a number when in reality you want a “sort by last activity” or something like that? Having actually resolved issues mixed with things that for whatever reason had no visible activity for a while seems like making things worse rather than better on the organizational side.

      1. 3

        If one responds just to avoid autoclosing it this does cause noise and thereby takes time from people actively working on fixing it.

        My experience shows that minor bugs generally stay open forever, as no one is really interested in tackling those. Yeah, there are exceptions from time to time, but the overall picture is more or less the same. Btw, those tickets get auto-closed ultimately because no one expressed interest in fixing them. If there was any activity associated with them they’d forever stay open, even if you’re using some bot.

        Isn’t it just reducing a number when in reality you want a “sort by last activity” or something like that? Having actually resolved issues mixed with things that for whatever reason had no visible activity for a while seems like making things worse rather than better on the organizational side.

        Well, everyone has their own perspective here. I’ve tried keep issues open forever for 10 years and now it’s time to try something new. Frankly, I’ve seen very little activity on older tickets across all of my projects, that’s why I’m not really expecting something would change in a material way. I usually sort things by activity, when it comes to answering questions and reviewing PRs, but this doesn’t help when I have to pick tasks for myself (and I guess other core contributors experience this as well).

      2. 7

        The real issue here is that github’s issue tracker is really primitive. On a more sophisticated tracker (I prefer redmine but there are dozens of decent ones) sorting, filtering, categorising and generally ‘tracking’ of issues is much more fine grained and controllable. It is still a good idea to close unhelpful issues, but it is no longer overwhelming when there are thousands of them.

        A bug tracker should be designed to handle volume. The github tracker is an afterthought on a source repository hosting site. My advice for major projects would be to host a dedicated public bug tracker. Have a bot that takes all github issues, reposts them to the actual tracker, adds a link in the original, and then closes them straight away.

        1. 1

          No argument from me. GitHub Issues definitely doesn’t make managing projects fun. :-)

        2. 4

          I like the idea of automatically closing stale issues; it’s harder for that to come across as personal to the submitter. Combined with a policy of readily reopening auto-closed issues if they reappear, I can see that working well.

          Autoclose might even be a worthwhile first-class feature for github’s issue tracker.

          1. 13

            I find there to be little worse than autoclose. With autoclose, issues that are known to exist and have reproduction cases will get closed simply because no one has had time to fix them yet, and then things fall through the cracks.

          2. 4

            I saw this and initially thought “Ugh they want me to model my behavior after the Alec Baldwin’s psycho sales lead in Glengarry Glen Ross?

            And then I read the article and really appreciate / agree with the message.

            I haven’t maintained a big open source project yet, but I’ve worked in the software industry for decades at this point, and teams lying to themselves about what’s actually feasible by allowing their backlog to balloon out of control is SUCH a common occurrence that it’s almost the default.

            At some point you have to become ruthless and declare “Backlog bankruptcy” and start over, keeping it real on an ongoing basis.

            1. 3

              I’m torn. The post resonates with me, and I maintain Yetibot which currently has 264 open issues. A lot of these were important (and sometimes very small) improvements and some have been open for years. But lately I’ve also been making progress on the backlog as I’ve been able to spend a portion of my time at my job working on the project.

              I’m also investigating ZenHub as an alternative to Waffle since Waffle shut down. ZenHub has the concept of an Ice Box where you toss issues that you don’t plan to work on.

              I could see closing issues and labeling them with maybe someday or whatever so that I could go back and revisit later if I wanted.

              1. 2

                What we used to do at job with JIRA was kind of sort tickets in the backlog so that the most important would be on top (and assigned to the current sprint). We closed tickets that were no longer relevant when we encountered them, but didn’t feel particularly stressed because of them.

                I understand hobby projects are different and obviously everyone is entitled to manage their personal time however they feel like, but I wouldn’t support closing old tickets neither as a user nor developer. Hiding problems doesn’t make them go away. But this, in part, depends on what you mean by closing. If you flag them so that you’re able to search for them easily, I wouldn’t really make a big deal of discussing whether they should shine in red or green. On the other hand, simply closing them with “wontfix” and making legitimate bug reports indistinguishable from garbage doesn’t feel right.

                Again, everyone can follow whatever approach works best for them, these are just my $0.02.

                1. 1

                  always be cobbling