12 ms·

Good on them for actually tracking this feature request for over a decade and not just closing it after three weeks for “lack of interest.” Looking at you, eve

Good on them for actually tracking this feature request for over a decade and not just closing it after three weeks for “lack of interest.” Looking at you, every random GitHub project ever.

leppr 6y ago
Having a revenue stream helps.
- Denvercoder9 6y ago
  Does it? It's not like you're paying GitHub per open issue. I've literally had issues I filed that the maintainer verified as an actual bug be closed due to lack of activity. I can understand that an unpaid maintainer doesn't have the time or motivation to fix it, but closing issues you know are valid seems insane to me.
  - acdha 6y ago
    Is it a human closing it or a bot? If you run an open source project there's a natural tendency to install a bot to auto-close all of the issues which people open because they didn't read the docs, want you to do free consulting for their business, have an irreproducible bug report, etc. and since most projects are short on labor that makes it somewhat inevitable that someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.
    - Denvercoder9 6y ago
      A bot, but > someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified. I don't understand this part. Aside from the fact that it's trivial to exclude certain tags (it's the same config file, and it's in the first example they give), doing this effectively makes your issue tracker useless as an issue tracker. Why not completely disable the issue tracker instead then?
      - acdha 6y ago
        Oh, I'm not saying it's great. What I'm saying is that the process often looks like this: 1. Release a project on GitHub 2. Get busy with other things / deluged in issues 3. “I don't have time for this. Let me install the auto-close bot!” 4. Issues get closed 5. [sometimes never] “I better configure the auto-close bot to only act on untriaged issues”
  - ampdepolymerase 6y ago
    They meant Mozilla having revenue, not GitHub.
    - Talanes 6y ago
      So did the person you're replying to.
  - leppr 6y ago
    The maintainer may see issues as "something that they should fix", vs "something that could be fixed". If they see it as the former and have no intention of working on it, then closing makes sense. I don't think there's a universal code of conduct on how to handle Github issues.
_jal 6y ago
I half-seriously suggested that a project I used to care about set up a cron job to delete requests older than a year automatically. The rationale was that they only did that sporadically every few years, when some other change mooted the issue. If they ignored feature requests on a schedule, it would better manage external expectations. See also, The CADT Model (but copy-paste the link in to your browser bar to avoid a bit of unrelated commentary): https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
- NoodleIncident 6y ago
  Please remove the link.
  - wongarsu 6y ago
    The link is good and insightful, if you copy-paste it into the browser bar. If you click it it redirect to a fairly tasteless image complaining about being linked from HN.
    - userbinator 6y ago
      Turn off cross-domain referer sending: https://wiki.mozilla.org/Security/Referrer https://wiki.mozilla.org/Security/Referrer
    - zbrozek 6y ago
      It seems to work perfectly fine either way for me. Not sure what the complaint is?
      - wongarsu 6y ago
        I think it doesn't redirect if you have visited the site before. Otherwise you get redirected to https://cdn.jwz.org/images/2016/hn.png https://cdn.jwz.org/images/2016/hn.png
    - Qwertious 6y ago
      The whole thing is less than a page long and dead simple, I'm just going to copy/paste the entire page verbatim: > The CADT Model >© 2003 Jamie Zawinski <jwz@jwz.org> >In February 2003, a bunch of the outstanding bugs I'd reported against various GNOME programs over the previous couple of years were all closed as follows: >>Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks... >This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version. >I'm so totally impressed at this Way New Development Paradigm. Let's call it the *"Cascade of Attention-Deficit Teenagers"* model, or *"CADT"* for short. >It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8? >But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again. [random GIF of a compass, that links to the homepage]
renewiltord 6y ago
Also Gnome. Always cracked me up. Like I'd make this issue with like all the details reported and everything. ESR would have wept. And then "Does this issue still occur in Gnome 3?" and closed a week later all while I'm on vacation. Homie, this sat here for like 5 years, surely you can be a little patient. Anyway, that taught me not to report something that's not a game-ender. Which is probably what they want too, so I guess we're all in some sort of equilibrium.
- ziftface 6y ago
  That's kind of sad though, since that type of issue is really valuable if the project is under active development.
- sneak 6y ago
  jwz has nicknamed this the CADT model, for "cascade of attention-deficit teenagers". (edit: _jal beat me to it.) Few things are as infuriating as taking the time to write a great bug report just for it to be ignored or autoclosed.
jjav 6y ago
Absolutely. I severely dislike the "bug scrub" attitude that's prevalent in some places that amounts to just closing anything that is not P1 and older than some short time window. The idea of a bug tracker is to track bugs in the product. If the bug still exists in the code, the bug in the tracker should still be open.
- Agentlien 6y ago
  For open repositories like this I certainly agree. And when I worked at a smaller company with no dedicated QA team we never closed bugs, either. But in game development with dedicated QA I feel such scrubs are necessary because when they're not done you end up wasting days just confirming that old bugs can no longer be reproduced and flagging them to be closed. Most bugs which linger are symptoms of other bugs which have been addressed. If they're still there they will almost certainly be found again by QA the moment you close it. In fact, old bugs often even have newer duplicates.
- olvy0 6y ago
  I'm one of the maintainers / developers / support personnel for an internal app that was created circa 1996. We still have open bugs that's 20 years old and haven't yet been fixed. When I got this role, I instated a culture of never closing old bugs, despite some of my managers wanting me to do that many times, and one of them even going on a rampage once and closing some of them (which I reversed as soon as he left). Some of the bugs are still encountered by new users, unfortunately, but are not fixed yet since they are not critical enough or have enough impact compared to other bugs. To his credit, that manager also came up with a more-or-less effective formula to rate the bugs according to their importance based on several criteria. Which helps a lot with the upkeep and with planning ahead. And occasionally, one of the very old bugs will be critical enough for a large enough group of users that it will rise up in the ratings to be fixed. I also set aside time for bug grooming once in a while, closing bugs which were fixed or are no longer relevant. Unfortunately. at this point we are a small team with only 2 experienced devs (the rest are very good but are relatively new graduates and/or without a lot of experience and require supervision) and close to 5000 open bugs and requests, and a steady stream of new feature requests and bug reports. We also have too many internal users for our own good. It's tough. But the dude abides.
fuzzy2 6y ago
The downside is that Mozilla tracks thousands of open tickets, most of which are probably obsolete. But who is going to start now with reviewing stuff from 20 years ago? As much as it pains me (I’m still tracking multiple bugs I reported) to say this, but all tickets with no activity for some reasonable time period must simply be closed. Things are _already_ out of control.
- Cthulhu_ 6y ago
  That's too simplistic. What if it IS an issue, or what if it WILL be fixed, but because of priorities it's always bumped down the list? What do you then, bump it every few weeks? No, any open source project needs someone (or multiple people) triaging tickets; either keep them open and make sure they are implemented in a reasonable time, or close them as a 'wontfix'. Of course, then you'll have the issue of people opening up new tickets for the same thing, and the triagers will have to either point them to the old ticket, or the discussion about whether or not to do it has to be restarted.
  - fuzzy2 6y ago
    I totally agree. There’s just this thing called “reality” and unless your ticket by coincidence ends up catching the eye of someone who can actually do something about it, it will be left to rot. And because nobody will bother looking at the oldest ticket known to man™, the close-bot may as well close it. Tens of thousands of untriaged reports aren’t helping anyone.
  - kevincox 6y ago
    I think there is a place for "Priority: Would Accept Patch". AKA we don't think it is a bad idea (otherwise we would close) but at this point we don't think that "the developers" will ever get to it. However leave it open, people can mark interest (hopefully with a vote not a bump) or maybe even write a patch. It's not hurting anyone just sitting there.
volongoto 6y ago
I have seen projects where the developer(s) would say things like: "This feature request sounds good to have but we don't have the time for this now. So, I'm closing it. Could you please create it again in 6 months?" I'm lost for words. Can't you just put a tag and park it? What is this obsession about keeping the issue count low?

Good on them for actually tracking this feature request for over a decade and not just closing it after three weeks for “lack of interest.” Looking at you, every random GitHub project ever.

leppr 6y ago

Having a revenue stream helps.

Denvercoder9 6y ago
Does it? It's not like you're paying GitHub per open issue. I've literally had issues I filed that the maintainer verified as an actual bug be closed due to lack of activity. I can understand that an unpaid maintainer doesn't have the time or motivation to fix it, but closing issues you know are valid seems insane to me.
- acdha 6y ago
  Is it a human closing it or a bot? If you run an open source project there's a natural tendency to install a bot to auto-close all of the issues which people open because they didn't read the docs, want you to do free consulting for their business, have an irreproducible bug report, etc. and since most projects are short on labor that makes it somewhat inevitable that someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.
  - Denvercoder9 6y ago
    A bot, but > someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified. I don't understand this part. Aside from the fact that it's trivial to exclude certain tags (it's the same config file, and it's in the first example they give), doing this effectively makes your issue tracker useless as an issue tracker. Why not completely disable the issue tracker instead then?
    - acdha 6y ago
      Oh, I'm not saying it's great. What I'm saying is that the process often looks like this: 1. Release a project on GitHub 2. Get busy with other things / deluged in issues 3. “I don't have time for this. Let me install the auto-close bot!” 4. Issues get closed 5. [sometimes never] “I better configure the auto-close bot to only act on untriaged issues”
- ampdepolymerase 6y ago
  They meant Mozilla having revenue, not GitHub.
  - Talanes 6y ago
    So did the person you're replying to.
- leppr 6y ago
  The maintainer may see issues as "something that they should fix", vs "something that could be fixed". If they see it as the former and have no intention of working on it, then closing makes sense. I don't think there's a universal code of conduct on how to handle Github issues.

_jal 6y ago

I half-seriously suggested that a project I used to care about set up a cron job to delete requests older than a year automatically. The rationale was that they only did that sporadically every few years, when some other change mooted the issue. If they ignored feature requests on a schedule, it would better manage external expectations. See also, The CADT Model (but copy-paste the link in to your browser bar to avoid a bit of unrelated commentary): https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html

NoodleIncident 6y ago
Please remove the link.
- wongarsu 6y ago
  The link is good and insightful, if you copy-paste it into the browser bar. If you click it it redirect to a fairly tasteless image complaining about being linked from HN.
  - userbinator 6y ago
    Turn off cross-domain referer sending: https://wiki.mozilla.org/Security/Referrer https://wiki.mozilla.org/Security/Referrer
  - zbrozek 6y ago
    It seems to work perfectly fine either way for me. Not sure what the complaint is?
    - wongarsu 6y ago
      I think it doesn't redirect if you have visited the site before. Otherwise you get redirected to https://cdn.jwz.org/images/2016/hn.png https://cdn.jwz.org/images/2016/hn.png
  - Qwertious 6y ago
    The whole thing is less than a page long and dead simple, I'm just going to copy/paste the entire page verbatim: > The CADT Model >© 2003 Jamie Zawinski <jwz@jwz.org> >In February 2003, a bunch of the outstanding bugs I'd reported against various GNOME programs over the previous couple of years were all closed as follows: >>Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks... >This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version. >I'm so totally impressed at this Way New Development Paradigm. Let's call it the *"Cascade of Attention-Deficit Teenagers"* model, or *"CADT"* for short. >It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8? >But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again. [random GIF of a compass, that links to the homepage]

renewiltord 6y ago

Also Gnome. Always cracked me up. Like I'd make this issue with like all the details reported and everything. ESR would have wept. And then "Does this issue still occur in Gnome 3?" and closed a week later all while I'm on vacation. Homie, this sat here for like 5 years, surely you can be a little patient. Anyway, that taught me not to report something that's not a game-ender. Which is probably what they want too, so I guess we're all in some sort of equilibrium.

ziftface 6y ago
That's kind of sad though, since that type of issue is really valuable if the project is under active development.
sneak 6y ago
jwz has nicknamed this the CADT model, for "cascade of attention-deficit teenagers". (edit: _jal beat me to it.) Few things are as infuriating as taking the time to write a great bug report just for it to be ignored or autoclosed.

jjav 6y ago

Absolutely. I severely dislike the "bug scrub" attitude that's prevalent in some places that amounts to just closing anything that is not P1 and older than some short time window. The idea of a bug tracker is to track bugs in the product. If the bug still exists in the code, the bug in the tracker should still be open.

Agentlien 6y ago
For open repositories like this I certainly agree. And when I worked at a smaller company with no dedicated QA team we never closed bugs, either. But in game development with dedicated QA I feel such scrubs are necessary because when they're not done you end up wasting days just confirming that old bugs can no longer be reproduced and flagging them to be closed. Most bugs which linger are symptoms of other bugs which have been addressed. If they're still there they will almost certainly be found again by QA the moment you close it. In fact, old bugs often even have newer duplicates.
olvy0 6y ago
I'm one of the maintainers / developers / support personnel for an internal app that was created circa 1996. We still have open bugs that's 20 years old and haven't yet been fixed. When I got this role, I instated a culture of never closing old bugs, despite some of my managers wanting me to do that many times, and one of them even going on a rampage once and closing some of them (which I reversed as soon as he left). Some of the bugs are still encountered by new users, unfortunately, but are not fixed yet since they are not critical enough or have enough impact compared to other bugs. To his credit, that manager also came up with a more-or-less effective formula to rate the bugs according to their importance based on several criteria. Which helps a lot with the upkeep and with planning ahead. And occasionally, one of the very old bugs will be critical enough for a large enough group of users that it will rise up in the ratings to be fixed. I also set aside time for bug grooming once in a while, closing bugs which were fixed or are no longer relevant. Unfortunately. at this point we are a small team with only 2 experienced devs (the rest are very good but are relatively new graduates and/or without a lot of experience and require supervision) and close to 5000 open bugs and requests, and a steady stream of new feature requests and bug reports. We also have too many internal users for our own good. It's tough. But the dude abides.

fuzzy2 6y ago

The downside is that Mozilla tracks thousands of open tickets, most of which are probably obsolete. But who is going to start now with reviewing stuff from 20 years ago? As much as it pains me (I’m still tracking multiple bugs I reported) to say this, but all tickets with no activity for some reasonable time period must simply be closed. Things are _already_ out of control.

Cthulhu_ 6y ago
That's too simplistic. What if it IS an issue, or what if it WILL be fixed, but because of priorities it's always bumped down the list? What do you then, bump it every few weeks? No, any open source project needs someone (or multiple people) triaging tickets; either keep them open and make sure they are implemented in a reasonable time, or close them as a 'wontfix'. Of course, then you'll have the issue of people opening up new tickets for the same thing, and the triagers will have to either point them to the old ticket, or the discussion about whether or not to do it has to be restarted.
- fuzzy2 6y ago
  I totally agree. There’s just this thing called “reality” and unless your ticket by coincidence ends up catching the eye of someone who can actually do something about it, it will be left to rot. And because nobody will bother looking at the oldest ticket known to man™, the close-bot may as well close it. Tens of thousands of untriaged reports aren’t helping anyone.
- kevincox 6y ago
  I think there is a place for "Priority: Would Accept Patch". AKA we don't think it is a bad idea (otherwise we would close) but at this point we don't think that "the developers" will ever get to it. However leave it open, people can mark interest (hopefully with a vote not a bump) or maybe even write a patch. It's not hurting anyone just sitting there.

volongoto 6y ago

I have seen projects where the developer(s) would say things like: "This feature request sounds good to have but we don't have the time for this now. So, I'm closing it. Could you please create it again in 6 months?" I'm lost for words. Can't you just put a tag and park it? What is this obsession about keeping the issue count low?