We welcome contributions from the open source community. If you want to contribute, we ask you to follow these guidelines. Please reach out to us if you have questions or wish to contribute.
Please follow our Code of Conduct when contributing.
We use the following code and API conventions:
The license information for this project can be found in LICENSE.md. We use SPDX license identifiers in source code files.
When adding a new source code file or modifying an existing one as a Lifely/INFO developer, please update the SPDX
license identifier accordingly:
For most source code files (e.g. .ts
, .js
, .kt
and .java
files) please add the following SPDX license identifier to the top of the file:
/*
* SPDX-FileCopyrightText: <YYYY> Lifely
* SPDX-License-Identifier: EUPL-1.2+
*/
Where <YYYY>
is the current year. E.g. 2024
.
For other file types (e.g. .html
and .xml
files) please add the following SPDX license identifier to the top of the file:
<!--
~ SPDX-FileCopyrightText: <YYYY> Lifely
~ SPDX-License-Identifier: EUPL-1.2+
-->
Finally, for e.g. .sh
files please add:
#
# SPDX-FileCopyrightText: <YYYY> Lifely
# SPDX-License-Identifier: EUPL-1.2+
#
Tip: configure your IDE to automatically add these headers to new source code files. For example, in IntelliJ IDEA please follow the instructions on https://www.jetbrains.com/help/idea/copyright.html.
If the file does not already include Lifely
in the copyright text, please update the SPDX license identifier
on the top of the file by adding a , <YYYY> Lifely
to the SPDX-FileCopyrightText
identifier where <YYYY>
is the current year. E.g.:
/*
* SPDX-FileCopyrightText: 2021 Atos, 2024 Lifely
* SPDX-License-Identifier: EUPL-1.2+
*/
Note that each contributor should only be mentioned once in an SPDX header, where we use the convention that the year indicates the initial year when a contribution was made by that contributor.
We automatically check for SPDX license identifiers in our source code with a GitHub workflow that uses the Skywalking Eyes GitHub Action.
Using the Skywalking Eyes configuration file in our codebase you can also run this check locally, and optionally add SPDX license identifiers to files that are missing them. Please see https://github.com/apache/skywalking-eyes for instructions.
We use Conventional Commits for our commit messages. Specifically we use the following format for our commit messages:
<type>[optional scope]: <description>
[body]
[footer]
When you create a Pull Request (PR) please follow the following instructions to comply to our Conventional Commits guidelines:
- Make sure the PR title complies to:
<type>[optional scope]: <description>
. E.g.feat: add new feature
. - In the PR body fill in the body consisting of one line of text. E.g.
Added new exciting feature.
- In the footer reference the JIRA issue (typically a subtask) number from the
PodiumD Zaak JIRA project as follows:
Solves PZ-XXX
, whereXXX
is the JIRA issue number.
For example:
We use the Conventional Commits GitHub Action to check if a new PR complies to our Conventional Commits guidelines described above.
This plugin unfortunately only checks on PR creation time and not when you merge your PR. So when merging a PR in GitHub using Squash and Merge please copy the PR body into the GitHub Squash and Merge description text area.