Contact for Expo Go contributions
Before putting work into a Pull Request for Expo Go, check with the Expo team on Discord at https://chat.expo.dev.
Expo & React Native · all subjects
asked in real use
8 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Documentation reviewer role: accuracy vs implementation
The documentation reviewer checks whether documentation is true and matches the code implementation. The reviewer reads source code in packages/<pkg>/src/ before reporting discrepancies. Prose style is machine-enforced by linters (Vale, oxlint, eslint) so style issues should not be flagged.
Platform-specific behavior claims must match implementation
When documentation states a behavior is universal but the diff changes only one platform, or when two platform implementations (iOS, Android, web) genuinely differ, the reviewer must flag this discrepancy. The repository ships iOS, Android and web from one API, so platform differences must be documented accurately.
Code samples must use exported and current APIs
Code samples must import only symbols that the package actually exports or still exports under that name. Samples cannot use APIs that have been renamed, deprecated, or removed in the same PR. Samples must include all now-required arguments, providers, or configuration steps.
Translated and versioned documentation must stay consistent
When English documentation under docs/pages/ changes, translated mirrors (such as docs/pages/ja/) must not be left documenting old behavior. Changes to docs/pages/versions/unversioned/ must describe behavior in the target SDK version. New or renamed pages must be reachable from docs/constants/navigation.js.
User-visible API changes require documentation
New public exports, props, config options, or CLI flags must have documentation somewhere in the PR. Changed defaults or newly required permissions must be documented. Documentation should not contradict the new behavior.
Do not flag: prose style, links, version snapshots, typos, undocumented unchanged items
The reviewer should not flag prose style (wording, tone, capitalization), broken links, Tailwind classes, missing CHANGELOG entries, versioned documentation snapshots, typos in comments that do not change meaning, requests to document unchanged items, marketing opinions, or documentation for internal-only APIs marked @hidden.
Verify implementation before claiming documentation is wrong
Read the source code implementation before reporting a documentation discrepancy. A documentation finding that turns out to correctly describe the code is worse than silence. False positives undermine reviewer credibility.