diff --git a/README.dev.md b/README.dev.md index 4f1e5af61..f76ead677 100644 --- a/README.dev.md +++ b/README.dev.md @@ -6,21 +6,27 @@ If you're looking for user documentation, go [here](README.md). We welcome all contributions to this open-source project, as long as they follow our [code of conduct](https://github.com/EIT-ALIVE/eitprocessing/blob/main/CODE_OF_CONDUCT.md). -We appreciate it if you adhere to our naming and style [conventions](#conventions) below. +We also ask you to adhere to our [naming and style conventions](#conventions). + +We appreciate if you follow the steps below. Don't be discouraged if you struggle with any of these: if you feel you +have made or can make a valuable contribution. We are happy to help, so please reach out! Do keep in mind that you might +be asked to append additional commits or make changes to your pull request. + +1. announce your plan to the rest of the community _before you start working_. This announcement should be done via GitHub in the form of a (new) [issue](https://github.com/EIT-ALIVE/eitprocessing/issues); +2. wait until some kind of consensus is reached about your idea being a good idea; +3. if needed, fork the repository to your own Github profile and create your own feature branch off of the latest master commit. While working on your feature branch, make sure to stay up to date with the main branch by pulling in changes, possibly from the 'upstream' repository (follow the instructions [here](https://help.github.com/articles/configuring-a-remote-for-a-fork/) and [here](https://help.github.com/articles/syncing-a-fork/)); +4. make sure the existing [tests still work](#testing-locally) by running `pytest`; +5. add your own tests (recommended); +6. update or expand the documentation; +7. push your feature branch (or fork) to the eitprocessing repository on GitHub; +8. [create a pull request](https://help.github.com/articles/creating-a-pull-request/), following our [PR conventions]() + and link it to the issue in step 1; +9. ensure that all automatically generated checks pass and update make changes as required to solve any resulting issues; + - it can be tricky to discover what some of the problems mean, feel free to reach out if you have difficulties finding out. +10. request a review of your PR once you are happy with its state or if you require feedback. -Please follow these steps: - -1. (**important**) announce your plan to the rest of the community _before you start working_. This announcement should be in the form of a (new) issue; -1. (**important**) wait until some kind of consensus is reached about your idea being a good idea; -1. if needed, fork the repository to your own Github profile and create your own feature branch off of the latest master commit. While working on your feature branch, make sure to stay up to date with the master branch by pulling in changes, possibly from the 'upstream' repository (follow the instructions [here](https://help.github.com/articles/configuring-a-remote-for-a-fork/) and [here](https://help.github.com/articles/syncing-a-fork/)); -1. make sure the existing tests still work by running `pytest` (see also [here](#testing-locally)); -1. add your own tests (if necessary); -1. update or expand the documentation; -1. update the `CHANGELOG.md` file with change; -1. push your feature branch to (your fork of) the eitprocessing repository on GitHub; -1. create the pull request, e.g. following the instructions [here](https://help.github.com/articles/creating-a-pull-request/). - -In case you feel like you've made a valuable contribution, but you don't know how to write or run tests for it, or how to generate the documentation: don't let this discourage you from making the pull request; we can help you! Just go ahead and submit the pull request, but keep in mind that you might be asked to append additional commits to your pull request. +Note that all contrubtions to this project will be published under our [Apache 2.0 licence] +(). ### Conventions @@ -31,21 +37,18 @@ readibility or simplicity is more important than absolute correctness. It is hard to define the precise balance we are looking for, so instead we will refer to the [Zen of python](https://peps.python.org/pep-0020/). -Note that all contrubtions to this project will be published under our [Apache 2.0 licence] -(). +#### Linting and formatting + +We use the [Ruff formatter](https://pypi.org/project/black/) to format code. If you use Visual +Studio Code, the [extension by +Microsoft](https://marketplace.visualstudio.com/items?itemName=ms-python.black-formatter) is a good +place to start. This extension is currently in preview, but seems to work more reliably than older implementations. #### Docstrings We use the [google convention](https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html) for writing docstrings. -#### Code formatting - -We use the [Black formatter](https://pypi.org/project/black/) to format code. If you use Visual -Studio Code, the [extension by -Microsoft](https://marketplace.visualstudio.com/items?itemName=ms-python.black-formatter) is a good -place to start. This extension is currently in preview, but seems to work more reliably than older implementations. - #### Branch naming convention Please try to adhere to the following branch naming convention: @@ -60,7 +63,7 @@ Also, it simplifies tab autocompletion when switching to your branch. Please use an [angular convention type](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type), followed by a semicolon and then a description when creating a PR. -E.g., `feat: added module to calculate the answer to life, the universe, and everything`. +E.g., `feat: added module to calculate the answer to life, the universe, and everything` ### Creating a PR diff --git a/README.md b/README.md index 098108c75..ba8855459 100644 --- a/README.md +++ b/README.md @@ -17,8 +17,6 @@ Processing of lung image data from electrical impedance tomography -The project setup is documented in [project_setup.md](project_setup.md). Feel free to remove this document (and/or the link to this document) if you don't need it. - ## Installation Install eitprocessing as follows: diff --git a/project_setup.md b/project_setup.md deleted file mode 100644 index 0b64d8a3d..000000000 --- a/project_setup.md +++ /dev/null @@ -1,107 +0,0 @@ -# Project Setup - -Here we provide some details about the project setup. Most of the choices are explained in the -[guide](https://guide.esciencecenter.nl). Links to the relevant sections are included below. Feel free to remove this -text when the development of the software package takes off. - -For a quick reference on software development, we refer to [the software guide -checklist](https://guide.esciencecenter.nl/#/best_practices/checklist). - -## Python versions - -This repository is set up with Python versions: - -- 3.10 - - -## Package management and dependencies - -You can use either pip or conda for installing dependencies and package management. This repository does not force you -to use one or the other, as project requirements differ. For advice on what to use, please check [the relevant section -of the -guide](https://guide.esciencecenter.nl/#/best_practices/language_guides/python?id=dependencies-and-package-management). - -- Runtime dependencies should be added to `setup.cfg` in the `install_requires` list under `[options]`. -- Development dependencies should be added to `setup.cfg` in one of the lists under `[options.extras_require]`. - -## Packaging/One command install - -You can distribute your code using PyPI. -[The guide](https://guide.esciencecenter.nl/#/best_practices/language_guides/python?id=building-and-packaging-code) can -help you decide which tool to use for packaging. - -## Testing and code coverage - -- Tests should be put in the `tests` folder. -- The `tests` folder contains: - - Example tests that you should replace with your own meaningful tests (file: `test_my_module.py`) -- The testing framework used is [PyTest](https://pytest.org) - - [PyTest introduction](https://pythontest.com/pytest-book/) - - PyTest is listed as a development dependency - - This is configured in `setup.cfg` -- The project uses [GitHub action workflows](https://docs.github.com/en/actions) to automatically run tests on GitHub infrastructure against multiple Python versions - - Workflows can be found in [`.github/workflows`](.github/workflows/) -- [Relevant section in the guide](https://guide.esciencecenter.nl/#/best_practices/language_guides/python?id=testing) - -## Documentation - -- Documentation should be put in the [`docs/`](docs/) directory. The contents have been generated using `sphinx-quickstart` (Sphinx version 1.6.5). -- We recommend writing the documentation using Restructured Text (reST) and Google style docstrings. - - [Restructured Text (reST) and Sphinx CheatSheet](https://thomas-cokelaer.info/tutorials/sphinx/rest_syntax.html) - - [Google style docstring examples](http://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html). -- The documentation is set up with the ReadTheDocs Sphinx theme. - - Check out its [configuration options](https://sphinx-rtd-theme.readthedocs.io/en/latest/). -- [AutoAPI](https://sphinx-autoapi.readthedocs.io/) is used to generate documentation for the package Python objects. -- `.readthedocs.yaml` is the ReadTheDocs configuration file. When ReadTheDocs is building the documentation this package and its development dependencies are installed so the API reference can be rendered. -- [Relevant section in the guide](https://guide.esciencecenter.nl/#/best_practices/language_guides/python?id=writingdocumentation) - -## Coding style conventions and code quality - -- [Relevant section in the NLeSC guide](https://guide.esciencecenter.nl/#/best_practices/language_guides/python?id=coding-style-conventions) and [README.dev.md](README.dev.md). - -## Continuous code quality - -We check code quality by hand, and continously upgrade as time allows. - -## Package version number - -- We recommend using [semantic versioning](https://guide.esciencecenter.nl/#/best_practices/releases?id=semantic-versioning). -- For convenience, the package version is stored in a single place: `eitprocessing/.bumpversion.cfg`. -- Don't forget to update the version number before [making a release](https://guide.esciencecenter.nl/#/best_practices/releases)! - -## Logging - -- We recommend using the logging module for getting useful information from your module (instead of using print). -- The project is set up with a logging example. -- [Relevant section in the guide](https://guide.esciencecenter.nl/#/best_practices/language_guides/python?id=logging) - -## CHANGELOG.md - -- Document changes to your software package -- [Relevant section in the guide](https://guide.esciencecenter.nl/#/best_practices/releases?id=changelogmd) - -## CITATION.cff - -- To allow others to cite your software, add a `CITATION.cff` file -- It only makes sense to do this once there is something to cite (e.g., a software release with a DOI). -- Follow the [making software citable](https://guide.esciencecenter.nl/#/citable_software/making_software_citable) section in the guide. - -## CODE_OF_CONDUCT.md - -- Information about how to behave professionally -- [Relevant section in the guide](https://guide.esciencecenter.nl/#/best_practices/documentation?id=code-of-conduct) - -## CONTRIBUTING.md - -- Information about how to contribute to this software package -- [Relevant section in the guide](https://guide.esciencecenter.nl/#/best_practices/documentation?id=contribution-guidelines) - -## MANIFEST.in - -- List non-Python files that should be included in a source distribution -- [Relevant section in the guide](https://guide.esciencecenter.nl/#/best_practices/language_guides/python?id=building-and-packaging-code) - -## NOTICE - -- List of attributions of this project and Apache-license dependencies -- [Relevant section in the guide](https://guide.esciencecenter.nl/#/best_practices/licensing?id=notice)