react-native-community/discussions-and-proposals: React Native RFC Process

What React Native Discussions and Proposals Handles

This repository provides a public channel for discussing changes and ideas related to the main React Native project. Its stated audience is the React Native community, including people who want to improve the framework, contributors looking for a place to discuss framework concerns, and developers who may later participate in proposals. The README says the repository was created to support greater transparency from the Core and Facebook teams and to offer a dedicated communication channel.

It is a governance and discussion repository, not an implementation package. The repository has directories for `core-meetings/`, `partners/`, and `proposals/`, but its documentation does not identify a build artifact, executable, library entry point, or installable package. The linked homepage, `https://reactnative.dev`, belongs to React Native itself rather than to a separately documented product in this repository. This distinction matters for engineers searching for React Native code. The main framework repository is the place associated with the actual React Native library, while this repository records community discussion around that library.

The repository also has no GitHub releases according to its GitHub metadata. A missing release does not prevent participation in discussions, but it means contributors should not expect to install a versioned release from this repository.

Issue Discussions, RFCs, and Core Meeting Notes

The repository divides its participation model into discussions and proposals. The issue section is open to anyone who wants to raise a subject related to the React Native library that deserves discussion. This is the broadest part of the process. It can cover an unresolved question, a framework concern, or an idea that is not yet shaped as a formal request for comments.

The RFC process has a narrower purpose. According to the README, it provides a consistent and controlled path for new features to be proposed and championed before they enter the project. It is inspired by the React RFC repository at `https://github.com/reactjs/rfcs`, but the README explicitly says that not every substantial change is expected to go through this process. The RFC mechanism therefore operates as one route for proposing features, not as a mandatory approval gate for every modification.

The `core-meetings/` directory adds a third layer. The README states that top contributors regularly meet to discuss ongoing problems and draft solution proposals. Meeting notes and topics for that process are kept in the directory. This creates a documented path from community attention to contributor discussion and then toward a written proposal, although the README does not specify a fixed timeline, approval vote, or mandatory transition from meeting notes to an RFC.

Repository Layout and Participation Boundaries

The repository layout reflects different kinds of participation material rather than the source tree of a software package. The root README explains the process. `core-meetings/` stores meeting notes and topics. `proposals/` is the repository location for proposals. The `partners/` directory is present in the repository layout, but the README does not describe its contents or operating rules, so its role should not be inferred beyond the directory name. The `.github/` directory and `assets/` directory are also listed, but no additional workflow is documented there.

This structure tells contributors where durable discussion records may be found, but it does not provide an automated submission system described in the README. Participation begins through the repository's GitHub issue section for discussion. Proposals are maintained under the proposal area, and core meeting material is published under the meeting directory. The README does not document a CLI, GitHub Application, form schema, bot, validation command, or service that files issues automatically.

That boundary also means this repository should not be used as a substitute for reporting ordinary defects in the main React Native codebase. The README describes proposals and discussions about the framework, while the main repository is separately identified as the main React Native repository. It does not claim to provide runtime support, issue triage for implementation bugs, or a patch review process.

Joining the Discussion Without Installing a Package

There is no installation step for this repository. The README does not provide commands for adding a package, cloning a development environment, running tests, or building a service. Participants use the repository's GitHub issue section for discussions, and the repository's proposal and core meeting directories serve as the published areas for the corresponding materials.

A first contribution therefore starts with reading the root README and the linked Code of Conduct, then checking whether the idea concerns the main React Native library. If it is suitable for broad discussion, a contributor can open a discussion in the issue section. If the idea has reached the stage of a concrete feature proposal, the RFC process described by the README provides the route for proposing and championing it. The README does not provide a template, command, label requirement, or review checklist, so none can be prescribed here.

The same limits apply to examining existing work. A contributor can inspect `core-meetings/` for meeting notes and topics and inspect `proposals/` for proposals already recorded by the repository. The README does not say that proposals are automatically compiled, indexed, or synchronized with the issue section. It also does not document how a proposal moves from discussion to acceptance or implementation in the main React Native repository.

Proposal Scope, Trade-offs, and Failure Cases

The main trade-off is between an open discussion channel and a controlled proposal path. The issue section is open to anyone proposing a subject that deserves discussion, which makes it useful for early ideas and concerns that have not reached proposal form. The RFC process adds structure for new features that need to be proposed and championed. The README also avoids claiming that every substantial change must use an RFC, which preserves flexibility for other project work.

That flexibility is a real limitation for anyone expecting a complete governance system. The README does not specify the exact distinction between a discussion, a proposal, and a substantial change that does not require an RFC. It does not define acceptance criteria, decision authority, response times, implementation status, or a formal relationship between RFC outcomes and releases. A contributor can therefore identify the available channels without knowing from the README alone when a proposal will be accepted or implemented.

It is also the wrong tool for developers seeking documentation about how to build an application with React Native. This repository does not present installation instructions, APIs, components, configuration, or versioned releases for the framework. Those needs belong to React Native's main project resources. The absence of a package manifest, executable, or release record in the repository metadata reinforces that distinction.

License, Maintenance, and Upgrade Context

The GitHub repository metadata lists the license as unknown, and the README does not provide a license file or license terms. No licensing conclusion should be drawn from the repository's purpose. Contributors should verify the repository's license and any separate terms associated with the main React Native project before reusing material.

The repository is not archived, and its last push was on 2026-09-17. That fact supports saying that the repository is not marked archived and has recorded a recent push, but it does not establish who makes decisions, how quickly proposals receive answers, or whether every area is actively maintained. The repository has no GitHub releases, so there is no release history here to use as an upgrade guide.

For ongoing React Native adoption, the relevant version and compatibility information must come from the main React Native project. This repository can help establish the context of a discussion or proposal, but the README does not document a dependency upgrade procedure or a compatibility matrix.

Editorial conclusion

React Native contributors should use this repository when they want a public discussion or RFC for a change to the main React Native project. Application developers looking for installation instructions, released code, or a supported framework should use the main React Native repository instead. Before opening a proposal, contributors should verify that the topic belongs in the main project, check the existing `proposals/` and `core-meetings/` contents, and read the linked Code of Conduct.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. react-native-community/discussions-and-proposals on GitHub
4. README