--- /dev/null
+<!--
+Copyright 2020 ETSI
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+implied.
+See the License for the specific language governing permissions and
+limitations under the License
+-->
+# Contributing
+
+When contributing to this repository, please first discuss the change you wish to make via issue,
+email, or any other method with the owners of this repository (Module Development Leads - MDL)
+before making a change.
+
+Please note we have a code of conduct, please follow it in all your interactions with the project.
+
+## Process for Committing changes and Pushing them to Gerrit
+
+1. Ensure that you have properly configured your git environment, and you have read these
+ guidelines (<https://osm.etsi.org/docs/developer-guide/>). Please remind to configure your
+ username and user email that you use in your ETSI On Line (EOL) account). Please remind to
+ install the Gerrit commit-msg hook for the cloned repository in order to automatically insert a
+ Change-Id tag in commit messages.
+2. Ensure that you work in the right branch for the change. The brach will be typically `master`,
+ but in some circumstances, the MDL could ask you to use a release branch (e.g. `v7.0`) or a
+ feature branch (e.g. `featureXXXX`).
+3. Ensure that any new added file includes the Apache2 license header. In case you don't know how
+ to add it, look at other files in the repo and follow the same practice, or ask to the MDL.
+4. Ensure any new build dependencies are included in the Dockerfile.
+5. If it makes sense, update the README.md with details of changes to the module.
+6. Increase the version numbers in any examples files and the README.md to the new version that this
+ commit would represent. The versioning scheme we use is [SemVer](http://semver.org/).
+7. When creating the commit, ensure that the commit is properly signed and includes the change-id.
+8. Before pushing to gerrit, it is strongly recommended that you rebase your work
+ (`git pull --rebase`), so that your work is on top of the current remote branch.
+9. Push to the right gerrit branch `HEAD:refs/for/BRANCH`.
+10. Look at the Gerrit entry and check for Jenkins validation and MDL review. In case of comments
+ from MDL or Jenkins fails, amend your commit following the guidelines and push again to gerrit.
+
+## 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,
+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.
+
+### Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at <OSM_MDL@LIST.ETSI.ORG>. 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][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/
projects / TEMPLATE.git / blobdiff