[MH] added basic docs and badges in readme

Signed-off-by: Matthias Holzer <[email protected]>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,49 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: 'Prio: Triage, Status: Pending, Type: Bug'
+assignees: ''
+
+---
+
+<!--- Provide a general summary of the Issue in the Title above -->
+
+<!--
+*Remember, an issue is not the place to ask questions. Please check out our contribution guidelines. 
+Before you open an Issue, please check if a similar issue already exists or has been closed before.*
+
+*Delete the above section and the instructions in the sections below before submitting*
+-->
+
+## Bug report
+
+## Expected Behavior - What where you expecting to happen?
+<!--- If you're describing a bug, tell us what should happen -->
+
+## Current Behavior - What happens?
+<!--- If describing a bug, tell us what happens instead of the expected behavior -->
+
+## Possible Solution
+<!--- Not obligatory, but suggest a fix/reason for the bug -->
+
+## What are the steps to reproduce this issue? (for bugs)
+<!--- Provide a link to a live example, or an unambiguous set of steps to -->
+<!--- reproduce this bug. Include code to reproduce, if relevant -->
+1.
+2.
+3.
+
+## Context
+<!--- How has this issue affected you? What are you trying to accomplish? -->
+<!--- Providing context helps us come up with a solution that is most useful in the real world -->
+
+## Any logs, error output, etc?
+
+## Your Environment
+<!--- Include as many relevant details about the environment you experienced the bug in -->
+* Version used:
+* Environment name and version (e.g. Chrome 39, node.js 5.4):
+* Operating System and version (desktop or mobile):
+
+## Notes and further information

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,33 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: 'Prio: Triage, Status: Pending, Type: Feature'
+assignees: ''
+
+---
+
+<!--- Provide a general summary of the Issue in the Title above -->
+
+<!--
+*Remember, an Issue is not the place to ask questions. Please check out our contribution guidelines. 
+Before you open an Issue, please check if a similar Issue already exists or has been closed before.*
+
+*Delete the above section and the instructions in the sections below before submitting*
+-->
+
+# Feature request
+
+## Expected Behavior - What where you expecting to happen?
+<!--- Tell us how the change/improvement should work -->
+
+## Current Behavior - What happens?
+<!--- Explain the difference from current behavior -->
+
+## Possible Solution
+<!--- Not mandatory, but suggest ideas how to implement the addition or change -->
+
+## Context
+<!--- Providing context helps us come up with a solution that is most useful in the real world -->
+
+## Notes and further information

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,65 @@
+<!--- Provide a general summary of your changes in the Title above -->
+
+<!---  
+*DO keep Pull Requests small so they can be easily reviewed.*
+ *DO make sure your contribution fits the openness and scalability for future extensions*
+ *DO make sure unit tests pass.*
+ *DO make sure any public APIs are XML documented.*
+ *DO make sure not to introduce any compiler warnings.*
+ *AVOID making significant changes to the driver's overall architecture.*
+*Delete the above section and the instructions in the sections below before submitting.* 
+--->
+
+## Type of request
+<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to change)
+- [ ] Refactoring 
+- [ ] Documentation or documentation changes
+
+## Related Issue(s)
+<!--- This project only accepts Pull Requests related to open Issues -->
+<!--- If suggesting a new feature or change, please discuss it in an issue first -->
+<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
+<!--- Please link to the issue here: -->
+
+## Concept 
+<!--- Why is this change required? What problem does it solve? -->
+#### Description of the change
+<!--- Describe your changes in detail -->
+#### Description of current state
+#### Description of target state
+
+#### Estimated investment / approximate investment
+<!--- Full Time Equivalents / Lines of code / € costs or something like that -->
+
+#### Initiator
+name / company / position / created at
+
+
+## Technical information
+#### Platform / target area
+<!--- What platform(s) is effected? -->
+
+#### known side-effects
+#### other 
+#### DB Changes (if so: incl. scripts with definitions and testdata)
+		
+
+
+#### How has this Tested?
+<!--- Please describe in detail how you tested your changes. -->
+<!--- Include details of your testing environment, and the tests you ran to -->
+<!--- see how your change affects other areas of the code, etc. -->
+
+#### Screenshots, Uploads, other documents (if appropriate):
+<!--- describe the uploaded documents -->
+
+## Checklist:
+<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
+- [ ] My code follows the code style of this project.
+- [ ] I agree with die CLA.
+- [ ] I have read the CONTRIBUTING docs.
+- [ ] I have added/updated necessary documentation (if appropriate).

CODE_OF_CONDUCT.md

@@ -0,0 +1,52 @@
+# Contributor Covenant 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 [email protected]. The project team will review and investigate all complaints, and will respond in a way that it deems 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.
+
+## Escalation
+
+To report an issue with the project leadership team, please contact Matthias Holzer ([@holzerma](https://github.com/holzerma)) or Markus Rothmueller ([@MarRothm](https://github.com/MarRothm)) via GitHub.
+
+## 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/
+
+

CODING_MANIFEST.md

@@ -0,0 +1,134 @@
+
+
+
+# Coding Manifest
+### Introduction
+We are very happy, you are interested in this project! :metal:   
+
+If you have any questions, please read the relevant docs on this GitHub repositories and our FAQ on the website first, there is a good chance some questions may be answered already.
+
+The contributed code, task, concept or design needs to fit into the general system architecture and must provide the key principles described below.
+
+## 1. How we work
+### 1.1 Branches
+In this project there will be one branch: 
+> **master**  
+>This is the projects main branch, where all Pull Requests, will be merged into. Of course this branch may be instable.  
+ 
+We will not provide a stable branch. Stable versions will be tagged directly on the master branch.
+
+### 1.2	Workflow
+In our projects we prefer a lightly customized GitHub Workflow, to get a more detailed level in the pull request / review process. Basic concept is built on the following standard [workflow](https://guides.github.com/introduction/flow/).
+
+The key aspects of the used workflow are as follows:
+- Each developer pushes to their own repository and pulls from others.
+- Developers who want to make a change to another repository, create a fork on GitHub and work on their own clone.
+- When forked repositories are ready to be merged, Pull Requests are sent to the original repository maintainer.
+- The Pull Requests include all of the proposed changes, project and code specific policies and their associated discussion threads.
+- Whenever a Pull Request is accepted, the change is merged by the maintainer (integration manager and/or dictator) and pushed to their blessed repository.
+
+In order to be able to contribute to one of the association’s projects you must open a Pull Request. You should usually open a Pull Request in the following situations:
+- Submit trivial fixes (for example, a typo, a broken link or an obvious error)
+- Start work on a contribution that was already asked for, or that you’ve already discussed, in an issue
+- A Pull Request may be one of the following types:  
+  - idea for a solution (as basis for further exchange)
+  - solutions for an (open) issue
+  - bugfix
+  - new feature implementation  
+  - code parts / snippets for a related issues
+  - improvement of code  
+  - new documentation / documentation changes
+  - anything else relevant to the project
+
+A Pull Request doesn’t have to represent finished work. It’s usually better to open a Pull Request early on, so others can watch or give feedback on your progress. Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later.
+
+Please check out our [contribution guideline](CONTRIBUTING.md) for a detailed description.
+
+### 1.3	Issues / Pull requests mandatory information
+For creating Issues or Pull Requests please use the provided templates. 
+Our maintainers will check the formal requirements first. 
+
+Please check out our [contribution guideline](CONTRIBUTING.md) for a detailed description.
+
+## 2 Project Standards & Quality Standards
+
+### 2.1 Coding Standards
+
+New contributions should meet the general java code conventions (see <https://google.github.io/styleguide/javaguide.htmll>).
+
+All code contributions must meet the following coding guidelines:
+
+* Your code must not contain any compile errors or warnings (some warnings reported by Eclipse IDE may be allowed)
+* Your code must not contain any problems reported by SpotBugs
+* Don't implement god classes (classes with several 1,000 lines of code)
+* Public API (classes, methods, variables, ...) must contain Javadoc. It is recommended also to document internal API.
+* Don't commit Sysouts. Use logger to monitor the correct and expected program workflow.
+* Implement JUnit-Tests against new and changed code parts.
+* All JUnit-Tests must pass (green).
+* JUnit-Tests should be integrated into the buid process (e.g. Maven).
+* Binary artifacts (dlls, jars, etc.) are not allowed to be checked in. They should be referenced from the provided Nexus server.
+
+### 2.2 Recommendations and hints
+
+* Use the proposed Eclipse IDE for code contributions. 
+* Use the proposed setup process Oomph of the project. (if any) 
+* Use the AdoptOpenJDK JVM binaries from <https://adoptopenjdk.net/>
+* Use SpotBugs to identify and avoid bad and illegal coding patterns (a reference configuration will follow soon).
+* Use SonarQube to identify code smells, bugs and vulnerabilities.
+* Think about modularity during the implementation (e.g. new features can be added as optional artifacts). 
+* Code and documentation must be done only in English.
+* Think about appropriate names for classes, methods and variables
+  * Don't use naming shortcuts, e.g. EM for ExecutionManager
+  * Don't use only general names (e.g. Manager, Util, etc.)
+  * Name the classes, methods and variables suitable to their responsibility (e.g. IRunnable implementation checking the version can be called CheckVersionRunnable)
+
+Your code needs to run on all supported systems. (Java / operating systems). 
+
+### 2.3  Conventions
+The contributed code, task, concept or design needs to fit into the general system architecture and must provide the following key principles:
+
+##### Internationalization
+- Always use English language for names, variables, classes, definitions, packages, comments etc. 
+- outsourcing from text parts into properties (resource files), so that the project can be easily translated
+- no queries against locale specific  
+- developer messages might not need to be internationalized (e.g., debug logging, exception messages not relevant to the user, etc).
+
+##### Scalability
+- Every new extension must be open and designed so they are easily extended for other usecases. Other requirements must not be influenced in any case. 
+
+##### Multi Tenancy
+- Functional or technical extensions must fit the multi-tenancy concept.
+
+##### Multi-Currency
+- Functional or technical extensions must fit the multi-currency concept.
+
+##### Time Zones
+- Functional or technical extensions must fit the the current time-zone concept.
+
+### 2.4 Tests
+- Implement JUnit-Tests against new and changed code parts.
+- All JUnit-Tests must pass (green).
+
+### 2.5 Versioning
+versioning (tdb)
+
+## 3 Development workflow
+
+Creation of new functional and technical artefacts may follow our standardized development process:
+- General approval for project relevance.
+- Conception/Discussion for changes in the data model
+- Creation of a functional design (if needed) with a follow-up approval
+- Creation of a technical design (if needed) with a follow-up approval
+- Implementation of the functionality / feature 
+  - Please stick to our standards and general architecture guidelines:
+    -  Implementation should be in the correct plugins (for modularization), packages or classes. 
+    -  Strictly make use of the correct layers (Business-, Dialog-, UI-,Adapter) (if needed)
+- Implementation of Unit- and/or Integration Tests
+- Review from one of our maintainers
+  - Always keep in mind, that the code must fulfill performance and security requirements in order to get accepted.
+
+
+
+
+
+