When this skill is activated, always start your first response with the 🧢 emoji.

Open Source Management

Open source management is the discipline of running a healthy, sustainable open source project. It covers everything beyond writing code - governance structures, contribution workflows, licensing decisions, community building, release management, and long-term project health. This skill gives an agent the knowledge to help maintainers set up and run OSS projects that attract contributors, minimize maintainer burnout, and follow widely accepted industry standards.

When to use this skill

Trigger this skill when the user:

• Wants to set up a new open source project with proper governance files
• Needs help writing or improving CONTRIBUTING.md, CODE_OF_CONDUCT.md, or issue templates
• Asks about choosing an open source license (MIT, Apache 2.0, GPL, etc.)
• Wants to write or automate changelogs and release notes
• Needs help with semantic versioning decisions
• Asks about managing contributors, reviewing PRs, or triaging issues
• Wants to build or grow an open source community
• Needs a governance model (BDFL, meritocratic, foundation-backed)

Do NOT trigger this skill for:

• Writing application code or fixing bugs (use language-specific or clean-code skills)
• Internal/proprietary project management (use operations or product skills instead)

Key principles

1. Lower the barrier to contribute - Every friction point in the contribution process costs you potential contributors. Clear docs, good first issues, fast PR reviews, and automated checks all reduce friction. The easier it is to contribute, the more people will.

2. Document decisions, not just code - Governance, versioning policy, release cadence, and architectural decisions should be written down. Undocumented tribal knowledge is the fastest path to a project that only one person can maintain.

3. Automate the boring parts - Use CI/CD for tests, linting, changelog generation, release publishing, and CLA checks. Maintainer time is the scarcest resource in any OSS project - spend it on design decisions and community, not repetitive tasks.

4. Be explicit about expectations - Contributors need to know response time expectations, code style requirements, and the process for proposing changes. Maintainers need to set boundaries on their own availability to avoid burnout.

5. License deliberately - Your license choice determines how your project can be used, forked, and commercialized. Choose early, understand the implications, and never change licenses without careful legal and community consideration.

Core concepts

Project health files form the foundation of any OSS project. At minimum, a project needs: README.md (what and why), LICENSE (legal terms), CONTRIBUTING.md (how to help), and CODE_OF_CONDUCT.md (behavioral expectations). GitHub recognizes these files and surfaces them in the community profile.

Governance defines who makes decisions and how. The three dominant models are: BDFL (Benevolent Dictator for Life - one person has final say, e.g. early Python), meritocratic (commit rights earned through sustained contribution, e.g. Apache projects), and foundation-backed (a legal entity stewards the project, e.g. Linux Foundation, CNCF). Most small projects start as BDFL and evolve as they grow.

Semantic versioning (SemVer) communicates change impact through version numbers: MAJOR.MINOR.PATCH. MAJOR means breaking changes, MINOR means new features (backward compatible), PATCH means bug fixes. Pre-release versions use suffixes like -alpha.1 or -rc.1. See references/semver-releases.md.

Contributor lifecycle runs from first contact to core maintainer: user -> reporter -> contributor -> committer -> maintainer. Each stage needs clear documentation on expectations and privileges. See references/community-building.md.

Common tasks

Set up a new open source project

Create these files in the repository root:

1. LICENSE - Choose a license (see "Choose a license" task below)
2. README.md - Project name, description, install, usage, contributing link, license badge
3. CONTRIBUTING.md - Development setup, coding standards, PR process, issue guidelines
4. CODE_OF_CONDUCT.md - Adopt Contributor Covenant v2.1 (industry standard)
5. SECURITY.md - How to report vulnerabilities (never via public issues)
6. .github/ISSUE_TEMPLATE/ - Bug report and feature request templates
7. .github/PULL_REQUEST_TEMPLATE.md - PR checklist with description, testing, and breaking change sections

Always include a DCO (Developer Certificate of Origin) or CLA (Contributor License Agreement) requirement for projects that may have IP concerns.

Choose a license

Use this decision framework:

See references/licensing-guide.md for detailed comparison and edge cases.

Write a changelog

Follow the Keep a Changelog format (keepachangelog.com):

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added
- New feature X for doing Y

### Changed
- Updated dependency Z to v2.0

### Fixed
- Bug where A caused B (#123)

## [1.2.0] - 2025-03-01

### Added
- Initial support for feature W

Group changes under: Added, Changed, Deprecated, Removed, Fixed, Security. Never mix user-facing changes with internal refactors in the same entry.

Triage issues effectively

Apply labels and prioritize using this workflow:

1. Acknowledge within 48 hours - even a "thanks, we'll look at this" reduces contributor frustration
2. Label by type (bug, feature, question, documentation) and priority (critical, high, medium, low)
3. Tag good first issues - look for self-contained tasks with clear scope and mark them good first issue
4. Close stale issues politely after 90 days of inactivity with a bot (use actions/stale)
5. Link duplicates rather than just closing them - the reporter's wording may help future searchers

Manage releases

Follow this release checklist:

1. Decide the version bump using SemVer rules (see references/semver-releases.md)
2. Update CHANGELOG.md - move Unreleased items under the new version heading
3. Update version in package.json / pyproject.toml / Cargo.toml / etc.
4. Create a git tag: git tag -a v1.2.0 -m "Release v1.2.0"
5. Push tag: git push origin v1.2.0
6. CI publishes to package registry (npm, PyPI, crates.io, etc.)
7. Create GitHub Release from the tag with changelog content as body
8. Announce on community channels (Discord, Twitter, blog)

Automate steps 2-7 with tools like release-please, semantic-release, or changesets to eliminate human error.

Write a CONTRIBUTING.md

A good CONTRIBUTING.md covers these sections in order:

# Contributing to [Project Name]

Thank you for your interest in contributing!

## Code of Conduct

This project follows the [Contributor Covenant](CODE_OF_CONDUCT.md).

## How to Contribute

### Reporting Bugs
- Search existing issues first
- Use the bug report template
- Include reproduction steps, expected vs actual behavior, environment details

### Suggesting Features
- Open a discussion or feature request issue
- Explain the problem you're solving, not just the solution you wa