Merge pull request #274 from react-native-community/organization-repo…

…sitory-policy

Add organization repository proposal and plan docs

partners/0000-partner-organizations.md

@@ -0,0 +1,17 @@
+# Partner organizations and the React Native Community organization
+
+On April 17, 2019 an initial list of partner organizations was included in [a description of the React Native ecosystem](https://github.com/facebook/react-native/commit/a1250da64625c1da581fe600f805fd321cd12d4f) in the `facebook/react-native` repository.
+
+> Partners are companies that are significantly invested in React Native and have been for years. Informed by their use of React Native, they push for improvements of the core and/or the ecosystem around it. Facebook's partners think of React Native as a product: they understand the trade offs that the project makes as well as future plans and goals. Together we shape the vision for React Native to make it the best way to build applications.
+
+The list of partners can expand and contract over time. At the time of writing the current list of partners is, in alphabetic order: Callstack, Expo, Facebook, Infinite Red, Microsoft, and Software Mansion. Among these partners are creators and stakeholders in the React Native Community organization.
+
+## React Native Community organization: formalizing a decision process
+
+The motivating example for the need for a more formalized decision process can be seen by looking at the ["What packages belong in react-native-community?"](https://github.com/react-native-community/discussions-and-proposals/issues/176) issue, which has remained open for nearly a year and a half despite being a fundamental question for the organization. Part of the reason that this question remained unanswered for so long is that there wasn't any formal decision making process in place for the organization and nobody wanted or had the authority to act unilaterally, so it wasn't clear how to proceed.
+
+The creators of the React Native Community organization decided that a practical way to make good decisions for the organization would be to have representatives from each of the React Native partner organizations vote on any proposals for significant changes. This would ensure that a diverse range of interests were considered while still limiting the number of parties involved to a small enough group to minimize overhead.
+
+To initialize a governance model, representatives from the partners took a vote that on the first proposal: "decisions that will meaningfully change the react-native-community organization will require approval by a majority of partners". To give all partners a voice in the initial decision, we agreed that this vote to establish majority rule would need to be passed unanimously.
+
+The vote passed 6-0, establishing a governance model where partners can make decisions on behalf of the react-native-community by majority rule.

partners/0001-organization-repository-policy.md

@@ -0,0 +1,47 @@
+# What repositories belong in React Native Community?
+
+## Summary of the current state
+
+#### The React Native Community organization has no official policy for what repositories belong or do not belong in the organization. It currently is home to four categories of repositories:
+
+1) modules that were initially in the react-native repository but separated out (async-storage, etc).
+2) packages used to support these modules (bob, etc).
+3) resources for the react-native community (discussions-and-proposals, upgrade-helper, releases, etc).
+4) arbitrary modules that were added at some point for different reasons (video, camera, linear-gradient, etc).
+
+> :bulb: [Check out this gist](https://gist.github.com/brentvatne/9ab778c9d68f48e47c9987690232d131) for a full list of repositories and their groupings
+
+#### React Native Community is perceived by developers in the ecosystem to be a 2nd party organization (not quite "core", blessed and worked on by Facebook and the core team, and not on the same level as other third parties) and packages are therefore assumed to be high quality, well supported, and generally trustworthy.
+
+Perceived affiliation between Facebook and the repositories in the organization is not desirable for Facebook or the community, but it's hard to avoid. The organization has some "official" repositories like `discussions-and-proposals` and `releases`, and so putting other libraries next to them naturally has this effect. The result is that the libraries in the organization have a marketing advantage over other libraries in the ecosystem, and this is counterproductive to creating an ecosystem where the best projects rise to the top.
+
+#### Developers use the React Native Community organization to discover packages ("does React Native Community have a package for X?") rather than a tool that is better suited for the job.
+
+Given the previous point, it makes sense that users will make the React Native Community organization their first stop in discovering libraries to use in their projects. GitHub organizations are not meant to serve as a directory for a community of projects and does a poor job of it compared to a purpose-built tool, such as React Native Directory, which is capable of listing projects from any organization and providing additional context to help developers make an informed decision.
+
+#### Authors and users of libraries frequently request that a library be moved to React Native Community.
+
+This could be because it is no longer maintained, or the author wants help, or users want more confidence that it will continue to be maintained, or the author wants to promote their library and get a boost to their library downloads and improve their CV or ability to sell their services to clients by association with the organization.
+
+The incentives for a developer to try to get a repository into the React Native Community organization hint at the underlying issues discussed above.
+
+There is no clear benefit to including tens or hundreds of libraries maintained by distinct groups of people (or not maintained) in a single organization, and so we have been holding off on adding new repositories to the organization until some clarity is achieved (hopefully through this discussion).
+
+## Proposed change
+
+#### React Native Community will transition towards hosting only the repositories that fit into category 3.
+
+The organization will contain repositories that act as forums for structured discussions and/or provide information about React Native and the ecosystem. These repositories may be purely textual, or they may be tools like the Upgrade Helper and React Native Directory, depending on what is better suited for the job. The organization will not include libraries that developers install and use in their projects.
+
+Libraries that fit into categories 1, 2, and 4 will be moved to other organizations or users. For example, Callstack might take over some projects that they actively maintain and Microsoft might take others. Unaffiliated developers would just move the repository to their own personal GitHub or an organization built specifically for the repository, eg: http://github.com/react-navigation/. An action plan can be detailed at a later date.
+
+This also solves the issue of arbitrarily blessing specific solutions that may not be the best now or in the long term for the ecosystem. Rather than blessing specific libraries, we can direct developers to the [React Native Directory website](https://reactnative.directory) and continue iterating on it to help developers assess quality and discover and select the best packages for their needs. Additionally, we can move React Native Directory back to React Native Community. Developers who wanted to add their repository to the organization for marketing purposes can put it on the directory instead.
+
+### Tradeoffs
+
+- Many packages have moved their name to the @react-native-community npm scope and removing that would create thrash. This is not a big deal for packages that are directly consumed by the developer, in my opinion, but it can be in places where the package is heavily depended on by other packages, eg: @react-native-community/async-storage is a building block for many other libraries.
+- Lean core libraries include some fundamental building blocks for most apps, like slider, net-info, progress-view, webview, and async-storage. Will moving them out of the organization make them more difficult to discover?
+
+## Result
+
+Partners voted unanimously to approve the proposed change on 08/19/2020.

partners/0002-apply-organization-repository-policy.md

@@ -0,0 +1,31 @@
+# Plan for applying the new React Native Community repository policy
+
+To summarize the descision made in ["What repositories belong in React Native Community?"](https://github.com/react-native-community/discussions-and-proposals/blob/master/partners/0000-organization-repository-policy.md):
+
+> The organization will contain repositories that act as forums for structured discussions and/or provide information about React Native and the ecosystem. These repositories may be purely textual, or they may be tools like the Upgrade Helper and React Native Directory, depending on what is better suited for the job. The only exception to this is React Native CLI, which will continue to live in React Native Community as long as the maintainers believe this to be the best home for it.
+
+[The partners making this decision](https://github.com/facebook/react-native/blob/master/ECOSYSTEM.md#partners) prioritize the health and growth of the community of React Native developers, which is much larger than those with maintainer access to any specific organization. High quality modules can and should come from anyone, anywhere. We recognize that developers value using the react-native-community brand as a library quality heuristic, but we believe that there are heuristics that are more useful and also healthier for the community. Our focus will be on things that scale; helping discoverability, making it easy to find quality packages, and building tooling to help create and maintain these packages.
+
+Now that a policy has been decided, we can move forward with enacting the changes to align the organization with it. As a maintainer of one of these packages, you don't need to wait to start making these changes. While you may follow what you think is best for your package, we are providing some recommended steps we think will help ease the migration.
+
+That said, **we know that changing package names can be challenging and a difficult transition for the ecosystem**. We will take care to support the community through this migration as best as we can.
+
+## Where on GitHub will the repositories be moved to?
+
+Our recommendation for lean core libraries and libraries with multiple maintainers is to move them to their own dedicated organization, for example: react-native-webview would be moved to a new organization called react-native-webview, and would live at react-native-webview/webview. We have gone ahead and reserved all of the organizations by these names where possible, reach out to @brentvatne to have him transfer ownership to you if needed.
+
+If a library has just one maintainer, or is maintained only by developers from a single company, then the repository may be better suited for the individual or company GitHub account.
+
+Libraries that have been archived or otherwise abandoned will be moved to a React Native Community Archive organization in order to keep the repository list focused.
+
+If you a maintainer of a repository in the React Native Community organization and have any questions or concerns about how to proceed, or if you lack the required organization permissions, please let it be known in #community-hub. If you are not sure if you have the right/authority to act on moving a repository but consider yourself to be the primary maintainer, please also raise this in #community-hub.
+
+## What should be done about packages that are scoped under @react-native-community on npm?
+
+We recommend deprecating the latest release with a message that the package name has changed, and republishing that exact same release under the new package name. Ideal package names may not always be available, but you might be able to reach out to the current owners of those packages and have them transfer ownership.
+
+Most packages that were not formerly available as part of React Native core are already unscoped. If your package used to exist without the @react-native-community scope and you have since migrated to it, you may consider migrating back to the original package name.
+
+## How will developers discover commonly needed packages like async-storage, slider, webview, net-info, and others?
+
+[React Native Directory](https://reactnative.directory/) is the recommended resource for library discovery. We have surfaced it in the official documentation and may at some point merge the two. Further discussion on how we can surface some extremely commonly required dependencies should continue on [this issue](https://github.com/react-native-directory/website/issues/444).

partners/README.md

@@ -0,0 +1,10 @@
+# Partners
+
+Members of the organizations [listed as partners on the react-native repository](https://github.com/facebook/react-native/blob/master/ECOSYSTEM.md#partners) collaborate to manage the React Native Community organization and related community tools, such as React Native Directory. Decisions that will meaningfully change the React Native Community organization require approval by a majority of partners.
+
+The scope of responsibility and list of partners is expected to change over time, and will be documented here alongside other decisions and actions.
+
+## Documentation
+
+- [0000: What repositories belong in React Native Community?](0000-organization-repository-policy.md)
+- [0001: Plan for applying the new React Native Community repository policy](2018-08-cli-meeting.md)