Add community, contributing guidelines.

docs/source/index.md

@@ -66,5 +66,6 @@ or
 
 pages/tutorials
 pages/how_tos
+pages/community/community
 pages/api_index
 ```

docs/source/pages/community/community.md

@@ -0,0 +1,30 @@
+# Community
+
+
+Contributions to **datashuttle** are strongly encouraged, if you would like to submit
+a bug fix or implement a new feature, please feel free! We are a
+friendly bunch and happy to [answer any questions](https://neuroinformatics.zulipchat.com/#narrow/stream/405999-DataShuttle) before,
+during or after a contribution. See the [Contributing Guide](contributing.md) for more details.
+
+We are in general very keen to hear feedback on what works and doesn't work
+in **datashuttle** and
+[NeuroBlueprint](https://neuroblueprint.neuroinformatics.dev)
+
+Please get in contact with any thoughts on how these tools can be
+improved by opening a
+[GitHub Issue](https://github.com/neuroinformatics-unit/datashuttle/issues)
+or at our
+[Zulip Chat](https://neuroinformatics.zulipchat.com/#narrow/stream/405999-DataShuttle).
+
+To see what we have planned in future for **datashuttle**, visit
+our [Roadmap](roadmap.md).
+
+
+```{toctree}
+:maxdepth: 2
+:caption: index
+:hidden:
+
+contributing
+roadmap
+```

docs/source/pages/community/contributing.md

@@ -0,0 +1,144 @@
+# Contributing Guide
+
+**Contributors to datashuttle are absolutely encouraged**, whether to fix a bug or develop a new feature.
+
+If you're unsure about any part of the contributing process and have any questions, please
+get in touch through our [Zulip chat](https://neuroinformatics.zulipchat.com/#narrow/stream/405999-DataShuttle).
+Otherwise, please dive right in to contributing by
+[creating a developlemt environment](creating-a-development-environment)
+and [opening a pull request](pull-requests).
+
+The core development team will support you in contributing code, irrespective of your experience!
+
+### Creating a development environment
+
+To install **datashuttle** along with all packages necessary
+for development, see the 'Developers' tab on the
+[How to install **datashuttle**](how-to-install)
+page for full details.
+
+Briefly, once Rclone is installed it requires only cloning the repository:
+
+```sh
+git clone [email protected]:neuroinformatics-unit/datashuttle.git
+```
+
+and pip-installing **datashuttle** with the developer tag:
+
+
+```sh
+pip install -e .[dev]
+```
+
+or if using `zsh`:
+
+```sh
+pip install -e '.[dev]'
+```
+
+Finally, initialise the [pre-commit hooks](#formatting-and-pre-commit-hooks):
+
+```bash
+pre-commit install
+```
+
+
+### Pull requests
+
+In all cases, please submit code to the main repository via a pull request. The developers recommend, and adhere,
+to the following conventions:
+
+- Please submit *draft* pull requests as early as possible (you can still push to the branch once submitted) to
+  allow for discussion.
+- One approval of a PR (by a repo owner) is enough for it to be merged.
+- Unless someone approves the PR with optional comments, the PR is immediately merged by the approving reviewer.
+
+
+A typical PR workflow would be:
+* Create a new branch, make your changes, and add them with `git add`
+* When you try to commit, the [pre-commit hooks](#formatting-and-pre-commit-hooks) will be triggered.
+* `git add` any changes made by the hooks, and commit. See more on dealing with the [pre-commit hooks](#formatting-and-pre-commit-hooks) below.
+* Push your changes to GitHub and open a draft pull request.
+* Please don't hesitate to ask any developer for help on draft pull requests at our [Zulip chat](https://neuroinformatics.zulipchat.com/#narrow/stream/405999-DataShuttle).
+* If all checks run successfully, you may mark the pull request as ready for review.
+* Respond to review comments and implement any requested changes.
+* One of the maintainers will approve the PR and add it to the [merge queue](https://github.blog/changelog/2023-02-08-pull-request-merge-queue-public-beta/).
+* Your PR will be (squash-)merged into the *main* branch!
+
+When submitting a PR, it is useful to think about how the new
+features will be tested. If you are familiar with testing, please
+try to add tests of new functionality but if not, no problem! We are happy to help
+with both the design and implementation of tests so please don't
+let this stop you opening a PR. We take a similar approach to
+[documenting new features](#contributing-documentation), discussed further below.
+
+### Formatting and pre-commit hooks
+
+Running `pre-commit install` will set up [pre-commit hooks](https://pre-commit.com/) to ensure a consistent formatting style. Currently, these include:
+* [ruff](https://github.com/astral-sh/ruff) does a number of jobs, including code linting and auto-formatting.
+* [mypy](https://mypy.readthedocs.io/en/stable/index.html) as a static type checker.
+* [check-manifest](https://github.com/mgedmin/check-manifest) to ensure that the right files are included in the pip package.
+* [codespell](https://github.com/codespell-project/codespell) to check for common misspellings.
+
+
+Pre-commit hooks will automatically run when a commit is made. To run all the hooks before committing:
+
+```sh
+pre-commit run  # for staged files
+pre-commit run -a  # for all files in the repository
+```
+
+Some problems will be automatically fixed by the hooks. In this case, you should
+stage the auto-fixed changes and run the hooks again:
+
+```sh
+git add .
+pre-commit run
+```
+
+If a problem cannot be auto-fixed, the corresponding tool will provide
+information on what the issue is and how to fix it. For example, `ruff` might
+output something like:
+
+```sh
+movement/io/load_poses.py:551:80: E501 Line too long (90 > 79)
+```
+
+This pinpoints the problem to a single code line and a specific [ruff rule](https://docs.astral.sh/ruff/rules/) violation.
+Sometimes you may have good reasons to ignore a particular rule for a specific line of code. You can do this by adding an inline comment, e.g. `# noqa: E501`. Replace `E501` with the code of the rule you want to ignore.
+
+
+Don't worry if you are stuck and are not sure how to fix linting
+issues. Feel free to commit with the `--no-verify` option which will
+skip pre-commit checks, and ask for help in your PR.
+
+
+For docstrings, we adhere to the [numpydoc](https://numpydoc.readthedocs.io/en/latest/format.html) style.
+Make sure to provide docstrings for all public functions, classes, and methods.
+
+## To improve the documentation
+
+It is very important the documentation for **datashuttle** is clear
+accurate and concise. A key principle of **datashuttle** is it should
+make data acquisition simple and easy—therefore it should be
+well documented.
+
+For these reasons every part of all software must be documented as
+well as possible, and all new features must be fully documented. If you
+see anywhere the documentation can be improved, please don't hesitate
+to make a contribution.
+
+### Editing the documentation
+
+The documentation is hosted using [GitHub Pages](https://pages.github.com/), and the source can be found at
+[GitHub](https://github.com/neuroinformatics-unit/datashuttle/tree/main/docs).
+Most content is found under `docs/source`, where the structure mostly mirrors the rendered website.
+
+To edit a page, please:
+
+- Fork the repository
+- Make edits to the relevant pages
+- Create a pull request outlining the changes made
+
+If you aren't sure where the changes should be made, please
+[get in touch!](https://neuroinformatics.zulipchat.com/#narrow/stream/405999-DataShuttle).

docs/source/pages/community/roadmap.md

@@ -0,0 +1 @@
+# Roadmap