add triage cadence, roles & escalation matrix for stale-issue automation

.github/workflows/stale.yml

@@ -0,0 +1,43 @@
+name: Mark stale issues and PRs
+
+# Enforces the inactivity windows defined in TRIAGE.md
+
+on:
+  schedule:
+    - cron: "17 6 * * *" # Daily at 06:17 UTC
+  workflow_dispatch:
+
+permissions:
+  issues: write
+  pull-requests: write
+
+jobs:
+  stale:
+    name: Stale triage
+    runs-on: ubuntu-latest
+    steps:
+      - name: Mark stale items
+        uses: actions/stale@v9
+        with:
+          stale-issue-message: >
+            Is this issue abandoned? It had no activity for 30 days.
+            It has been marked stale and will be closed in 14 days if no further activity occurs.
+            Add an update to keep it open.
+            See TRIAGE.md for our triage cadence.
+          close-issue-message: >
+            This issue was automatically closed due to continued inactivity.
+          stale-pr-message: >
+            Is this pull request abandoned? It had no activity for 21 days.
+            It has been marked stale and will be closed in 7 days if no further activity occurs.
+            Add a comment or push a commit to keep it open.
+            See TRIAGE.md for our triage cadence.
+          close-pr-message: >
+            This pull request was automatically closed due to continued inactivity.
+          days-before-issue-stale: 30
+          days-before-issue-close: 14
+          days-before-pr-stale: 21
+          days-before-pr-close: 7
+          stale-issue-label: stale
+          stale-pr-label: stale
+          exempt-issue-labels: pinned,Security
+          exempt-pr-labels: pinned,Security

CONTRIBUTING.md

@@ -150,6 +150,8 @@ Brief description of changes made.
 3. Address any feedback or requested changes
 4. Once approved, your PR will be merged
 
+Issues and PRs are triaged on a regular cadence — see [TRIAGE.md](TRIAGE.md) for the schedule, labels, response-time expectations, and stale-item policy.
+
 ## Content Guidelines
 
 ### Documentation Structure

TRIAGE.md

@@ -0,0 +1,60 @@
+# Issue & PR Triage Cadence
+
+This document defines how issues and pull requests in this repository are triaged, how often, and by whom. It exists so contributors know what to expect and maintainers share one consistent process.
+
+## Cadence
+
+| Activity | Frequency | When |
+| --- | --- | --- |
+| Triage new issues and PRs | Weekly | Ahead of each Developer Experience Working Group session |
+| Review open PRs | Within 48 hours of submission | Rolling |
+| Revisit stale items | Monthly | First week of each month |
+
+Triage happens alongside the weekly working group sessions, so newly raised items are discussed while the group is already together.
+
+## Triage checklist
+
+For every new issue or PR, the triaging maintainer:
+
+1. **Acknowledge** — leave a short comment thanking the contributor and setting expectations.
+2. **Label** — apply at least one type label (`documentation`, `enhancement`, `bug`) and, where useful, a status label (`triage`, `needs-info`, `good first issue`, `help wanted`).
+3. **Assess scope** — small, well-defined items can be approved on the spot; larger proposals are routed to a Developer Advocate for discussion, per the [submission process](CONTRIBUTING.md#submission-process).
+4. **Assign or park** — assign an owner, or mark `help wanted` / `good first issue` for community pickup.
+5. **Link work** — ensure every PR is linked back to its issue.
+
+## Labels
+
+| Label | Meaning |
+| --- | --- |
+| `triage` | New item not yet reviewed by a maintainer |
+| `needs-info` | Waiting on the reporter for details; may go stale if unanswered |
+| `good first issue` | Suitable for newcomers |
+| `help wanted` | Maintainers would like community help here |
+| `stale` | Applied automatically after prolonged inactivity (see automation below) |
+| `pinned` | Exempt from stale automation |
+
+## Response-time expectations (SLAs)
+
+- **New issues**: first maintainer response within **1 week**.
+- **New PRs**: first review within **48 hours**, as stated in `CONTRIBUTING.md`.
+- **Agreed work**: PR submitted within **1 week** of scope agreement, per `CONTRIBUTING.md`.
+
+## Stale automation
+
+The [`stale.yml`](.github/workflows/stale.yml) workflow enforces the inactivity part of this cadence:
+
+- **Issues** are marked `stale` after **30 days** without activity and closed **14 days** later if still inactive.
+- **PRs** are marked `stale` after **21 days** without activity and closed **7 days** later if still inactive.
+- Items labelled `pinned` or `Security` are never marked stale.
+- Any comment or update resets the clock.
+
+## Roles
+
+- **Triagers**: Developer Advocates and the repository maintainers listed in [CODEOWNERS](CODEOWNERS).
+- **Escalation**: Scope or priority disagreements are resolved in the weekly working-group session.
+
+---
+
+Thank you for helping make Cardano more accessible to developers worldwide! 🚀
+
+*For questions about contributing, first become a member at [Intersect](https://www.intersectmbo.org/) and register at [members.intersectmbo.org](https://members.intersectmbo.org/registration) to get voting rights and access to our Discord community's #developer-experience channel. See our [Intersect Membership Guide](website/docs/intersect-membership-guide.md) for all membership benefits.*