Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
103 lines (72 loc) · 3.69 KB

CONTRIBUTING.md

File metadata and controls

103 lines (72 loc) · 3.69 KB

Contributing to OpenSIN-AI

Thank you for contributing to OpenSIN-AI. This guide explains how to contribute effectively across our organization.

Before You Start

  1. Read this guide — it covers our workflow, standards, and expectations.
  2. Check existing issues and discussions — your idea may already be tracked.
  3. Understand the system — read the OpenSIN-AI organization profile to see where your contribution fits.

How We Work

Our contribution flow follows a clear path:

  1. Discussion — ideas, questions, and direction-setting happen in Discussions.
  2. Issue — concrete work is tracked as Issues with clear scope and acceptance criteria.
  3. Branch — implementation happens on a dedicated branch.
  4. Pull Request — changes are reviewed before merging.
  5. Merge — approved changes are integrated into the main codebase.

Opening Issues

Use the appropriate issue template when available. Each template is designed to capture the right information:

  • Bug report — for broken behavior or regressions
  • Feature request — for new functionality or improvements
  • Documentation request — for missing, unclear, or outdated docs
  • Operational task — for governance, maintenance, migration, or setup work

Every issue should include:

  • Clear title
  • Concrete description
  • Expected vs actual behavior (for bugs)
  • Acceptance criteria or definition of done

Creating Pull Requests

Every PR should:

  • Explain what changed and why
  • Define clear scope (in scope / out of scope)
  • Include validation details (testing, manual checks, evidence)
  • Reference related issues
  • Be reviewable — small, focused, and coherent

PR Checklist

  • The purpose of the change is clear
  • Scope is well-defined
  • Validation is credible
  • Documentation updated if needed
  • No unrelated changes included
  • Follow-up work identified if anything was deferred

Code Standards

  • Follow existing patterns in the repository
  • Write clear, readable code
  • Keep changes focused and reviewable
  • Update documentation when behavior changes
  • Do not introduce unrelated changes

Review Process

  • Reviews are for quality, clarity, and risk — not gatekeeping
  • Feedback should be concrete, respectful, and solution-oriented
  • Reviewers should explain the "why" behind their suggestions
  • Authors should respond to feedback or explain their reasoning

Commit Messages

  • Keep messages clear and descriptive
  • Follow the repository's existing commit style
  • Each commit should represent one logical change

Getting Help

Recognition

Every contribution matters. Whether it's a bug fix, documentation improvement, feature, or operational task — it makes OpenSIN-AI stronger.

Boundary Rules

Before changing org-wide defaults, answer:

  1. Is this a reusable org default, or is it specific to one repo?
  2. Does another repo already own the canonical source of truth?

Put it in .github if:

  • it improves org-wide issue, PR, support, or community defaults
  • it applies broadly across the organization

Do NOT put it in .github if:

  • it is repo-specific runtime or product truth
  • it is official documentation body
  • it is an implementation-specific boundary that should live in a single repo

OpenSIN-AI is built by people who care about structure, execution, and real impact. Thank you for being part of it.