Hacker News Reader

Comment by hysan | Hacker News Reader

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_...

View on HN

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.

> 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.

We don't use GitHub issue counts as "KPI" at Facebook.

The explanation is more prosaic: https://news.ycombinator.com/item?id=17316150

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.

>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.

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...

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.

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.

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?!?

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.

Huh? You don't need a spidey sense to close a bug you just fixed, you just close it.

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.

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.

So they cannot do even the basic issue tracking? Wow, what a mess.

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

Reply on news.ycombinator.com