130 lines
4.2 KiB
Markdown
130 lines
4.2 KiB
Markdown
# Contributing to preprocessing
|
|
|
|
Thank you for considering contributing to `preprocessing`!
|
|
Your input helps make this package robust, reliable, and extensible for the community.
|
|
|
|
Please follow these guidelines to ensure a smooth and constructive contribution process.
|
|
|
|
## How to contribute
|
|
|
|
### 1. Clone your fork
|
|
Clone the repository from your own GitHub account to your local machine:
|
|
|
|
```bash
|
|
git clone https://gitea.iwm-tuebingen.de/AG4/preprocessing.git
|
|
cd preprocessing
|
|
```
|
|
|
|
### 2. Create a feature branch
|
|
Create a new branch for the changes you intend to make. This keeps your modifications separate from the `main` branch.
|
|
|
|
```bash
|
|
git checkout -b feature/your-feature-name
|
|
```
|
|
|
|
Please ensure that your branch name is descriptive of the changes you are making, such as `feature/calculation-of-subscales` or `bugfix/fix-data-validation`.
|
|
|
|
### 3. Make your changes
|
|
- Implement your changes in the appropriate files inside `src/`.
|
|
- Update or create tests under `tests/` as needed.
|
|
|
|
### 4. Format and lint your code
|
|
Ensure that your code is correctly formatted and adheres to project style guidelines.
|
|
This helps maintain code consistency across the repository.
|
|
|
|
Note that `black` for formatting and `ruff` for linting and the `pytest` tests should all be run via a pre-commit hook.
|
|
In order to do this, you need to set `pre-commit` up in your local repository
|
|
(it should be installed via the dev dependencies already).
|
|
|
|
To set up `pre-commit`, run the following command in your terminal:
|
|
|
|
```bash
|
|
pre-commit install
|
|
```
|
|
|
|
If you need to run it for existing code, you can do so running
|
|
|
|
```bash
|
|
pre-commit run --all-files
|
|
```
|
|
|
|
This will automatically format and lint your code according to the project's standards.
|
|
|
|
For manual checks and formatting:
|
|
|
|
Format the code using `black`:
|
|
|
|
```bash
|
|
black .
|
|
ruff check
|
|
ruff check --fix
|
|
ruff format
|
|
```
|
|
|
|
These tools are included in the [project.optional-dependencies.dev] section of pyproject.toml.
|
|
To install them for development, use:
|
|
|
|
```bash
|
|
pip install -e .[dev]
|
|
```
|
|
|
|
### 5. Run the tests
|
|
Ensure that all tests pass before submitting your changes. We use pytest for testing.
|
|
|
|
```bash
|
|
pytest
|
|
```
|
|
|
|
If any tests fail, fix the issues before proceeding.
|
|
|
|
### 6. Commit your changes
|
|
Once you are satisfied with your changes, commit them to your feature branch:
|
|
|
|
```bash
|
|
git add .
|
|
git commit -m "Add your commit message here"
|
|
```
|
|
Make sure to write a clear and concise commit message that describes the changes you made.
|
|
|
|
### 7. Push your changes
|
|
|
|
Push your changes to your branch:
|
|
|
|
```bash
|
|
git push origin feature/your-feature-name
|
|
```
|
|
|
|
### 8. Create a Pull Request (PR)
|
|
Navigate to the [main repository](https://gitea.iwm-tuebingen.de/HMC/preprocessing)
|
|
and open a pull request (PR) to the `main` branch.
|
|
The PR should describe the changes you made and why they are useful.
|
|
- Be sure to include a clear, concise description of your changes in the PR.
|
|
- If applicable, link to relevant issues in the PR description.
|
|
|
|
### 9. Review Process
|
|
|
|
After submitting your PR, a maintainer will review your changes. The review process may involve:
|
|
- Asking for changes or clarifications.
|
|
- Reviewing code style, formatting, and test coverage.
|
|
- Discussing the approach or implementation.
|
|
|
|
Once your PR is approved, it will be merged into the main branch.
|
|
|
|
## Pull Request Guidelines
|
|
- Include tests: Ensure that your changes come with appropriate test coverage.
|
|
- Follow coding standards: Follow the code style and formatting guidelines outlined in the project.
|
|
- Single feature per PR: Each PR should address a single feature or bug fix.
|
|
- Small, focused PRs: Keep your PRs small and focused to make reviewing easier.
|
|
|
|
## Reporting Bugs
|
|
If you find a bug in the software:
|
|
- [Search existing issues](https://gitea.iwm-tuebingen.de/HMC/preprocessing/issues): Before opening a new bug report, check if the issue has already been reported.
|
|
- Open a new issue: If the issue hasn't been reported yet, open a new issue with the following information:
|
|
- A clear description of the problem.
|
|
- Steps to reproduce the issue.
|
|
- Expected behavior vs. actual behavior.
|
|
- Any error messages or logs.
|
|
|
|
## License
|
|
|
|
By contributing, you agree that your contributions will be licensed under the same license as the project. |