ProjectsV2: Manage Project Views via GraphQL

[pyoio]

Select Topic Area

Question

Feature Area

Projects

Body

Hi, the GraphQL API has all the required machinery to manage ProjectV2 fields (<create|update|delete>ProjectV2Field()), it would be incredibly useful to be able to do the same to manage views, we have a couple of motivating use cases:

1. Be able to define project fields and views in code in a repo, and automatically apply them to one or more projects
2. Be able to keep multiple projects in sync with a template project that has been updated since the child project was copied

A suitable alternative would be that GitHub automate some way for child projects to have fields and views auto-synced to the template project they spawned from, with some level of configurability (e.g., the ability to exempt specific fields from having their field values sync'd)

Guidelines

• I have read the above statement and can confirm my post is relevant to the GitHub feature areas Issues and/or Projects.

[oleg-proudnikov]

This makes a lot of sense. It would be great if GitHub reconciled template to all child projects. Perhaps this inheritance would be on an opt-in basis. Alternatively a child project could have an Sync Fields/Views from Template. However, it looks like the decision to decouple a Project from its template is intentional due to complexity of this relationship.

Having an API would make sense here. If I could create a set of Views in a template and then copy them via an API to several projects, it would achieve the same outcome.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[gringolito]

I'm building a set of Claude Code skills that bootstraps and manages a fully GitHub-native backlog workflow — Issues + Projects v2 + Milestones + Labels — through a set of AI agents. Everything except the views can be automated end-to-end via the API.

The minimum API surface we'd need:

• createProjectV2View — to create a view
• updateProjectV2View — to set filter and grouping
• reorderProjectV2Views — to set the view position in the project (maybe could be joined with the updateProjectV2View
• deleteProjectV2View - to delete a view

The pattern already exists for fields (createProjectV2Field / updateProjectV2Field / deleteProjectV2Field). Parity for views would unlock a whole class of "project-as-code" tooling — templates, AI agents, org-wide provisioning scripts — that currently can't deliver a complete setup without fallback to manual steps.