Fixed a bad merge.

CODING_GUIDELINES.md

@@ -9,6 +9,21 @@ We deviate from the [Google Python Style Guide][google-style-guide] only in the
 - We use [`ruff-linter`][ruff-linter] instead of [`pylint`][pylint].
 - We use [`ruff-formatter`][ruff-formatter] for source code and imports formatting, which may work differently than indicated by the guidelines in section [_3. Python Style Rules_](https://google.github.io/styleguide/pyguide.html#3-python-style-rules). For example, maximum line length is set to 100 instead of 79 (although docstring lines should still be limited to 79).
 - According to subsection [_2.19 Power Features_](https://google.github.io/styleguide/pyguide.html#219-power-features), direct use of _power features_ (e.g. custom metaclasses, import hacks, reflection) should be avoided, but standard library classes that internally use these power features are accepted. Following the same spirit, we allow the use of power features in infrastructure code with similar functionality and scope as the Python standard library.
+- For readability purposes, when a docstring contains more than the required summary line, we prefer indenting the first line at the same cursor position as the first opening quote, although this is not explicitly considered in the doctring conventions described in subsection [_3.8.1 Docstrings_](https://google.github.io/styleguide/pyguide.html#381-docstrings). Example:
+
+  ```python
+  # single line docstring
+  """A one-line summary of the module or program, terminated by a period."""
+
+  # multi-line docstring
+  """
+  A one-line summary of the module or program, terminated by a period.
+
+  Leave one blank line. The rest of this docstring should contain an
+  overall description of the module or program.
+  """
+  ```
+
 - According to subsection [_3.19.12 Imports For Typing_](https://google.github.io/styleguide/pyguide.html#31912-imports-for-typing), symbols from `typing` and `collections.abc` modules used in type annotations _"can be imported directly to keep common annotations concise and match standard typing practices"_. Following the same spirit, we allow symbols to be imported directly from third-party or internal modules when they only contain a collection of frequently used typying definitions.
 
 ### Common questions
@@ -71,7 +86,7 @@ The terseness vs. helpfulness tradeoff should be more in favor of terseness for
 
 ### Docstrings
 
-TODO: update to autodoc2
+TODO: update to `autodoc2`
 
 We generate the API documentation automatically from the docstrings using [Sphinx][sphinx] and some extensions such as [Sphinx-autodoc][sphinx-autodoc] and [Sphinx-napoleon][sphinx-napoleon]. These follow the Google Python Style Guide docstring conventions to automatically format the generated documentation. A complete overview can be found here: [Example Google Style Python Docstrings](https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html#example-google).
 
@@ -140,4 +155,3 @@ Testing components is a critical part of a software development project. We foll
 [sphinx-autodoc]: https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html
 [sphinx-napoleon]: https://sphinxcontrib-napoleon.readthedocs.io/en/latest/index.html#
 [sphinx-rest]: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html
-[ci-docs]: docs/development/CI/infrastructure.md

CONTRIBUTING.md

@@ -99,7 +99,8 @@ Before submitting a pull request, check that it meets the following criteria:
 4. If the pull request contains code authored by first-time contributors, they should add their names to the [AUTHORS.md](AUTHORS.md) file.
 5. Pick one reviewer and try to contact them directly to let them know about the pull request. If there is no feedback in 24h/48h try to contact them again or pick another reviewer.
 6. Once the pull request has been approved, it should be squash-merged as soon as possible with a meaningful description of the changes. We use the [Conventional Commits][https://www.conventionalcommits.org/en/v1.0.0/#summary] specification for writing informative and automation-friendly commit messages. The following _commit types_ are accepted:
-   - `chore`: changes that only modify development-related tools, the build system configuration or external dependencies
+   - `build`: changes that affect the build system or external dependencies
+   - `chore`: changes related to the development tools or process
    - `ci`: changes to our CI configuration files and scripts
    - `docs`: documentation only changes
    - `feat`: a new feature

pyproject.toml

@@ -100,22 +100,24 @@ extend-select = [
   "G",  # flake8-logging-format
   "C4",  # flake8-comprehensions
   "PT",  # flake8-pytest-style
-  "UP",  # pyupgrade  # TODO: evaluate and remove if needed
+  "UP",  # pyupgrade       # TODO: in evaluation
   "ARG",  # flake8-unused-arguments
   "ERA",  # eradicate
   "ICN",  # flake8-import-conventions
   "PGH",  # pygrep-hooks
   "PIE",  # flake8-pie
   "PTH",  # flake8-use-pathlib
-  "RET",  # flake8-return  # TODO: evaluate and remove if needed
+  "RET",  # flake8-return   # TODO: in evaluation
   "RUF",  # Ruff-specific
-  "SIM",  # flake8-simplify  # TODO: evaluate and remove if needed
+  "SIM",  # flake8-simplify # TODO: in evaluation
   "T10",  # flake8-debugger
-  "T20",  # flake8-print  # TODO: evaluate and remove if needed
+  "T20",  # flake8-print    # TODO: in evaluation
   "NPY"  # NumPy specific rules
 ]
 ignore = [
-  'E501'  # [line-too-long]
+  'B905',  # [zip-without-explicit-strict]
+  'E501',  # [line-too-long]
+  'UP038'  # [non-pep604-isinstance]
 ]
 ignore-init-module-imports = true
 unfixable = []
@@ -144,5 +146,6 @@ section-order = [
 ]
 
 [tool.ruff.lint.per-file-ignores]
-"noxfile.py" = ["T20"]
-"tests/**" = ["T10", "T20"]
+"!tests/**.py" = ["PT"]  # Ignore `flake8-pytest-style` everywhere except in `tests/`
+"noxfile.py" = ["T20"]  # Ignore `flake8-print`
+"tests/**" = ["T10", "T20"]  # Ignore `flake8-debugger` and `flake8-print`