Automating GitHub Projects: The Missing GraphQL Views for Development Dashboards
Bridging the Automation Gap in GitHub Projects V2
GitHub Projects v2 has become an indispensable tool for many development teams, offering flexible ways to manage work, track progress, and visualize data. However, a recent discussion in the GitHub Community highlights a significant roadblock for teams striving for full automation and 'project-as-code' workflows: the lack of GraphQL mutations for managing ProjectV2 views.
The discussion, initiated by user gringolito, points out that while other ProjectV2 primitives like fields can be programmatically created, updated, and deleted via GraphQL, views — the primary way teams interact with their project data and form the basis of many development dashboard examples — remain stubbornly manual. This means that any sophisticated automation, CI workflow, or AI agent designed to provision a GitHub Project must still rely on a human to manually configure views within the GitHub UI.
The Problem: Manual View Configuration Breaks Automation
Imagine setting up an entire project programmatically: labels, custom fields, issue forms, and more. Everything is automated, streamlined, and repeatable. Then, you hit a wall. To create the essential table, board, or roadmap views that define how your team sees and interacts with the project data, you have to switch back to manual clicks. This not only introduces friction but also undermines the core principle of 'project-as-code' and consistent project provisioning.
Gringolito's use case with Claude Code skills, aiming to bootstrap and manage a fully GitHub-native backlog workflow using AI agents, perfectly illustrates this pain point. The final, critical step of configuring views with their specific filters, grouping, sorting, and slicing options simply cannot be automated. This gap affects any organization looking to implement:
- Org-wide project templates
- Automated onboarding for new teams
- CI-driven project setup
- AI agents managing projects on behalf of teams
The sentiment was echoed by P-r-e-m-i-u-m, who affirmed, "The gap is real. Trying to automate a 'project-as-code' workflow only to get blocked at the finish line by manual UI configuration is super frustrating."
The Proposed Solution: GraphQL Parity for Views
The solution seems straightforward: extend the existing GraphQL API to include mutations for views, mirroring the functionality already available for fields. The pattern is already established, as seen with:
createProjectV2Field / updateProjectV2Field / deleteProjectV2FieldTo achieve full automation, the community proposes at least these new mutations:
createProjectV2View— for creating table, board, or roadmap views.updateProjectV2View— for configuring filters, fields, group by, sort by, and slice by options.deleteProjectV2View— for removing existing views.
Additionally, a mechanism for controlling view order, possibly a reorderProjectV2Views mutation or a position / afterId input on updateProjectV2View, would ensure the default landing view can also be automated.
Impact on Developer Productivity and Engineering Metrics
Implementing these GraphQL mutations would be a game-changer for developer productivity. It would enable seamless, end-to-end automation of GitHub ProjectV2 provisioning, allowing teams to standardize their project setups, reduce manual overhead, and ensure consistency across multiple projects. This consistency is vital for gathering reliable engineering team metrics and creating accurate development dashboard examples that reflect true project status and performance.
The community's call for this feature is a clear signal that developers are pushing the boundaries of what's possible with GitHub's API, seeking to unlock new levels of automation and efficiency. It’s the missing piece for true Projects v2 automation, empowering teams to build more robust, AI-driven, and 'project-as-code' workflows.
