Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
135 lines (96 loc) · 5.42 KB

CONTRIBUTING.md

File metadata and controls

135 lines (96 loc) · 5.42 KB

Contributing

We value and encourage community contributions. To get started, please follow these guidelines:

  1. Code of Conduct
  2. Issues
  3. Vulnerabilities
  4. Development
  5. Pull Requests

1. Code of Conduct

Please read and follow our Code of Conduct.

2. Issues

Engagement starts with an Issue where conversations and debates can occur around bugs and feature requests:

  • ✅ Do search for a similar or existing Issue prior to submitting a new one.
  • ❌ Do not use Issues for personal support. Use Discussions or StackOverflow instead.
  • ❌ Do not side-track or derail Issue threads. Stick to the topic, please.
  • ❌ Do not post comments using just "+1", "++" or "👍". Use Reactions instead.

👾 Bugs

A bug is an error, flaw, or fault associated with any part of the project:

  • ✅ Do search for a similar or existing Issue prior to submitting a new one.
  • ✅ Do describe the bug concisely. Avoid adding extraneous code, logs, or screenshots.
  • ✅ Do attach a minimal test or example to demonstrate the bug.

💡 Feature Requests

A feature request is an improvement or new capability associated with any part of the project:

  • ✅ Do search for a similar or existing Issue prior to submitting a new one.
  • ✅ Do provide sufficient motivation and use case(s) for the feature.
  • ❌ Do not submit multiple unrelated requests within one request.

TIP: Engage as much as possible within an Issue before proceeding with contributions.

3. Vulnerabilities

A vulnerability is a security-related risk associated with any part of the project or its dependencies:

  • ✅ Do refer to our Security Policy for more information.
  • ✅ Do report vulnerabilities via this link.
  • ❌ Do not report any Issues or mention vulnerabilities in public Discussions for discretionary purposes.

4. Development

🌱 Branches

  • develop - Default branch for all feature development and Pull Requests.
  • main - Stable branch for all periodic releases.

🔒 Dependencies

  • Python (>= 3.8)
  • pip for package management. Use pip install -r requirements/all.txt to install dependencies.
  • Optional: Set up your environment using conda, virtualenv, or another method. Refer to Python virtual environments for guidance.

📦 Project Setup

  1. Fork the repository and create a branch from develop.
  2. Clone the forked repo, checkout your branch, and install the dependencies with pip install -r requirements/all.txt.
  3. Run tests using pytest to ensure everything is working correctly.

📂 Directory Structure

When contributing, please note the following key files and directories: ├── docker │ ├── Dockerfile ├── docs │ ├── index.rst │ ├── ... ├── requirements │ ├── all.txt │ ├── ... ├── spockflow │ ├── components │ │ ├── scorecard │ │ ├── tree │ │ ├── dtable │ ├── inference │ ├── ... ├── core.py ├── exceptions.py ├── nodes.py ├── tests │ ├── test_example.py │ ├── ...

  • docker - Contains all files related to Docker images.
  • docs - Documentation files.
  • requirements - Directory containing .txt files for different optional requirements.
  • spockflow/components - Contains all components for the Hamilton DAG, including:
    • scorecard - For scorecards.
    • tree - For decision trees.
    • dtable - For decision tables.
  • spockflow/inference - Files needed to serve the module as a live endpoint.
  • core.py - Contains code to inject components into the Hamilton DAG.
  • exceptions.py - Base for exceptions produced by various components.
  • nodes.py - Core module for all components.
  • tests - Contains unit tests for the project.

🏷 Naming Conventions

  • ✅ Do follow PEP 8 for naming conventions.
  • ✅ Do use descriptive names for files and modules.
  • ✅ Do name Python classes in CamelCase and functions in snake_case.

🔍 Code Quality

  • ✅ Do adhere to PEP 8 style guidelines.
  • ✅ Do use black for automatic code formatting.

🧪 Testing

  • ✅ Do write tests using pytest.
  • ✅ Do ensure all tests pass before submitting a Pull Request.

5. Pull Requests

  • ✅ Do ensure your branch is up to date with the develop branch.
  • ✅ Do ensure there are no conflicts with the develop branch.
  • ✅ Do make sure all tests pass and code is formatted using black.
  • ✅ Do provide a clear description of the changes and the purpose of the Pull Request.

TIP: Make sure to review the existing codebase and follow the conventions used throughout the project.

Thank you for contributing! We appreciate your efforts to improve the project.