This is Beagle's contributing guide. You will find here some resources to help you contribute.
1.1. Code of Conduct
1.2. Legal
2.1. Pull Request title
2.2. Issues
2.2.1. Check the issue tracker
4. Community
Please follow the Code of Conduct in all your interactions with our project.
-
Beagle is licensed over ASF - Apache License, version 2, so new files must have the ASL version 2 header. For more information, please check out Apache license.
-
All contributions are subject to the Developer Certificate of Origin (DCO). When you commit, use the
**-s**option to include the Signed-off-by line at the end of the commit log message.
Check out the requisites before contributing to Beagle:
When opening a PR, add the title with a prefix of the type of change you are contributing, for example feat: for a new feature. You can see other types in the How can you contribute? section.
Your Pull Request should look like this:
feat: add field in component image to allow resizingThis format is called conventional commits. It helps us understand what each modification is actually doing, and allow us to automatically generate better release notes and versions.
For more information, please read the official specifications.
If you found a bug or have an idea, check out the following sections before submitting your contribution.
All our issues are centralized in our main repository, it is quite likely that you will find a topic that is being discussed. Check the open issues, another good way to start is good first issues.
Writing a good issue will help our team better analyze and manage your contributions, therefore, follow the standards and best practices below:
With the title:
Project:Scope - Title Description
-
Project: Name of the project or repository you want to contribute to.
-
Scope: Add what your issue refers to:
-
Bug report: Report a reproducible bug.
-
Feature request: Suggest a new idea for Beagle.
-
Example: Beagle-android:feat request - Suggestion for a better user experience
With the issue description:
Try to explain the scenario to us by following these tips:
- Context: explain the conditions which led you to write this issue.
- Problem or idea: the context should lead to something, an idea or a problem that you’re facing.
- Solution or next step: this where you move forward. You can engage others (request feedback), assign somebody else to the issue, or simply leave it for further investigation, but you absolutely need to propose a next step towards solving the issue.
This is a security layer for the project and for the developers. It is mandatory.
Follow one of these two methods to add DCO to your commits:
1. Command line Follow the steps: Step 1: Configure your local git environment adding the same name and e-mail configured at your GitHub account. It helps to sign commits manually during reviews and suggestions.
git config --global user.name “Name”
git config --global user.email “[email protected]”
Step 2: Add the Signed-off-by line with the '-s' flag in the git commit command:
$ git commit -s -m "This is my commit message"
2. GitHub website You can also manually sign your commits during GitHub reviews and suggestions, follow the steps below:
Step 1: When the commit changes box opens, manually type or paste your signature in the comment box, see the example:
Signed-off-by: Name < e-mail address >
For this method, your name and e-mail must be the same registered on your GitHub account.
See the guidelines to submit your changes.
You can contibute with a new feature, bug fix, documentation and more, check out below:
- feat: A new feature (adding a new component, providing new variants for an existing component, etc.).
- fix: A bug fix (correcting a styling issue, addressing a bug in a component's API, etc.).
When updating non-dev dependencies, mark your changes with the
fix:type. - docs: Documentation-only changes.
- style: Changes that do not affect the meaning of the code
(whitespace, formatting, missing semicolons, etc). Not to be used for CSS changes as those are meaningful changes, consider using
feat:offix:instead. - refactor: A code change that neither fixes a bug nor adds a feature.
- perf: A code change that improves performance.
- test: Adding missing tests or correcting existing tests.
- build: Changes that affect the build system (changing webpack or Rollup config for example).
- ci: Changes to our CI configuration files and scripts (changing
Fastlane, adding or changing Danger plugins, etc.). - chore: Other changes that don't modify source or test files. Use this type when adding or updating dev dependencies.
- revert: Reverts a previous commit.
Note: If you're introducing a breaking change, the message body should start with
BREAKING CHANGE:.
Follow the Pull Request submission guidelines below:
Step 1. Search for issues and PRs that relate to your submission to avoid duplication;
Step 2. Make sure that the issue describes the problem you're fixing, or documents the design for the feature you'd like to add. Discussing the design upfront helps to ensure that we're ready to accept your work.
Step 3. Fork the ZupIT/beagle repo;
Step 4. Make your changes in a new git branch.
Step 5. Follow our Coding Rules;
Step 6. Commit your changes using a descriptive commit message, Signing all your commits and making sure to include appropriate test cases.=;
Step 7. Push your branch to GitHub;
Step 8. In GitHub, send a pull request to beagle:main;
After Beagle's team analyze your contribution, we may add some questions and suggestions, you should:
-
Make the required updates.
-
Re-run Beagle's test suites and CI workflows to ensure everything is still working properly.
-
Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
git rebase main -i git push -f
- Do you have any question about Beagle? Let's chat in our forum.
Thank you for your contribution!