The practical attraction is consistency: classify the work, record the details, and spend less time deciphering your own backlog six months later.
What personal accounts can configure
GitHub’s announcement sets out two complementary tools:
| Capability | Defaults | Customization |
|---|---|---|
| Issue types | Bug, Task, Feature | Customize the defaults and create up to 25 types |
| Issue fields | Priority, Effort, Start date, Target date | Customize the defaults and create up to 25 fields |
Supported field formats include text, number, date, single-select, and multi-select. Fields can be pinned to particular issue types or made available on issues without a type. Configuration lives in personal account settings under Planning, on the Issue types and Issue fields pages.
These are account-level definitions rather than a separate configuration exercise for every repository. GitHub’s documentation states that user-defined fields apply across repositories, while its REST documentation confirms that repositories inherit enabled issue types from their owner.
For a maintainer, a sensible starting point might be keeping the three default types and adding only the metadata needed for prioritization. A backlog should help organize development, not become a second application to maintain.
How to start using them
For personally owned repositories, the account owner manages the definitions. GitHub documents the following setup paths:
- Create an issue type: Open personal Settings, select Planning → Issue types, and choose Create new type. Enter a name and description, choose a color, and click Create. Existing types can also be edited or disabled.
- Create an issue field: Open Planning → Issue fields, choose New field, enter a name, and select its field type. Configure applicable options, visibility, and type pinning, then click Create.
- Apply the metadata: Set the type and field values when creating an issue or opening an existing one. GitHub also supports using them in Projects for custom views and bulk updates.
GitHub’s usage documentation explains what success looks like: fields appear in an issue’s right-hand sidebar, and fields pinned to its selected type appear automatically. If a field is missing, use Add field in the sidebar; entered values save automatically. People with triage access or greater can set and edit field values.
Two details worth checking before reorganizing a backlog
Issue fields and project fields are not interchangeable. GitHub’s documentation explains that an issue field’s value lives on the issue and stays consistent across projects containing it. A project-level field belongs to one project, so the same issue can carry different values in different projects. Both can coexist, but duplicate fields tracking the same concept—such as two versions of “Priority”—can create confusion.
That distinction suggests a useful dividing line: use issue fields for shared facts about the work, and retain project-specific fields where different planning contexts genuinely need different values.
Visibility also matters. GitHub documents Restricted as the default field visibility. For personally owned repositories, restricted values are visible to the owner and collaborators with at least read access; public fields are visible to anyone viewing the issue. Only public-visibility fields are available in public projects. A field missing from a public project may therefore be a visibility issue rather than a failed configuration.
There are boundaries to the feature, too. GitHub currently documents issue fields as available on issues, not pull requests, and says values cannot be populated through issue templates or URL query parameters. Its supported alternatives include the sidebar, Projects, APIs, and GitHub Actions.
Automation and fewer navigation detours
GitHub says both issue types and fields can be managed programmatically through REST, GraphQL, and webhooks. The same announcement also adds a smaller convenience: users can create labels and milestones directly from an issue when a search finds no matching entry, without visiting the repository’s separate management pages.
For automation builders, GitHub’s documentation supplies a useful detail: the issues event uses field_added when a field value is set or updated, and field_removed when a value is cleared. The payload includes the field name, type, value, and previous value. Despite its name, field_added is therefore relevant to changes, not just first-time assignment.
The most useful approach is incremental: establish a small shared vocabulary, test it on a few issues, and only then expand. Personal-account maintainers now have the structured tools; keeping the structure understandable remains the human part.