Merge pull request #174 from rl-institut/release/v1.0.0

initial release v1.0.0

.flake8

@@ -1,3 +1,5 @@
 [flake8]
 max-line-length=100
-exclude=docs,examples
+exclude=docs,examples,scenarios
+#extend_ignore=DAR101,DAR201,DAR401
+docstring_style=sphinx

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,15 @@
+Fixes #Issue
+
+**Changes proposed in this pull request**:
+- Your changes
+
+The following steps were realized (required):
+- [ ] Correct linting with `flake8 path_to_script`
+- [ ] Check if tests pass locally with `python -m pytest tests/`
+- [ ] Add the description of your changes to the CHANGELOG.md in subsection with release name `## [Unreleased]` and state the PR number with `#`
+
+Also the following steps were realized (if applies):
+- [ ] Write docstrings to your code
+- [ ] Explain new functionalities in readthedocs
+- [ ] Write test(s) for new patch of code
+- [ ] Check building of documentation with `doc/make html`

.github/workflows/pythonpackage.yaml

@@ -7,7 +7,7 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        python-version: [3.6, 3.8]
+        python-version: [3.8, '3.10']
 
     steps:
     - uses: actions/checkout@v2
@@ -20,9 +20,13 @@ jobs:
         python -m pip install --upgrade pip
     - name: Lint with flake8
       run: |
-        pip install flake8
+        pip install flake8 darglint
         flake8 .
     - name: Test with pytest
       run: |
         pip install pytest
-        pytest src/tests.py
+        python -m pytest tests/
+    - name: Build documentation
+      run: |
+        pip install -r doc/requirements.txt
+        make -C doc html

.gitignore

@@ -1,6 +1,12 @@
 .*.sw[op]
 /__pycache__
 *.pyc
+.DS_Store
 
-tests/
-docs/
+.coverage
+htmlcov/
+
+docs/
+.vscode/
+_build/
+scenarios/

CHANGELOG.md

@@ -0,0 +1,25 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+Template:
+```
+## [0.0.0] - Name of Release - 20YY-MM-DD
+
+### Added
+- [(#)]()
+### Changed
+- [(#)]()
+### Removed
+- [(#)]()
+```
+
+
+## [1.0.0] - Initial Release SpiceEV - 2023-05-24
+
+### Added
+- first release! 🎉
+

CONTRIBUTING.md

@@ -0,0 +1,173 @@
+<!--SPDX-License-Identifier: MIT-->
+<!--Version: v1.0.0-->
+
+# Collaborative Development
+
+## Prerequisites
+- [GitHub](https://github.com/) as a public repository. Please create an account.
+- [Git](https://git-scm.com/) for version control. [Git How To](https://githowto.com/) and [Git Cheat Sheet](https://training.github.com/downloads/github-git-cheat-sheet.pdf) provide an introduction into working with Git.
+
+## Types of interaction
+Please be self-reflective and always maintain a good culture of discussion and active participation.
+
+### A. Use
+Since the open license allows free use, no notification is required. 
+However, for the authors it is valuable information who uses the software for what purpose. 
+Indicators are `Watch`, `Fork` and `Starred` of the repository. 
+If you are a user, please get in contact with developers via issues or e-mail (as stated in setup.py) and use the `Watch` function to stay updated.
+
+### B. Comment
+You can give ideas, hints or report bugs in issues, in PR, at meetings or other channels. 
+This is no development but can be considered a notable contribution. 
+
+### C. Contribute and Review
+You add code and become an author of the repository. 
+You must follow the workflow!
+
+### D. Mantain and Release
+You contribute and take care of the repository. 
+You review and answer questions. 
+You coordinate and carry out the release.
+
+## Workflow
+The workflow for contributing to this project has been inspired by the workflow described by [Vincent Driessen](https://nvie.com/posts/a-successful-git-branching-model/).
+
+### 1. Describe the issue on GitHub
+Create [an issue](https://help.github.com/en/articles/creating-an-issue)
+in the GitHub repository. 
+The `issue title` describes the problem you will address.  <br>
+This is an important step as it forces one to think about the "issue".
+Make a checklist for all needed steps if possible.
+
+### 2. Solve the issue locally
+
+#### 2.0. Get the latest version of the `dev` branch
+Load the `dev branch`:
+```bash
+git checkout dev
+```
+
+Update with the latest version:
+```bash
+git pull
+```
+
+##### Permanent branches
+* master - includes the current stable version
+* dev - includes all current developments
+
+#### 2.1. Create a new (local) branch
+Create a new feature branch:
+```bash
+git checkout -b feature/my-feature
+```
+
+Naming convention for branches: `type`/`short-description`
+
+##### `type`
+* feature - includes the feature that will be implemented
+* fix - includes the quick improvements on the dev branch
+* hotfix - includes small improvements before an release, should be branched from a release branch
+* release - includes the current version to be released
+
+The majority of the development will be done in `feature` branches.
+
+##### `short-description`
+Describe shortly what the branch is about. 
+Avoid long descriptive names for branches, 2-4 words are optimal.
+
+##### Other hints
+- Separate words with `-` (minus)
+- Avoid using capital letters
+- Do not put your name to the branch name, it's a collaborative project
+- Branch names should be precise and informative
+
+Examples of branch names: `feature/add-changelog`, `fix/docstrings`, `hotfix/update-plots`, `release/v1.1.0`
+
+#### 2.2. Start editing the files
+- Divide your feature into small logical units
+- Start to write the documentation or a docstring
+- Don't rush, have the commit messages in mind
+- Add your changes to the CHANGELOG.md
+
+Check branch status:
+```bash
+git status
+```
+
+#### 2.3. Commit your changes 
+If the file does not exist on the remote server yet, use:
+```bash
+git add filename.md
+```
+
+Then commit regularly with:
+```bash
+git commit filename.md
+```
+
+Write a good `commit message`:
+- "If applied, this commit will ..."
+- Follow [existing conventions for commit messages](https://chris.beams.io/posts/git-commit)
+- Keep the subject line [shorter than 50 characters](https://chris.beams.io/posts/git-commit/#limit-50)
+- Do not commit more than a few changes at the time: [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit)
+- Use [imperative](https://chris.beams.io/posts/git-commit/#imperative)
+- Do not end the commit message with a [period](https://chris.beams.io/posts/git-commit/#end) ~~.~~ 
+- End the commit message with the `issueNumber` including the "#"
+
+Examples of commit message: `Add plotting function #42` or `Update documentation #1`
+
+#### 2.4 Fix your latest commit message
+Do you want to improve your latest commit message? <br>
+Is your latest commit not pushed yet? <br>
+Edit the commit message of your latest commit:
+```bash
+git commit --amend
+```
+
+### 3. Push your commits
+Push your `local` branch on the remote server `origin`. <br>
+If your branch does not exist on the remote server yet, use:
+```bash
+git push -u origin feature/my_feature_branch
+```
+
+Then push regularly with:
+```bash
+git push
+```
+
+### 4. Submit a pull request (PR)
+Follow the GitHub guide [creating-a-pull-request](https://help.github.com/en/articles/creating-a-pull-request). <br>
+The PR should be directed: `base: dev` <- `compare: feature/collaboration`. <br>
+Add the line `Close #<issue-number>` in the description of your PR.
+When it is merged, it [automatically closes](https://help.github.com/en/github/managing-your-work-on-github/closing-issues-using-keywords) the issue. <br>
+Assign a reviewer and get in contact.
+
+#### 4.0. Let someone else review your PR
+Follow the GitHub guide [approving a pull request with required reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews). <br>
+Assign one reviewer or a user group and get into contact.
+
+If you are the reviewer:
+- Check the changes in all corresponding files.
+- Checkout the branch and run code.
+- Comment if you would like to change something (Use `Request changes`)
+- If all tests pass and all changes are good, `Approve` the PR. 
+- Leave a comment and some nice words!
+
+#### 4.1. Merge the PR
+Follow the GitHub guide [merging a pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request).
+
+#### 4.2. Delete the feature branch
+Follow the GitHub guide [deleting a branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository#deleting-a-branch).
+
+### 5. Close the issue
+Document the result in a few sentences and close the issue. <br>
+Check that all steps have been documented:
+
+- Issue title describes the problem you solved?
+- All commit messages are linked in the issue?
+- The branch was deleted?
+- Entry in CHANGELOG.md?
+- PR is closed?
+- Issue is closed?

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2022 Reiner Lemoine Institut
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.