other vital documents

.gitlab/merge_request_templates/Default.md

+# Summary
+
+    Insert a meaningful description for this merge request here.  What is the
+    new/changed behavior? Which bug has been fixed? Are there related Issues?
+
+# Focus
+
+    Point the reviewer to the core of the code change. Where should they start
+    reading? What should they focus on (e.g. security, performance,
+    maintainability, user-friendliness, compliance with the specs, finding more
+    corner cases, concrete questions)?
+
+# Test Environment
+
+    How to set up a test environment for manual testing?
+
+# Check List for the Author
+
+Please, prepare your MR for a review. Be sure to write a summary and a
+focus and create gitlab comments for the reviewer. They should guide the
+reviewer through the changes, explain your changes and also point out open
+questions. For further good practices have a look at [our review
+guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md)
+
+- [ ] All automated tests pass
+- [ ] Reference related Issues
+- [ ] Up-to-date CHANGELOG.md
+- [ ] Annotations in code (Gitlab comments)
+  - Intent of new code
+  - Problems with old code
+  - Why this implementation?
+
+
+# Check List for the Reviewer
+
+
+- [ ] I understand the intent of this MR
+- [ ] All automated tests pass
+- [ ] Up-to-date CHANGELOG.md
+- [ ] The test environment setup works and the intended behavior is
+  reproducible in the test environment
+- [ ] In-code documentation and comments are up-to-date.
+- [ ] Check: Are there spezifications? Are they satisfied?
+
+For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).
+
+
+/assign me
+/target_branch dev

CHANGELOG.md

+# 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.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+### Added
+
+### Changed
+
+### Deprecated
+
+### Removed
+
+### Fixed
+
+### Security

CODE_OF_CONDUCT.md

+# 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, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, 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 **t.fitschen (AT) indiscale.com**,
+**d.hornung (AT) indiscale.com**, **a.schlemmer (AT) indiscale.com**, or
+**h.tomwoerden (AT) indiscale.com**.  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 https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+

CONTRIBUTING.md

+# Contributing
+
+Thank you very much to all contributers—[past, present](HUMANS.md), and prospective ones.
+
+## Code of Conduct
+
+By participating, you are expected to uphold our [Code of Conduct](CODE_OF_CONDUCT.md).
+
+## How to Contribute
+
+* You found a bug, have a question, or want to request a feature? Please file
+  a Gitlab issue.
+* You want to contribute code or write documentation? There is no standardized
+  way to contribute code yet. Please contact us at <info@indiscale.com> if
+  there has not been any prior contact.
+
+## Merge Requests and Code Review
+
+Please, prepare your MR for a review: Be sure to write a summary section and a
+focus section. The summary should summarize what your MR is about. The focus
+should point the reviewer to the most important code changes.
+
+Also, create gitlab comments for the reviewer. They should guide the
+reviewer through the changes, explain your changes and also point out open
+questions.
+
+For further good practices have a look at
+[our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).

DEPENDENCIES.md

+# GENERAL
+
+* >=cmake-3.14
+* >=gcc-10.2.0 | >=clang-11
+
+# BUILD DOCS
+
+* doxygen
+* >=python-3.7
+* >=pip-21.0.1
+* python packages from the `doc/requirements.txt` file.
+
+# BUILD AND RUN TESTS
+
+* >=clang-tidy-11
+
+# COVERAGE
+
+* >=gcc-10.2.0
+* >=lcov-1.15
+
+# FORMATTING
+
+* >=clang-formatting-11

FEATURES.md

+

HUMANS.md

+# Active Contributors
+
+* Timm Fitschen <t.fitschen@indiscale.com>

README.md

 # libcaosdb
 
-This is libcaosdb - a plain C client library for CaosDB.
+## Welcome
 
-## Build
+This is the development repository of **libcaosdb** - a plain C client library
+for CaosDB and a part of the CaosDB project.
 
-We use [cmake](https://cmake.org) as build tool.
+## Setup
 
-1. `cmake -B build`
-2. `cd build`
-3. `cmake --build .`
+Please read the [README_SETUP.md](README_SETUP.md) for instructions on how to
+develop, build and use this code.
 
-## Unit Tests
+## Further Reading
 
-### Run
+Please refer to the [official documentation](https://docs.indiscale.com/caosdb-cpplib/) for more information.
 
-Build tests as described above. In the build directory, run `ctest`
+## Contributing
 
-### Framework
+Please read [CONTRIBUTING.md](CONTRIBUTING.md).
 
-We use [cmocka](https://cmocka.org) for unit testing
+## License
 
-### Coverage
+* Copyright (C) 2021 Indiscale GmbH <info@indiscale.com>
 
-* We use gcov and lcov for generating test coverage reports.
-
-## Code Formatting
-
-* `clang-format -i --verbose **/*.c **/*.h`
-
-## Documentation
-
-In the build directory, run
-
-* `cmake --build . --target doc-doxygen` (generate Doxygen)
-* `cmake --build . --target doc-sphinx` (generate Sphinx)
+All files in this repository are licensed under a [GNU Affero General Public
+License](LICENCE.md) (version 3 or later).

README_SETUP.md

+# How to Develop and Use Libcaosdb
+
+## Build
+
+We use [cmake](https://cmake.org) as build tool.
+
+1. `cmake -B build`
+2. `cd build`
+3. `cmake --build .`
+
+## Unit Tests
+
+### Run
+
+Build tests as described above. In the build directory, run `ctest`
+
+### Framework
+
+We use [GoogleTest](https://google.github.io/googletest/) for unit testing.
+
+### Coverage
+
+We use [gcov](https://gcc.gnu.org/onlinedocs/gcc/Gcov.html) and
+[lcov](https://github.com/linux-test-project/lcov) for generating test coverage
+reports.
+
+In the build directory, generate the coverage report by running
+`cmake --build . --target unit_test_coverage`.
+
+Note that this special target will run the tests again. Thus it is not
+necessary to run `ctest` prior to this target.
+
+The coverage report can be viewed in a browser by opening
+`<build_directory>/unit_test_coverage/index.html`.
+
+## Code Formatting
+
+* `clang-format -i --verbose **/*.c **/*.h`
+
+## Documentation
+
+In the build directory, run
+
+* `cmake --build . --target doc-doxygen` (generate Doxygen)
+* `cmake --build . --target doc-sphinx` (generate Sphinx)

RELEASE_GUIDELINES.md

+# Release Guidelines for the CaosDB Python Client Library
+
+This document specifies release guidelines in addition to the generel release
+guidelines of the CaosDB Project
+([RELEASE_GUIDELINES.md](https://gitlab.com/caosdb/caosdb/blob/dev/RELEASE_GUIDELINES.md))
+
+## General Prerequisites
+
+* All tests are passing.
+* FEATURES.md is up-to-date and a public API is being declared in that document.
+* CHANGELOG.md is up-to-date.
+* DEPENDENCIES.md is up-to-date.
+
+## Steps
+
+1. Create a release branch from the dev branch. This prevents further changes
+   to the code base and a never ending release process. Naming: `release-<VERSION>`
+
+2. Update CHANGELOG.md
+
+3. Check all general prerequisites.
+
+4. Prepare [CMakeLists.txt](./CMakeLists.txt): Check the `MAJOR`, `MINOR`, `PATCH`
+   version variables.
+
+5. Merge the release branch into the main branch.
+
+6. Tag the latest commit of the main branch with `v<VERSION>`.
+
+7. Delete the release branch.
+
+8. TODO...