What packages belong in react-native-community? #176
Comments
|
Thanks for writing this up! Just for reference, let me past here some thoughts I had around this topic the other day:
|
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.
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:
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. |
|
I agree with the overall direction here. A couple of additional thoughts to consider:
|
+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/ |
|
I'd suggest three metrics for deciding which repos to include:
|
kelset
added
the
🗣 Discussion
|
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):
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
Just to mention a couple: 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): |
|
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. 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. |
@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? |
|
Idea: have an (somehow official) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Hi everyone, discussing this issue lugg/react-native-config#382 the maintainer gave me permission in this repo and in the npm. I came here to ask if we should migrate to |
|
I think you should do what is best for that project assuming it isn’t part of this org. If that means bringing on more people to maintain the project that would be a good idea regardless of what Org it was in. :-) |
|
@luancurti I personally think it's a good candidate to be adopted by the community. It's proven to be a pretty critical part of the RN ecosystem and I'd like to see the maintenance responsibilities be shared more broadly |
|
I think a repo such as luggit/react-native-config should be a community repo, since it provides android and iOS environment and build functionality, and solves vital security issues for variables in native code which JS devs wouldnt be familiar with. It's standing out as the only repo that provides all of this functionality, and it already has a growing community where it currently lives. To add to the discussion about what defines a repo that belongs in react-native-community I think it should have at least some of the following:
|
|
I noticed no more repos are being added until this discussion has reached a conclusion, although the discussion is already 4 months old. In my opinion this in unproductive. I would say adding and removing repos should be done as things evolve or react-native release out of the box features. How to deal with deprecating repos can be discussed when they arise by the community. |
|
Just peeping in to this discussion, I was brought here after looking at the handoff issue on react-native-config. I agree with @conor909 - letting this discussion lull is a bottleneck. |
|
Hey folks, I know it's not a real update on this conversation and I've not been super involved in RN the last few weeks, but I've seen in the Core Contributors Discord that this is indirectly being discussed on... hopefully over the next month or so there is going to be a clearer guideline on this topic. |
|
Come on, guys... It's already mid July almost and still no progress/clarity on adopting react-native-config into the react-native-community.. Can we please get this going as more and more developers are waiting on this??? |
|
Why are developers waiting on this? Why are they unable to use react-native-config today? |
|
@TheSavior The owner hasn't got time to maintain it, and I suppose no one person wants to take it on. You can see this issue lugg/react-native-config#382 |
|
In the meantime, I'd recommend https://github.com/maxkomarychev/react-native-ultimate-config |
|
The ownership has already been transferred, and there's a number of
developers that are willing to contribute and maintain it and/or looking to
get their pull-requests merged.
Nevertheless, it is not constructive for the whole react-native communtiy
if it takes months to take a relatively simple decision concerning a pretty
popular package.
…On Fri, Jul 10, 2020, 11:51 AM Conor McGrath ***@***.***> wrote:
@TheSavior <https://github.com/TheSavior> The owner hasn't got time to
maintain it, and I suppose no one person wants to take it on. You can see
this issue lugg/react-native-config#382
<lugg/react-native-config#382>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#176 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALSRIMCL4XZSF74U4PK7E7LR25BKRANCNFSM4JV7PW5Q>
.
|
|
Disclosure: I am the author of alternative solution https://github.com/maxkomarychev/react-native-ultimate-config.
What will be different when/if package is moved to community? What prevents people from community to open pull requests in the original repository? It looks like @luancurti is a member of the community and he has permissions. There is alternative solution https://github.com/maxkomarychev/react-native-ultimate-config and why should Btw, there is a story of a successful fork (not even transferring) of the repo to new author: from https://github.com/wkh237/react-native-fetch-blob to https://github.com/joltup/rn-fetch-blob and it happened without |
|
@maxkomarychev this discussion isn’t about react-native-config, it’s about the direction of react-native-community, but the point is it’s already been counterproductive since people were waiting on an outcome on this discussion for months before someone decided to take on the config project. It seems this discussion was the cause of the slow process for that particular package, but potentially more |
|
Personally, I would prefer that the RN community org does not grow larger - in terms of number of repos that are in it, but rather smaller, if possible. From my (limited) experience, when a library is in the RNC it (1) gives the module a "premium badge" just because of its presence in RNC - whereas in reality, any module can be great regardless of what GH org it is in. (2) Users assume that if a module is in RNC, it is top quality - and that may or may not be true. Some modules are in great shape, others like datetimepicker have a lot of work that needs to be done - I say that as that module's maintainer. This may negatively affect the orgs perception. (3) Kinda related to (2) - I feel like because a module is in RNC, folks might assume it has "a team of maintainers" - which is not automatically true, and from my experience in datetimepicker, outside contributions do not happen as often as I'd expect. |
|
Thank you everyone for sharing your perspective and insight to help work through this issue! This question has now been answered in the "What repositories belong in React Native Community?" doc. To learn more about the decision process, refer to "Partner organizations and the React Native Community organization". To learn more about the plan for moving towards the new state of the React Native Community organization, refer to "Plan for applying the new React Native Community repository policy". In summary:
|
|
Hi all. Arrived here after noticing packages like Some of the main reasons behind the lean core initiative were said to be:
Ownership of the modules was never in question; one would assume the modules would still have some kind of blessing or support from the core RN team even as they moved to separate repos. The two docs linked above say this solves the issue of arbitrarily blessing specific solutions, but I think most of us users considered that a feature, not a bug™. Ownership and quality concerns are briefly touched but not really addressed in those. I find it concerning that essential platform features such as net-info, async-storage, camera-roll, notifications, geolocation, clipboard access, are now all independent projects. There are expectations from core-sanctioned libraries - you know they will meet some baseline for testing, CI, cross-platform support, etc and be part of at least one [important app]'s test suite - that cannot be consistently met by independent repos (emphasis on consistently). These are foundational features for almost every application, not custom extensions, and there is barely any reason for competing libraries to exist in those spaces; so looking back at the original reasons it feels like throwing the baby out with the bathwater. It will hurt the experience of developing and maintaining a RN app by pushing the burden of finding & vetting libraries for basic platform features, plus making sure they are always compatible and up-to-date onto the users. Is that a desirable change? |
|
Thanks for sharing that @ricardobeat. I absolutely see where you are coming from and the desire to continue having "core-sanctioned" libraries. Your comment implies that we've historically not communicated the reality of the situation, and lulled people into a false sense of security. This change brings to the surface this reality for us to figure out how to move forward as a community. When all of these modules were built in to React Native, they were essentially unmaintained, even though to those using React Native they didn't look that way. FB didn't use them, none of the maintainers were familiar with the code and were afraid of changing it, and thus PRs didn't get merged because of that risk of breakage. So they moved out of core. Among the reasons you quoted, it also to removed FB as the gate keepers of this code, and to let people more changes more confidently. In the react-native-community org a lot of contributors stepped up and jumped in to these modules, but it wasn't any more "sanctioned" by core, by FB, or by the other partner companies. And while these maintainers did an amazing job with a bunch of these modules, many of the modules in the org stopped being maintained because the contributors stopped using them at their work, or numerous other reasons. At the same time, there have been other modules outside of core, or outside of the community that may be better maintained and have more features. Some examples are from the amazing modules that Expo maintains. But even though they are perhaps better modules, because they aren't in core, they appear "unsanctioned" and thus, to the detriment of the products teams build, they aren't being chosen. So we are moving the modules out of the Community org. These modules aren't being maintained by fewer people, and aren't any less supported. But now perception can match the reality. And with that, we can move on to helping the community focus on discoverability and deciding on the right package for their needs. That's one of the goals of reactnative.directory that we've been working on. We think this will be healthier and more sustainable in the long run than the approaches we've taken before. I hope that makes some sense. I'm happy to hear if you have more thoughts and concerns. We want to do the right things here. 🙂 |
|
@TheSavior thanks for the context! I really did not know that, had the assumption that these were developed in parallel with the core as standard platform features, and took the intent to unbundle at face value.
That is surprising - I can't picture a released app that does not use net info, clipboard or persistent storage. Does FB really not have a need for those, or just use custom private modules? |
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:
The requests I've seen recently don't fall into one of these existing categories but instead need a new category. Something like:
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:
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.
The text was updated successfully, but these errors were encountered: