Pavan Kumar Dubasi

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:

Created issues when I remembered something needed doing
No priorities beyond gut feeling
No sprint cycles, just endless backlog
Contributors asked "what should I work on?" and I'd say "anything marked 'good first issue'"
No governance, just me making decisions in the moment
Risk management was "hope nothing breaks"
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 Type	Authority	Process
Technical architecture	Tech Lead	RFC + community review
Feature prioritization	Project Owner	Sprint planning
Bug fixes	Any maintainer	Standard PR review
Breaking changes	Project Owner	Community consultation
New maintainers	Project Owner	Nomination + 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:

Epic	Issues	Description
Core Features	21	Advanced search, sorting, previews
Backend Infrastructure	11	API, caching, security
Testing & Quality	17	Unit tests, E2E coverage
Accessibility	5	WCAG 2.1 AA compliance
Maintenance	9	Configuration, workflows
Documentation	70	Guides, references, tutorials
AI Integration	38	Recommendations, 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)

Activity	Owner	Tech Lead	Maintainer	Contributor
Feature design	A	R	C	I
Code implementation	I	C	A	R
Code review	I	C	R	I
Release decision	R	A	C	I
Documentation	I	C	R	R

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:

Risk	Probability	Impact	Score	Mitigation
Dependency vulnerabilities	High (4)	Major (4)	16	Dependabot + weekly audits
AI integration complexity	Medium (3)	Major (4)	12	Phased rollout, fallback modes
GitHub API rate limits	Medium (3)	Moderate (3)	9	GraphQL batching, caching
Svelte 5 breaking changes	Low (2)	Moderate (3)	6	Pin versions, migration guide
Contributor availability	Medium (3)	Minor (2)	6	Documentation, 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:

Parameter	Value
Available hours	40
Focus factor	0.7 (meetings, context switching)
Effective capacity	28 hours
Story points	1 point = 4 hours
Sprint capacity	7 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:

Sprint	Committed	Completed	Accuracy
Sprint 1	8	6	75%
Sprint 2	7	7	100%
Sprint 3	7	-	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:

Category	Checklist Item
Code Quality	TypeScript strict mode passes
	ESLint reports zero errors
	Prettier formatting applied
	No console.log in production code
Testing	Unit tests written for new functions
	Existing tests pass
	Manual testing completed
Review	CodeRabbit AI review addressed
	Human reviewer approved
	No merge conflicts
Documentation	JSDoc 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:

All Issues - Complete list with filters
Kanban - Visual workflow (Backlog → In Progress → Review → Done)
Roadmap - Timeline with milestones
Sprint Board - Current sprint items
Priority Matrix - Urgent vs Important grid
Epic Overview - Progress by epic
Risk Dashboard - Active risks with status
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

Metric	Before	After	Change
Issues with priority	0	151	All categorized
Issues with sprint	0	42	7 sprints planned
Documented processes	0	28 files	Full coverage
Contributor onboarding time	~1 week	~1 day	85% faster
Decision clarity	Low	High	No ambiguity
Bus factor	1 (just me)	3+	Project survives
Risk visibility	None	5 tracked	Proactive

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

Section	Requirement	Document	Status
5	Governance	GOVERNANCE.md	Complete
6.1	Scope	WORK_BREAKDOWN_STRUCTURE.md	Complete
6.2	Stakeholders	STAKEHOLDER_REGISTER.md	Complete
6.3	Resources	RACI_MATRIX.md	Complete
6.4	Change Control	CHANGE_MANAGEMENT.md	Complete
6.5	Communication	COMMUNICATION_PLAN.md	Complete
6.7	Risk	RISK_REGISTER.md	Complete
6.8	Release	RELEASE_CHECKLIST.md	Complete
6.9	Knowledge	LESSONS_LEARNED.md	Complete

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

PMI PMBOK Agile Compliance

Practice	Document	Status
Sprint Planning	SPRINT_PLANNING.md	Complete
Retrospectives	SPRINT_RETROSPECTIVE.md	Complete
Definition of Done	DEFINITION_OF_DONE.md	Complete
Backlog Management	GitHub Projects	Complete
Velocity Tracking	Sprint metrics	Complete
Burndown Charts	GitHub Insights	Complete
Daily Standups	Async in GitHub	Complete
Release Management	RELEASE_CHECKLIST.md	Complete
Continuous Improvement	LESSONS_LEARNED.md	Complete

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

GitHub Best Practices

Category	Files	Status
Community Health	README, CONTRIBUTING, CODE_OF_CONDUCT, LICENSE	Complete
Security	SECURITY.md, vulnerability policy	Complete
Support	SUPPORT.md, discussion templates	Complete
Issue Templates	9 templates	Complete
PR Template	Checklist format	Complete
Automation	Dependabot, CI/CD, PR checks	Complete
Code Ownership	CODEOWNERS	Complete

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:

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

Next week:

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

This month:

Add remaining ISO 21502 documents
Configure automated workflows
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.