Initialize the repo for synplus wiht the health documents

4-THE-REPO-OWENER.md

@@ -0,0 +1,36 @@
+# How should I adopt the file structure to my needs:
+
+By initializing your repository the TOSCom has generated some useful documents. Some of them are mandatory and must not been changed, some of them are mandatory, but should be attuned to your needs, and some of them are optional. Here is a description of the documents, their purposes, and what you may/should (not) do with them:
+
+* **4THEREPOWENER.md** :- this file
+* **AUTHORS** :- It is good tradition in GPL licensed projects to give the contributors credit by naming them explicitly.
+- _YOU SHOULD NOT DELETE THIS FILE!_
+- Complete the list of contributors by your main contributors.
+- Insert a name if the respective person has gained copyrights (has done more than only correcting typos)
+* **CODE_OF_CONDUCT.md** :- some well known rules how contributors should behave:
+- You may erase this file if you do not need it
+- If you are going to use it, please replace the contact address ``opensource@telekom.de`` by your own address
+* **CODEOWNERS** :- a list of persons denoted by their GitHub accounts who are shall handle with pull requests
+- You may erase this file if you do not need it - but to have such a file (and the respective persons) is a good practice if you use GitHub
+- Append your code owners identifiers to the initially inserted person @kreincke.
+- Erase the initially inserted codeowner ``kreincke``
+* **codestyle/checkstyle.xml** :- a description how to write source code
+- You may erase or replace this file in accordance to your needs.
+* **CONTRIBUTING.md** :- a description how the community can contribute to your project
+- You may erase this file if you do not need it.
+- If you delete it, find another method (CLA etc.) to enforce your contributors also to license their work under the terms of the same license you've selected for your project.
+- If you are going to use it, please replace the contact address ``opensource@telekom.de`` by your own address
+* The licens text of and for your project
+- _YOU MAY NOT DELETE THIS FILE!_
+* **OSDF.md** :- a template for creating the Open Source Declaration File: If you bundle and distribute open source 3rd party software together with the package compiled from your repo, then you also must distribute some compliance artifacts. One method to do so is to fill in / create such a declaration file. In opposite of the THIRD-PARTY-NOTICES this file must only contain the components you really distribute together with your software, it is not intended to be a complete dependency documentation.  
+* **README.md** :- the general project description file
+-  _YOU MAY NOT DELETE THIS FILE!_
+- _YOU MAY NOT DELETE THE LICENSING STATEMENT AT THE END OF THE FILE!_
+- You may and should adopt the content to your needs. The initially inserted structure is best practice.
+* **SECURITY.md** :- a description to which address vulnerabilities should be made known
+- You may erase this file if you do not need it.
+- If you are going to use it, please replace the contact address ``opensource@telekom.de`` by your own address
+* **THIRD-PARTY-NOTICES** :- a list of dependencies which are required by the project / product.
+* **templates/fileheader.txt** :- a template for initializing any new files
+- Each file must contain an instantiated version of the fileheader.txt
+- You must adopt the copyright line to your reality

AUTHORS

@@ -0,0 +1,17 @@
+Copyright (c) 2020 Deutsche Telekom AG.
+
+This project is licensed under GNU General Public License 3.0:
+
+Deutsche Telekom AG and all other contributors / copyright owners license this file to you under the terms of the GPL-v3:
+
+syncplus is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
+
+syncplus is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License along with reposbasics. If not, see <https://www.gnu.org/licenses/ you may not use the content of this repository except in compliance with the License.
+
+Contributors:
+-------------
+
+Karsten Reincke [kreincke], Deutsche Telekom AG

CODEOWNERS

@@ -0,0 +1,8 @@
+# This file provides an overview of code owners in this repository.
+
+# Each line is a file pattern followed by one or more owners.
+# The last matching pattern has the most precedence.
+# For more details, read the following article on GitHub: https://help.github.com/articles/about-codeowners/.
+
+# These are the default owners for the whole content of this repository. The default owners are automatically added as reviewers when you open a pull request, unless different owners are specified in the file.
+* @kreincke 

CODE_OF_CONDUCT.md

@@ -0,0 +1,130 @@
+
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders 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, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be 
+reported to the community leaders responsible for enforcement at 
+[opensource@telekom.de](mailto:opensource@telekom.de).
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.
+

CONTRIBUTING.md

@@ -0,0 +1,75 @@
+# Contributing
+
+## Code of conduct
+
+All members of the project community must abide by the [Contributor Covenant, version 2.0](CODE_OF_CONDUCT.md).
+Only by respecting each other can we develop a productive, collaborative community.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting [opensource@telekom.de](mailto:opensource@telekom.de) and/or a project maintainer.
+
+We appreciate your courtesy of avoiding political questions here. Issues which are not related to the project itself will be closed by our community managers.
+
+## Engaging in our project
+
+We use GitHub to manage reviews of pull requests.
+
+* If you are a new contributor, see: [Steps to Contribute](#steps-to-contribute)
+
+* If you have a trivial fix or improvement, go ahead and create a pull request, addressing (with `@...`) a suitable maintainer of this repository (see [CODEOWNERS](CODEOWNERS) of the  repository you want to contribute to) in the description of the pull request.
+
+* If you plan to do something more involved, please reach out to us and send an [email](mailto:opensource@telekom.de). This will avoid unnecessary work and surely give you and us a good deal of inspiration.
+
+* Relevant coding style guidelines are available in the respective sub-repositories as they are programming language-dependent.
+
+## Steps to Contribute
+
+Should you wish to work on an issue, please claim it first by commenting on the GitHub issue that you want to work on. This is to prevent duplicated efforts from other contributors on the same issue.
+
+If you have questions about one of the issues, please comment on them, and one of the maintainers will clarify.
+
+We kindly ask you to follow the [Pull Request Checklist](#Pull-Request-Checklist) to ensure reviews can happen accordingly.
+
+## Contributing Code
+
+You are welcome to contribute code in order to fix a bug or to implement a new feature.
+
+The following rule governs code contributions:
+
+* Contributions must be licensed under the [GPL-v3](COPYING)
+* Newly created files must be opened by an instantiated version to the file 'templates/file-header.txt'
+* At least if you add a new file to the repository, add your name into the contributor section of the file NOTICE (please respect the preset entry structure)
+
+## Contributing Documentation
+
+You are welcome to contribute documentation to the project.
+
+The following rule governs documentation contributions:
+
+* Contributions must be licensed under the same license as code, the [GPL-v3](COPYING)
+
+## Pull Request Checklist
+
+* Branch from the master branch and, if needed, rebase to the current master branch before submitting your pull request. If it doesn't merge cleanly with master you may be asked to rebase your changes.
+
+* Commits should be as small as possible while ensuring that each commit is correct independently (i.e., each commit should compile and pass tests).
+
+* Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests. If tested manually, provide information about the test scope in the PR description (e.g. “Test passed: Upgrade version from 0.42 to 0.42.23.”).
+
+* Create _Work In Progress [WIP]_ pull requests only if you need clarification or an explicit review before you can continue your work item.
+
+* If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment, or you can ask for a review by contacting us via [email](mailto:opensource@telekom.de).
+
+* Post review:
+  * If a review requires you to change your commit(s), please test the changes again.
+  * Amend the affected commit(s) and force push onto your branch.
+  * Set respective comments in your GitHub review to resolved.
+  * Create a general PR comment to notify the reviewers that your amendments are ready for another round of review.
+
+## Issues and Planning
+
+* We use GitHub issues to track bugs and enhancement requests.
+
+* Please provide as much context as possible when you open an issue. The information you provide must be comprehensive enough to reproduce that issue for the assignee. Therefore, contributors may use but aren't restricted to the issue template provided by the project maintainers.
+
+* When creating an issue, try using one of our issue templates which already contain some guidelines on which content is expected to process the issue most efficiently. If no template applies, you can of course also create an issue from scratch.
+
+* LABLEs :- TBD