Skip to content

Contributing Guide

Summary: Thank you for your interest in contributing to our project! This guide outlines our contribution process, coding standards, and how to get your changes merged.

How to Contribute

We welcome contributions of all kinds, from bug fixes to new features, documentation, and improvements to STRIDE's tagging model or workflows. To get started, please follow these steps:

  1. Fork the Repository: Create your own copy of the repository on GitHub.
  2. Create a Branch: Create a new branch for your changes.
    git checkout -b feature/my-awesome-feature
  3. Make Your Changes:
    • Write your code and add tests to cover your changes.
    • If updating documentation, ensure you follow the structure and clarity standards in /docs.
    • If proposing new tag dimensions or workflows, describe your rationale in the PR description and update the relevant documentation (see Tagging Model).
  4. Ensure Tests Pass: Run the full test suite to ensure your changes don't break anything.
    pytest
  5. Commit Your Work: Follow our commit message conventions.
    git commit -m "feat: Add my awesome feature"
  6. Submit a Pull Request (PR): Push your branch to your fork and open a PR against our main branch. Provide a clear description of your changes, especially if you are updating STRIDE's tagging, workflows, or documentation.

Coding Standards

  • Style Guide: We follow the PEP 8 style guide for Python code. We use black for formatting and ruff for linting.
  • Testing: All new features must be accompanied by tests. We use pytest for our testing framework.
  • Documentation: If you add a new feature or update STRIDE's tagging model, workflows, or architecture, please update the relevant documentation in the /docs directory (especially onboarding and glossary files).

Commit Message Convention

We follow the Conventional Commits specification. This helps us automate changelog generation and makes the commit history more readable.

Format: <type>(<scope>): <subject>

  • type: feat, fix, docs, style, refactor, test, chore
  • scope: (optional) The part of the codebase you are changing (e.g., api, db, tagging, docs).
  • subject: A short, imperative-tense description of the change.

Example:
feat(tagging): add new dimension for outcome type

Pull Request Process

  1. Once a PR is submitted, a core team member will review it.
  2. You may be asked to make changes based on the feedback.
  3. If your PR updates STRIDE's tagging model, workflows, or documentation, a subject matter expert may review for consistency.
  4. Once the PR is approved and all checks pass, it will be merged into the main branch.

For a more detailed setup guide, see the Onboarding Guide.