7 ms·

The biggest problem I've run into with React Native has been their handling of issues. Far too frequently I'll google an issue I'm having and click a link to a

by plopz 8y ago

The biggest problem I've run into with React Native has been their handling of issues. Far too frequently I'll google an issue I'm having and click a link to a bug report that matches the exact problem I'm having and provides a repro only to see that the issue was closed for inactivity. Never mind the issue is still valid, and the comments on the issue will ask for it to be re-opened and the response is to open a new issue. So then you start this goose chase of hunting down the current issue since it starts getting into this loop of closed, open a new issue, closed, open a new issue, closed, open a new issue, etc. And everytime this happens relevant information gets lots because its not transferred to the new issue. And then you finally find the newest, currently active iteration of the issue and find out that its still not fixed and the workaround is to stop using the React Native version and re-implement the feature yourself natively on both ios and android.

arcticfox 8y ago
I've had this exact experience multiple times. Ironically if you wrote this up as an issue in their tracker, I would surely have one more such experience when they closed it shortly after. That said I complain out of love, because React Native is just awesome when it works.
52-6F-62 8y ago
I've found that to be relevant for a few issues (including one of my own) with Facebook Open Source projects—that or they just go unheeded by staff, but confirmed by a stream of others. I am a distant outsider to that company, I haven't used the platform in years and remain quite critical of it and many business practices especially regarding recent exposures (though I am a fan of their engineering they've released or open-sourced for the web)— yet I can understand somewhat how staff associated with such projects are not necessarily actively and regularly allocated to addressing those issues. At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company [re: endpoint-shareholders]—mindshare, general confidence, whatever. Big corps often do what big corps do...
- danabramov 8y ago
  >At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company That's not the case with React Native though. The problem is that the surface area is vast, and the popularity is booming through the roof. If RN team looked at every issue, the (very active) development would stall completely. On the "web" React repo we can afford to do this because our surface area is much smaller, but on RN it's not practical. So instead, the RN team tends to focus on the issues that are reported most often by the FB product teams. While this is not a great outside communication strategy, it ends up highlighting most pain points shared by folks outside the company too. Note this includes vast architectural improvements as highlighted in the post--something that goes way beyond a traditional GitHub issue report. While admittedly this approach puts FB's needs first, it also serves as an important way to keep the team focused. It is very hard to deal with dozen new issues every day and still move the project forward so they chose this path. I want to highlight that RN has maintainers outside of FB who help with different parts of the codebase (because again, the surface area is vast), sometimes with more expertise in those areas than people at FB. So the project isn't dependent on FB maintainers looking at issues alone. Folks outside can, and do help. This doesn't mean issues don't end up being addressed in the end. But GH issue communication model just doesn't scale well for RN.
  - 52-6F-62 8y ago
    All good points, thanks. I guess I was remarking on other experiences more to do with other FB Open Source projects versus giants like RN. edit: Just realized which Dan you are. Thanks for the insights. Your team does good work.
  - olfactory 8y ago
    I think you should just hire a few smart people who can be dedicated to supporting these issues which are high priority outside Facebook. These issues are extremely costly to teams using React and they absolutely need much faster resolution.
    - tmaier 8y ago
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
jbarham 8y ago
It's the CADT model of software development: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
- tlrobinson 8y ago
  FYI links to jwz.org from Hacker News redirect to an... interesting... image. Copy and paste into your browser instead. As an aside, who's really the man child? Hacker News users, or the ~50 year old man insulting/trolling them with that image?
- maddyboo 8y ago
  NSFW Warning
  - deleted 8y ago
    [deleted]
  - jocoda 8y ago
    works ok for me now
    - maddyboo 8y ago
      Previously it redirected to a photoshopped picture of a testicle in a cup.
      - elbear 8y ago
        It still does for me.
- paulddraper 8y ago
  Strip your referrer https://fkref.com/?8XB37z8i https://fkref.com/?8XB37z8i
whistlerbrk 8y ago
I mean... It's a fast moving ecosystem and a coalition of the willing. You have to submit PRs too. I'm not unsympathetic to your claim but context matters. This is an enthusiasm problem. Not a community one
shaneos 8y ago
The response that I've gotten, after complaining repeatedly, is that the team simply has no time to look at any externally reported issues, and that it's essentially a waste of time opening an issue. This makes me very sad (as an ex-FBer especially), I wish that FB would just add another 3 or 4 engineers to the team with the explicit goal of giving them the bandwidth to be good open source stewards. I'm sure the FB engineers don't like having to ignore the community, but they do as a matter of policy.
- olfactory 8y ago
  This is a great point. There have been a few issues that I've followed only to find that eventually the entire thread on Github with tons of example cases of the bug gets "closed for inactivity" because nobody from Facebook would respond to it.
- ricardobeat 8y ago
  They don't need to add more engineers - as an open-source project, all they should have to do is put one person to manage the community, encourage and vet new contributors. But that would mean losing some control.
- ascorbic 8y ago
  They could learn a lot from Microsoft. VS Code, Typescript and related projects are a shining example of how to handle issues on open source projects. In fact, considering what heavy users they are of React Native, maybe Microsoft could be taking a more active role in the core project.
golergka 8y ago
I've had the same experience in multiple open source projects. Seems like not spending though resources on unsexy things, like QA, is typical for open source – although I'd rather expect it from volunteers than FB's engineering team.
sercand 8y ago
Another similar issue is they never accept Pull Requests from github.
- HectorRamos 8y ago
  There's a long tail of PRs to go through and review, and the ones we review may take a while to get to a point where they are accepted, but saying PRs are never accepted isn't quite accurate: https://github.com/facebook/react-native/pulls?utf8=%E2%9C%93&q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+-author%3Ahramos+label%3A%22import+started%22 https://github.com/facebook/react-native/pulls?utf8=%E2%9C%9...
HectorRamos 8y ago
I'm one of the open source React Native maintainers here at Facebook, and I'm the one who has set the direction for how issues are treated on our React Native repository. To anyone whose issue I've closed prematurely, it's OK to feel upset about it. Please do let me know when that happens, as that is the signal I'm looking for. Out of thousands of issues that the bot has closed automatically, only a few dozen end up getting commented on after the fact. Some of these issues we won't reopen because there is no minimal repro (usually because they were opened before we started enforcing the issue template, in which case, please open a new issue!), but in many cases all it needs is for a maintainer to go in and re-open the issue. If you're reading this and you are one of the people actively participating in the repo, and you'd like to get added to the team that manages issues, please reach out. We have a handful of non-Facebook maintainers with this type of access and we're always looking for more. Shoot an email to my first name @ fb.com. At this time, we're only automatically closing issues that don't make use of the template. The requirements are actually quite lax: all we ask is for you to run `react-native info` so we can get more information about your setup, and a minimal reproducible example. Questions and requests for help do get sent to Stack Overflow, and this is with the community's best interest in mind as we want to focus on bugs and regressions that affect people's apps. For anything that is not a bug report or a request for help, we have an open-ended discussion template that can be used to file issues that used to get closed automatically in the past. We used to close stale issues more aggressively in the past, which was needed to get us down from thousands of open issues down to a more manageable state. The bot now only closes issues after four months of inactivity. The bot does give a 30 day warning which should be enough for people to verify if the bug is still present in the latest release, in which case they can leave a comment and the bot won't bug you for another 90 days. This way, we can prune out any issues that got fixed in a release - as others have commented, sometimes the people fixing a bug are not aware that an issue was filed for the bug for various reasons. But the true purpose of the stale bot is transparency: if there has been no activity in the issue in such a long time, it's not something people should expect to see fixed soon. Typically, issues where someone is able and willing to provide a fix for, or long-running issues describing a problem that does not have an easy fix but the core team wishes to fix at some point, will have some sort of ongoing discussion, in which case we protect the issue from being closed by adding the appropriate label ("Core Team" or "For Discussion"). Finally, I want to point out that the project is open source. If you are waiting for a fix to be merged and need to unblock yourself right now, you can always cut a release off your own fork. Please let us know when you do this, as this helps provide us with some signal about PRs that could be prioritized. PS: If you would like to learn more about how we prepare each release, please visit https://github.com/react-native-community/react-native-releases/issues https://github.com/react-native-community/react-native-relea...

by plopz 8y ago

arcticfox 8y ago

I've had this exact experience multiple times. Ironically if you wrote this up as an issue in their tracker, I would surely have one more such experience when they closed it shortly after. That said I complain out of love, because React Native is just awesome when it works.

52-6F-62 8y ago

I've found that to be relevant for a few issues (including one of my own) with Facebook Open Source projects—that or they just go unheeded by staff, but confirmed by a stream of others. I am a distant outsider to that company, I haven't used the platform in years and remain quite critical of it and many business practices especially regarding recent exposures (though I am a fan of their engineering they've released or open-sourced for the web)— yet I can understand somewhat how staff associated with such projects are not necessarily actively and regularly allocated to addressing those issues. At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company [re: endpoint-shareholders]—mindshare, general confidence, whatever. Big corps often do what big corps do...

danabramov 8y ago
>At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company That's not the case with React Native though. The problem is that the surface area is vast, and the popularity is booming through the roof. If RN team looked at every issue, the (very active) development would stall completely. On the "web" React repo we can afford to do this because our surface area is much smaller, but on RN it's not practical. So instead, the RN team tends to focus on the issues that are reported most often by the FB product teams. While this is not a great outside communication strategy, it ends up highlighting most pain points shared by folks outside the company too. Note this includes vast architectural improvements as highlighted in the post--something that goes way beyond a traditional GitHub issue report. While admittedly this approach puts FB's needs first, it also serves as an important way to keep the team focused. It is very hard to deal with dozen new issues every day and still move the project forward so they chose this path. I want to highlight that RN has maintainers outside of FB who help with different parts of the codebase (because again, the surface area is vast), sometimes with more expertise in those areas than people at FB. So the project isn't dependent on FB maintainers looking at issues alone. Folks outside can, and do help. This doesn't mean issues don't end up being addressed in the end. But GH issue communication model just doesn't scale well for RN.
- 52-6F-62 8y ago
  All good points, thanks. I guess I was remarking on other experiences more to do with other FB Open Source projects versus giants like RN. edit: Just realized which Dan you are. Thanks for the insights. Your team does good work.
- olfactory 8y ago
  I think you should just hire a few smart people who can be dedicated to supporting these issues which are high priority outside Facebook. These issues are extremely costly to teams using React and they absolutely need much faster resolution.
  - tmaier 8y ago

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

jbarham 8y ago

It's the CADT model of software development: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html

tlrobinson 8y ago
FYI links to jwz.org from Hacker News redirect to an... interesting... image. Copy and paste into your browser instead. As an aside, who's really the man child? Hacker News users, or the ~50 year old man insulting/trolling them with that image?
maddyboo 8y ago
NSFW Warning
- deleted 8y ago
  [deleted]
- jocoda 8y ago
  works ok for me now
  - maddyboo 8y ago
    Previously it redirected to a photoshopped picture of a testicle in a cup.
    - elbear 8y ago
      It still does for me.
paulddraper 8y ago
Strip your referrer https://fkref.com/?8XB37z8i https://fkref.com/?8XB37z8i

whistlerbrk 8y ago

I mean... It's a fast moving ecosystem and a coalition of the willing. You have to submit PRs too. I'm not unsympathetic to your claim but context matters. This is an enthusiasm problem. Not a community one

shaneos 8y ago

The response that I've gotten, after complaining repeatedly, is that the team simply has no time to look at any externally reported issues, and that it's essentially a waste of time opening an issue. This makes me very sad (as an ex-FBer especially), I wish that FB would just add another 3 or 4 engineers to the team with the explicit goal of giving them the bandwidth to be good open source stewards. I'm sure the FB engineers don't like having to ignore the community, but they do as a matter of policy.

olfactory 8y ago
This is a great point. There have been a few issues that I've followed only to find that eventually the entire thread on Github with tons of example cases of the bug gets "closed for inactivity" because nobody from Facebook would respond to it.
ricardobeat 8y ago
They don't need to add more engineers - as an open-source project, all they should have to do is put one person to manage the community, encourage and vet new contributors. But that would mean losing some control.
ascorbic 8y ago
They could learn a lot from Microsoft. VS Code, Typescript and related projects are a shining example of how to handle issues on open source projects. In fact, considering what heavy users they are of React Native, maybe Microsoft could be taking a more active role in the core project.

golergka 8y ago

I've had the same experience in multiple open source projects. Seems like not spending though resources on unsexy things, like QA, is typical for open source – although I'd rather expect it from volunteers than FB's engineering team.

sercand 8y ago

Another similar issue is they never accept Pull Requests from github.

HectorRamos 8y ago
There's a long tail of PRs to go through and review, and the ones we review may take a while to get to a point where they are accepted, but saying PRs are never accepted isn't quite accurate: https://github.com/facebook/react-native/pulls?utf8=%E2%9C%93&q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+-author%3Ahramos+label%3A%22import+started%22 https://github.com/facebook/react-native/pulls?utf8=%E2%9C%9...

HectorRamos 8y ago

I'm one of the open source React Native maintainers here at Facebook, and I'm the one who has set the direction for how issues are treated on our React Native repository. To anyone whose issue I've closed prematurely, it's OK to feel upset about it. Please do let me know when that happens, as that is the signal I'm looking for. Out of thousands of issues that the bot has closed automatically, only a few dozen end up getting commented on after the fact. Some of these issues we won't reopen because there is no minimal repro (usually because they were opened before we started enforcing the issue template, in which case, please open a new issue!), but in many cases all it needs is for a maintainer to go in and re-open the issue. If you're reading this and you are one of the people actively participating in the repo, and you'd like to get added to the team that manages issues, please reach out. We have a handful of non-Facebook maintainers with this type of access and we're always looking for more. Shoot an email to my first name @ fb.com. At this time, we're only automatically closing issues that don't make use of the template. The requirements are actually quite lax: all we ask is for you to run `react-native info` so we can get more information about your setup, and a minimal reproducible example. Questions and requests for help do get sent to Stack Overflow, and this is with the community's best interest in mind as we want to focus on bugs and regressions that affect people's apps. For anything that is not a bug report or a request for help, we have an open-ended discussion template that can be used to file issues that used to get closed automatically in the past. We used to close stale issues more aggressively in the past, which was needed to get us down from thousands of open issues down to a more manageable state. The bot now only closes issues after four months of inactivity. The bot does give a 30 day warning which should be enough for people to verify if the bug is still present in the latest release, in which case they can leave a comment and the bot won't bug you for another 90 days. This way, we can prune out any issues that got fixed in a release - as others have commented, sometimes the people fixing a bug are not aware that an issue was filed for the bug for various reasons. But the true purpose of the stale bot is transparency: if there has been no activity in the issue in such a long time, it's not something people should expect to see fixed soon. Typically, issues where someone is able and willing to provide a fix for, or long-running issues describing a problem that does not have an easy fix but the core team wishes to fix at some point, will have some sort of ongoing discussion, in which case we protect the issue from being closed by adding the appropriate label ("Core Team" or "For Discussion"). Finally, I want to point out that the project is open source. If you are waiting for a fix to be merged and need to unblock yourself right now, you can always cut a release off your own fork. Please let us know when you do this, as this helps provide us with some signal about PRs that could be prioritized. PS: If you would like to learn more about how we prepare each release, please visit https://github.com/react-native-community/react-native-releases/issues https://github.com/react-native-community/react-native-relea...