will/InfiniTime
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #348 from CoderThomasB/fix-typo-doc/contribute.md

Browse Source 
Fixed typos in the doc/contribute.md using google docs’s spelling check system
This commit is contained in:
JF002 2021-05-15 09:58:38 +02:00 committed by GitHub
commit 783dde948b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/contribute.md
View File

@ -8,7 +8,7 @@ As the documentation is part of the source code, you can submit your improvement
## Fix bugs, add functionalities and improve the code
You want to fix a bug, add a cool new functionality or improve the code? See *How to submit a pull request below*.
## Spread the word
Pinetime is a cool open source project that deserves to be know. Talk about it around you, on social networks, on your blog,... and let people know that we are working on an open-source firmware for a smartwatch!
The Pinetime is a cool open source project that deserves to be known. Talk about it around you, on social networks, on your blog,... and let people know that we are working on an open-source firmware for a smartwatch!
# How to submit a pull request ?
@ -21,7 +21,7 @@ Pinetime is a cool open source project that deserves to be know. Talk about it a
- Write documentation related to your new feature is applicable;
- Create the pull-request and write a great description about it : what does your PR do, why, how,... Add pictures and video if possible;
- Wait for someone to review your PR and take part in the review process;
- You PR will eventually be merged :)
- Your PR will eventually be merged :)
Your contribution is more than welcome!
@ -29,20 +29,20 @@ If you want to fix a bug, add a functionality or improve the code, you'll first
When your feature branch is ready, **make sure it actually works** and **do not forget to write documentation** about it if it's relevant.
I **strongly discourage to create a PR containing modifications that haven't been tested**. If, for any reason, you cannot test your modifications but want to publish them anyway, **please mention it in the description**. This way, other contributors might be willing to test it and provide feedbacks about your code.
I **strongly discourage to create a PR containing modifications that haven't been tested**. If, for any reason, you cannot test your modifications but want to publish them anyway, **please mention it in the description**. This way, other contributors might be willing to test it and provide feedback about your code.
Also, before submitting your PR, check the coding style of your code against the **coding conventions** detailed below. This project also provides [clang-format](../.clang-format) and [clang-tidy](../.clang-tidy) configuration files. You can use them to ensure correct formatting of your code.
Do not forget to check the files you are going to commit and remove those who are not necessary (config files from your IDE, for example). Remove old comments, commented code,...
Then, you can submit a pull-request for review. Try to **describe your pull request as much as possible**: what did you do in this branch, how does it work, how is it designed, are there any limitations,... This will help the contributors to understand and review your code easily. You can add pictures and video to the description so that contributors will have a quick overview of you work.
Then, you can submit a pull-request for review. Try to **describe your pull request as much as possible**: what did you do in this branch, how does it work, how is it designed, are there any limitations,... This will help the contributors to understand and review your code easily. You can add pictures and video to the description so that contributors will have a quick overview of your work.
Other contributors can post comments about the pull request, maybe ask for more info or adjustements in the code.
Other contributors can post comments about the pull request, maybe ask for more info or adjustments in the code.
Once the pull request is reviewed an accepted, it'll be merge in **develop** and will be released in the next release version of the firmware.
Once the pull request is reviewed and accepted, it'll be merge in **develop** and will be released in the next release version of the firmware.
## Why all these rules?
Reviewing pull-requests is a **very time consuming task** for the creator of this project ([JF002](https://github.com/JF002)) and for other contributors who take the time to review them. Every little thing you do to make their lifes easier will **increase the chances your PR will be merge quickly**.
Reviewing pull-requests is a **very time consuming task** for the creator of this project ([JF002](https://github.com/JF002)) and for other contributors who take the time to review them. Every little thing you do to make their lives easier will **increase the chances your PR will be merge quickly**.
When reviewing PR, the author and contributors will first look at the **description**. If it's easy to understand what the PR does, why the modification is needed or interesting and how it's done, a good part of the work is already done : we understand the PR and its context.
@ -63,7 +63,7 @@ It's OK to include C code if this code comes from another library like FreeRTOS,
## Coding style
The most important rule to follow is to try to keep the code as easy to read and maintain as possible.
- **Identation** : 2 spaces, no tabulation
- **Indentation** : 2 spaces, no tabulation
- **Opening brace** at the end of the line
- **Naming** : Choose self-describing variable name
- **class** : PascalCase