Data/WorkingGroups/CrashReporting
(This is a draft. Fleshing this out as we speak.)
Contents
Quick summary
- One-line description: All things crash reporting at Mozilla.
- Mailing list: crash-reporting-wg@mozilla.org
- Matrix channel (primary): #crashreporting matrix channel
- Status reports: 2021
- Current coordinator: Will Kahn-Greene
This working group is governed by Mozilla's code of conduct and etiquette guidelines. For more details, please read the Mozilla Community Participation Guidelines.
Charter
The Crash Reporting Working Group collects individuals working on crash reporting and crash data related infrastructure at Mozilla so as to coordinate and align work across groups, identify and address issues related to crash reporting and crash data, and maintain the vision and strategy for crash reporting at Mozilla.
Goals
- Build and maintain the strategic vision for crash reporting to support Mozilla products.
- Coordinate work towards the strategic vision, organization priorities, engineering initiatives, and stakeholder needs.
- Coordinate and align research and experimentation with new approaches to advance the state of our crash reporting technology.
- Centralize support funnel for stakeholders and users of crash reporting and crash data. Adding new annotations, protected data access, debugging crashes, supporting new products, supporting new platforms, data analysis, crashiness metrics, etc.
- Centralize engineering communication channels.
- Coordinate data stewardship. Lean data practices, risk vs. value, etc.
- Coordinate documenting efforts. Things like data lineage, tools, and processes. User docs, analysis docs, developer docs. Where documentation lives and how to find it.
- Capture, archive, and make searchable historical knowledge especially architecture decisions and events.
- Communicate announcements and updates about ongoing initiatives and projects that affect engineers, products, data analysis, etc.
- Celebrate and elevate the importance of our work and how it impacts product engineering and product success at Mozilla. Presentations, blog posts, mailing list announcements, etc.
- The best stickers.
Non-goals (at this time)
- This group will not own things. This group is a coordination venue for individuals and groups who own the modules and work. Future goal might be that this group is reified in some way such that it could own goals, deliverables, modules, etc.
- This group will not fix everything. This group will pick and choose feasible tasks over time that move us forward towards the vision as time and resources allow.
- This group will not own crash reporting for websites and other non-products. Maybe we could do this especially as the lines between our crash reporting infrastructure and Sentry's blur, but not now.
Stakeholders
- Those who work on crash reporting tooling and infrastructure
- Those who use and analyze crash data
- Those who work on stability related work
- Those who debug crashes
Membership
The Crash Reporting Working Group is a public group and we welcome anyone else who's interested in or works on crash reporting and crash data at Mozilla or elsewhere.
To join, subscribe to the mailing list and join the Matrix channel listed above.
Crash reporting projects/teams
| Project name | Description | Contact | For Support |
|---|---|---|---|
| Crash Reporting | Infrastructure and tools used to generate, submit and process crash reports | gsvelto | #crashreporting on Matrix |
| android-components crash library | AC crash reporter | royang | |
| Socorro / Crash Stats (module) | Mozilla's crash ingestion pipeline and tools | willkg | #crashreporting on Matrix, bugs |
| Tecken / Mozilla Symbols Server | Mozilla's symbols server | willkg | #crashreporting on Matrix, bugs |
| dump_syms | Debug symbols dumper | calixte | #crashreporting on Matrix |
| third-party symbols acquisition and management | calixte / gsvelto | #crashreporting on Matrix | |
| misc tools for crash analysis | marco | #crashreporting on Matrix | |
| clouseau | Tool to help to find patches which are potentially responsible of a crash | calixte | #crashreporting on Matrix |
| spikes | Library to detect spikes in data coming from Socorro. | calixte | #crashreporting on Matrix |
| crash correlations service | marco | #crashreporting on Matrix | |
| crashstats-tools | Python library for using Crash Stats | willkg | #crashreporting on Matrix, issues |
| Firefox profiler | Web app for Firefox performance analysis | mstange | #profiler on Matrix |
| rust-minidump | Rust crate with tools used to process minidumps | gankra / gsvelto | #crashreporting on Matrix |
| minidump-writer | Rust crate used as a replacement for the Breakpad client libraries | gsvelto | #crashreporting on Matrix |
Documentation
TBD
Initiatives / Work being done
- Breakpad client tools rewrite
- Out-of-process crash reporting
- Crash reporting oxidation
- Crash reporting oxidation sub-projects
Monthly status rollup
Every month, the coordinator will send out an email asking for status updates from teams/projects working on crash reporting things. The prompts:
- What's your team/project?
- What did you accomplish? (Descriptions, bug numbers, etc)
- What are you working on now or think you'll have done this month? (Descriptions, bug numbers, etc)
- What do you need help with?
- Blog posts, articles, conference talks, announcements in the last month?
- What else do you think is helpful for everyone to know?
Keep in mind this is a public list, so if you're working on confidential/NDA/security-sensitive things, this status update isn't the place for that.
After a few days/week/whatever, updates will get compiled into a newsletter. Use Google Docs for this so individuals can fix issues. Then send to:
- cross-posted to firefox-dev, stability, and crash-reporting-wg mailing lists
- Crash Reporting status wiki page
- TBD: a mobile list
- TBD: a Data Org list
- TBD: posted on Data blog
FAQ
TBD
