Maintaining Open Source

GitHub Issues is the public interface for your open source project, but it is a terrible planning tool. Issues pile up from users with varying levels of detail. Feature requests mix with bug reports. Duplicates accumulate. And everything is public, which means you cannot candidly note "this is low priority because the requester misunderstands the architecture" or "I want to do this but it requires a breaking change I am not ready to announce."

Maintainers need a private planning space -- somewhere to triage what actually matters, track their own roadmap independent of issue noise, and plan releases without every thought being visible to the community. You need a board that reflects your priorities, not everyone else's.

Use ContextSwitch as your private kanban alongside GitHub Issues. When a new issue comes in, decide if it matters and create a card on your board with your own priority, your own context, and your own notes. Reference the GitHub issue number in the card if you want, but the card is yours -- it captures what you actually plan to do about it, not what the requester asked for.

This separation is freeing. Your public issue tracker stays responsive and community-friendly. Your private board stays honest and focused. The two do not need to be in sync because they serve different purposes.

If you maintain multiple packages, each gets its own database file. Maintaining both category_encoders and elote? Each project has a dedicated .db with its own kanban board, its own priorities, its own diary. No cross-contamination between projects.

But you still get the unified timeline. When you sit down for an open source session, the timeline shows what needs attention across all your projects. Maybe category_encoders has a regression that shipped last week and elote has a PR that has been waiting for review for a month. One view, all your maintainer responsibilities, clear priorities.

Use the kanban columns as release milestones. Set up your board as Backlog, v2.1, v2.2, and Done. As you triage issues and plan features, drag them into the appropriate release column. When priorities shift -- and they always do -- drag items between releases. The board is your release plan, visible at a glance, adjustable in seconds.

This is faster than managing milestones in GitHub, and more flexible. You can reorganize an entire release plan with a few drag-and-drop moves instead of editing dozens of issue metadata fields.

ContextSwitch ships with a built-in MCP server, so Claude Code can read your board and help you prioritize. Ask "What is the highest impact item for the next release?" and Claude reviews your cards, their priorities, and your diary notes to give a reasoned answer. Ask "I have four hours this afternoon -- what should I work on?" and Claude factors in deadlines, blocking issues, and effort estimates.

For maintainers who work on open source in limited time windows, this kind of intelligent triage is the difference between spending your Saturday afternoon on the most impactful work versus getting lost in whatever issue is loudest.

Public changelogs show what shipped. The project diary captures why. Use it to record the dead ends you explored, the design decisions you made, and the tradeoffs you accepted. "Chose approach B for the encoder refactor because A required breaking the public API, and we are not ready for a major version bump until Q3."

This is invaluable when you need to write release notes, explain a design decision in a PR review, or remember six months later why you did not take the obvious approach. The diary is your private dev log -- timestamped, searchable, and always available through the MCP server when Claude needs context about your project history.

Get ContextSwitch on the Mac App Store