RADAR-base Roadmap #
A roadmap of proposed RADAR-base Improvements. There is a tagged category for “good-first-issue” curated for new contributors. Suggestions are always welcome!
https://github.com/orgs/RADAR-base/projects/10
Contribution Guidelines #
Contributors Guidelines #
All code contributions must be made under the Apache 2 open-source licence. This licence file can be viewed in the top-level directory of the GitHub repositories in the RADAR-base Organisation.
Contributors Guidelines #
No one is perfect, and we are no different. If you find an issue, please take a few minutes to let us know.
- Take a look at the current issues (there’s a handy search feature) to see if someone has already reported an issue. If they have, workarounds or proposed fixes might be posted in the issue, which could save you time.
- If the issue has not been reported, please open an issue.
- Look for questions or updates to your issue, as we might need additional information. The faster we get the information, the faster we can resolve your issue.
- The fastest way to fix your issue is to fix the bug yourself. See the “Have a fix or want to get your hands dirty?” section below to find out how to show off your awesome developer skills!
Help Wanted flag #
This plugin is maintained by a community of developers. We do this in our spare time and don’t have unlimited time to implement features or fix bugs. As such, we look to others who can submit pull requests to fix bugs or make enhancements.
Have a fix or want to get your hands dirty? #
It’s really not that hard! If you have questions, please don’t hesitate to ask in an issue, as we can try to help point you in the right direction.
I found the code, but now what? #
Submitting a bug fix or feature takes only a few minutes.
- Fork the repository.
- Create a new branch.
- Make the code change.
- Create a commit and push it to your repo.
- See the Pull Request section to let us know if your code is ready to be merged into the main repo.
MAKE SURE THE CODE WORKS WITHOUT MODIFYING OR CHECKING IN ANY PLATFORM FILES. Any changes to platform files (like build scripts, config files or anything in the /platform directory) should be made by the plugin. Since Cordova 4.3.0, the platform management feature allows you to build your project without checking in any platform files.
Pull Requests #
- Fill in the required template
- Include one feature/bug fix per Pull Request. Multiple issues in one PR can increase the complexity of the review and could delay the merging of your code.
- Maintain the formatting (specifically white spacing) in the files you are modifying.
- Reference the Issue number in the PR if there’s a related issue
- If you are adding new APIs or changing behavior, include entries in the README.md so new users know how to interact with the new features. We want everyone to use your work!
Need to test a PR? #
We rely on the community to help test out fixes and enhancements to this plugin. You can test out a PR by running the following commands:
cordova plugin remove cordova-plugin-firebase
cordova plugin add https://github.com/<username>/cordova-plugin-firebase.git#<branch>
- replace
<username>
with the name of user/org where the branch resides - replace
<branch>
with the name of the branch used to create the PR
- replace
cordova prepare
For example, to test the fix made by PR #832, you would use the url https://github.com/briantq/cordova-plugin-firebase.git#revert-lazy-init
since briantq
is the name of the user and revert-lazy-init
is the name of the branch. This information is available at the top of each PR. For this specific PR, the following information is displayed:
- briantq wants to merge 2 commits into arnesson:master from briantq:revert-lazy-init
The last part being the vital information as it tells you exactly what to use in the URL.
Slack and Github Discussions #
Help can be sought from the community. This is voluntary support so please be mindful of community time and effort.
You may join the Developer’s Slack Channel here. There should be channels for most platform components and other discussion forums.
Most of the Key GitHub Repositories will have Discussion Channels. These are generally preferred to Slack for triage and longer component-specific discussions as they are more visible to the community.