Skip to content

Latest commit

 

History

History
109 lines (73 loc) · 4.5 KB

File metadata and controls

109 lines (73 loc) · 4.5 KB

Contributing to DevOps-OS

Thank you for your interest in contributing to DevOps-OS! 🚀 We welcome contributions of all kinds — new features, bug fixes, documentation improvements, and more.


📋 Table of Contents


Code of Conduct

Please be respectful and constructive in all interactions. We are committed to providing a welcoming and inclusive environment for everyone.


Getting Started

  1. Fork the repository and clone your fork locally.
  2. Set up your development environment using the provided Dev Container (.devcontainer/) or install dependencies manually:
    pip install -r cli/requirements.txt -r mcp_server/requirements.txt
  3. Run the test suite to make sure everything is working before you start:
    python -m pytest cli/test_cli.py mcp_server/test_server.py tests/test_comprehensive.py -v

Development Workflow

We follow a standard, issue-driven development process for all new features and bug fixes:

1. Find or Create an Issue

  • Browse the open issues to find something you would like to work on.
  • If no issue exists for your idea, create a new issue describing the feature or bug clearly.
  • If an issue already exists, leave a comment expressing your interest in working on it (e.g., "I'd like to work on this — happy to take it if it's not already assigned.").

2. Get Assigned

  • A maintainer will review your comment and assign the issue to you, or leave a comment confirming you can self-assign.
  • Do not start significant work until the issue is assigned to avoid duplicate efforts.

3. Work on the Issue

  • Create a feature branch from main:
    git checkout -b feature/your-feature-name
  • Make your changes following the coding conventions in the project.
  • Add progress updates as comments on the issue while you work — this keeps the community informed and lets maintainers provide early feedback.
  • Write or update tests to cover your changes.
  • Ensure all existing tests continue to pass.

4. Submit a Pull Request

  • Push your branch and open a PR against main.
  • Use the PR template — fill in all required sections including a description of changes, linked issue, testing done, and checklist items.
  • Keep PRs focused: one feature or bug fix per PR.

5. Resolve Review Comments

  • A maintainer will review your PR and may leave comments or request changes.
  • Address all review comments and push the fixes to the same branch.
  • Once all review comments are resolved and the CI checks pass, a maintainer will merge the PR.

AI-Assisted Development

DevOps-OS welcomes and encourages the use of AI coding tools to accelerate development. Specifically:

  • You are free to use AI coding assistants in agent mode (e.g., GitHub Copilot Agent, Cursor, Cline, or similar tools) to help scaffold, write, and refactor code.
  • AI-assisted contributions are held to the same quality and review standards as all other contributions. You are responsible for reviewing, testing, and understanding any code generated by an AI before submitting it.
  • When using agent mode to add a new feature, ensure the agent follows the project's structure and conventions as described in this document and in the existing codebase.
  • Always run the test suite after AI-generated changes to verify correctness.

Submitting a Pull Request

When opening a PR, please:

  1. Link the related issue using Closes #<issue-number> or Fixes #<issue-number> in the PR description.
  2. Fill out the PR template completely — incomplete PRs may be closed without review.
  3. Ensure CI is passing before requesting a review.
  4. Keep the diff small and focused — large, unfocused PRs are harder to review and more likely to be rejected or delayed.

PR Review Process

  • Every PR is reviewed by at least one maintainer before merging.
  • Maintainers aim to provide initial feedback within a few business days.
  • PRs that pass review and CI checks will be merged into main by a maintainer.
  • Do not merge your own PRs unless you are a maintainer explicitly approving your own work.

Thank you for helping make DevOps-OS better! 🙏