Merge branch 'main' into chore/update-to-topic-name-and-regions-in-external-ids

Signed-off-by: Rense Bakker <b.rense@gmail.com>

Author: brense

.github/workflows/yml-lint.yaml

@@ -0,0 +1,17 @@
+name: YAML Lint
+
+on:
+  pull_request:
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Install Prettier
+        run: npm install --global prettier
+
+      - name: Check YAML formatting
+        run: prettier --check "**/*.yaml"

CODE_OF_CONDUCT.md

@@ -0,0 +1,73 @@
+<!--
+SPDX-FileCopyrightText: 2014 Coraline Ada Ehmke
+
+SPDX-License-Identifier: CC-BY-4.0
+-->
+
+
+# Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of
+experience, education, socio-economic status, nationality, personal appearance,
+race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+*   Using welcoming and inclusive language
+*   Being respectful of differing viewpoints and experiences
+*   Gracefully accepting constructive criticism
+*   Focusing on what is best for the community
+*   Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+*   The use of sexualized language or imagery and unwelcome sexual attention or
+    advances
+*   Trolling, insulting/derogatory comments, and personal or political attacks
+*   Public or private harassment
+*   Publishing others' private information, such as a physical or electronic
+    address, without explicit permission
+*   Other conduct which could reasonably be considered inappropriate in a
+    professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviors that they deem inappropriate, threatening,
+offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+
+## Conflict Resolution
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at OSPO@alliander. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the Contributor Covenant, version 1.4,
+available at
+https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

CONTRIBUTING.md

@@ -0,0 +1,101 @@
+<!--
+SPDX-FileCopyrightText: 'Copyright Contributors to the LSIS project' 
+
+SPDX-License-Identifier: Apache-2.0
+-->
+
+
+# How to Contribute
+
+We'd love to accept your patches and contributions to this project. There are
+just a few small guidelines you need to follow.
+
+## Ways of contributing
+
+Contribution does not necessarily mean committing code to the repository. 
+We recognize different levels of contributions as shown below in increasing order of dedication:
+
+1. Keep the API specifications up to date by opening issues or pull requests.
+2. Request changes via issues or pull requests.
+
+## Filing bugs, security vulnerability or feature requests
+
+You can file bugs against and feature requests for the project via github issues. Consult [GitHub Help](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/creating-an-issue) for more
+information on using github issues.
+
+If you think you've found a potential vulnerability in this project, please
+email <lsis@alliander.com> to responsibly disclose it.
+
+## Community Guidelines
+
+This project follows the following [Code of Conduct](CODE_OF_CONDUCT.md).
+
+## REUSE Compliance & Source Code Headers
+
+All the files in the repository need to be [REUSE compliant](https://reuse.software/). 
+We use the pipeline to automatically check this.
+If there are files which are not complying, the pipeline will fail the pull request will be blocked.
+
+This means that every file containing source code must include copyright and license
+information. This includes any JS/CSS files that you might be serving out to
+browsers. (This is to help well-intentioned people avoid accidental copying that
+doesn't comply with the license.)
+
+MPL-2.0 header:
+
+```
+    SPDX-FileCopyrightText: 'Copyright Contributors to the LSIS project' 
+    SPDX-License-Identifier: MPL-2.0
+```
+
+## Signing the Developer Certificate of Origin (DCO)
+
+This project utilize a Developer Certificate of Origin (DCO) to ensure that 
+each commit was written by the author or that the author has the appropriate rights 
+necessary to contribute the change. 
+Specifically, we utilize [Developer Certificate of Origin, Version 1.1](http://developercertificate.org/), 
+which is the same mechanism that the Linux® Kernel and many other communities use to manage code contributions. 
+The DCO is considered one of the simplest tools for sign-offs from contributors as the representations are 
+meant to be easy to read and indicating signoff is done as a part of the commit message.
+
+This means that each commit must include a DCO which looks like this:
+
+`Signed-off-by: Joe Smith <joe.smith@email.com>`
+
+The project requires that the name used is your real name and the e-mail used is your real e-mail. 
+Neither anonymous contributors nor those utilizing pseudonyms will be accepted.
+
+There are other great tools out there to manage DCO signoffs for developers to make it much easier to do signoffs:
+* Git makes it easy to add this line to your commit messages. Make sure the `user.name` and `user.email` are set in your git configs. Use `-s` or `--signoff` to add the Signed-off-by line to the end of the commit message.
+* [Github UI automatic signoff capabilities](https://github.blog/changelog/2022-06-08-admins-can-require-sign-off-on-web-based-commits/) for adding the signoff automatically to commits made with the GitHub browser UI. This one can only be activated by the github org or repo admin. 
+* [GitHub UI automatic signoff capabilities via custom plugin]( https://github.com/scottrigby/dco-gh-ui ) for adding the signoff automatically to commits made with the GitHub browser UI
+* Additionally, it is possible to use shell scripting to automatically apply the sign-off. For an example for bash to be put into a .bashrc file, see [here](https://wiki.lfenergy.org/display/HOME/Contribution+and+Compliance+Guidelines+for+LF+Energy+Foundation+hosted+projects). 
+* Alternatively, you can add `prepare-commit-msg hook` in .git/hooks directory. For an example, see [here](https://github.com/Samsung/ONE-vscode/wiki/ONE-vscode-Developer's-Certificate-of-Origin).
+
+## Code reviews
+
+All patches and contributions, including patches and contributions by project members, require review by one of the maintainers of the project. We
+use GitHub pull requests for this purpose. Consult
+[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
+information on using pull requests.
+
+## Pull Request Process
+Contributions should be submitted as Github pull requests. See [Creating a pull request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request) if you're unfamiliar with this concept.
+
+The process for a code change and pull request you should follow:
+
+1. Create a topic branch in your local repository, following the naming format
+"feature-[description]". For more information see the Git branching guideline.
+1. Make changes, compile, and test thoroughly. Ensure any install or build dependencies are removed before the end of the layer when doing a build. Code style should match existing style and conventions, and changes should be focused on the topic the pull request will be addressed. For more information see the style guide.
+1. Push commits to your fork.
+1. Create a Github pull request from your topic branch.
+1. Pull requests will be reviewed by one of the maintainers who may discuss, offer constructive feedback, request changes, or approve
+the work. For more information see the Code review guideline.
+1. Upon receiving the sign-off of one of the maintainers you may merge your changes, or if you
+   do not have permission to do that, you may request a maintainer to merge it for you.
+
+## Attribution
+
+This Contributing.md is adapted from Google
+available at
+https://github.com/google/new-project/blob/master/docs/contributing.md