I built this React application as a fun project using Cursor to help me visualize my GitHub project issues and pull requests through interactive charts and graphs. It helps me understand my team's progress, performance patterns, and code review behaviors. I use it to track sprint velocity, analyze workload distribution, and identify trends in our development process. You are welcome to use it.
It is hosted at https://vivekkodira.github.io/github-issue-graph/
- Interactive visualization of GitHub issues and pull requests
- Team performance analysis
- Code review insights
- Sprint velocity tracking
- Issue dependency graph
- Automated insights generation
-
Enter your GitHub repository details in the configuration section:
- Repository Owner
- Repository Name
- Project ID (optional)
- GitHub Token (required for API access)
-
Click the "Render" button to fetch and display your repository data
This is a client-side-only single-page app (React 19 + Vite + TypeScript) — there is no backend. The browser calls the GitHub API directly and stores everything locally.
- If the user has entered a Project ID, GraphQL calls are made to GitHub's API (
projectFetcher.ts); if only a repository is entered, REST calls are made instead (issueFetcher.js). Pull requests are fetched separately (prFetcher.ts). - Each response is normalised into a single flat
TaskFormatshape bytaskConverter.ts, so every chart consumes the same structure regardless of the source API. - The normalised tasks and PRs are stored in RxDB (backed by IndexedDB via the Dexie storage adapter) in the
tasksandprscollections. - Chart components subscribe reactively to the RxDB collections and re-render when the data changes. Filtering is done with reactive RxDB Mango queries (
mangoQueryBuilder.ts). - App configuration (repo, token, optional OpenAI key, planned effort/date) is the only thing kept in
localStorage; fetched data lives in IndexedDB. Raw API responses are also cached locally to avoid refetching.
flowchart TD
A[User Input] -->|Project ID Entered| B[GraphQL Calls to GitHub API]
A -->|Only Repository Entered| C[REST Calls to GitHub API]
A --> P[REST Calls for Pull Requests]
B --> D[Normalized into flat TaskFormat]
C --> D
P --> D
D --> E[Stored in RxDB / IndexedDB]
E -->|Reactive subscriptions + Mango query filters| F[Parsed and Massaged by Charts]
F --> G[Various Visualizations Displayed]
See docs/RXDB_MIGRATION.md for details on the data layer.
- Completion Charts
- Planned Task Completion Count
- Planned Task Completion Effort
- Overall Task Completion
- Sprint Velocity Chart: Track team's velocity across sprints
- Effort Prediction Chart: Predict project completion timeline based on current velocity
- Status Chart: View issue status distribution
- Sprint Chart: Analyze sprint-wise task distribution
- Assignee Charts
- Task distribution by assignee
- Pie charts showing workload distribution
- Line charts tracking assignee performance over time
- Reviewer Charts
- Review workload distribution
- Reviewer performance trends
- Author Charts
- PR creation trends by author
- Author contribution patterns
- PR Review Chart: Review patterns and statistics
- PR Lifecycle Chart: Time taken for PR reviews and merges
- Code Churn Chart: Code changes and modifications
- Review Quality Chart: Quality metrics for code reviews
- Review Word Cloud: AI-enhanced visualization of common terms in PR reviews
flowchart TD
A[PR Review Comments] --> B[Text Processing]
B --> C[Stop Words Filtering]
C --> D[Word Normalization]
D --> E[Word Frequency Analysis]
E --> F[AI Processing]
F --> G[Word Cloud Generation]
G --> H[Interactive Visualization]
H --> I[Word Filtering UI]
I --> J[Real-time Updates]
- Interactive visualization of issue dependencies
- Network graph showing relationships between issues
- Filter and explore issue connections
- Automated insights generation based on data analysis
- Color-coded insights (green for positive trends, red for negative)
- Key metrics and patterns highlighted
-
Much of the code in the charts was generated using Cursor. There is scope for better design & refactoring.
-
This application assumes certain custom fields are configured in your GitHub repository:
- Sprint: Used to group tasks into sprints (e.g., "Sprint-1", "Sprint-2")
- Size: Used for task size estimation (e.g., "S", "M", "L")
- Estimate (days): Planned effort in days
- Actual (days): Actual effort spent in days
These fields are used for:
- Effort estimation and tracking
- Sprint velocity calculations
- Workload distribution analysis
- Performance trend insights
If your repository doesn't use these custom fields, some charts and insights may not work as expected. You can configure these field mappings in the project configuration.
- Clone the repository
- Install dependencies:
npm install
- Run:
npm run dev
The application includes a debug mode for troubleshooting and data inspection. Debug mode is controlled via browser localStorage, so you can enable/disable it without code changes or rebuilding.
- Open your browser's developer console (F12 or Cmd+Option+I on Mac)
- Run the following command:
localStorage.setItem('ENABLE_DEBUG', 'true')
- Refresh the page
- Click "Render" to fetch data
When enabled, debug mode will:
- Log the first issue's data structure to the console
- Display all available field names
- Automatically download a
flattened_tasks_debug.jsonfile with the complete data - Log raw GraphQL responses (if using project queries)
To disable debug mode, run this in the browser console:
localStorage.removeItem('ENABLE_DEBUG')Debug mode is useful for:
- Inspecting the data structure of your issues
- Verifying custom fields are being fetched correctly
- Troubleshooting GraphQL queries
- Understanding the flattened data format
- Testing new custom field configurations
-
Example: Bugs found by testers
-
Example: Change requests
Get automated, color-coded insights about team performance and project trends
