[Add] GH templates

Author: sam.gerene

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# 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 s.gerene@rheagroup.com. 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.
+
+## 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/

.github/CONTRIBUTING.md

@@ -0,0 +1,64 @@
+# How to contribute
+
+We would like to start with saying thank you for wanting to contribute to UI-DSM codebase. We want to keep it as easy as possible to contribute changes that get things working in your environment. There are a few guidelines that we need contributors to follow so that we have a chance of keeping on top of things.
+
+- [Making Changes](#making-changes)
+  - [Handling Updates from Upstream/Development](#handling-updates-from-upstreamdevelopment)
+  - [Sending a Pull Request](#sending-a-pull-request)
+- [Style Guidelines](#style-guidelines)
+
+## Making Changes
+
+1. [Fork](http://help.github.com/forking/) on GitHub
+1. Clone your fork locally
+1. Configure the upstream repo (`git remote add upstream git://github.com/RHEAGROUP/UI-DSM`) 
+1. Checkout development
+1. Create a local branch (`git checkout -b myBranch`) from development
+1. Work on your feature
+1. Rebase if required (see below)
+1. Push the branch up to GitHub (`git push origin myBranch`)
+1. Send a Pull Request on GitHub
+
+You should **never** work on a clone of master or development, and you should **never** send a pull request from master or development - always from a branch. The reasons for this are detailed below.
+
+### Handling Updates from Upstream/Development
+
+While you're working away in your branch it's quite possible that your upstream development (most likely the canonical UI-DSM version) may be updated. If this happens you should:
+
+1. [Stash](http://git-scm.com/book/en/Git-Tools-Stashing) any un-committed changes you need to
+1. `git checkout development`
+1. `git pull upstream development`
+1. `git checkout myBranch`
+1. `git rebase development myBranch`
+1. `git push origin development` - (optional) this makes sure your remote development is up to date
+
+This ensures that your history is "clean" i.e. you have one branch off from development followed by your changes in a straight line. Failing to do this ends up with several "messy" merges in your history, which we don't want. This is the reason why you should always work in a branch and you should never be working in, or sending pull requests from, development.
+
+If you're working on a long running feature then you may want to do this quite often, rather than run the risk of potential merge issues further down the line.
+
+### Sending a Pull Request
+
+While working on your feature you may well create several branches, which is fine, but before you send a pull request you should ensure that you have rebased back to a single "Feature branch". We care about your commits, and we care about your feature branch; but we don't care about how many or which branches you created while you were working on it :smile:.
+
+When you're ready to go you should confirm that you are up to date and rebased with upstream/development (see "Handling Updates from Upstream/development" above), and then:
+
+1. `git push origin myBranch`
+1. Send a descriptive [Pull Request](https://help.github.com/articles/creating-a-pull-request/) on GitHub - making sure you have selected the correct branch in the GitHub UI!
+1. Wait for @samatrhea to merge your changes in.
+
+And remember; **A pull-request with tests is a pull-request that's likely to be pulled in.** :grin: Bonus points if you document your feature in our [wiki](https://github.com/RHEAGROUP/UI-DSM/wiki) once it has been pulled in
+
+## Style Guidelines
+
+- Indent with 4 spaces, **not** tabs.
+- No underscore (`_`) prefix for member names.
+- Use `this` when accessing instance members, e.g. `this.Name = "UI-DSM";`.
+- Use the `var` keyword unless the inferred type is not obvious.
+- Use the C# type aliases for types that have them, e.g. `int` instead of `Int32`, `string` instead of `String` etc.
+- Use meaningful names (no hungarian notation), we like long descriptive names of methods, variables and parameters.
+- Wrap `if`, `else` and `using` blocks (or blocks in general, really) in curly braces, even if it's a single line.
+- Put `using` statements inside namespace.
+- Pay attention to whitespace and extra blank lines
+- Absolutely **no** regions
+
+> If you are a ReSharper user, you can make use of our `.DotSettings` file to ensure you cover as many of our style guidelines as possible. There may be some style guidelines which are not covered by the file, so please pay attention to the style of existing code.

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,23 @@
+### Prerequisites
+
+- [ ] I have written a descriptive issue title
+- [ ] I have verified that I am running the latest version of the UI-DSM
+- [ ] I have searched [open](https://github.com/RHEAGROUP/UI-DSM/issues) and [closed](https://github.com/RHEAGROUP/UI-DSM/issues?q=is%3Aissue+is%3Aclosed) issues to ensure it has not already been reported
+
+### Description
+<!-- A description of the bug or feature -->
+
+### Steps to Reproduce
+<!-- List of steps, sample code, failing test or link to a project that reproduces the behavior -->
+
+### System Configuration
+<!-- Tell us about the environment where you are experiencing the bug -->
+
+- UI-DSM version:
+  - [ ] UI-DSM:         
+  - [ ] Other:              
+- Environment (Operating system, version and so on):
+- .NET Framework version:
+- Additional information:
+
+<!-- Thanks for reporting the issue to UI-DSM! -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,11 @@
+### Prerequisites
+
+- [ ] I have written a descriptive pull-request title
+- [ ] I have verified that there are no overlapping [pull-requests](https://github.com/RHEAGROUP/UI-DSM/pulls) open
+- [ ] I have verified that I am following the UI-DSM [code style guidelines](https://raw.githubusercontent.com/RHEAGROUP/UI-DSM/master/.github/CONTRIBUTING.md)
+- [ ] I have provided test coverage for my change (where applicable)
+
+### Description
+<!-- A description of the changes proposed in the pull-request -->
+
+<!-- Thanks for contributing to UI-DSM! -->

.github/coverlet.runsettings

@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<RunSettings>
+  <DataCollectionRunSettings>
+    <DataCollectors>
+      <DataCollector friendlyName="XPlat Code Coverage">
+        <Configuration>
+          <Format>opencover</Format>
+        </Configuration>
+      </DataCollector>
+    </DataCollectors>
+  </DataCollectionRunSettings>
+</RunSettings>

NOTICE

@@ -0,0 +1,3 @@
+UI-DSM
+Copyright 2022 RHEA System S.A.
+Copyright 2022 ATG Europe

Nuget.Config

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="utf-8"?>
+<configuration>
+  <packageSources>
+    <clear />    
+	<add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
+  </packageSources>
+</configuration>