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