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
Copy file name to clipboardExpand all lines: doc/howtocontribute.rst
+77-2Lines changed: 77 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,82 @@ Introduction
7
7
------------
8
8
9
9
The purpose of this document is to help contributors get started with
10
-
the Open Simulation Interface (OSI) codebase.
10
+
the ASAM Open Simulation Interface (OSI) codebase.
11
+
12
+
As an open-source standardisation project, we welcome and encourage the community to submit patches directly to the project. In our collaborative open source environment, standards and methods for submitting changes help reduce the chaos that can result from an active development community.
13
+
14
+
This document explains how to participate in project conversations, log bugs and enhancement requests, and submit patches to the project so your patch will be accepted quickly in the codebase.
15
+
16
+
Licensing
17
+
---------
18
+
19
+
OSI uses the Mozilla Public License, v. 2.0. (as found in the LICENSE file in the project’s GitHub repo).
20
+
21
+
The license tells you what rights you have as a developer, provided by the copyright holder. It is important that the contributor fully understands the licensing rights and agrees to them. Sometimes the copyright holder isn’t the contributor, such as when the contributor is doing work on behalf of a company.
22
+
23
+
Developer Certification of Origin (DCO)
24
+
---------------------------------------
25
+
26
+
To make a good faith effort to ensure licensing criteria are met, the OSI project requires the Developer Certificate of Origin (DCO) process to be followed.
27
+
28
+
The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, (described more fully later in this document), the developer simply adds a Signed-off-by statement and thereby agrees to the DCO.
29
+
30
+
When a developer submits a patch, it is a commitment that the contributor has the right to submit the patch per the license. The DCO agreement is shown below and `online <http://developercertificate.org/>`_.
31
+
::
32
+
33
+
Developer's Certificate of Origin 1.1
34
+
35
+
By making a contribution to this project, I certify that:
36
+
37
+
(a) The contribution was created in whole or in part by me and I
38
+
have the right to submit it under the open source license
39
+
indicated in the file; or
40
+
41
+
(b) The contribution is based upon previous work that, to the
42
+
best of my knowledge, is covered under an appropriate open
43
+
source license and I have the right under that license to
44
+
submit that work with modifications, whether created in whole
45
+
or in part by me, under the same open source license (unless
46
+
I am permitted to submit under a different license), as
47
+
Indicated in the file; or
48
+
49
+
(c) The contribution was provided directly to me by some other
50
+
person who certified (a), (b) or (c) and I have not modified
51
+
it.
52
+
53
+
(d) I understand and agree that this project and the contribution
54
+
are public and that a record of the contribution (including
55
+
all personal information I submit with it, including my
56
+
sign-off) is maintained indefinitely and may be redistributed
57
+
consistent with this project or the open source license(s)
58
+
involved.
59
+
60
+
DCO Sign-Off Methods
61
+
--------------------
62
+
63
+
The DCO requires a sign-off message in the following format appear on each commit in the pull request:
The DCO text can either be manually added to your commit body, or you can add either ``-s`` or ``--signoff`` to your usual Git commit commands. If you forget to add the sign-off you can also amend a previous commit with the sign-off by running ``git commit --amend -s``. You can add sign-offs to multiple commits (including commits originally authored by others, if you are authorized to do so) using ``git rebase --signoff``. If you’ve pushed your changes to GitHub already you’ll need to force push your branch after this with ``git push --force-with-lease``.
69
+
70
+
If you want to be reminded to add the sign-off for commits in your repository, you can add the following commit-message git hook to your repository:
71
+
72
+
.. code:: shell
73
+
74
+
#!/bin/sh
75
+
#
76
+
# Check for DCO/Signed-off-by in message
77
+
#
78
+
79
+
if! grep -q "^Signed-off-by: ""$1"
80
+
then
81
+
echo"Aborting commit: Commit message is not signed off">&2
82
+
exit 1
83
+
fi
84
+
85
+
Placing this script into a file called ``.git/hooks/commit-msg`` and making it executable (e.g. using ``chmod a+x .git/hooks/commit-msg`` on unixoid operating systems) will prevent commits without a sign-off.
11
86
12
87
13
88
Reporting issues
@@ -69,7 +144,7 @@ the commits are combined
69
144
into one commit and merged into the master branch.
70
145
Once a pull request is ready, it is reviewed and
71
146
approved, then squashed using the ``--fast-forward`` option of Git in order to
72
-
maintain a streamlined Git history.
147
+
maintain a streamlined Git history. Pull requests without a Sign-Off message (see DCO above) will not be accepted.
Copy file name to clipboardExpand all lines: doc/interfaceconventions.rst
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ When adding new messages, enums, field messages and field enums to OSI we enforc
7
7
8
8
Message Naming
9
9
---------------
10
-
A message definition should always be in camel case. This means that the first letter of each word in a message should be upper case without any spaces. See example below:
10
+
A message definition should always be in PascalCase. This means that the first letter of each word in a message should be upper case without any spaces. See example below:
11
11
12
12
.. code-block:: protobuf
13
13
@@ -37,7 +37,7 @@ All messages that are intended to be exchanged as a stand-alone message, i.e. no
37
37
38
38
Field Message Naming
39
39
---------------------
40
-
After defining a message fields can be added to it in snake case format. This means every letter is lower case and the words are connected through an underline character. See example below:
40
+
After defining a message fields can be added to it in snake_case format. This means every letter is lower case and the words are connected through an underline character. See example below:
41
41
42
42
.. code-block:: protobuf
43
43
@@ -55,7 +55,7 @@ All field numbers of 10000 and above are reserved for user-defined extensions an
55
55
56
56
Enum Naming
57
57
------------
58
-
The naming of an enum should be camel case. See example below:
58
+
The naming of an enum should be PascalCase. See example below:
59
59
60
60
.. code-block:: protobuf
61
61
@@ -70,7 +70,7 @@ The naming of an enum should be camel case. See example below:
70
70
71
71
Enum Field Naming
72
72
------------
73
-
The naming of an enum field should be all in upper case. The start should be converted from the enum name camel case to upper case snake case. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
73
+
The naming of an enum field should be all in upper case. The start should be converted from the enum name PascalCase to UPPER_CASE_SNAKE_CASE. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
74
74
75
75
.. code-block:: protobuf
76
76
@@ -92,12 +92,12 @@ Summary
92
92
--------
93
93
Here a small summary for the naming conventions:
94
94
95
-
Messages: camel case
95
+
Messages: PascalCase
96
96
97
-
Message Fields: snake case
97
+
Message Fields: snake_case
98
98
99
-
Enum: camel case
99
+
Enum: PascalCase
100
100
101
-
Enum Fields: upper case, name of enum converted in upper case snake case and then following the specified name
101
+
Enum Fields: Name of enum converted in UPPER_CASE_SNAKE_CASE and then following the specified name
102
102
103
103
After defining the messages do not forget to comment them. See also the `section for commenting <https://opensimulationinterface.github.io/osi-documentation/open-simulation-interface/doc/commenting.html>`_ of fields and messages.
0 commit comments