GitHub Projects for Unreal Engine

What it is

GitHub Projects organizes issues, pull requests, and draft issues in customizable table, board, and roadmap views. Fields, filters, charts, templates, and workflows adapt the project to a team's process.

A crash issue can carry Priority, Platform, Target release, and Verification fields while its linked pull request shows the code change. Projects fits teams that already maintain this work in GitHub. Check whether artists and production staff can use the same issue workflow before adopting it for the whole studio.

With Unreal Engine

GitHub Projects fits Unreal work that already starts as a GitHub issue or pull request. A crash fix can keep its owner, priority, target release, pull request, and verification state in one project view.

Where it fits

How it works

Items and live GitHub data

Projects contain issues, pull requests, and draft issues. Changing an issue assignee or label in the project updates the repository item, and changes to the repository item appear in the project.¹⁸

Fields and views

Text, number, date, single-select, iteration, repository, assignee, and issue fields can drive a view. Repository-backed fields stay synchronized with their issue or pull request. Project custom fields remain local, while organization issue fields live on supported same-organization issues.¹⁴⁹

Roadmaps and charts

A roadmap lays project items against date fields and iteration markers. Insights charts group and aggregate field values for status or throughput reporting, but they exclude archived and deleted items. These views are only as accurate as the fields contributors maintain.¹¹¹²

Built-in and external automation

Built-in workflows can add matching items, change Status, mark closed or merged work Done, and archive completed items. The current plan limits how many auto-add workflows a project can use. GitHub Actions and the GraphQL API cover rules that need repository events or custom logic.⁵⁶⁷

Organization issue fields

Organization-level issue fields provide consistent typed metadata across repositories and projects. They can be filtered, grouped, and charted, but organization visibility and item type rules affect where values appear.⁹

In production

1. 01

   Choose the issue boundary

   Create an issue when work needs an owner, acceptance condition, or discussion. A draft issue is fine while arranging a release, but convert it before expecting repository fields and issue automation to behave like a repository issue.

2. 02

   Build views around roles

   Use a table for triage and field edits, a board for active work, and a roadmap for scheduled items. Keep views focused on the information each team uses.²

3. 03

   Let repository events update engineering status

   Let pull request reviews and merges move engineering status. Keep a separate verification state when a merged fix still needs an editor check or packaged-build test.

4. 04

   Give non-engineers an issue form

   Give artists and production staff an issue form that asks for the build, expected result, actual result, and attachment. Do not make them choose repository labels that only engineering understands.

Best practices

Keep the issue as the work record

Use issue forms to collect the build, platform, reproduction steps, expected result, actual result, and evidence. Let the project organize that issue instead of copying its status into a second card.³

Separate merged, verified, and released

Track the merged change, runtime test, and release separately. Record the tested build and release version before marking the issue complete.

Reserve organization fields for shared meaning

Use an organization issue field only when repositories agree on the value and ownership. Keep repository-specific metadata in labels or local fields so one team cannot silently redefine another team's report.

Limit automation permissions

Start with built-in project workflows. Use a GitHub App with only the required repository and project permissions when custom organization automation is necessary. Archive completed items and review stale fields before adding another column.

Gotchas

Auto-add does not backfill old items

Enabling auto-add does not backfill existing matches, though an existing matching item can be added after a later update. Free allows one auto-add workflow, Pro and Team allow five, and Enterprise Cloud or Server allows 20.⁵

Organization fields do not work on every item

Draft items, pull requests, and issues from repositories outside the organization can show blank organization issue fields. Do not base a required workflow on a field those item types cannot carry.⁴

Built-in Done rules can overstate completion

A default workflow can set Status to Done when an issue closes or a pull request merges. Keep verification and release evidence separate when Done is supposed to mean the change worked in a packaged build.

Project access does not grant repository access

Giving someone access to a project does not reveal an item from a private repository they cannot access. Test the project and repository permissions separately before using a shared view for outside collaborators.¹⁰

The repository token cannot edit organization projects

The default GitHub Actions token is scoped to its repository and cannot access projects. Custom project automation needs a GitHub App or personal access token with suitable project access.⁷

Projects have hard size limits

A project supports up to 50 fields and 50,000 active plus archived items. Organization issue fields have a separate limit of 25 per organization. Long-lived intake projects need a deliberate archive and deletion policy.¹⁹¹³

Adoption checklist

• Decide which repositories and issue types the project includes, and reserve organization fields for values with the same meaning across those repositories.
• Document the difference between Done, merged, verified, and released.
• Give non-engineering contributors a short issue creation path.
• Review Action permissions before allowing workflows to change project fields.
• Link builds, files, and reviews with stable identifiers.

Related guides

• Project FeedProject management with built-in file review.
• JiraWork tracking with configurable fields, approval workflows, boards, and release reports.
• LinearIssue tracking with projects, milestones, optional cycles, and GitHub or GitLab links.
• Frame.ioFile review with timecoded comments, version comparison, share links, and supported 3D previews.
• SyncSketchSynchronized review for animation dailies, drawovers, audio, and supported 3D files.

Sources

Official sources checked September 24, 2026.

1. 1About GitHub Projectsdocs.github.com
2. 2GitHub Projects best practicesdocs.github.com
3. 3Planning and tracking workdocs.github.com
4. 4GitHub Projects fieldsdocs.github.com
5. 5GitHub Projects auto-adddocs.github.com
6. 6GitHub Projects item limitsdocs.github.com
7. 7GitHub Actions project accessdocs.github.com
8. 8GitHub Projects documentationdocs.github.com
9. 9Organization issue fieldsdocs.github.com
10. 10Managing project accessdocs.github.com
11. 11GitHub Projects roadmap layoutdocs.github.com
12. 12GitHub Projects insightsdocs.github.com
13. 13Archiving project itemsdocs.github.com