Welcome to our Open Source space. Before you get started, please take a moment to read through this document to understand how you can contribute, the guidelines you should follow, and the process for submitting your contributions.
This CONTRIBUTING.md document is intended for use within the Enedis-OSS organization and applies to all projects hosted under the Enedis-OSS GitHub Organization.
Thank you for considering contributing to Enedis-OSS! We appreciate your interest in helping us improve our open-source projects. To ensure a smooth and collaborative contribution process, please follow the guidelines below.
By default, contributors must fork the project repository on GitHub by clicking the "Fork" button. This will create a copy of the repository under your GitHub account. Clone your forked repository to your local development environment.
git clone https://github.com/your-username/enedis-oss-project.git
Create a new branch for your contribution. Use a clear and descriptive name for the branch, indicating the purpose of your contribution.
git checkout -b feature/your-contribution
Make your desired changes to the codebase, following the project's coding standards, guidelines, and best practices.
Commit your changes with a concise and informative commit message. Please reference any relevant issues or discussions if applicable.
git commit -m "Add feature: your changes"
Push your changes to your forked repository on GitHub.
git push origin feature/your-contribution
Visit the original project repository on GitHub. You should see a "Compare & pull request" button. Click it.
Submit a pull request, providing a detailed explanation of your changes, why they are necessary, and any related issues or discussions.
The project maintainers will review your pull request. Be prepared to make additional changes or address feedback if necessary.
Once your pull request is accepted, your changes will be merged into the main project.
Thank you for contributing to Enedis-OSS. Your contributions help us make our open-source projects better and more valuable to the community. Happy coding!
In all communication, email exchanges, project-related documentation, code source comments, the Open Source project team should adhere to the following principles:
- No discrimination
- Respect for individuals (as an example, a real case where a variable was named "SDF" instead of "EOF" because some found it amusing)
- No offensive messages
- Accessibility
Contributors are the ambassadors of their products. Speaking at conferences and events is part of the contribution. All speaking engagements and communications are guided by strong messaging
If the contributor is an Enedis member, he should be aware that the source code will be accessible to the internet community after its contribution. It is essential, therefore, to purge the code of:
- Sensitive procedures that cannot be made public. For example, security algorithms protecting critical Enedis resources.
- Secrets (connection strings or internal SI passwords, comments, or scripts revealing confidential information, etc.). In general, developers have the following obligations regarding Open Source licenses:
- Keep all legal notices and license texts in the source code intact.
- Add specific notices to any file containing code covered by the license.
- Document all changes.
- Display notices during execution.
- Modified versions must always be libraries and work with other applications (avoid contamination issues). In cases of uncertainty, it is essential to isolate custom components as much as possible through internal development and build the project with dynamic linking between components to avoid contamination problems during the application of licenses. It is a good practice to establish a testing procedure for the project so that an external contributor can apply regression tests and add unit tests.
The recommended format is to place licensing information in one of these files: The complete content of the chosen licence by the project.
All modified or newly created source files must have a standardized header. Enedis copyright notices are added alongside existing ownership notices (other than those of Enedis).
Standard :
Copyright (C) -, - Enedis (https://www.enedis.fr/)
SPDX-License-Identifier:
: Project start year
: Current year; For recent projects, only the current year is indicated
: Project name
: Use the SPDX identifier
IMPORTANT: It is mandatory to use the SPDX standard to encode the license and enable tools to accurately characterize the designated license.
Standard : @author , - Enedis (https://www.enedis.fr/)
: mentions @author of collaborators
: optionally professional email
The use of Github Copilot during the development phase of any project published on the Enedis-OSS GitHub is prohibited. This is because it raises questions of fairness, legitimacy, and legality related to accusations of copyright violations by developers and the Software Freedom Conservancy. Indeed, Copilot can also be integrated into Visual Studio Code and other Microsoft tools (soon in the entire Office suite). The issue of license compliance arises from the fact that the source of what the assistant suggests is not identified. Therefore, one must be aware of this before publishing on Git.
DSI-OSCOE-ENEDIS in enedis.fr
