4 ms·

I remember asking about this on Reddit and got a response from someone on the RN team.[1] > In practice this means that we have issues coming in, but we never

by hysan 8y ago

I remember asking about this on Reddit and got a response from someone on the RN team.[1] > In practice this means that we have issues coming in, but we never close them when they are fixed, causing them to pile up. So we decided that the best thing we could do is mark them as stale and close old issues that nobody has commented on in a while. If we mistakenly closed something that is still an issue, the community will let us know and we can reopen it. The discussion I had with them was interesting, but it didn't leave me feeling like anything would really change. Seeing your comment reminded me of this and I guess the status quo has remained. [1] https://ps.reddit.com/r/reactnative/comments/7wqxjy/why_are_so_many_issues_being_closed_without_being/ https://ps.reddit.com/r/reactnative/comments/7wqxjy/why_are_...

je42 8y ago
most of the time the issues are also not fixed (a cross multiple releases) some of the issues are really basic ones, one can wonder why they made a release with them in the first place.
- deleted 8y ago
  [deleted]
ak39 8y ago
I can't seem to understand what the problem with "pile up" is? The whole idea of logging issues is to see how long they're open for! In fact good projects take the painstaking exercise to coalesce tickets that are in fact the same with an original item IN ORDER TO track the correct age of the ticket. This sounds totally backwards.
- _pmf_ 8y ago
  > This sounds totally backwards. It is. It's the result of low level managers using issue counts as KPI: now it's a metric that must be gamed.
  - danabramov 8y ago
    We don't use GitHub issue counts as "KPI" at Facebook. The explanation is more prosaic: https://news.ycombinator.com/item?id=17316150 https://news.ycombinator.com/item?id=17316150
- workinthehead 8y ago
  Nope, wrong on all counts. You need to delete stale issues, it's no good having an endless backlog of someone's nice-to-haves that they no longer even care about. And, the "whole idea" of logging issues is not to see how long they are open for... it's to, you know, log issues, because they can't be fixed instantaneously. Measuring how long they are open for is just a pointy-haired boss side effect, because those are the kind of idiots that would think that kind of metric means anything.
  - allthenews 8y ago
    >Measuring how long they are open for is just a pointy-haired boss side effect...kind of metric means anything. I don't think such cynicism is warranted. Open issue time is a useful metric, at the very least over time, of how quickly developers are fixing problems and how complex they are becoming. Certainly not something for a pointy haired boss to optimize exclusively for, but a useful bit of data to be taken into consideration with other measurements of performance.
    - bonesss 8y ago
      Of all the KPIs for development teams, how-f-ing-long-will-it-take is a pretty 'key' one, IMO. It's not the only factor, it's highly product dependent, but it is very relevant to most outward facing activity...
  - valuearb 8y ago
    I agree that how long they are open is meaningless, but closing them before they are fixed throws the baby out with it's dirty bathwater.
e40 8y ago
but we never close them when they are fixed, causing them to pile up This is the problem. Why not close them when they are fixed?!?
- kbsletten 8y ago
  Well, unless they have a triage team, you're counting on developers having a Spidey-sense that there's an open issue related to what they're working on. I assume the issue list is something they never asked for but feel obligated to doing a minimal amount to clean up.
  - valuearb 8y ago
    Huh? You don't need a spidey sense to close a bug you just fixed, you just close it.
    - HectorRamos 8y ago
      This assumes that the person fixing the bug is either the same one who filed the bug, or they were motivated to fix the bug after finding the GitHub issue. In many cases, the fix comes from within Facebook or from a different contributor when we/they run into the issue themselves.
      - valuearb 8y ago
        And this is exactly why React Native is such an unprofessional pile of crap. Random code changes from random people with no prioritization, documentation or coherent history.
      - _Tev 8y ago
        So they cannot do even the basic issue tracking? Wow, what a mess.
- dgoldstein0 8y ago
  If you have enough issues, just deduping and knowing when a commit fixes an issue to remember to close it becomes a problem. Not saying this is an excuse, but it's unfortunate reality that "close most issues, see which ones come back" is one of the easier ways to focus on the most important bugs

by hysan 8y ago

je42 8y ago

most of the time the issues are also not fixed (a cross multiple releases) some of the issues are really basic ones, one can wonder why they made a release with them in the first place.

deleted 8y ago
[deleted]

ak39 8y ago

I can't seem to understand what the problem with "pile up" is? The whole idea of logging issues is to see how long they're open for! In fact good projects take the painstaking exercise to coalesce tickets that are in fact the same with an original item IN ORDER TO track the correct age of the ticket. This sounds totally backwards.

_pmf_ 8y ago
> This sounds totally backwards. It is. It's the result of low level managers using issue counts as KPI: now it's a metric that must be gamed.
- danabramov 8y ago
  We don't use GitHub issue counts as "KPI" at Facebook. The explanation is more prosaic: https://news.ycombinator.com/item?id=17316150 https://news.ycombinator.com/item?id=17316150
workinthehead 8y ago
Nope, wrong on all counts. You need to delete stale issues, it's no good having an endless backlog of someone's nice-to-haves that they no longer even care about. And, the "whole idea" of logging issues is not to see how long they are open for... it's to, you know, log issues, because they can't be fixed instantaneously. Measuring how long they are open for is just a pointy-haired boss side effect, because those are the kind of idiots that would think that kind of metric means anything.
- allthenews 8y ago
  >Measuring how long they are open for is just a pointy-haired boss side effect...kind of metric means anything. I don't think such cynicism is warranted. Open issue time is a useful metric, at the very least over time, of how quickly developers are fixing problems and how complex they are becoming. Certainly not something for a pointy haired boss to optimize exclusively for, but a useful bit of data to be taken into consideration with other measurements of performance.
  - bonesss 8y ago
    Of all the KPIs for development teams, how-f-ing-long-will-it-take is a pretty 'key' one, IMO. It's not the only factor, it's highly product dependent, but it is very relevant to most outward facing activity...
- valuearb 8y ago
  I agree that how long they are open is meaningless, but closing them before they are fixed throws the baby out with it's dirty bathwater.

e40 8y ago

but we never close them when they are fixed, causing them to pile up This is the problem. Why not close them when they are fixed?!?

kbsletten 8y ago
Well, unless they have a triage team, you're counting on developers having a Spidey-sense that there's an open issue related to what they're working on. I assume the issue list is something they never asked for but feel obligated to doing a minimal amount to clean up.
- valuearb 8y ago
  Huh? You don't need a spidey sense to close a bug you just fixed, you just close it.
  - HectorRamos 8y ago
    This assumes that the person fixing the bug is either the same one who filed the bug, or they were motivated to fix the bug after finding the GitHub issue. In many cases, the fix comes from within Facebook or from a different contributor when we/they run into the issue themselves.
    - valuearb 8y ago
      And this is exactly why React Native is such an unprofessional pile of crap. Random code changes from random people with no prioritization, documentation or coherent history.
    - _Tev 8y ago
      So they cannot do even the basic issue tracking? Wow, what a mess.
dgoldstein0 8y ago
If you have enough issues, just deduping and knowing when a commit fixes an issue to remember to close it becomes a problem. Not saying this is an excuse, but it's unfortunate reality that "close most issues, see which ones come back" is one of the easier ways to focus on the most important bugs