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
Consistency is an important aspect of a codebase. To ensure consistency in Mbed OS code, we have created contributing guidelines. Any contribution to Mbed OS needs to meet the following criteria:
3
+
Mbed OS is an open source, device software ecosystem for the internet of things. Contributions are an important part of the ecosystem, and our goal is to make it as simple as possible to become a contributor.
4
4
5
-
- Design and coding style: Be consistent with your changes. We define software design principles and coding style in [this document](../contributing/style.html).
6
-
- Contributions guidance: The process and how we review contributions is described in the [workflow](../contributing/workflow.html) document.
7
-
- Licenses: Licenses should comply with the [licenses described here](../contributing/license.html).
5
+
You can make contributions to source code and documentation. We develop both on GitHub. Mbed uses the same open source license for contributions (inbound) as it uses for the the project (outbound). Our default and preferred software license is Apache License version 2.0 (Apache-2.0).
6
+
7
+
To encourage collaboration, as well as robust, consistent and maintainable code, we have built a set of guidelines for contributing to Mbed.
8
+
9
+
### How to contribute
10
+
11
+
Mbed OS has a team of maintainers who provide guidance and direction to contributors. This team is responsible for helping you get your changes in, as well as controlling the overall quality and consistency of the software. For more information about the maintainers and their responsibilities, please see [our workflow](https://os.mbed.com/docs/development/contributing/workflow.html#mbed-os-maintainers).
12
+
13
+
We accept contributions in the form of pull requests. Each pull request must be reviewed by at least one other developer experienced with the functionality. For contributions that span multiple functionalities, multiple reviewers may be necessary. After reviews are complete, we test the changes as part of a larger system. The testing includes but is not limited to: functional correctness, static analysis, integration with other parts of the system, code style or formatting and regressions, such as code size increase or performance degredation. If any of the testing fails, more work will be needed before we accept the contribution. For more information about how to contribute, please see [our workflow](https://os.mbed.com/docs/development/contributing/workflow.html#mbed-os-maintainers).
14
+
15
+
### Types of contributions
16
+
17
+
There are a few [types of contributions](../contributing/workflow.html#pull-request-types). Each type has different priorities and requirements. When contributing, it’s important not to mix types and instead to create multiple contributions if needed. The type of contribution affects how and when it is incorporated into Mbed OS.
18
+
19
+
### Licensing
20
+
21
+
A license is the contract between the author permitting the use of software to others. It specifies what you can and cannot do when receiving the software. It provides protection for both the user and owner of the software. In an Mbed project, you can find the full terms of the license in a file named LICENSE. Additionally, all source files must contain the SPDX identifier as a comment at the beginning of the file.
22
+
23
+
Note that one repository may contain multiple, independent code bases, each with their own license. If you are integrating two libraries with different licenses, it is important that each library retain its original license. If a repository has software with multiple licenses, the contribution will be made according to the license of the file the contribution modifies. By creating a pull request on GitHub, you are agreeing to license your contributions under the same license as the original code. This is commonly referred to as "inbound=outbound". This enables contributions to happen in a quick and effortless way and encourages collaboration.
24
+
25
+
Most Mbed OS software is licensed under a permissive license. The three most common permissive licenses are:
26
+
27
+
- Apache 2.0.
28
+
- BSD 3-Clause.
29
+
- MIT.
30
+
31
+
For new Mbed projects, we suggest adopting the Apache 2.0 license. Note that any Mbed software release under a permissive license cannot accept any code that is licensed under a "copyleft" license. Doing so would prevent us from continuing to distribute our code under the permissive license. You are welcome to use Mbed software with copyleft licenses, as long as the rules of the copyleft license are followed.
32
+
33
+
You can find a more detailed description on licenses in the [contributing guidelines](../contributing/guidelines/license.html).
8
34
9
35
### Access to the ARMmbed organization on GitHub
10
36
@@ -16,14 +42,22 @@ You might require direct access to the ARMmbed organization for one of the follo
16
42
17
43
If so, you can request to become an organization member, but you must first ensure your GitHub profile meets the following requirements:
18
44
19
-
- All users must have 2 Factor Authentication enabled.
20
-
- Arm staff must have their Name, Company (Arm), Location and Arm email address publicly visible.
21
-
- All others should have their Name and Company visible. Entering your Location will help us interpret response times according to time zones.
45
+
- All users must have two-factor authentication enabled.
46
+
- Arm staff must have their Name, Company (Arm)and Location publicly visible.
47
+
- All others should have their Name and Company visible. Including your Location helps us interpret response times according to time zones.
22
48
23
-
### New repository
49
+
### Creating new repositories
24
50
25
-
Each repository must contain:
51
+
If you create a new repository in the ARMmbed organization on GitHub, it must follow some rules. Each repository must contain a:
26
52
27
53
-`CONTRIBUTING.md` file (similar to [Mbed OS contributing](https://github.com/ARMmbed/mbed-os/blob/master/CONTRIBUTING.md)).
28
-
-`LICENSE` file - the full license text or overview of every license in the repo with links.
29
-
-`README.md` has a license and contributing section (similar to [Mbed OS license and contributions section](https://github.com/ARMmbed/mbed-os/blob/master/README.md#license-and-contributions)).
54
+
-`LICENSE` file, the full license text or overview of every license in the repository with links.
55
+
-`README.md` with a license and contributing section (similar to [Mbed OS license and contributions section](https://github.com/ARMmbed/mbed-os/blob/master/README.md#license-and-contributions)).
56
+
57
+
### Tips
58
+
59
+
- The maintainers and reviewers are your friends. At times, programming can be personal. However, it's important to realize that we all share a common goal and that honest feedback is constructive feedback.
60
+
- Larger contributions take longer to be accepted than smaller contributions. The best contributions are small and purposeful, achieving a single goal. We may ask you to split up a contribution if it contains multiple unrelated changes.
61
+
- Consistency is an important aspect of a code base. To ensure consistency in Mbed OS code, we have created contributing guidelines. Any contribution to Mbed OS needs to meet the following criteria:
62
+
- Design and coding style: Be consistent with your changes. The existing style of a code base overrules any personal preference. We define software design principles and coding style in [the style](../contributing/style.html) and [software design](../contributing/software-design.html) guidelines.
63
+
- Contributions guidance: The [workflow](../contributing/workflow.html) document describes the contribution process and how we review contributions.
0 commit comments