You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’re thrilled that you’d like to contribute to this project. We aim to make contributing to Qualcomm QRB ROS is easy, enjoyable, and educational for everyone.
5
-
All contributions are welcome, whether they are features, issues, documentation, guides, or anything else. Your help is essential for keeping this project great and for making it better.
4
+
We’re thrilled that you’d like to contribute to this project. We aim to make contributing to Qualcomm QRB ROS is easy, enjoyable, and educational for everyone. All contributions are welcome, whether they are features, issues, documentation, guides, or anything else. Your help is essential for keeping this project great and for making it better.
6
5
7
-
-[Code of Conduct](#conduct)
8
-
-[Issues and Bugs](#bug)
9
-
-[New Feature](#feature)
10
-
-[Submission Guidelines](#submission)
11
-
-[Contributing Guidelines](#guidelines)
12
-
-[Commit Message Format](#commit)
13
-
14
-
## <aname="conduct"></a> Code of Conduct
15
-
Please read and follow our [code of conduct](CODE-OF-CONDUCT.md).
6
+
## Contributing Guidelines
7
+
Before you submit a pull request to QRB ROS project, please ensure that you have followed these guidelines:
8
+
- Code should be well-documented and formatted according to the [Code style and language versions](https://docs.ros.org/en/jazzy/The-ROS2-Project/Contributing/Code-Style-Language-Versions.html).
9
+
- All changes should be covered by tests.
10
+
- Commits should be well-written and descriptive, with a clear summary of the changes made and any relevant context.
11
+
- Pull requests should target the `main` branch and include a clear summary of the changes made.
16
12
17
-
## <aname="bug"></a> Bug report
13
+
## Bug report
18
14
If you find a bug in the source code, you can help us by [submitting an issue](../../issues). Even better, you can submit a [Pull Request](../../pulls) with a fix.
19
15
20
-
## <aname="feature"></a> New feature
21
-
You can request a new feature by [Feature Request](../../issues/new?template=feature_request.yaml).
16
+
## New feature
17
+
You can request a new feature by [submitting an issue](../../issues).
18
+
<Updatelinkwithtemplate>
22
19
23
20
If you'd like to implement a new feature, it's always good to be in touch with us before you invest time and effort, since not all features can be supported.
24
21
25
22
- For a Major Feature, first open an issue and outline your proposal. This will let us coordinate efforts, prevent duplication of work, and help you craft the change so that it's successfully integrated into the project.
26
-
- Small Features can be crafted and directly [submitted as a Pull Request](#submit-pr).
23
+
- Small Features can be crafted and directly [submitted as a Pull Request](#submitting-a-pull-request).
27
24
28
25
29
-
## <aname="submission"></a> Submission Guidelines
26
+
#How to make a code contribution
30
27
31
-
### Submit an Issue
32
-
Before you submit an issue, please check if your problem already exists in [issues](../../issues).
33
-
You can submit new issues by selecting from our [Bug Report](../../issues/new?template=bug_report.yaml) and filling out the bug report template.
28
+
## Open to community
29
+
You can check all the issues that are open for community contributions. Check [issues](../../issues).
34
30
35
-
### <aname="submit-pr"></a> Submitting a pull request
31
+
## Submitting a pull request
36
32
37
-
#### Create a fork
33
+
Please read our [code of conduct](CODE-OF-CONDUCT.md) and [license](LICENSE).
34
+
35
+
### Create a fork
38
36
[Fork](../../fork) the repository to your GitHub organization. This means that you'll have a copy of the repository under your-username/repository-name.
39
37
40
38
1. Go to the repository page.
41
39
2. Click the "Fork" button in the top-right corner of the page.
42
40
3. Follow the instructions to create a fork of the repository in your own GitHub account.
Replace your-username and repository-name with your GitHub username and the name of the forked repository.
50
48
51
-
####Create a new branch
49
+
### Create a new branch
52
50
Create a new branch based on `main` for your changes.
53
51
54
52
```bash
55
53
git checkout -b <my-branch-name> main
56
54
```
57
55
58
-
####Make your changes
56
+
### Make your changes
59
57
Make your changes with bug fix or new feature.
60
58
61
-
####Commit your changes
59
+
### Commit your changes
62
60
Use the [DCO](http://developercertificate.org/). You can attest to the DCO by commiting with the **-s** or **--signoff** options or manually adding the "Signed-off-by":
63
61
```bash
64
62
git add .
65
63
git commit -s -m "<type>: <subject>"
66
64
```
67
65
<addcommittemplate>
68
66
69
-
####Push your changes
67
+
### Push your changes
70
68
```bash
71
69
git push -u origin <my-branch-name>
72
70
```
73
71
The `-u` is shorthand for `--set-upstream`. This will set up the tracking reference so subsequent runs of `git push` or `git pull` can omit the remote and branch.
74
72
75
-
#### Create pull request
76
-
Refer to [Creating a pull request from a fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)
73
+
### Create pull request
77
74
- Go to your forked repository on GitHub.
78
75
- You should see a prompt to compare and create a pull request for your recently pushed branch. Click on it.
79
76
- If you don’t see the prompt, go to the “Pull requests” tab and click the “New pull request” button.
@@ -94,90 +91,3 @@ Here are a few things you can do that will increase the likelihood of your pull
94
91
If you want to make multiple independent changes, please consider submitting them as separate pull requests.
95
92
- Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
96
93
- It's a good idea to arrange a discussion with other developers to ensure there is consensus on large features, architecture changes, and other core code changes. PR reviews will go much faster when there are no surprises.
Before you submit a pull request to QRB ROS project, please ensure that you have followed these guidelines:
100
-
- Code should be well-documented and formatted according to the [Code style and language versions](https://docs.ros.org/en/jazzy/The-ROS2-Project/Contributing/Code-Style-Language-Versions.html).
101
-
- All changes should be covered by tests.
102
-
- Commits should be well-written and descriptive, with a clear summary of the changes made and any relevant context.
103
-
- Pull requests should target the `main` branch and include a clear summary of the changes made.
104
-
105
-
## <aname="commit"></a> Commit Message Format
106
-
> This is inspired and adapted from [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
107
-
108
-
A commit message consists of a **header**, **body** and **footer**.
|**build**| Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
125
-
|**chore**| Other changes that don't modify src or test files |
126
-
|**ci**| Changes to our CI configuration files and scripts (examples: Github Actions, SauceLabs) |
127
-
|**docs**| Documentation only changes |
128
-
|**feat**| A new feature |
129
-
|**fix**| A bug fix |
130
-
|**perf**| A code change that improves performance |
131
-
|**refactor**| A code change that neither fixes a bug nor adds a feature |
132
-
|**revert**| Reverts a previous commit |
133
-
|**style**| Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)|
134
-
|**test**| Adding missing tests or correcting existing tests |
135
-
136
-
### Scope
137
-
A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.
138
-
139
-
### Description
140
-
141
-
The description contains succinct description of the change:
142
-
143
-
* use the imperative, present tense: "change" not "changed" nor "changes"
144
-
* don't capitalize first letter
145
-
* no dot (.) at the end
146
-
147
-
### Body
148
-
149
-
Just as in the **description**, use the imperative, present tense: "change" not "changed" nor "changes".
150
-
The body should include the motivation for the change and contrast this with previous behavior.
151
-
152
-
### Footer
153
-
154
-
The footer can contain information about breaking changes and deprecations and is also the place to reference GitHub issues and other PRs that this commit closes or is related to.
Breaking Change section should start with the phrase `BREAKING CHANGE: ` followed by a *brief* summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.
178
-
179
-
Similarly, a Deprecation section should start with `DEPRECATED: ` followed by a short description of what is deprecated, a blank line, and a detailed description of the deprecation that also mentions the recommended update path.
180
-
181
-
### Revert
182
-
183
-
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
0 commit comments