"Crash" issues - clean-up and next steps

[trjExpensify]

Coming from this discussion.

• [ ] Only open a "crash" issue after it happens more than 10 times
• [ ] For existing crashes logged, update the reopen logic to see if the crash count is less than 10 before reopening
• [ ] Remove the $500 price cap on crash issues
• [ ] Implement source maps to aid with investigating these issues (GH)
• [ ] Close the loop on people running staging builds locally sending false positives (GH)
• [ ] Improve the documentation for how to approach these issues, and link the readme in the crash issue creation template

CC: @AndrewGable @JmillsExpensify @michaelhaxhiu @roryabraham

[JmillsExpensify]

Should we throw a Bug label on this, on someone assign themself? I'm thinking yes since some of those todos are BZ tasks.

[trjExpensify]

I don't think it's a bug really, it's a process improvement.

I'll assign myself anyway and take on this one:

Remove the $500 price cap on crash issues

[JmillsExpensify]

Ok cool. Mainly I think someone from BZ should assign themselves.

[iwiznia]

There's already an issue for the source maps https://github.com/Expensify/App/issues/9293 Not sure if we want to close that out or remove that part from this isssue. FWIW I think adding the source map should be the first step, because without it, some crashes are impossible to diagnose.

[trjExpensify]

It's linked to this issue in the OP.

[AndrewGable]

Focused on the source maps as the first priority for this, then will get to this.

[AndrewGable]

Closing per https://github.com/Expensify/Expensify/issues/243479, tl;dr we are turning off Firebase crashes for the time being.