What packages belong in react-native-community?

[elicwhite]

Introduction

There have been some requests lately for adding repositories to react-native-community. I'd like for the org to have some guidelines as to what should be in the org. When should existing repos be moved in? When should new packages be created first in the org vs starting outside?

From my perspective, almost all of the modules that currently exist in the org to fall into these categories:

• Modules that were initially in core but separated out (cli, WebView, AsyncStorage, etc...)
• Packages used to support these modules (react-native-circleci-orb, docker-android, bob)
• Repos maintaining the larger community of React Native (discussions-and-proposals, upgrade-helper, releases)

The requests I've seen recently don't fall into one of these existing categories but instead need a new category. Something like:

• Modules that seem important to the ecosystem, but the existing repo / maintainers are viewed by some users as not meeting their needs

Do we want to expand the scope of react-native-community to be a home for these modules?

I worry about react-native-community becoming a centralized org that most of the react-native modules want to be in. I'm even more nervous about bringing in repos or forks of repos that are currently under-maintained.

I would rather see these modules become healthy on their own, and if they can't because the existing maintainers are unreachable, then for a fork to become healthy. If that isn't possible then being in the react-native-community org doesn't seem like it would solve the problem itself.

Concrete Proposal

My concrete proposal is that the org stays focused on the three existing categories. However, is also willing to accept new modules to the org only if they are already well maintained by multiple people and very common in the community.

Examples of such modules are:

• Expo's set of well supported modules
• react-navigation/react-navigation
• wix/react-native-navigation
• kmagiera/react-native-gesture-handler
• software-mansion/react-native-reanimated

Thoughts?

I'm curious for any thoughts the community has. I wasn't around at the beginning of this org so I don't have context on the original purpose. I also work on the core and don't write many apps with RN as a user, so I'm not exactly sure how people perceive this org and if my perspective is inconsistent with that.

[grabbou]

Thanks for writing this up! Just for reference, let me past here some thoughts I had around this topic the other day:

From my perspective, RNC is a bit like standard library - provides high quality modules to work with React Native that guarantee certain level of performance, stability and maintanance (now or in the future - we will not left important modules behind). It contains the most useful modules, most important ones and things that you will need sooner or later working with React Native.

[elicwhite]

provides high quality modules to work with React Native that guarantee certain level of performance, stability and maintenance

I agree with this. Modules in the org should have a certain quality bar and be well maintained. I wouldn't want to add new modules to the org that we don't feel confident can hit this bar.

It contains the most useful modules, most important ones and things that you will need sooner or later working with React Native.

Yeah, I think it includes some of the most commonly depended on / important modules, but there are many very important modules outside the org. In fact, I think some of the most important modules actually live outside. I think typically the most commonly depended on / important modules got that way because they have a healthy set of maintainers already. Just to list a few:

• Expo's set of well supported modules
• react-navigation/react-navigation
• wix/react-native-navigation
• kmagiera/react-native-gesture-handler
• software-mansion/react-native-reanimated

I do agree though that if the maintainers of these modules asked for them to be moved into the react-native-community org, that would be a reasonable thing for us to consider.

The requests we typically see aren't from modules like these, they are from modules that are under-maintained, hoping to become maintained by being in the org.

I updated my initial post with a concrete proposal including these thoughts.

[harinikmsft]

I agree with the overall direction here. A couple of additional thoughts to consider:

• It may be worthwhile to articulate what react-native-community is not trying to be in addition to defining what it is. For example: react-native-community is not an organization of modules and components that round out the set of APIs towards a minimum viable product offering for building most react-native apps.
• While a centralized org. is probably not in the best interest of fostering a thriving community, there is still a need for publishing some recommendations on what qualities makeup a well-maintained module and for customers of react-native to be able to find/filter/navigate the vast ecosystem more meaningfully. We have been discussing about this topic and will have some proposals here shortly - I just want to tease here that whatever we come up with together should apply to the modules that do get added to react-native-community organization.

[stmoy]

provides high quality modules to work with React Native that guarantee certain level of performance, stability and maintenance

I agree with this. Modules in the org should have a certain quality bar and be well maintained. I wouldn't want to add new modules to the org that we don't feel confident can hit this bar.

+1. Part of the motivation for having modules in react-native-community is the implicit (or explicit) expectations around quality.

I'd assert that part of the motivation for having this discussion is the customer need to know which modules are of the highest quality/well maintained/supported/etc. A tangential way to help establish this list could be through secondary tools like https://www.native.directory/

[Ashoat]

I'd suggest three metrics for deciding which repos to include:

1. Popularity, eg. npm weekly downloads
2. Code quality, repo maturity. Subjective decision by scanning through the files and making sure everything's reasonable
3. Invested and involved maintainers. This one is crucial. It's worth noting that we're having trouble maintaining some of the existing RNC repos already. Some examples: react-native-push-notification-ios, react-native-clipboard

[kelset]

Hey everyone.

Thanks for opening this conversation - I swear I'll try to to be brief in my response. As conversations on this subject of packages in the community (& guidelines around them) and the role have been opened in the past (I won't repeat what was written there for sake of brevity, but I would suggest that reading them to get a better overview is key for the success of this topic):

• Migrating a repo into the React Native Community
• Guidelines for community packages
• Documenting community components
• React-native-community & React-community: let's talk about them <- in particular I would recommend this to understand how the current iteration of RNComm came to be

---

@TheSavior

From my perspective, almost all of the modules that currently exist in the org to fall into these categories:

I'm a bit surprised by this phrase, as I find it quite different. The 3 categories you mention are only represent less than 50% of the repositories in the organisation - and most of the other repositories are instead what you define as a "new" category of

Modules that seem important to the ecosystem, but the existing repo / maintainers are viewed by some users as not meeting their needs

Just to mention a couple: lottie-react-native, react-native-maps, *-tab-view, *-svg etc etc. (there are at least 35 of these) and a good portion of them were in the org before any of the ones belonging on the 3 categories above.

This is because the original thought is in line with @grabbou's POV.

All of this said, I agree that there should be a series of "metrics" to use when deciding if to "accept" an "application to RNComm" - and on this topic I agree with @Ashoat, in particular with his 3rd point (for the second one I would suggest that at least two different people would validate that in order to avoid single-person-biases).

I will not dive on the "whys" and "hows" of packages joining the RNComm for brevity sake (since the question is only about "what"), but I can confirm that what @stmoy says about "expected quality" is one of the reason there should be "relevant" packages in the org.

Last 2c$: untying a repository (+npm publish rights) from a single person but having it in an org is crucial for the long term sustainability of said package.

---

All of this said, this kind of decision is tied to some sort of governance and since it's "rooted' on members of the community actively working on these libraries I would suggest reviving these conversations (or to start new ones):

• Getting involved in the React Native Community
• Governance in the React Native Community
• Sustainability in the React Native Community

[akshetpandey]

I think one type of repo that should definitely be in react-native-community are meta-repos. Meta repos are repo that provide guidelines and tooling for creating react-native libraries.

One example is https://github.com/brodybits/create-react-native-module.
Especially considering there were code decisions made in the cli based on what this repo was doing.

I would personally also love to see a awesome-react-native type list hosted in react-native-community that includes known libraries that follow guidelines and are expected to work with most rn-community tooling without issues.

[kelset]

Meta repos are repo that provide guidelines and tooling for creating react-native libraries.

@akshetpandey there was an attempt at that with this repo -> https://github.com/react-native-community/.github but sort of died of starvation in a way

---

My brain played a trick on me and made me look at this problem in "another direction": what if there was another org for all the packs that don't belong in the RNComm, but that would still provide the basic idea of moving libs out of the ownership of a single authors? Like, something like an asylum/cattery of sort? This maybe could also be like, the minor league to RNComm's major league in a way? Where a certain libs learns/grows/validate itself (in terms of community wanting it, etc) to the point of being able to "graduate" into the RNComm?