doc(contributing) first few guidelines on doc, commits, and PRs

These are largely taken from `datalad-next` and reflect the practice for
that project for the past months.

CONTRIBUTING.md

@@ -31,3 +31,45 @@ hatch build
 ```
 hatch publish
 ```
+
+## Contribution style guide
+
+A contribution must be complete with code, tests, and documentation.
+
+`datasalad` is a core library for a software ecosystem. Therefore, tests are essential. A high test-coverage is desirable. Contributors should aim for near-complete coverage (or better). Tests must be dedicated for the code of a particular contribution. It is not sufficient, if other code happens to also exercise a new feature.
+
+### Documentation
+
+Docstrings should be complete with information on parameters, return values, and exception behavior. Documentation should be added to and rendered with the sphinx-based documentation.
+
+### Commits
+
+Commits and commit messages must be [Conventional Commits](https://www.conventionalcommits.org). Their compliance is checked for each pull request. The following commit types are recognized:
+
+- `feat`: introduces a new feature
+- `fix`: address a problem, fix a bug
+- `doc`: update the documentation
+- `rf`: refactor code with no change of functionality
+- `perf`: enhance performance of existing functionality
+- `test`: add/update/modify test implementations
+- `ci`: change CI setup
+- `style`: beautification
+- `chore`: results of routine tasks, such as changelog updates
+- `revert`: revert a previous change
+- `bump`: version update
+
+Any breaking change must have at least one line of the format
+
+    BREAKING CHANGE: <summary of the breakage>
+
+in the body of the commit message that introduces the breakage. Breaking changes can be introduced in any type of commit. Any number of breaking changes can be described in a commit message (one per line). Breaking changes trigger a major version update, and form a dedicated section in the changelog.
+
+### Pull requests
+
+Contributions submitted via a pull-request (PR), are expected to be a clear, self-describing series of commits. The PR description is largely irrelevant, and could be used for a TODO list, or conversational content. All essential information concerning the code and changes **must** be contained in the commit messages.
+
+Commit series should be "linear", with individual commits being self-contained, well-described changes.
+
+If possible, only loosely related changes should be submitted in separate PRs to simplify reviewing and shorten time-to-merge.
+
+Long-standing, inactive PRs (draft mode or not) are frowned up, as they drain attention. It is often better to close a PR and open a new one, once work resumes. Maintainers may close inactive PRs for this reason at any time.