CopperlineOS .github

Organization-wide community health files, reusable CI workflows, and templates.
This repository provides shared guidance and automation for all repos in the CopperlineOS org. If you’re contributing to any CopperlineOS project, start here.

TL;DR: Issues/PR templates, CONTRIBUTING, SECURITY, CODEOWNERS, and reusable GitHub Actions so every repo feels consistent.

---

What's in this repo

.github/
├─ CODE_OF_CONDUCT.md        # Contributor Covenant (org-wide)
├─ CONTRIBUTING.md           # How to contribute, style, PR process
├─ SECURITY.md               # Reporting vulnerabilities
├─ ISSUE_TEMPLATE/
│  ├─ bug_report.yml
│  ├─ feature_request.yml
│  └─ rfc.yml                # Proposal template (links to rfcs repo)
├─ PULL_REQUEST_TEMPLATE.md  # PR checklist (tests, docs, changelog)
├─ workflows/
│  ├─ rust-ci.yml            # Reusable Rust CI (fmt, clippy, test)
│  ├─ website-ci.yml         # Reusable website build
│  ├─ docs-link-check.yml    # Markdown/links/mermaid checks
│  └─ release-draft.yml      # Tag + release notes helper
├─ LABELS.md                 # Label taxonomy
└─ README.md                 # You are here

GitHub automatically applies community health files from this repo to all repos in the org (unless overridden).

---

How to use the reusable CI workflows

Reference these in a repository’s workflow using uses:. Example Rust CI:

name: CI
on:
  push: { branches: [ main ] }
  pull_request:
jobs:
  rust-ci:
    uses: CopperlineOS/.github/.github/workflows/rust-ci.yml@main
    with:
      rust-version: stable

Other reusable workflows:

• website-ci.yml – build the Docusaurus site (used by website).
• docs-link-check.yml – lint Markdown, check links/anchors.
• release-draft.yml – generate release notes from PR titles/labels.

---

Contribution process (short version)

1. Discuss first — open an issue or RFC (for protocol/architecture changes).
2. Fork & branch — small, focused PRs with clear titles.
3. Tests — required where practical (unit/integration).
4. Docs — update docs/ or repo README when behavior changes.
5. Reviews — at least one maintainer approval; CI must pass.
6. Merging — squash-merge by default; keep commit messages meaningful.

See CONTRIBUTING.md for deeper details (coding style, commit conventions, PR checklist).

---

Versioning & stability

• SemVer for libraries and tools.
• Protocol versions are explicit (e.g., ports/v0). Breaking changes require an RFC and a version bump.
• Many components will be 0.x until protocols stabilize; breaking changes can still occur with care.

---

Labels

We use a small, predictable label set across repos (see LABELS.md):

• type: bug · feature · refactor · docs · chore
• status: help wanted · good first issue · blocked · needs design
• area: compositor · copper · blitter · audio · sdk · tools · docs
• priority: P0 · P1 · P2

Maintainers may add repo-specific labels if needed; prefer reuse first.

---

Security

See SECURITY.md. In short:

• Please report vulnerabilities privately to security@copperline.os (placeholder) or via GitHub Security Advisories.
• Don’t open public issues for potential vulnerabilities.
• We aim for responsible disclosure and prompt fixes.

---

Code of Conduct

We follow the Contributor Covenant. Be kind, be constructive, and assume good intent. See CODE_OF_CONDUCT.md.

---

Governance & maintainers

• Day-to-day decisions are made by repo maintainers (listed in CODEOWNERS within each repo).
• Cross-cutting decisions (protocols, security, architecture) go through the RFC process in CopperlineOS/rfcs.
• Maintainers group: @CopperlineOS/maintainers (pending setup).

---

Getting help

• Open an issue in the most relevant repo.
• For general questions, use the discussions tab (where enabled) or the website repo’s discussions.
• For security-sensitive topics, use the security contact above.

---

See also

• Docs: CopperlineOS/docs
• RFCs: CopperlineOS/rfcs
• Website: CopperlineOS/website
• Core services: copperd · compositord · blitterd · audiomixerd
• SDKs & tools: sdk-rs · sdk-c · tools