👍🎉 First off, thanks for taking the time to contribute! 🎉👍
The following is a set of guidelines for contributing to this project. Please take a moment to review this document in order to make the contribution process straightforward and effective for everyone involved.
We adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.
A great way to contribute to the project is to send a detailed report when you encounter an issue. We always appreciate a well-written, thorough bug report, and will thank you for it!
Check that our issue database doesn't already include that problem or suggestion before submitting an issue. If you find a match, you can use the "subscribe" button to get notified on updates. Do not leave random "+1" or "I have this too" comments, as they only clutter the discussion, and don't help resolving it. However, if you have ways to reproduce the issue or have additional information that may help resolving the issue, please leave a comment.
Blu's staff takes security and privacy issues seriously. If you discover a potential point of failure, please bring it to their attention immediately!
Please DO NOT file a public issue, but rather send your report privately to seguranca@useblu.com.br.
Read more: SECURITY.md
First of all, you will need to create an issue for the feature or bugfix that you want to work on. When you open a new issue, there will be a template that will be automatically added to the text of the issue, which you would need to fill in. Doing this will help us to understand better what the ticket is about.
Unsure where to begin contributing? You can start by looking through these issues:
- Good first issues - issues which should only require a few lines of code, and a test or two.
- Help wanted issues - issues which should be a bit more involved than beginner issues.
- We adopted Github Flow.
- Assigns the issue to you. Let everyone know that you took that issue to settle.
- Fork the repo and create your branch from master. A guide on how to fork a repository: https://help.github.com/articles/fork-a-repo/
- Make commits of logical and atomic units.
- Submit a pull request.
After getting some feedback, push to your fork and submit a pull request. We may suggest some changes, improvements or implementation alternatives.
In case you've got a small change in most of the cases, your pull request would be accepted quicker 😉.
Please follow these steps to have your contribution considered by the maintainers:
- Follow all instructions in the template
- Follow the styleguides
- After you submit your pull request, verify that all status checks are passing
What if the status checks are failing?
If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.
While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.
It’s important that every piece of code is reviewed by at least one core contributor familiar with that codebase. Here are some things we look for:
- Required CI checks pass. This is a prerequisite for the review, and it is the PR author's responsibility. As long as the tests don’t pass, the PR won't get reviewed.
- Simplicity. Is this the simplest way to achieve the intended goal? If there are too many files, redundant functions, or complex lines of code, suggest a simpler way to do the same thing. In particular, avoid implementing an overly general solution when a simple, small, and pragmatic fix will do.
- Testing. Do the tests ensure this code won’t break when other stuff changes around it? When it does break, will the tests added help us identify which part of the library has the problem? Did we cover an appropriate set of edge cases? Look at the test coverage report if there is one. Are all significant code paths in the new code exercised at least once?
- No unnecessary or unrelated changes. PRs shouldn’t come with random formatting changes, especially in unrelated parts of the code. If there is some refactoring that needs to be done, it should be in a separate PR from a bug fix or feature, if possible.
- Code has appropriate comments. Code should be commented, or written in a clear “self-documenting” way.
Prerequisites
- Node 12.8.0+ (if you need other versions we recommend the node version manager)
- Yarn 1.22.0+ (required, because of yarn workspace)
- VSCode (optional, but it's useful because we share common configs and extensions)
git clone https://github.com/ocean-ds/ocean-android.git # bonus: use your own fork for this step
cd ocean-android
# TODO: how to install dependencies # install dependenciesTODO: need help here.
The development language is English. All comments and documentation should be written in English, so we can share our knowledge with developers around the world.
We adopted conventional commits. This improves the readability of the git history and generates automatic changelogs.
- There's a jetbrains plugin to help you.
- Use the present tense ("add xyz" not "added xyz").
- Use the imperative mood ("move cursor to..." not "Moves cursor to...").
TODO: need help here.
TODO: need help here.
TODO: need help here.
The code that is written needs to be tested to ensure that it achieves the desired behavior. Tests either fall into a unit test or an integration test.
- All source files must be 100% coverage with tests.
TODO: need help here.
- Use markdown to create project documentation.