🏗 starting

Author: kelset

README.md

@@ -0,0 +1,37 @@
+# React Native: Discussions and Proposals
+
+Do you have an idea on how to make React Native better?
+
+Do you want to discuss an aspect of the framework?
+
+This repository is the right place to do so!
+
+## Introduction
+
+This repository was born by the desire of more transparency and a dedicated communication channels among members of the community.
+
+In order to do so, it has been decided to focus this repository to provide a safe environment to propose and generate interesting conversations related to the [main React Native](https://github.com/facebook/react-native) repository.
+
+### Discussions
+
+React Native is still a young framework, and its rapid release cycle leaves the door open for discussing how it can evolve at every step of the way.
+
+The issue section of this repository is open for anyone to propose a subject related to the React Native library that deserves a discussion.
+
+### RFCs
+
+The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to be proposed and championed to then enter the project.
+
+It is inspired by the [React RFC repo](https://github.com/reactjs/rfcs), but today we don't expect for every substantial change to go through this process; however, we hope that this brings more awareness to the community.
+
+## CoC
+
+Similarly to the main repository, this project has adopted a Code of Conduct that we expect project participants to adhere to. Please read [the full text](https://code.facebook.com/codeofconduct) so that you can understand what actions will and will not be tolerated.
+
+## TODO
+
+- [ ] better README (expand on the Discussion section, explain better why another repo)
+- [ ] create label system
+- [ ] create templates for issues and PRs
+- [ ] migrate [For discussion](https://github.com/facebook/react-native/labels/For%20Discussion) issues from the main repo
+- [ ] complete and review the RFC process

proposals/0000-template.md

@@ -0,0 +1,58 @@
+---
+title: Title goes here
+author:
+- Jane Doe
+date: today
+---
+
+# RFC0000: Title goes here
+
+## Summary
+
+Brief explanation of the change.
+
+## Basic example
+
+If the proposal involves a new or changed API, include a basic code example. Omit this section if it's not applicable.
+
+## Motivation
+
+Why are we doing this? What use cases does it support? What is the expected outcome?
+
+Please focus on explaining the motivation so that if this RFC is not accepted, the motivation could be used to develop alternative solutions. In other words, enumerate the constraints you are trying to solve without coupling them too closely to the solution you have in mind.
+
+## Detailed design
+
+This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with React Native to understand, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used. Any new terminology should be defined here.
+
+## Drawbacks
+
+Why should we _not_ do this? Please consider:
+
+- implementation cost, both in term of code size and complexity
+- whether the proposed feature can be implemented in user space
+- the impact on teaching people React Native
+- integration of this feature with other existing and planned features
+- cost of migrating existing React Native applications (is it a breaking change?)
+
+There are tradeoffs to choosing any path. Attempt to identify them here.
+
+## Alternatives
+
+What other designs have been considered? Why did you select your approach?
+
+## Adoption strategy
+
+If we implement this proposal, how will existing React Native developers adopt it? Is this a breaking change? Can we write a codemod? Should we coordinate with other projects or libraries?
+
+## How we teach this
+
+What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing React patterns?
+
+Would the acceptance of this proposal mean the React Native documentation must be re-organized or altered? Does it change how React Native is taught to new developers at any level?
+
+How should this feature be taught to existing React Native developers?
+
+## Unresolved questions
+
+Optional, but suggested for first drafts. What parts of the design are still TBD?

proposals/README.md

@@ -0,0 +1,40 @@
+# Planning and Proposals for Reach Native
+
+Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow in the React Native project. Some changes are substantial enough to need additional planning, and others have enough impact to need additional community input. We ask that both of these use the following proposal format below when practical.
+
+[Active Proposal List](https://github.com/react-native-community/discussions-and-proposals/pulls?q=is%3Aopen)
+
+## The process
+
+In short, to make a major change to React Native, make a proposal and submit it as a pull request. The community will review it and may opt to approve it. At that point the proposal is accepted and may be implemented.
+
+- Fork this repository [react-native-community/discussions-and-proposals](http://github.com/react-native-community/discussions-and-proposals)
+- Copy `proposals/0000-template.md` to `proposals/0000-my-feature.md` (where 'my-feature' is the title in kebab case; don't assign a number yet).
+- Fill in the proposal. Put care into the details: **Proposals that do not present convincing motivation, demonstrate understanding of the impact of the design, or are disingenuous about the drawbacks or alternatives tend to be poorly-received**.
+- Submit a pull request. As a pull request the proposal will receive feedback from the larger community, and the author should be prepared to revise it in response.
+- Build consensus and integrate feedback. Proposals that have broad support are much more likely to make progress than those that don't receive any comments.
+- Eventually, the team will decide whether the proposal is a candidate for adoption.
+- A proposal can be modified based upon feedback from the team and community. Significant modifications may trigger a new final comment period.
+- A proposal may be rejected by the team after public discussion has settled and comments have been made summarizing the rationale for rejection. A member of the team should then close the associated pull request.
+- An proposal may be accepted. A team member will merge the proposal's associated pull request, at which point the proposal will become adopted.
+
+## After acceptance
+
+Once a proposal is accepted, then authors may implement it. This may mean submitting a pull request to the React Native repository or putting some other process into place. Acceptance however does not mean that resources are committed to the work; instead it means that the group is open to the change taking place.
+
+Modifications to accepted proposals can be done in followup PRs.
+
+## Implementing a proposal
+
+The author of a proposal is not obligated to implement it. Of course, the proposal author (like any other community member) is welcome to post an implementation for review.
+
+## Reviewing a proposal
+
+Periodically the team will attempt to review the active proposals. We try to accept proposals at the monthly team meeting, and actions are recorded in the meeting minutes. Every accepted feature should have a core team champion, who will represent the feature and its progress.
+
+**React Native's proposal process owes its inspiration to the [Rust RFC process], the [Ember RFC process], the [Yarn RFC process], and the [React RFC process]**
+
+[yarn rfc process]: https://github.com/yarnpkg/rfcs
+[react rfc process]: https://github.com/reactjs/rfcs
+[rust rfc process]: https://github.com/rust-lang/rfcs
+[ember rfc process]: https://github.com/emberjs/rfcs