Our documentation is important to us, please provide feedback on how we can improve it.
Firstly, thanks for considering contributing to React Native Firebase! It's people like you that make the open source community such a great community! 😊
We welcome any type of contribution, not just code.
You can learn more about the various ways of contributing to this project by visiting any of the sections below.
error_outlineIssues, PRs & Project Management
Help out with GitHub Issues, answering help requests on Discord and reviewing GitHub Pull Requests. This helps maintainers focus more on programming.
Adding new guides, examples, updating references or new FAQs. We also welcome grammatical improvements, e.g. fixing spelling mistakes.
codeCode, Testing & Review
Learn how to contribute, review and test code to the project and learn more about our coding guidelines.
editMarketing & Content
Have you recently written an article or tutorial about React Native Firebase? We'd love to include it on the documentation.
person_pinCommunity & Events
Hosting a meetup or event that features React Native Firebase? We may be able to sponsor it through our Open Collective, provide swag or even attend it.
attach_moneyDonations & Expenses
Donating through our Open Collective exclusively helps to support all the maintainers and collaborators. We also encourage contributors to submit expenses for work done.
Code of Conduct
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
Discord Server Code of Conduct
When joining and interacting with our Open Source Discord server we kindly ask that you follow the above linked Code of Conduct at all times.
As the creators and maintainers of this project, we want to ensure that the project lives and continues to grow. Not blocked by any singular person's time.
One of the simplest ways of doing this is by encouraging a larger set of shallow contributors. Through this we hope to mitigate the problems of a project that needs updates but there is no-one who has the power to do so.
If you get a merged Pull Request, regardless of content (typos, code, doc fixes), then you'll most likely receive push access to this repository. This is checked for on pull request merges and an invite is sent to you via GitHub.
Offhand, it is easy to imagine that this would make code quality suffer, but in reality it offers fresh perspectives to the codebase and encourages ownership from people who are depending on the project. If you are building a project that relies on this codebase, then you probably have the skills to improve it and offer valuable feedback.
Everyone comes in with their own perspective on what a project could/should look like, and encouraging discussion can help expose good ideas sooner.
Why do we give out push access?
It can be overwhelming to be offered the chance to wipe the source code for a project.
Do not worry, we do not let you push directly to master, docs or any of the version (e.g.
v5.x.x) branches, these branches are protected by the review process. We have the convention that someone other than the submitter should merge non-trivial pull requests.
As an repository contributor, you can merge other people's pull requests, or other contributors can merge yours. You will not be assigned a pull request, but you are welcome to jump in and take a code review on topics that interest you - just let others know you're picking up something by tagging in on an existing issue or creating a new one and assigning it to yourself.
This project is not continuously deployed, this leaves space for debate after review and offering everyone the chance to revert, or make an amending pull request. If it feels right and follows the guidelines, then merge.
How can we help you get comfortable contributing?
It is normal for a first pull request to be a potential fix for a problem but moving on from there to helping the project's direction can be difficult.
We try to help contributors cross that barrier by offering good first step issues (labelled
Help: Good First Issue). These issues can be fixed without feeling like you are stepping on toes. Ideally, these are non-critical issues that are well defined. They will be purposely avoided by mature contributors to the project, to make space for others.
Additionally issues labelled
Help: Needs Triage or
Help: General can also be picked up, these may not necessarily require code changes but rather help with debugging and finding the cause of the issue whether it's a bug or an users incorrect setup of the library or project.
We aim to keep all project discussion inside GitHub issues. This is to make sure valuable discussion is accessible via search. If you have questions about how to use the library, or how the project is running - GitHub issues are the goto tool for this project.
The project is owned and managed by Invertase.