Skip to content

Latest commit

 

History

History
142 lines (95 loc) · 4.94 KB

CONTRIBUTING.md

File metadata and controls

142 lines (95 loc) · 4.94 KB

Contributing

Contributions are welcome and will be fully credited.

Please read and understand the contribution guide before creating an issue or pull request.

Etiquette

This project is open source, and as such, the maintainers give their free time to build and maintain the source code held within. They make the code freely available in the hope that it will be of use to other developers. It would be extremely unfair for them to suffer abuse or anger for their hard work.

Please be considerate towards maintainers when raising issues or presenting pull requests. Let's show the world that developers are civilized and selfless people.

It's the duty of the maintainer to ensure that all submissions to the project are of sufficient quality to benefit the project. Many developers have different skillsets, strengths, and weaknesses. Respect the maintainer's decision, and do not be upset or abusive if your submission is not used.

Viability

When requesting or submitting new features, first consider whether it might be useful to others. Open source projects are used by many developers, who may have entirely different needs to your own. Think about whether or not your feature is likely to be used by other users of the project.

Procedure

Before filing an issue:

  • Attempt to replicate the problem, to ensure that it wasn't a coincidental incident.
  • Check to make sure your feature suggestion isn't already present within the project.
  • Check the pull requests tab to ensure that the bug doesn't have a fix in progress.
  • Check the pull requests tab to ensure that the feature isn't already in progress.

Before submitting a pull request:

  • Check the codebase to ensure that your feature doesn't already exist.
  • Check the pull requests to ensure that another person hasn't already submitted the feature or fix.

Requirements

If the project maintainer has any additional requirements, you will find them listed here.

  • PEP 8 Style Guide - Follow Python's official style guide. You can use tools like black, flake8, or ruff to ensure code quality.

  • Type hints - Use type hints for all function signatures and important variables. Run mypy to check type correctness.

  • Add tests! - Your patch won't be accepted if it doesn't have tests. We use pytest for testing.

  • Document any change in behaviour - Make sure the README.md and any other relevant documentation are kept up-to-date.

  • Consider our release cycle - We try to follow SemVer v2.0.0. Randomly breaking public APIs is not an option.

  • One pull request per feature - If you want to do more than one thing, send multiple pull requests.

  • Send coherent history - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please squash them before submitting.

Development Setup

  1. Clone the repository:

    git clone https://github.com/Wilfried-Tech/notchpay-python.git
cd notchpay-python

  2. Install dependencies using uv (recommended):

    uv sync

    Or using pip:

    pip install -e ".[dev]"

  3. Run tests:

    uv run pytest

  4. Run tests with coverage:

    uv run pytest --cov=src/notchpay --cov-report=html

  5. Run type checking:

    uv run mypy src/notchpay

  6. Format your code (optional but recommended):

    uv run black src/notchpay tests

Testing Guidelines

  • Write tests for both synchronous and asynchronous versions of your code
  • Ensure test coverage remains above 80%
  • Mock external API calls using pytest fixtures
  • Test edge cases and error scenarios
  • Follow the existing test structure in the tests/ directory

Code Style

  • Use meaningful variable and function names
  • Keep functions small and focused on a single task
  • Add docstrings to all public functions and classes
  • Use type hints for all function parameters and return values
  • Follow the existing code structure and patterns

Pull Request Process

  1. Fork the repository
  2. Create a new branch from master: git checkout -b feature/amazing-feature
  3. Make your changes
  4. Add tests for your changes
  5. Run the test suite and ensure all tests pass
  6. Run type checking with mypy
  7. Update documentation if needed
  8. Commit your changes: git commit -m 'Add some amazing feature'
  9. Push to your fork: git push origin feature/amazing-feature
  10. Open a Pull Request against the master branch

Reporting Issues

When reporting issues, please include:

  • Python version
  • Operating system
  • Steps to reproduce the issue
  • Expected behavior
  • Actual behavior
  • Any relevant error messages or stack traces

Happy coding!