From cd03103ffa9dc0b5ec4d550409292082eeea84ed Mon Sep 17 00:00:00 2001 From: Gilbert Sanchez Date: Tue, 21 Apr 2026 14:45:45 -0700 Subject: [PATCH 1/2] feat: add org profile landing page profile/README.md: tool roster (Plaster, PSDepend) with status badges, adopt-your-tool CTA linking to the adoption request template, help-wanted CTA linking to good-first-issues and help-wanted across the org, links to governance and CoC. --- profile/README.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 profile/README.md diff --git a/profile/README.md b/profile/README.md new file mode 100644 index 0000000..dbb5532 --- /dev/null +++ b/profile/README.md @@ -0,0 +1,32 @@ +# PowerShellOrg + +PowerShellOrg is a community-run GitHub organization that adopts and maintains open-source PowerShell tools that would otherwise go unmaintained. + +## Maintained tools + +| Module | Description | Status | +|---|---|---| +| [Plaster](https://github.com/PowerShellOrg/Plaster) | Template-based scaffolding engine for PowerShell projects and modules | ![Active](https://img.shields.io/badge/status-active-brightgreen) | +| [PSDepend](https://github.com/PowerShellOrg/PSDepend) | Dependency management for PowerShell scripts and modules | ![Active](https://img.shields.io/badge/status-active-brightgreen) | + +## Want us to adopt your tool? + +If you maintain (or used to maintain) a PowerShell tool that needs a new home, we want to hear from you. + +Read the [adoption criteria](https://github.com/PowerShellOrg/.github/blob/main/docs/adoption-criteria.md) first, then open an **[Adoption Request](https://github.com/PowerShellOrg/.github/issues/new?template=tool_adoption_request.yml)**. + +We respond to all requests within 7 days and make a decision within 30. + +## Want to help? + +Every project in this org accepts contributions. A good place to start: + +- **[Good first issues across the org](https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3APowerShellOrg+label%3A%22good+first+issue%22)** — smaller, well-scoped tasks +- **[Help wanted across the org](https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3APowerShellOrg+label%3A%22help+wanted%22)** — tasks where we've explicitly asked for a PR + +See [CONTRIBUTING.md](https://github.com/PowerShellOrg/.github/blob/main/.github/CONTRIBUTING.md) for how we work. + +## Governance and community + +- [Governance model](https://github.com/PowerShellOrg/.github/blob/main/.github/GOVERNANCE.md) — how decisions get made, roles, maintainer lifecycle +- [Code of Conduct](https://github.com/PowerShellOrg/.github/blob/main/.github/CODE_OF_CONDUCT.md) — how we treat each other From de5ceec81ee303179dd657609419bc28878256b2 Mon Sep 17 00:00:00 2001 From: Gilbert Sanchez Date: Tue, 21 Apr 2026 14:41:55 -0700 Subject: [PATCH 2/2] docs: add maintainer onboarding, revival playbook, and adoption criteria MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit maintainer-onboarding.md: day-1 access checklist, branch protection verification, PSGallery key issuance process (naming convention PowerShellOrg--), CI bootstrap, communication norms. revival-playbook.md: five-phase checklist — Phase 0 (inventory/transfer), Phase 1 (issue triage with comment templates), Phase 2 (PR triage with decision tree), Phase 3 (build modernization a–g), Phase 4 (first release gate), Phase 5 (ongoing cadence and graduation path). adoption-criteria.md: six must-be-true criteria, six org commitments, four submitter commitments, workflow with 7d ack / 30d decision. --- docs/adoption-criteria.md | 116 ++++++++++++++ docs/maintainer-onboarding.md | 137 +++++++++++++++++ docs/revival-playbook.md | 279 ++++++++++++++++++++++++++++++++++ 3 files changed, 532 insertions(+) create mode 100644 docs/adoption-criteria.md create mode 100644 docs/maintainer-onboarding.md create mode 100644 docs/revival-playbook.md diff --git a/docs/adoption-criteria.md b/docs/adoption-criteria.md new file mode 100644 index 0000000..a75ae81 --- /dev/null +++ b/docs/adoption-criteria.md @@ -0,0 +1,116 @@ +# Adoption Criteria + +This document describes how PowerShellOrg evaluates tools for adoption, what we commit to when we adopt something, and what the submitter commits to. + +Read this before submitting a [Tool Adoption Request](https://github.com/PowerShellOrg/.github/issues/new?template=tool_adoption_request.yml). + +--- + +## Must-be-true criteria + +All six of the following must be true before we will adopt a tool. These are not negotiable. + +### 1. Open-source license + +The tool must have an OSI-approved open-source license in place before or at the time of transfer. We strongly prefer MIT or Apache 2.0, which are compatible with the rest of the org's tooling and license stack. + +Tools with no license, or with proprietary or source-available licenses, are ineligible. If the original author is willing to relicense to MIT, that resolves the issue — we can help coordinate. + +### 2. Author consent or demonstrated abandonment + +We do not take over maintained projects without permission. + +- **If the original author is reachable and active:** We require explicit written consent (a GitHub comment, email, or issue) from the author or all current maintainers. This protects them and protects us. +- **If the project appears abandoned:** We require documented evidence that we made a reasonable good-faith effort to reach the author (GitHub @-mention, issue opened, email to the address in the git log or package metadata) and received no response after at least 30 days. + +When in doubt, we wait. Burning bridges with the original author is not worth any single tool. + +### 3. Real user base + +The tool must have evidence of real-world use: PSGallery downloads, GitHub stars/forks, dependent projects, forum mentions, or other signals that someone besides the submitter relies on it. + +We will not adopt a tool that has no users outside its author, because there would be no one to maintain it for. + +### 4. Manageable scope + +The tool's maintenance burden must be sustainable given the org's current maintainer pool. We consider: + +- Lines of code and architectural complexity +- Test coverage and CI state (a tool with no tests requires significant upfront investment) +- Open issue and PR backlog +- Dependency footprint + +We will not adopt a tool if doing so would overextend our maintainers. We would rather maintain a smaller number of tools well than a large number poorly. + +### 5. No unaddressed security issues + +We will not inherit a tool with known, unaddressed security vulnerabilities. Before adoption, the submitter must either: + +- Confirm there are no known security issues, or +- Document all known issues and commit to addressing them in the first release cycle + +This is not about perfection — it is about not knowingly shipping something unsafe to our users. + +### 6. No legal encumbrance + +The tool must not carry legal risks that would expose PowerShellOrg or its maintainers. Examples of disqualifying encumbrances: + +- Copyright claims from a third party +- Code copied from a non-compatible license without attribution +- Trademark issues +- Export control restrictions + +--- + +## What PowerShellOrg commits to + +When we adopt a tool, we commit to: + +1. **Maintaining it actively** — responding to issues within our SLA, reviewing PRs, and cutting releases when there are meaningful changes +2. **Not abandoning it silently** — if we decide we cannot maintain a tool, we will announce it publicly and give the community 90 days to find alternative stewardship before archiving +3. **Keeping it open source** — the tool will remain under its existing OSI license (or a compatible one with explicit permission) +4. **Not breaking the API or CLI interface without a major version bump** — we respect existing users' scripts and pipelines +5. **Giving credit** — the original author's contributions remain in git history and are acknowledged in the CHANGELOG and package metadata +6. **Handling security responsibly** — following our published security policy for vulnerability disclosure and response + +--- + +## What the submitter commits to + +Adoption requests that do not include a maintainer commitment are evaluated more skeptically. A tool with no one willing to maintain it is a higher-risk adoption. + +If you are submitting a request and are willing to maintain the tool: + +1. **Minimum 6 months of active maintenance** — you will triage issues, review PRs, and be reachable for at least 6 months after adoption +2. **On-boarding and knowledge transfer** — you will work with the PowerShellOrg maintainer team to document the tool's internals, known issues, and quirks before stepping back +3. **Good-faith participation** — you will engage with the community, respond to review comments, and follow PowerShellOrg's contribution norms +4. **Transparency about limitations** — if you know the tool has problems, you will document them upfront rather than letting us discover them post-adoption + +We understand life happens. If you need to step back before the 6 months are up, tell us early — we will work with you. + +--- + +## The adoption workflow + +| Step | Owner | Timeline | +|---|---|---| +| Submitter files a Tool Adoption Request | Submitter | — | +| Steward acknowledges the request and assigns it to the Council | Steward | 7 days | +| Council members review and comment | Council | 30 days | +| Steward makes a decision (adopt / decline / defer) | Steward | 30 days from submission | +| If adopted: repo transfer initiated, onboarding begins | Steward + submitter | Week of decision | +| Repo moves to `status-incoming`, Revival Playbook begins | Lead maintainer | Immediately after transfer | + +### What "declined" means + +A declined adoption request is not a judgment on the tool's quality or the submitter's intentions. Common reasons for declining: + +- The tool does not meet one of the must-be-true criteria +- Our current maintainer pool cannot take it on right now +- A better maintainer or org has already stepped up + +We will always explain the reason. Declined requests may be resubmitted when circumstances change. + +### What "deferred" means + +A deferred request means we are interested but there is a blocker we need to resolve first — usually the license, the author consent, or maintainer capacity. We will set a follow-up date and reopen the discussion then. diff --git a/docs/maintainer-onboarding.md b/docs/maintainer-onboarding.md new file mode 100644 index 0000000..4cb3d8c --- /dev/null +++ b/docs/maintainer-onboarding.md @@ -0,0 +1,137 @@ +# Maintainer Onboarding + +Welcome to PowerShellOrg. This checklist walks you through everything you need to be fully operational on day one and productive in the first week. + +--- + +## Day 1: Access and accounts + +### GitHub org access + +- [ ] Accept the org invite from the Steward (check your GitHub notifications and email) +- [ ] Verify you have **Write** access to your assigned repo(s) — navigate to the repo → **Settings** → **Collaborators and teams** +- [ ] Enable **two-factor authentication** on your GitHub account if not already enabled — this is a hard requirement for org membership ([docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication)) + +### Council channel + +- [ ] Introduce yourself in the Council channel: `` +- [ ] Note your timezone and typical availability (helps set realistic review expectations) + +### PSGallery account + +- [ ] Confirm you have a [PowerShell Gallery](https://www.powershellgallery.com/) account +- [ ] Share your PSGallery username with the Steward — you will need it for the API key issuance step below + +--- + +## Day 1: Repo familiarization + +- [ ] Clone the repo locally +- [ ] Read the repo's `README.md` and any existing `CONTRIBUTING.md` +- [ ] Read `CHANGELOG.md` to understand recent history +- [ ] Read open issues and PRs — look for anything labeled `needs-triage` or with recent activity + +--- + +## Day 1: Branch protection verification + +Verify the repo's default branch has the following protections enabled. Navigate to the repo → **Settings** → **Branches** → branch protection rule for `main`. + +- [ ] **Require a pull request before merging** — enabled +- [ ] **Require approvals** — at least 1 required reviewer +- [ ] **Dismiss stale pull request approvals when new commits are pushed** — enabled +- [ ] **Require status checks to pass before merging** — enabled; the CI workflow must be listed +- [ ] **Require branches to be up to date before merging** — enabled +- [ ] **Require linear history** — enabled +- [ ] **Do not allow force pushes** — enabled +- [ ] **Do not allow deletions** — enabled + +If any of these are missing, notify the Steward before merging anything. + +--- + +## Day 1: PSGallery API key + +PowerShellOrg uses **per-repo scoped API keys** for PSGallery. You do not get an org-wide key. + +### Key issuance process (Steward action) + +The Steward creates the key with these parameters: + +| Parameter | Value | +|---|---| +| Key name | `PowerShellOrg--` (e.g., `PowerShellOrg-PSDepend-2025-11`) | +| Glob pattern | The module name exactly (e.g., `PSDepend`) | +| Expiration | 365 days (the PSGallery maximum) | + +The Steward then: +1. Creates or updates the `PSGALLERY_API_KEY` Actions secret in the repo +2. Adds a rotation reminder to the private key tracking issue (pinned to this repo) +3. Notifies the maintainer that the key is in place + +### Maintainer steps + +- [ ] Confirm with the Steward that `PSGALLERY_API_KEY` is set in the repo's Actions secrets (**Settings** → **Secrets and variables** → **Actions**) +- [ ] Note the key expiration month — the Steward will initiate rotation, but you may be asked to trigger it + +### Key rotation + +Keys expire after 365 days. The Steward tracks rotation in a private pinned issue. When rotation is due: +1. Steward creates a new key on PSGallery with the same glob, new `YYYY-MM` suffix in the name +2. Steward updates the `PSGALLERY_API_KEY` secret in the repo +3. Old key is deleted from PSGallery +4. Tracking issue is updated + +--- + +## Day 1: CI bootstrap + +- [ ] Install the standard build stack locally: + + ```powershell + Install-Module psake -Scope CurrentUser -Force + Install-Module PowerShellBuild -Scope CurrentUser -Force + Install-Module PSScriptAnalyzer -Scope CurrentUser -Force + Install-Module Pester -Scope CurrentUser -Force -MinimumVersion '5.0' -MaximumVersion '5.99' + ``` + +- [ ] Run `Invoke-psake ?` in the repo root — confirm the standard tasks are listed (Init, Clean, Build, Test, Analyze, Publish) +- [ ] Run `Invoke-psake Test` — confirm all tests pass +- [ ] Run `Invoke-psake Analyze` — confirm no PSScriptAnalyzer warnings +- [ ] Navigate to the repo's **Actions** tab and confirm the CI workflow is running and green on `main` + +If the CI workflow is not present or not green, see the [Revival Playbook](revival-playbook.md) Phase 3 for modernization steps. + +--- + +## First week: Communication norms + +### Issue and PR triage + +| Repo status | First-response target | +|---|---| +| `status-active` | 7 days | +| `status-stable` | 30 days | + +First response means: a label applied, a comment acknowledging the issue, or a review comment on the PR — not necessarily a resolution. + +Set up GitHub notifications for your repo: **Watch** → **All activity**, or at minimum **Issues** and **Pull requests**. + +### Code review + +- Aim to complete (not just start) reviews within 30 days of assignment +- Use GitHub's "Request changes" only when a change is genuinely blocking — a comment thread is sufficient for most feedback +- When merging, prefer **Squash and merge** for single-commit PRs and **Merge commit** for multi-commit work where history is meaningful. Avoid **Rebase and merge** unless the branch is perfectly clean — it rewrites history and removes the merge traceability. + +### Releases + +- Announce releases in the Council channel when they go out +- Tag the release commit with `vX.Y.Z` — this triggers the release workflow +- The GitHub Release notes are auto-generated; add a brief human summary at the top if the automated notes are too sparse + +### Escalation + +- Blocked by a technical question? Post in the Council channel — another maintainer may know the answer. +- Blocked by a process question? Ask the Steward. +- Seeing behavior that might violate the Code of Conduct? Report to `conduct@powershellorg.example` or message the Steward directly. +- Need to step down or take a break? Tell the Steward as early as possible — we would rather hand off gracefully than have a repo go dark unexpectedly. diff --git a/docs/revival-playbook.md b/docs/revival-playbook.md new file mode 100644 index 0000000..74a157f --- /dev/null +++ b/docs/revival-playbook.md @@ -0,0 +1,279 @@ +# Revival Playbook + +This playbook describes how to bring an adopted tool from freshly transferred (`status-incoming`) to actively maintained (`status-active`). It is organized into five phases with explicit checklists. + +The phases overlap. Do not wait for Phase 1 to be fully complete before starting Phase 2. The timelines are guidelines; pace to the actual state of the repo. + +--- + +## Phase 0: Take inventory (week 1) + +Everything in this phase happens before or immediately after the repo transfer. It is primarily Steward and lead maintainer work. + +### Transfer and access + +- [ ] Repo transferred to `github.com/PowerShellOrg` +- [ ] Repo topic `status-incoming` applied +- [ ] Lead maintainer(s) added to the repo with **Write** access +- [ ] Branch protection rules verified (see [maintainer-onboarding.md](maintainer-onboarding.md)) +- [ ] Default branch confirmed as `main` (rename from `master` if needed) + +### PSGallery setup + +- [ ] PSGallery package ownership transferred to the PowerShellOrg PSGallery account (or new package created if publishing fresh) +- [ ] Scoped API key created by Steward: `PowerShellOrg--`, glob = module name, 365-day expiry +- [ ] `PSGALLERY_API_KEY` Actions secret set in the repo +- [ ] Rotation reminder added to the Steward's private tracking issue + +### Baseline metrics (capture before making changes) + +- [ ] Last commit date recorded +- [ ] Last PSGallery release date and version recorded +- [ ] Open issue count recorded +- [ ] Open PR count recorded +- [ ] GitHub Stars / Forks recorded +- [ ] PSGallery download count recorded +- [ ] Existing CI status noted (passing / failing / none) + +These numbers are the baseline for the first release announcement and are useful for gauging improvement. + +--- + +## Phase 1: Issue triage (weeks 1–4) + +Goal: every open issue is labeled, acknowledged, and either closed or has a clear next step. + +### Label framework + +Apply the org standard label set if it is not already present. Minimum required labels: + +| Label | Purpose | +|---|---| +| `bug` | Confirmed incorrect behavior | +| `enhancement` | Feature request or improvement | +| `needs-triage` | Newly opened; not yet evaluated | +| `needs-info` | Waiting on reporter for more detail | +| `wontfix` | Valid but outside scope or priority | +| `duplicate` | Duplicate of another issue | +| `good first issue` | Suitable for a new contributor | +| `help wanted` | Maintainer welcomes a PR | +| `question` | How-to or usage question | +| `adoption-request` | Tool adoption request (org-level only) | + +### Triage process + +For each open issue: + +- [ ] Read the issue and reproduce if a bug report +- [ ] Apply a primary label (`bug`, `enhancement`, `question`, `wontfix`, etc.) +- [ ] Remove `needs-triage` once evaluated +- [ ] Post a comment if action is needed from the reporter + +#### Comment templates + +**Needs more info:** +``` +Thanks for the report. To help us investigate, could you provide: +- [ ] PowerShell version (`$PSVersionTable`) +- [ ] Module version (`(Get-Module ModuleName).Version`) +- [ ] Minimal reproduction script +- [ ] Full error output + +We'll hold this open for 30 days. If we don't hear back, we'll close it — feel free to reopen if you have the info later. +``` + +**Closing as won't fix:** +``` +Thank you for taking the time to file this. After review, we've decided not to implement this because [reason]. + +If you'd like to discuss further, please open a GitHub Discussion. We're happy to reconsider if the use case evolves. +``` + +**Closing stale issue (pre-adoption backlog):** +``` +This issue was open before PowerShellOrg adopted this module. We're doing a triage pass to start fresh. + +If this is still relevant and reproducible on the latest version, please reopen with a current repro. Thanks for your patience during the transition. +``` + +### Phase 1 exit criteria + +- [ ] All open issues have at least one label +- [ ] `needs-triage` label is empty +- [ ] Issues older than 2 years with no recent activity are closed with the stale comment above + +--- + +## Phase 2: PR triage (weeks 1–4, parallel with Phase 1) + +Goal: no PR sits without a decision. Move every open PR to one of: merged, closed, or actively under review. + +### Decision tree + +For each open PR: + +1. **Does it still apply cleanly?** If not, ask the author to rebase. If no response in 14 days, close with note. +2. **Is it in scope?** If not, close with explanation. +3. **Does it have tests?** If adding behavior without tests, request them. +4. **Can you merge it as-is?** Merge it. +5. **Can you merge it with minor changes?** Request changes or take over the branch. +6. **Is the author unresponsive?** Close with a note explaining they can reopen when available. + +#### Comment template — taking over a PR: +``` +Thanks for this contribution — the direction is right. Since [this PR has been open for X months / the author is unresponsive / the branch needs a rebase], I'm going to close this and open a new PR that incorporates your approach. + +Your contribution will be credited in the commit message and CHANGELOG. Thank you for the starting point. +``` + +#### Comment template — closing pre-adoption PR: +``` +This PR was open before PowerShellOrg adopted this module. As part of our triage, we're closing it to start fresh. + +If you'd still like to contribute this change, please open a new PR against the current `main`. See CONTRIBUTING.md for our current guidelines. Thank you for the work you put into this. +``` + +### Phase 2 exit criteria + +- [ ] No open PR is older than 30 days without a maintainer comment +- [ ] All mergeable PRs are merged or have a clear decision + +--- + +## Phase 3: Build modernization (weeks 2–6) + +Goal: the repo builds with the standard stack, CI is green on all platforms. + +Work through these in order. Each step is a standalone PR. + +### 3a: Pester migration + +- [ ] Confirm existing tests use Pester (or add tests if none exist) +- [ ] Upgrade to Pester 5 if on an older version — see the [Pester 5 migration guide](https://pester.dev/docs/migrations/v4-to-v5) +- [ ] All tests pass locally with `Invoke-Pester` + +### 3b: psake bootstrap + +- [ ] Add `psakeFile.ps1` to the repo root with the standard tasks: `Init`, `Clean`, `Build`, `Test`, `Analyze`, `Publish` +- [ ] `Invoke-psake ?` lists all tasks +- [ ] `Invoke-psake Test` runs Pester and passes + +### 3c: PowerShellBuild integration + +- [ ] `build.ps1` or the `psakeFile.ps1` references PowerShellBuild for shared task logic +- [ ] Module manifest is valid (`Test-ModuleManifest` passes) +- [ ] `Invoke-psake Build` produces a clean staged module in `output/` + +### 3d: PSScriptAnalyzer clean pass + +- [ ] `Invoke-psake Analyze` runs PSScriptAnalyzer with the org default ruleset +- [ ] All warnings resolved or suppressed with documented justification +- [ ] No `SuppressMessage` attributes without a comment explaining the suppression + +### 3e: GitHub Actions CI + +- [ ] `.github/workflows/ci.yml` added to the repo, calling the reusable workflow: + ```yaml + name: CI + on: + push: + branches: [main] + pull_request: + branches: [main] + jobs: + ci: + uses: PowerShellOrg/.github/.github/workflows/powershell-ci.yml@main + ``` +- [ ] CI is green on `main` across all four matrix legs (Win/PS5.1, Win/PS7, Linux/PS7, macOS/PS7) +- [ ] Branch protection status check updated to require this CI workflow + +### 3f: GitHub Actions release workflow + +- [ ] `.github/workflows/release.yml` added, calling the reusable workflow: + ```yaml + name: Release + on: + push: + tags: ['v*'] + jobs: + release: + uses: PowerShellOrg/.github/.github/workflows/powershell-release.yml@main + with: + module-name: + secrets: + PSGALLERY_API_KEY: ${{ secrets.PSGALLERY_API_KEY }} + ``` +- [ ] Test release with a pre-release tag (e.g., `v1.0.0-beta.1`) to confirm the workflow runs end-to-end + +### 3g: Test coverage baseline + +- [ ] Coverage report generated (Pester's `-CodeCoverage` parameter or a coverage tool) +- [ ] Baseline coverage percentage recorded in the tracking issue +- [ ] At least critical public functions have tests; gaps documented as issues + +### Phase 3 exit criteria + +- [ ] All standard psake tasks exist and pass +- [ ] CI is green on `main` +- [ ] PSScriptAnalyzer clean +- [ ] Release workflow tested + +--- + +## Phase 4: First clean release (weeks 4–8) + +Goal: cut a release under the PowerShellOrg banner that you are proud to put your name on. + +### Release gate checklist + +- [ ] `CHANGELOG.md` exists and documents what has changed since the last release (even if that is just "Transferred to PowerShellOrg, CI modernized") +- [ ] Module version bumped appropriately (patch if no user-facing changes, minor if new features, major if breaking) +- [ ] All tests passing on CI +- [ ] PSScriptAnalyzer clean +- [ ] Module manifest is accurate: description, author (or organization), copyright, tags, PSGallery URLs +- [ ] `README.md` updated: installation instructions current, usage examples work, badges updated +- [ ] Any open critical bugs addressed or explicitly deferred with a documented reason +- [ ] At least one other maintainer has reviewed the release PR (or Steward if solo) + +### Release steps + +1. Open a PR titled `chore: release vX.Y.Z` +2. Update `CHANGELOG.md` and bump the version in the module manifest +3. Get at least one review +4. Merge to `main` +5. Push the tag: `git tag vX.Y.Z && git push origin vX.Y.Z` +6. Confirm the release workflow succeeds: PSGallery package updated, GitHub Release created +7. Announce in the Council channel + +### Phase 4 exit criteria + +- [ ] At least one release published to PSGallery under PowerShellOrg +- [ ] GitHub Release exists with human-readable notes +- [ ] PSGallery package description updated to reflect PowerShellOrg stewardship + +--- + +## Phase 5: Ongoing maintenance and transition to active + +Once Phase 4 is done, the repo transitions from `status-incoming` to `status-active`. + +### Transition checklist + +- [ ] Repo topic updated from `status-incoming` to `status-active` +- [ ] `README.md` status badge updated +- [ ] Steward notified (they will update any org-level tracking) +- [ ] Announcement posted in Council channel + +### Ongoing cadence + +| Activity | Frequency | +|---|---| +| Issue triage | Weekly (or within 7 days of new issues) | +| PR review | Within 7 days of opening | +| Dependency review | Monthly (check for PSGallery module updates) | +| Release | As needed; no more than 3 months between releases if there are merged changes | +| PSGallery API key rotation | Annually (Steward-driven, maintainer confirms) | + +### Graduation to stable + +When the repo has been in `status-active` for at least 12 months, has had 2+ clean releases, has 2+ active maintainers, and has no critical open issues, propose graduation to `status-stable` in the Council channel. See [GOVERNANCE.md](../.github/GOVERNANCE.md) for the graduation criteria.