It was 11 PM on a Thursday. Christmas Eve. I was staring at my GitHub issues tab, trying to remember what I was supposed to work on next.

151 issues. 6 epics. No clear priority. No sprint structure. No definition of “done.”

Contributors asked what to work on. I’d point them to the issues list. They’d get overwhelmed. They’d leave.

I was running an open source project like a todo list. It wasn’t working.

The Problem: Open Source Without Structure

My project, IssueFlow, is a GitHub issue discovery platform. It helps developers find beginner-friendly issues to contribute to. Ironic that the project helping others find organized issues had the most disorganized issue tracker.

What my project management looked like before:

  1. Created issues when I remembered something needed doing
  2. No priorities beyond gut feeling
  3. No sprint cycles, just endless backlog
  4. Contributors asked “what should I work on?” and I’d say “anything marked ‘good first issue’”
  5. No governance, just me making decisions in the moment
  6. Risk management was “hope nothing breaks”
  7. Documentation existed in my head

The consequences:

  • 18 issues completed out of 151 (12% completion rate)
  • Contributors submitted PRs for the same feature (no coordination)
  • Critical bugs sat next to nice-to-haves with no distinction
  • I couldn’t take a week off without the project stalling
  • No one knew the project roadmap except me

I needed structure. Real structure. Not “add some labels” structure.

Why I Chose ISO 21502 and PMI PMBOK

When I started researching project management frameworks, I expected to find lightweight methodologies. Kanban boards. Simple sprint templates.

Instead, I found ISO 21502:2020 and PMI PMBOK 7th Edition.

My initial reaction: These are for enterprise projects. 100-person teams. Multi-million dollar budgets. Not solo developers with side projects.

My reaction after reading them: These are checklists of everything I was missing.

ISO 21502 isn’t a rigid process. It’s a set of guidelines covering what every project needs:

  • Governance (who decides what?)
  • Scope management (what are we building?)
  • Stakeholder engagement (who cares about this?)
  • Resource planning (who does what?)
  • Risk management (what could go wrong?)
  • Change control (how do we handle changes?)
  • Communication (how do we stay aligned?)
  • Quality management (how do we know it’s good?)
  • Knowledge management (what did we learn?)

PMI PMBOK adds agile-specific practices:

  • Sprint planning
  • Retrospectives
  • Definition of Done
  • Velocity tracking

Combined, they answer every question I’d been avoiding.

The Implementation: 28 Documents, 8 Views, 6 Workflows

Over two weeks, I built an ISO/PMI-compliant project management system entirely within GitHub. No external tools. No paid subscriptions. Just markdown files and GitHub Projects.

Governance (ISO 21502 Section 5)

Document: GOVERNANCE.md

Every project needs to answer: “Who makes decisions?”

In open source, this is often implicit. The maintainer decides. But implicit governance creates confusion when contributors disagree, or when the maintainer is unavailable.

I documented:

Decision-Making Framework:

Decision TypeAuthorityProcess
Technical architectureTech LeadRFC + community review
Feature prioritizationProject OwnerSprint planning
Bug fixesAny maintainerStandard PR review
Breaking changesProject OwnerCommunity consultation
New maintainersProject OwnerNomination + vote

Contribution Path:

flowchart LR
    A[Contributor] -->|1 merged PR| B[Regular Contributor]
    B -->|5 merged PRs| C[Maintainer]
    C -->|Nomination + Vote| D[Tech Lead]
    D -->|Architecture decisions| E[Project Owner]

Now contributors know exactly how to progress. No guessing. No politics.

Work Breakdown Structure (ISO 21502 Section 6.1)

Document: WORK_BREAKDOWN_STRUCTURE.md

I organized all 195 items into 7 major epics:

EpicIssuesDescription
Core Features21Advanced search, sorting, previews
Backend Infrastructure11API, caching, security
Testing & Quality17Unit tests, E2E coverage
Accessibility5WCAG 2.1 AA compliance
Maintenance9Configuration, workflows
Documentation70Guides, references, tutorials
AI Integration38Recommendations, multi-agent

Each epic has:

  • Clear deliverables
  • Dependency mapping
  • Milestone assignment
  • Effort estimates

The WBS isn’t just organization. It’s communication. Contributors can see exactly where the project is going and what piece they want to own.

RACI Matrix (ISO 21502 Section 6.3)

Document: RACI_MATRIX.md

RACI defines who is:

  • Responsible (does the work)
  • Accountable (approves the work)
  • Consulted (provides input)
  • Informed (needs to know)
ActivityOwnerTech LeadMaintainerContributor
Feature designARCI
Code implementationICAR
Code reviewICRI
Release decisionRACI
DocumentationICRR

Before RACI, contributors would submit PRs and wait. They didn’t know who reviewed what, or who made the final call.

PR Review Flow:

flowchart TD
    A[PR Submitted] --> B[Maintainer Reviews]
    B --> C{Architecture Question?}
    C -->|Yes| D[Tech Lead Consulted]
    C -->|No| E[Approval]
    D --> E
    E --> F[Merge]

Now the process is explicit. If you submit code, a Maintainer reviews it. If there’s an architectural question, the Tech Lead weighs in. No ambiguity.

Risk Register (ISO 21502 Section 6.7)

Document: RISK_REGISTER.md

Every project has risks. Most projects ignore them until they explode.

I identified 5 active risks:

RiskProbabilityImpactScoreMitigation
Dependency vulnerabilitiesHigh (4)Major (4)16Dependabot + weekly audits
AI integration complexityMedium (3)Major (4)12Phased rollout, fallback modes
GitHub API rate limitsMedium (3)Moderate (3)9GraphQL batching, caching
Svelte 5 breaking changesLow (2)Moderate (3)6Pin versions, migration guide
Contributor availabilityMedium (3)Minor (2)6Documentation, async workflows

The risk register isn’t about eliminating risk. It’s about knowing what to watch.

When Dependabot flagged a critical vulnerability last week, I wasn’t surprised. It was Risk #1. The mitigation was already in place. Response time: 4 hours.

Sprint Planning (PMI PMBOK Agile)

Document: SPRINT_PLANNING.md

I adopted 1-week sprints with:

Capacity planning:

ParameterValue
Available hours40
Focus factor0.7 (meetings, context switching)
Effective capacity28 hours
Story points1 point = 4 hours
Sprint capacity7 story points

Sprint goal template:

Sprint 3 Goal: By end of sprint, users can filter issues by label and language.

Committed Stories:

  • ISSUE-45: Label filtering (3 points)
  • ISSUE-47: Language selector (2 points)
  • ISSUE-51: Filter persistence (2 points)

Stretch Goals:

  • ISSUE-52: Filter presets (2 points)

Velocity tracking:

SprintCommittedCompletedAccuracy
Sprint 18675%
Sprint 277100%
Sprint 37-In progress

Sprints give rhythm. Contributors know when to expect releases. I know when to expect deliverables. The project moves forward predictably.

Definition of Done (PMI PMBOK Quality)

Document: DEFINITION_OF_DONE.md

“Done” is the most ambiguous word in software development. I made it explicit.

Story-level DoD:

CategoryChecklist Item
Code QualityTypeScript strict mode passes
ESLint reports zero errors
Prettier formatting applied
No console.log in production code
TestingUnit tests written for new functions
Existing tests pass
Manual testing completed
ReviewCodeRabbit AI review addressed
Human reviewer approved
No merge conflicts
DocumentationJSDoc comments for public functions
README updated if needed
CHANGELOG entry added

Release-level DoD:

Checklist Item
All sprint stories complete
E2E tests pass
Performance benchmarks met
Security scan clean
Accessibility audit passed
Documentation site updated

When a contributor asks “is this ready to merge?”, they check the DoD. No subjective judgment. Just checkboxes.

GitHub Projects Configuration

Document: PROJECT_MANAGEMENT_SETUP.md

I configured GitHub Projects V2 with:

8 Views:

  1. All Issues - Complete list with filters
  2. Kanban - Visual workflow (Backlog → In Progress → Review → Done)
  3. Roadmap - Timeline with milestones
  4. Sprint Board - Current sprint items
  5. Priority Matrix - Urgent vs Important grid
  6. Epic Overview - Progress by epic
  7. Risk Dashboard - Active risks with status
  8. My Items - Personal assignment filter

13 Custom Fields:

  • Status (Backlog, Ready, In Progress, In Review, Done, Blocked)
  • Sprint (Sprint 1-7)
  • Priority (P0: Critical, P1: High, P2: Medium, P3: Low)
  • Epic (Core, Backend, Testing, A11y, Maintenance, Docs, AI)
  • Effort (XS, S, M, L, XL)
  • Risk Level (None, Low, Medium, High, Critical)
  • Category (Feature, Bug, Enhancement, Docs, Chore, Test, Security, Refactor)
  • Story Points (1, 2, 3, 5, 8, 13)
  • Target Date
  • Notes

7 Insight Charts:

  • Status breakdown (pie chart)
  • Sprint progress (bar chart)
  • Priority distribution (bar chart)
  • Epic progress (stacked bar)
  • Effort distribution (pie chart)
  • Burn-up chart (line chart)
  • Category breakdown (pie chart)

6 Automated Workflows:

flowchart LR
    subgraph Triggers
        A[Issue Closed] --> W1[Status → Done]
        B[PR Merged] --> W2[Status → Done]
        C[PR Mentions Issue] --> W3[Auto-link]
        D[New Item] --> W4[Add to Project]
        E[Sub-issue Done] --> W5[Update Parent]
        F[All Sub-issues Done] --> W6[Close Parent]
    end

The Results: Before vs After

MetricBeforeAfterChange
Issues with priority0151All categorized
Issues with sprint0427 sprints planned
Documented processes028 filesFull coverage
Contributor onboarding time~1 week~1 day85% faster
Decision clarityLowHighNo ambiguity
Bus factor1 (just me)3+Project survives
Risk visibilityNone5 trackedProactive

The numbers matter. But the feeling matters more.

Before: Constant anxiety about what to work on, what I was forgetting, what contributors needed.

After: Clear priorities. Documented decisions. Sustainable pace.

The Compliance Checklist

After implementation, I audited against the standards:

ISO 21502:2020 Compliance

SectionRequirementDocumentStatus
5GovernanceGOVERNANCE.mdComplete
6.1ScopeWORK_BREAKDOWN_STRUCTURE.mdComplete
6.2StakeholdersSTAKEHOLDER_REGISTER.mdComplete
6.3ResourcesRACI_MATRIX.mdComplete
6.4Change ControlCHANGE_MANAGEMENT.mdComplete
6.5CommunicationCOMMUNICATION_PLAN.mdComplete
6.7RiskRISK_REGISTER.mdComplete
6.8ReleaseRELEASE_CHECKLIST.mdComplete
6.9KnowledgeLESSONS_LEARNED.mdComplete

ISO 21502 Score: 100% (9/9 sections)

PMI PMBOK Agile Compliance

PracticeDocumentStatus
Sprint PlanningSPRINT_PLANNING.mdComplete
RetrospectivesSPRINT_RETROSPECTIVE.mdComplete
Definition of DoneDEFINITION_OF_DONE.mdComplete
Backlog ManagementGitHub ProjectsComplete
Velocity TrackingSprint metricsComplete
Burndown ChartsGitHub InsightsComplete
Daily StandupsAsync in GitHubComplete
Release ManagementRELEASE_CHECKLIST.mdComplete
Continuous ImprovementLESSONS_LEARNED.mdComplete

PMI PMBOK Score: 100% (9/9 practices)

GitHub Best Practices

CategoryFilesStatus
Community HealthREADME, CONTRIBUTING, CODE_OF_CONDUCT, LICENSEComplete
SecuritySECURITY.md, vulnerability policyComplete
SupportSUPPORT.md, discussion templatesComplete
Issue Templates9 templatesComplete
PR TemplateChecklist formatComplete
AutomationDependabot, CI/CD, PR checksComplete
Code OwnershipCODEOWNERSComplete

GitHub Best Practices Score: 94% (15/16 features)

What I Learned

1. Documentation Is Communication

Every document I created answers a question someone would eventually ask:

  • “Who can merge PRs?” → GOVERNANCE.md
  • “What’s the priority?” → Sprint Board
  • “Is this done?” → DEFINITION_OF_DONE.md
  • “What could go wrong?” → RISK_REGISTER.md

Documentation isn’t bureaucracy. It’s asynchronous communication. Write it once, answer the question forever.

2. Structure Enables Freedom

This sounds counterintuitive. More process should mean less flexibility, right?

Wrong.

Before structure, every decision required my input. Contributors waited for me. I was the bottleneck.

After structure, contributors self-serve. They check the DoD. They pick from prioritized backlog. They follow the contribution guide. They don’t need me for routine decisions.

Structure freed me to focus on architecture and strategy instead of coordination and answering the same questions.

3. ISO/PMI Standards Are Checklists, Not Chains

I was afraid these standards would make the project feel corporate. They didn’t.

ISO 21502 doesn’t prescribe how to do governance. It says “you need governance.” I chose how to implement it.

PMI PMBOK doesn’t mandate 2-week sprints. It says “define your iteration cycle.” I chose 1-week sprints.

The standards are questions: “Have you thought about risk management?” The answers are yours.

4. GitHub Projects V2 Is Underrated

I almost bought Jira. I almost set up Linear. I almost self-hosted Plane.

Then I actually explored GitHub Projects V2.

Custom fields. Multiple views. Automated workflows. Insight charts. Built-in issue linking. Free for open source.

It’s not perfect. The UI can be clunky. Some features are hidden. But for open source projects, it’s more than enough.

Should You Implement This?

Yes, if you:

  • Maintain an open source project with >50 issues
  • Have or want multiple contributors
  • Feel overwhelmed by your backlog
  • Want to take time off without the project stalling
  • Need to demonstrate project maturity to potential sponsors or employers

Probably not if you:

  • Have a small personal project (<20 issues)
  • Work alone with no plans for contributors
  • Prefer minimal process (and accept the tradeoffs)
  • Need real-time collaboration (use Linear or Notion)

Definitely not if you:

  • Have fewer than 10 issues
  • The project is a one-time hack
  • You’re exploring, not building

Your Action Items

This week:

  1. Create GOVERNANCE.md with decision-making authority
  2. Create DEFINITION_OF_DONE.md with explicit checklists
  3. Set up GitHub Projects with at least Status and Priority fields

Next week:

  1. Create RISK_REGISTER.md with top 3-5 project risks
  2. Create RACI_MATRIX.md for core activities
  3. Set up Sprint view in GitHub Projects

This month:

  1. Add remaining ISO 21502 documents
  2. Configure automated workflows
  3. Run first formal sprint with retrospective

Within 3 months:

You’ll have a project that runs without you. Contributors know what to work on. Decisions are documented. Risks are tracked. The project is sustainable.

Get the Templates

All 28 documents are open source and available for reference:

Repository: github.com/VibeTensor/IssueFlow

Project Board: github.com/orgs/VibeTensor/projects/2

Fork the repo. Copy the documents. Adapt them to your project. They’re MIT licensed.

Resources

ISO 21502:2020:

PMI PMBOK:

GitHub Projects:

Open Source Governance:

One Last Thing

Six months ago, I would have dismissed ISO standards as overkill for open source. Enterprise theater for solo projects.

I was wrong.

The standards aren’t about paperwork. They’re about answering the questions every project eventually asks:

  • Who decides?
  • What’s the priority?
  • What does “done” mean?
  • What could go wrong?
  • Who does what?

You can answer these questions implicitly (and re-answer them constantly). Or you can document them once and move on.

I chose documentation. My project runs smoother. Contributors are happier. I sleep better.

195 issues. Zero chaos. That’s the power of structure.

Found this helpful? Share it with a maintainer drowning in GitHub issues. They might not realize there’s a better way.