Engineering

Open Source Maintenance Board

Triage issues, queue patches, and ship releases without losing track

Open source maintainers juggle incoming bug reports, community pull requests, security patches, and release cadences, often across scattered GitHub threads. The Open Source Maintenance Board gives you a focused Kanban board with four columns that mirror a real patch lifecycle: Triage, Patch Queue, In Progress, and Released. Pair it with an AI agent connected via the MCP server, and you can ask in plain language to create tasks for new issues, move confirmed bugs into the patch queue, or check what's ready to release — all backed by REST API access and the same board you'd manage manually. Built for solo maintainers and small core teams who want repo upkeep to feel less like inbox triage and more like a controlled pipeline.

kanboard.io/templates/oss-maintenance

Template preview

Open Source Maintenance Board

4 columns
Triage

Newly reported issues, bug reports, and community PRs awaiting maintainer review to confirm validity and priority.

3

Confirm reproduction for issue #482 memory leak

Reporter says leak occurs on long-running worker processes. Verify with provided script and label severity.

Review community PR #501: retry logic for HTTP client

Check test coverage and code style compliance before deciding if it advances to Patch Queue.

Evaluate feature request for dark mode in macOS app

Assess scope, check for duplicate requests, and decide if it fits current roadmap or should be closed.

Patch Queue

Confirmed bugs and accepted PRs ready to be scheduled into the next patch release.

3

CVE-2024-1122 dependency patch

Bump vulnerable transitive dependency to patched version and verify no breaking changes in REST API layer.

Fix race condition in task move_task handler

Concurrent move_task calls occasionally duplicate task position; needs locking fix before next patch.

Backport keyboard shortcut fix to v3.2 branch

Shortcut for command palette not registering on non-US keyboard layouts; backport approved fix.

In Progress

Fixes and patches actively being coded, tested, or reviewed by a maintainer or contributor.

2

Implement fix for issue #482 memory leak

Branch fix/482-mem-leak in progress; adding regression test before requesting review.

Apply CVE-2024-1122 dependency patch

Dependency bump applied locally, running full REST API test suite before opening PR.

Released

Patches merged, tagged, and shipped in a release; kept briefly for changelog reference before cleanup.

2

v3.2.1 patch release shipped

Includes CVE-2024-1122 fix and memory leak patch #482. Changelog published to repo README.

v3.2.0 keyboard shortcut backport shipped

Command palette shortcut fix confirmed working on non-US layouts, released and tagged.

How to run this board

Step 1

Community issues and PRs land in Triage, where maintainers or the agent confirm reproducibility, severity, and validity using list_tasks and get_task.

Step 2

Validated bugs and accepted PRs move to Patch Queue via move_task, tagged with the target patch version in the task description.

Step 3

When a maintainer starts coding, the task moves to In Progress and update_task records the branch name and status notes for anyone checking the board.

Step 4

Once merged and tagged in a release, tasks move to Released with the version number logged; stale Released tasks are periodically cleaned up with delete_task to stay within plan task limits.

Step 5

The agent uses get_board and list_projects to confirm project and column state before any bulk create or move operations, avoiding duplicate or orphaned tasks.

AI agent usage

Run it with AI agents

Open MCP setup

This playbook lets an AI agent triage GitHub-style issues, prep patch releases, and keep repo hygiene tasks moving across a Kanban board via the MCP server. The agent reads new items into Triage, promotes validated bugs into Patch Queue, tracks in-progress fixes in In Progress, and archives shipped work in Released. Maintainers give natural-language prompts; the agent calls list_tasks/get_task to check board state before creating or moving tasks, keeping the board as the single source of truth for open source maintenance work.

## Open Source Maintenance Board
Columns: Triage, Patch Queue, In Progress, Released

- When a new issue or PR is reported, create_task in **Triage** with a title matching the repo issue title.
- Before starting work, agent must call list_tasks on **Triage** to avoid duplicate task creation.
- Confirmed bugs with a reproduction move from **Triage** to **Patch Queue** via move_task.
- Once a maintainer begins coding, move_task to **In Progress** and update_task with the branch name.
- On merge + version tag, move_task to **Released** and update_task with the release version in the description.
- Free plan is capped at 25 tasks total; agent should warn maintainer and suggest closing/deleting stale Released tasks via delete_task before creating new ones.
Create a Triage task for the memory leak reported in issue #482, including reproduction steps in the description.
Move the 'CVE-2024-1122 dependency patch' task from Patch Queue to In Progress and update it with the fix branch name.
List all tasks currently in Released so I can decide which ones to delete to stay under the 25-task free plan limit.

Learn more about the board-centric workflow in Kanban for AI Agents or open the MCP guide.

Frequently asked questions

Can I manage multiple open source repos on the free plan?

The free plan supports 1 project and up to 25 tasks total, so most teams use one board per repo. If you maintain multiple repos, you'll need the pro plan ($12/mo or $96/yr) to create additional projects.

How do I avoid hitting the 25-task limit on an active repo?

Regularly move completed patches through Released and delete stale ones with delete_task once they're documented in your changelog. The agent can list Released tasks on request to help you decide what to clean up.

Can the agent automatically create tasks from GitHub issues?

The agent uses create_task through the MCP server based on the details you provide in a prompt; it does not independently poll GitHub, so you or your automation must supply the issue details for the agent to log.

Does this board replace GitHub Issues or PR tracking?

No, it's a lightweight Kanban layer for maintainers to track triage-to-release status. GitHub remains the source of discussion and code review; this board tracks workflow state via columns and tasks.

What happens if I need more than 25 tasks?

Upgrade to the pro plan for $12/mo or $96/yr, which removes the 25-task cap and the 1-project restriction, letting you scale the board across bigger backlogs or multiple repos.

Can I customize the columns for a different release process?

Yes, columns are just board structure, so you can rename or add columns as needed; just make sure any AGENTS.md automation references the exact column names you choose.

Related templates

Ready to create this board?

Sign in and use the template to create a project with columns and sample tasks.

Sign in to activate