Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
React-native-community & React-community: let's talk about them #63
With this discussion, I want to tackle a long lasting conversation that, like a wave, comes and goes in the chats of the React Native Contributors channels.
Historically, as umbrella organisations for react-native projects, there have been for a long time two entities:
And the conversations happened lately seemed to suggest that now there is no more the need for these two to be split.
The Core of It
Since I started using React Native, I become more aware of how much developers rely on third party packages to quickly insert new functionalities in their projects (given most of them come from a Web background where this is the approach*).
While a portion of those are hosted in repositories owned by the single person, a few of the 'most used' were instead in React Community or React Native Community. The fact that these two orgs coexisted was always a bit confusing to me, and also created the doubt of a scattered community and a bit of a 'bias' towards one or the other (ex. "oh well if it's hosted on XXX it's better").
Over the past 6-8 months, the React Native Community organisation has become a de-facto "officially endorsed by FB" hosting components from The Slimmening (ex. WebView) and with this very repo and the releases one I become more aware of how much the community is a shaping force in the evolution of React Native.
But this is still history-in-the-making, and I strongly feel that we need to take this chance to resolve this duality, and by doing so establish some structure to it so that everyone can benefit from a trustful place to get involved.
I believe that, similarly to projects like Flutter or Ionic (IIRC), the whole React Native community would benefit from an org that, by enforcing a set of standards for all the packages/repos hosted in it and providing a common place for all the maintainers to help each other, provides quality code for everyone and set the example for everyone in the community.
In conclusion, here's what I'd like to see happen:
* on the other hand, mobile devs expect more of a 'all in one' solution
** this whole process would also automatically effect the Slimmening repos, for which there has been talks of creating some guidelines but nothing has been done yet - so yeah we can merge the efforts
given the nature of the discussion, I'm tagging here all the people in the two orgs to make sure that they are aware of it:
@anp @brentvatne @felipecsl @ide @jimmylee @kmagiera @osdnk @skevy @tsapeta @axe-fb
(sorry in advance if you are not involved anymore
This all looks quite good to me and it seems to make sense to combine efforts.
I do have one question and a comment:
Thanks for starting the discussion and providing a nice recap.
That's, great. I think the Ocaml manifesto is a great starting point.
Just my 2 cents.
The smaller/simpler the library is, the easier you'll find contributors/maintainers (IMO).
Quick intro just in case, I'm the main contributor to the react-native-webview repository, so I already encountered most of these issues
I think it would be really bad not to step up and do this. Enforcing clear rules will help new contributors on every project to have clear rules and will show that we really care about their inputs / contributions.
I've just read the OCaml manifesto and I really like the contents / ideas inside it. Most of what inside would be completely applicable for us.
I think it is okay that some people won't want to follow the manifesto to the letter. However if a repository does not want to follow the rules, I think it should not stay in the community as it need to be easy for anyone to trust and contribute to the community repositories. (However if anyone does not want to follow the rules and have good reasons we might want to update the rules, let's not close our minds to anything different)
I'm no expert on that, but for now for the webview I've created a npm user react-native-community-bot that does all the publishing for me
This is something that could help have a healthier community but I guess we need to be careful on the how/why/when !
I'm no longer working at Expo and so I don't have any time carved out for RN stuff anymore, but I'd like to quickly express support for the general direction here. We created
To support what @Titozzz said (as another
I've created a guide for my own company here: https://github.com/infinitered/open-source/blob/master/Continuous-Deployment-Setup-NPM.md
This should help you started on CircleCI, which I do recommend.
@jamonholmgren We did also setup semantic-release for
Also there are many great react-native libraries that are not updated any more and I would love to see instructions on how to migrate those to react-native-community/react-community!
This issue makes me really excited!
Historically, I think it was super confusing for the developers what community was the "official one". Over time, I developed the conclusion that React was the "official" one (as lead by Expo in collaboration with React Native team members) whereas React Native Community was the one run by the community.
I am really happy that it became much more than just a place for projects, with RFC and Releases repositories being meta-projects for the community.
I think the plan presented in the first issue is good - we need a manifesto and some simple governance guidelines. I think this is really important first step. This organisation is going to be the central place for the community, which is going to take the momentum now.
Answering your questions:
I like the
In my understanding, when project is transferred to this organisation and becomes developed under React Native Community, its ownership is also shared with the members of this organisation. When a lead maintainer (aka product owner) wants to stop, he should follow the process (that we develop) of transferring this over to someone else within the RN Community. It is similar to what you would usually do when one of your employees leaves and there's work left that has to be taken.
If the repository stops following the manifesto, we should first check why it happens. I would be sceptical about removing projects from the community. Transferring ownership and the project would be similar to what happened recently with
We could replace the
As I said in the previous post, transferring project here also shares the ownership with the RN Community. Having a single
Look at Hapi.js community - some of the projects that are part of their Github organisation have a sponsor (there's a banner) and what they also do, which is great, is that each release is sponsored by a different company. Could be useful to get some funds into making change-logs and releases.
I think this would be a massive boon to the community and could help solve some of the issues where libraries are abandoned by authors and are left without a maintainer.
Is there currently any information about how to ask for a project to be transferred into
I have recently taken over maintainership of the previously abandoned
I agree with all being said, sounds like a wonderful idea. The only little detail I would like to add is that I think it would make a lot of sense to clarify what a project needs to fulfill and what a maintainer needs to so that it can enter this organization. (For example, I think
Hey everyone, thanks for the positive feedback so far
In the meantime, to keep the ball rolling:
I think it's an edge case - like, navigation is its own org - but tbh I don't see any issues with components that also work on Web, but ofc we should at least expect proper RN support first.
Matteo, as Mike wrote a bit after, there are actually ways, and also there is also the option of archiving a repo if we can't migrate it to the latest 'lead maintainer'.
Absolutely! We should have the same setup for all the repos (or at least an how to) for how to handle releases, how to handle issues, changelogs...
This is precisely what we'd like to produce along the manifesto I think, so yeah atm there are no fixed rules but until we write them down feel free to suggest anything around them :)
Sorry for the late answer, I'm the creator and maintainer of
I think merging the two organisations under react-native-community is the right move. We need a list of strong and maintained packages (possibly a simple website, with search).
Also, I would like to put react-native-permissions under the organisation (if @yonahforst agrees), and work on a v2 based on PermissionAndroid API for the android part (I guess it will not stay in the core)