From 47db837b431b53e9dd2ea53630e39bbcbb7d8df0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20B=C3=B6ckenhoff?= <dboe@ipp.mpg.de>
Date: Fri, 14 Jul 2023 09:49:08 +0200
Subject: [PATCH] Update template
---
CONTRIBUTING.rst | 303 ------------------
Makefile | 3 +-
.../contribution_types/bugs_fix.rst | 5 +
.../contribution_types/bugs_report.rst | 12 +
.../contributing/contribution_types/docu.rst | 9 +
.../contribution_types/features.rst | 5 +
.../contribution_types/feedback.rst | 11 +
.../contributing/contribution_types/index.rst | 21 ++
.../contributing/contribution_types/tests.rst | 5 +
.../contributing/guidelines/docu.rst | 5 +
.../contributing/guidelines/index.rst | 15 +
.../guidelines/merge_requests.rst | 15 +
.../contributing/guidelines/style.rst | 45 +++
docs/community/contributing/index.rst | 45 +++
docs/community/contributing/setup/index.rst | 42 +++
.../community/contributing/workflow/daily.rst | 33 ++
.../contributing/workflow/deploying.rst | 23 ++
docs/community/contributing/workflow/docu.rst | 16 +
.../community/contributing/workflow/index.rst | 17 +
.../contributing/workflow/testing.rst | 36 +++
docs/community/index.rst | 22 +-
docs/cookiecutter_input.json | 1 +
22 files changed, 384 insertions(+), 305 deletions(-)
delete mode 100644 CONTRIBUTING.rst
create mode 100644 docs/community/contributing/contribution_types/bugs_fix.rst
create mode 100644 docs/community/contributing/contribution_types/bugs_report.rst
create mode 100644 docs/community/contributing/contribution_types/docu.rst
create mode 100644 docs/community/contributing/contribution_types/features.rst
create mode 100644 docs/community/contributing/contribution_types/feedback.rst
create mode 100644 docs/community/contributing/contribution_types/index.rst
create mode 100644 docs/community/contributing/contribution_types/tests.rst
create mode 100644 docs/community/contributing/guidelines/docu.rst
create mode 100644 docs/community/contributing/guidelines/index.rst
create mode 100644 docs/community/contributing/guidelines/merge_requests.rst
create mode 100644 docs/community/contributing/guidelines/style.rst
create mode 100644 docs/community/contributing/index.rst
create mode 100644 docs/community/contributing/setup/index.rst
create mode 100644 docs/community/contributing/workflow/daily.rst
create mode 100644 docs/community/contributing/workflow/deploying.rst
create mode 100644 docs/community/contributing/workflow/docu.rst
create mode 100644 docs/community/contributing/workflow/index.rst
create mode 100644 docs/community/contributing/workflow/testing.rst
diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
deleted file mode 100644
index 03943a9..0000000
--- a/CONTRIBUTING.rst
+++ /dev/null
@@ -1,303 +0,0 @@
-Contributing
-============
-..
- [contributing]
-
-.. highlight:: shell
-
-Thank you for your interest in contributing to the project!
-Your contributions are greatly appreciated, and every little bit helps to make the project better for everyone.
-
-Types of Contributions
-----------------------
-
-There are many ways you can contribute to the project, including:
-
-.. toctree::
- :maxdepth: 2
-
- bugs_report
- bugs_fix
- feat
- docu
- tests
- feedback
-
-.. _bugs_report:
-
-Report Bugs
-~~~~~~~~~~~
-
-If you encounter a bug in the project, please report it by `creating an issue on the project's issue tracker <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/issues/>`_.
-When reporting a bug, please include:
-
-- Your operating system name and version
-- Any details about your local setup that might be helpful in troubleshooting
-- Detailed steps to reproduce the bug
-
-If you want quick feedback, it is helpful to mention specific developers
-(@developer_name) or @all. This will trigger a mail to the corresponding developer(s).
-
-.. _bugs_fix:
-
-Fixing Bugs
-~~~~~~~~~~~
-
-If you would like to help fix a bug in the project, take a look at the issues tagged as "bug" and "help wanted" in the project's issue tracker.
-These issues are open to anyone who wants to help fix them.
-
-.. _feat:
-
-Implementing Features
-~~~~~~~~~~~~~~~~~~~~~
-
-If you would like to help implement a new feature in the project, take a look at the issues tagged as "enhancement" and "help wanted" in the project's issue tracker.
-These issues are open to anyone who wants to help implement them.
-
-.. _docu:
-
-Writing Documentation
-~~~~~~~~~~~~~~~~~~~~~
-
-Good documentation is key to a successful project.
-If you would like to help improve the project's documentation, you can contribute by:
-
-- Adding documentation to the project's code
-- Writing new documentation pages or articles
-- Improving existing documentation pages or articles
-
-.. _tests:
-
-Writing Tests
-~~~~~~~~~~~~~
-
-`tfields` profits a lot from better :ref name="Testing":`testing`. We encourage you to add unittests
-with the `pytest` module (`unittest` module is OK, too) in the `tests` directory or doctests (as part of docstrings or in the documentation).
-
-.. _feedback:
-
-Submit Feedback
-~~~~~~~~~~~~~~~
-
-The best way to send feedback is to file an `Issue <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/issues/>`_.
-
-If you are proposing a feature:
-
-* Explain in detail how it would work.
-* Keep the scope as narrow as possible, to make it easier to implement.
-* Remember that this is a volunteer-driven project, and that contributions
- are welcome
-
-Setup and Install
------------------
-
-Ready to contribute?
-Here's how to set up `tfields` for local development.
-
-1. If you are part of the project team, you are welcome to submit changes through your own development branch in the main repository.
- However, if you are not part of the team, we recommend `forking <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/forks/new/>`_ the project and submitting changes through a pull request from your forked repository.
- This allows us to review and discuss your changes before merging them into the main project.
-2. Clone the repository to your local machine::
-
- .. code-block:: shell
-
- git clone git@gitlab.mpcdf.mpg.de:dboe/tfields.git
-
- Change adequately if you forked.
-
-3. Set up your the local development environment::
-
- .. code-block:: shell
-
- cd tfields/
- make env
-
- `make env` will setup a virtual conda environment for you, install all packages there and install `pre-commit <https://pre-commit.com/>`_.
-
-The above will only be necessary once.
-
-You are now ready to go.
-Have a look at
-
- .. code-block:: shell
-
- make help
-
-to get an overview over the daily operations that are automatized for you.
-
-Daily Operations
-----------------
-
-- Work on the virtual environment (created by `make env`) by activating it::
-
- .. code-block:: shell
-
- conda activate ./env
-
-- Work on a branch different from `master/main` for local development::
-
- .. code-block:: shell
-
- git checkout -b <name-of-your-bugfix-or-feature>
-
- Now you can make your changes locally.
-
-- When you're done making changes, check that these pass the linters and tests::
-
- .. code-block:: shell
-
- make test
-
-- Commit your changes and push your branch to origin::
-
- .. code-block:: shell
-
- git add <files to be added to your commit>
- git commit -m "Your detailed description of your changes."
- git push origin name-of-your-bugfix-or-feature
-
-- Submit a `merge request <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/merge_requests/>`_ through the repository website Follow the `Guidelines <#guidelines>` below.
-
-.. _guidelines:
-
-Code Review and Merge Request Guidelines
-----------------------------------------
-
-All code contributions to the project are reviewed by project maintainers before they are merged.
-To ensure that your code contribution is accepted, please follow these guidelines:
-
-Before you submit a `merge request <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/merge_requests/>`_, check that you follow these guidelines:
-
-1. Write code that is well-documented and easy to understand.
-2. Write tests that verify the behavior of your code.
- The merge request should work for all supported python versions and operation systems.
-3. Use the project's coding style guidelines.
-4. Submit a pull request that describes your changes and why they are valuable to the project.
-5. Respond to feedback from code reviewers in a timely manner.
- and make sure that the tests pass for all supported Python versions.
-
-Testing
--------
-
-To run tests, use
-
- .. code-block:: shell
-
- make test
-
-To run a subset of tests, you have the following options:
-
-- You can run a subset of tests by specifying a test file or test name
-
- .. code-block:: shell
-
- pytest tests/test_package.py
-
- pytest tests/test_package.py::Test_tfields::test_version_type
-
-- To test doctests, in docstrings or documentation, use the flag `--doctest-modules` (active by default via pyproject.toml)
-
- .. code-block:: shell
-
- pytest --doctest-modules docs/usage.rst
-
- pytest --doctest-modules tfields/core.py -k "MyClass.function_with_doctest"
-
-- Use the `--trace` option to directly jump into a pdb debugger on fails.
-
-To run tests with code coverage, use the command
-
- .. code-block:: shell
-
- make coverage
-
-This will generate an HTML report showing the coverage of each file in the project.
-
-Documentation
--------------
-To compile the documentation (including automatically generated module api docs), run
-
- .. code-block:: shell
-
- make docs
-
-To build the documentation and run a live-reloading server, use the command
-
- .. code-block:: shell
-
- make docs-serve
-
-This will start a server that will rebuild the documentation whenever a change is made, and display it in your web browser.
-
-Use doctests as much as possible in order to have tested examples in your documentation.
-
-Style Guide
------------
-
-Please follow the `google style guide <https://google.github.io/styleguide/pyguide.html>`_ illustrated
-by `this example <https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html>`_.
-
-Additionaly we format *args and **kwargs like so:
-
- .. code-block:: python
-
- def fun(param1: int, param2: float, *args, kw1: str = None, **kwargs)
- """
- Args:
- param1 (int): The first parameter.
- param2 (float): description
- *args (str): description
- Second line. List follow now
-
- 0: first position is used as ...
- 1: second position is used as ...
-
- further are passed to/consumed by/used for ...
-
- kw1 (Optional[str]): description. Defaults to None.
- Second line of description should be indented.
- **kwargs: description
-
- **sub_key1 (Optional[str]): This key is retrieved by kwargs.pop('sub_key1', Default)
- **sub_key2 (Optional[str]): This key is retrieved by kwargs.pop('sub_key1', Default)
-
- further are passed to/consumed by/used for ...
-
- ...
- """
-
-
-Deploying
----------
-
-A reminder for the maintainers on how to deploy.
-Make sure all your changes are committed.
-Then run
-
- .. code-block:: shell
-
- make publish
-
-.. dropdown:: Failed CI deploy stage
- :icon: alert
-
- In case of failure in the CI deploy stage after :code:`make publish`, use the following rule to delete the tag (also remote)
-
- .. code-block:: shell
-
- make untag
-
-If something fails on the ci side, you can make use of
-
-The CI will then deploy to PyPI if tests pass.
-
-TODO Notes
-----------
-
-If you add a `TODO` note to the code, please follow these conventions:
-
-- Use the format `TODO(@responsible-user): note` to assign responsibility for the note.
-- Place the `TODO` note in a docstring near the relevant code.
-- Use priority labels like `TODO-0`, `TODO-1`, and `TODO-2` to indicate the urgency of the note.
-
-We appreciate your contributions to the project and look forward to working with you!
diff --git a/Makefile b/Makefile
index af80cf9..cc724a5 100644
--- a/Makefile
+++ b/Makefile
@@ -80,7 +80,8 @@ requirements: pyproject.toml
install-docs:
ifeq ($(ENVACTIVE),true)
ifeq ($(DOCS_INSTALLED),false)
- ${CONDA_RUN}poetry install --with docs
+ ${CONDA_RUN}poetry install --with docs --all-extras
+
endif
else
@printf $(_WARN) "docs" "CONDA environment is not active. Make sure to activate the environment ($$ make env-activate) or install the requirements manually ($$ poetry install --with docs). The successful build of the following command is your responsibility."
diff --git a/docs/community/contributing/contribution_types/bugs_fix.rst b/docs/community/contributing/contribution_types/bugs_fix.rst
new file mode 100644
index 0000000..8aa22f3
--- /dev/null
+++ b/docs/community/contributing/contribution_types/bugs_fix.rst
@@ -0,0 +1,5 @@
+Fixing Bugs
+~~~~~~~~~~~
+
+If you would like to help fix a bug in the project, take a look at the issues tagged as "bug" and "help wanted" in the project's issue tracker.
+These issues are open to anyone who wants to help fix them.
diff --git a/docs/community/contributing/contribution_types/bugs_report.rst b/docs/community/contributing/contribution_types/bugs_report.rst
new file mode 100644
index 0000000..49c63ee
--- /dev/null
+++ b/docs/community/contributing/contribution_types/bugs_report.rst
@@ -0,0 +1,12 @@
+Report Bugs
+~~~~~~~~~~~
+
+If you encounter a bug in the project, please report it by `creating an issue on the project's issue tracker <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/issues/>`_.
+When reporting a bug, please include:
+
+- Your operating system name and version
+- Any details about your local setup that might be helpful in troubleshooting
+- Detailed steps to reproduce the bug
+
+If you want quick feedback, it is helpful to mention specific developers
+(@developer_name) or @all. This will trigger a mail to the corresponding developer(s).
diff --git a/docs/community/contributing/contribution_types/docu.rst b/docs/community/contributing/contribution_types/docu.rst
new file mode 100644
index 0000000..bcf69de
--- /dev/null
+++ b/docs/community/contributing/contribution_types/docu.rst
@@ -0,0 +1,9 @@
+Writing Documentation
+~~~~~~~~~~~~~~~~~~~~~
+
+Good documentation is key to a successful project.
+If you would like to help improve the project's documentation, you can contribute by:
+
+- Adding documentation to the project's code
+- Writing new documentation pages or articles
+- Improving existing documentation pages or articles
diff --git a/docs/community/contributing/contribution_types/features.rst b/docs/community/contributing/contribution_types/features.rst
new file mode 100644
index 0000000..3ec9489
--- /dev/null
+++ b/docs/community/contributing/contribution_types/features.rst
@@ -0,0 +1,5 @@
+Implementing Features
+~~~~~~~~~~~~~~~~~~~~~
+
+If you would like to help implement a new feature in the project, take a look at the issues tagged as "enhancement" and "help wanted" in the project's issue tracker.
+These issues are open to anyone who wants to help implement them.
diff --git a/docs/community/contributing/contribution_types/feedback.rst b/docs/community/contributing/contribution_types/feedback.rst
new file mode 100644
index 0000000..dcb9dfd
--- /dev/null
+++ b/docs/community/contributing/contribution_types/feedback.rst
@@ -0,0 +1,11 @@
+Submit Feedback
+~~~~~~~~~~~~~~~
+
+The best way to send feedback is to file an `Issue <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/issues/>`_.
+
+If you are proposing a feature:
+
+* Explain in detail how it would work.
+* Keep the scope as narrow as possible, to make it easier to implement.
+* Remember that this is a volunteer-driven project, and that contributions
+ are welcome
diff --git a/docs/community/contributing/contribution_types/index.rst b/docs/community/contributing/contribution_types/index.rst
new file mode 100644
index 0000000..6c6826a
--- /dev/null
+++ b/docs/community/contributing/contribution_types/index.rst
@@ -0,0 +1,21 @@
+..
+ [intro-start]
+
+Types of Contributions
+----------------------
+
+There are many ways you can contribute to the project, including:
+
+..
+ [intro-end]
+
+.. toctree::
+ :maxdepth: 2
+
+ bugs_report
+ bugs_fix
+ features
+ docu
+ tests
+ feedback
+
\ No newline at end of file
diff --git a/docs/community/contributing/contribution_types/tests.rst b/docs/community/contributing/contribution_types/tests.rst
new file mode 100644
index 0000000..7408801
--- /dev/null
+++ b/docs/community/contributing/contribution_types/tests.rst
@@ -0,0 +1,5 @@
+Writing Tests
+~~~~~~~~~~~~~
+
+`tfields` profits a lot from better :ref name="Testing":`testing`. We encourage you to add unittests
+with the `pytest` module (`unittest` module is OK, too) in the `tests` directory or doctests (as part of docstrings or in the documentation).
diff --git a/docs/community/contributing/guidelines/docu.rst b/docs/community/contributing/guidelines/docu.rst
new file mode 100644
index 0000000..402b944
--- /dev/null
+++ b/docs/community/contributing/guidelines/docu.rst
@@ -0,0 +1,5 @@
+Documentation
+-------------
+
+Use examples in code-fences ('.. code-block:: language-mode') or doctest prompts ('>>>') extensively but on a high level and not with too much detail.
+Details are to be tested systematically in pytests.
diff --git a/docs/community/contributing/guidelines/index.rst b/docs/community/contributing/guidelines/index.rst
new file mode 100644
index 0000000..dab7bd6
--- /dev/null
+++ b/docs/community/contributing/guidelines/index.rst
@@ -0,0 +1,15 @@
+..
+ [intro-start]
+
+Guidelines:
+-----------
+
+..
+ [intro-end]
+
+.. toctree::
+ :maxdepth: 2
+
+ style
+ docu
+ merge_requests
diff --git a/docs/community/contributing/guidelines/merge_requests.rst b/docs/community/contributing/guidelines/merge_requests.rst
new file mode 100644
index 0000000..a9bcada
--- /dev/null
+++ b/docs/community/contributing/guidelines/merge_requests.rst
@@ -0,0 +1,15 @@
+Merge Request and Code Review Guidelines
+----------------------------------------
+
+All code contributions to the project are reviewed by project maintainers before they are merged.
+To ensure that your code contribution is accepted, please follow these guidelines:
+
+Before you submit a `merge request <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/merge_requests/>`_, check that you follow these guidelines:
+
+1. Write code that is well-documented and easy to understand.
+2. Write tests that verify the behavior of your code.
+ The merge request should work for all supported python versions and operation systems.
+3. Use the project's coding style guidelines.
+4. Submit a pull request that describes your changes and why they are valuable to the project.
+5. Respond to feedback from code reviewers in a timely manner.
+ and make sure that the tests pass for all supported Python versions.
diff --git a/docs/community/contributing/guidelines/style.rst b/docs/community/contributing/guidelines/style.rst
new file mode 100644
index 0000000..0c2ef04
--- /dev/null
+++ b/docs/community/contributing/guidelines/style.rst
@@ -0,0 +1,45 @@
+Style Guide
+-----------
+
+Please follow the `google style guide <https://google.github.io/styleguide/pyguide.html>`_ illustrated
+by `this example <https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html>`_.
+
+Additionaly we format `*args` and `**kwargs` like so:
+
+ .. code-block:: python
+
+ def fun(param1: int, param2: float, *args, kw1: str = None, **kwargs)
+ """
+ Args:
+ param1 (int): The first parameter.
+ param2 (float): description
+ *args (str): description
+ Second line. List follow now
+
+ 0: first position is used as ...
+ 1: second position is used as ...
+
+ further are passed to/consumed by/used for ...
+
+ kw1 (Optional[str]): description. Defaults to None.
+ Second line of description should be indented.
+ **kwargs: description
+
+ **sub_key1 (Optional[str]): This key is retrieved by kwargs.pop('sub_key1', Default)
+ **sub_key2 (Optional[str]): This key is retrieved by kwargs.pop('sub_key1', Default)
+
+ further are passed to/consumed by/used for ...
+
+ ...
+ """
+
+TODO Notes
+^^^^^^^^^^
+
+If you add a `TODO` note to the code, please follow these conventions:
+
+- Use the format `TODO(@responsible-user): note` to assign responsibility for the note.
+- Place the `TODO` note in a docstring near the relevant code.
+- Use priority labels like `TODO-0`, `TODO-1`, and `TODO-2` to indicate the urgency of the note.
+
+We appreciate your contributions to the project and look forward to working with you!
diff --git a/docs/community/contributing/index.rst b/docs/community/contributing/index.rst
new file mode 100644
index 0000000..f5e85d8
--- /dev/null
+++ b/docs/community/contributing/index.rst
@@ -0,0 +1,45 @@
+Contributing
+============
+..
+ [contributing]
+
+.. highlight:: shell
+
+Thank you for your interest in contributing to the project!
+Your contributions are greatly appreciated, and every little bit helps to make the project better for everyone.
+
+.. include:: contribution_types/index.rst
+ :start-after: [intro-start]
+ :end-before: [intro-end]
+
+.. toctree::
+ :maxdepth: 2
+
+ contribution_types/index
+
+.. include:: setup/index.rst
+ :start-after: [intro-start]
+ :end-before: [intro-end]
+
+.. toctree::
+ :maxdepth: 2
+
+ setup/index
+
+.. include:: workflow/index.rst
+ :start-after: [intro-start]
+ :end-before: [intro-end]
+
+.. toctree::
+ :maxdepth: 2
+
+ workflow/index
+
+.. include:: guidelines/index.rst
+ :start-after: [intro-start]
+ :end-before: [intro-end]
+
+.. toctree::
+ :maxdepth: 2
+
+ guidelines/index
diff --git a/docs/community/contributing/setup/index.rst b/docs/community/contributing/setup/index.rst
new file mode 100644
index 0000000..48de0f4
--- /dev/null
+++ b/docs/community/contributing/setup/index.rst
@@ -0,0 +1,42 @@
+..
+ [intro-start]
+
+Setup and Install
+-----------------
+
+Ready to contribute?
+Here's how to set up `tfields` for local development.
+
+..
+ [intro-end]
+
+1. If you are part of the project team, you are welcome to submit changes through your own development branch in the main repository.
+ However, if you are not part of the team, we recommend `forking <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/forks/new/>`_ the project and submitting changes through a pull request from your forked repository.
+ This allows us to review and discuss your changes before merging them into the main project.
+2. Clone the repository to your local machine::
+
+ .. code-block:: shell
+
+ git clone git@gitlab.mpcdf.mpg.de:dboe/tfields.git
+
+ Change adequately if you forked.
+
+3. Set up your the local development environment::
+
+ .. code-block:: shell
+
+ cd tfields/
+ make env
+
+ `make env` will setup a virtual conda environment for you, install all packages there and install `pre-commit <https://pre-commit.com/>`_.
+
+The above will only be necessary once.
+
+You are now ready to go.
+Have a look at
+
+ .. code-block:: shell
+
+ make help
+
+to get an overview over the daily operations that are automatized for you.
diff --git a/docs/community/contributing/workflow/daily.rst b/docs/community/contributing/workflow/daily.rst
new file mode 100644
index 0000000..f2bfdb0
--- /dev/null
+++ b/docs/community/contributing/workflow/daily.rst
@@ -0,0 +1,33 @@
+Daily Operations
+----------------
+
+- Work on the virtual environment (created by `make env`) by activating it::
+
+ .. code-block:: shell
+
+ conda activate ./env
+
+- Work on a branch different from `master/main` for local development::
+
+ .. code-block:: shell
+
+ git checkout -b <name-of-your-bugfix-or-feature>
+
+ Now you can make your changes locally.
+
+- When you're done making changes, check that these pass the linters and tests::
+
+ .. code-block:: shell
+
+ make test
+
+- Commit your changes and push your branch to origin::
+
+ .. code-block:: shell
+
+ git add <files to be added to your commit>
+ git commit -m "Your detailed description of your changes."
+ git push origin name-of-your-bugfix-or-feature
+
+- Submit a `merge request <https://gitlab.mpcdf.mpg.de/dboe/tfields/-/merge_requests/>`_ through the repository website Follow the `Guidelines <#guidelines>` below.
+
\ No newline at end of file
diff --git a/docs/community/contributing/workflow/deploying.rst b/docs/community/contributing/workflow/deploying.rst
new file mode 100644
index 0000000..1d122d6
--- /dev/null
+++ b/docs/community/contributing/workflow/deploying.rst
@@ -0,0 +1,23 @@
+Deploying
+---------
+
+A reminder for the maintainers on how to deploy.
+Make sure all your changes are committed.
+Then run
+
+ .. code-block:: shell
+
+ make publish
+
+.. dropdown:: Failed CI deploy stage
+ :icon: alert
+
+ In case of failure in the CI deploy stage after :code:`make publish`, use the following rule to delete the tag (also remote)
+
+ .. code-block:: shell
+
+ make untag
+
+If something fails on the ci side, you can make use of
+
+The CI will then deploy to PyPI if tests pass.
diff --git a/docs/community/contributing/workflow/docu.rst b/docs/community/contributing/workflow/docu.rst
new file mode 100644
index 0000000..52d314c
--- /dev/null
+++ b/docs/community/contributing/workflow/docu.rst
@@ -0,0 +1,16 @@
+Documentation
+-------------
+
+To compile the documentation (including automatically generated module api docs), run
+
+ .. code-block:: shell
+
+ make docs
+
+To build the documentation and run a live-reloading server, use the command
+
+ .. code-block:: shell
+
+ make docs-serve
+
+This will start a server that will rebuild the documentation whenever a change is made, and display it in your web browser.
diff --git a/docs/community/contributing/workflow/index.rst b/docs/community/contributing/workflow/index.rst
new file mode 100644
index 0000000..4f8ded0
--- /dev/null
+++ b/docs/community/contributing/workflow/index.rst
@@ -0,0 +1,17 @@
+..
+ [intro-start]
+
+Workflow:
+---------
+
+..
+ [intro-end]
+
+.. toctree::
+ :maxdepth: 2
+
+ daily
+ testing
+ docu
+ deploying
+
\ No newline at end of file
diff --git a/docs/community/contributing/workflow/testing.rst b/docs/community/contributing/workflow/testing.rst
new file mode 100644
index 0000000..854670e
--- /dev/null
+++ b/docs/community/contributing/workflow/testing.rst
@@ -0,0 +1,36 @@
+Testing
+-------
+
+To run tests, use
+
+ .. code-block:: shell
+
+ make test
+
+To run a subset of tests, you have the following options:
+
+- You can run a subset of tests by specifying a test file or test name
+
+ .. code-block:: shell
+
+ pytest tests/test_package.py
+
+ pytest tests/test_package.py::Test_tfields::test_version_type
+
+- To test doctests, in docstrings or documentation, use the flag `--doctest-modules` (active by default via pyproject.toml)
+
+ .. code-block:: shell
+
+ pytest --doctest-modules docs/usage.rst
+
+ pytest --doctest-modules tfields/core.py -k "MyClass.function_with_doctest"
+
+- Use the `--trace` option to directly jump into a pdb debugger on fails.
+
+To run tests with code coverage, use the command
+
+ .. code-block:: shell
+
+ make coverage
+
+This will generate an HTML report showing the coverage of each file in the project.
diff --git a/docs/community/index.rst b/docs/community/index.rst
index ac7b6bc..5b28ce1 100644
--- a/docs/community/index.rst
+++ b/docs/community/index.rst
@@ -1 +1,21 @@
-.. include:: ../../CONTRIBUTING.rst
+.. asdf documentation master file, created by
+ sphinx-quickstart on Wed Jul 12 11:08:38 2023.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Welcome to asdf's documentation!
+================================
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Contents:
+
+ contributing/index
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
diff --git a/docs/cookiecutter_input.json b/docs/cookiecutter_input.json
index c28c849..c065a9d 100644
--- a/docs/cookiecutter_input.json
+++ b/docs/cookiecutter_input.json
@@ -1,4 +1,5 @@
{
+ "_repo_dir": "/home/IPP-HGW/dboe/.cookiecutters/dough",
"_template": "https://gitlab.com/dboe/dough.git",
"author": "Daniel B\u00f6ckenhoff",
"continuous_integration": "y",
--
GitLab