GitHub has made issue types and issue fields generally available on repositories owned by personal accounts. The November 11 change gives solo developers and open-source maintainers account-level ways to classify work and attach structured details across repositories, instead of defining every category separately or squeezing every difference into labels.
Issue types make a shared vocabulary for work
Personal accounts start with Bug, Task and Feature. An account owner can customize those or create up to 25 types, then apply them to issues across user-owned repositories. Types appear in issue lists and can be used for filtering, searching and project views. A maker maintaining a few small apps could use Feature for planned behavior, Bug for broken behavior and Task for maintenance, then add a specific type only when the default vocabulary stops being useful.
Types answer what kind of work an issue represents. Fields answer additional questions about that work. Keeping these separate lets a maintainer use one Priority field across bugs and features rather than create a different label scheme in every repository.
Fields add reusable details to issues
GitHub provides Priority, Effort, Start date and Target date by default. Account owners can customize the defaults or create up to 25 fields. The announcement says fields can use text, number, date, single-select and multi-select values. The current issue-field administration guide lists text, number, date and single-select, but not multi-select; that is a documentation mismatch, so check the field-type choices in your account before designing a workflow around multi-select.
Fields belong to the account and can apply across its repositories. You can pin a field to selected issue types or to issues without a type, so a release date need not clutter a routine bug report. GitHub documents a limit of ten pinned fields per issue type and 100 options per single-select field. A project can contain up to 50 fields in total, including system fields, so a project already near that ceiling may need cleanup before adding more.
Check visibility before using fields in public work
For public repositories, a field can be restricted or public; restricted is the default. Restricted values are visible to the repository owner and collaborators with at least read access, while public values can be seen by anyone viewing the issue. GitHub says the setting is enforced in the web interface, API, issue timeline and search suggestions. Only public fields are available to public and internal projects. If a field is changed from public to restricted while used in a public project, GitHub removes it from that project.
Issue fields also differ from project fields. An issue field lives on the issue and keeps the same value wherever that issue appears. A project field belongs to one project, so the same issue can have different values in different projects. GitHub says both can coexist, but duplicating something like Priority can leave maintainers unsure which value to trust. The docs describe the issue field as the source of truth when you move a shared property to the issue.
A practical setup for an individual maker
Start with the three default types and add only the fields that will change a decision: perhaps Priority and Effort for every issue, with Target date pinned to Feature and Task. If a field contains information that should not be public, keep its visibility restricted and remember that collaborators can still see it. Then check the relevant issue lists and project views before migrating any existing project fields, especially if the project is already close to its 50-field limit.
The changelog says REST and GraphQL APIs and webhooks can manage issue types and fields, which makes the feature usable in automation as well as manual triage. GitHub also announced that labels and milestones can now be created directly from an issue; that is a separate convenience and does not replace the account-wide issue type or field model.
For makers who maintain public software, this is a way to make a personal issue backlog easier to filter and reuse as it grows. It does not turn a repository into a project board by itself: types and fields describe issues, while a project remains the place to organize selected work into a particular plan. GitHub's separate Dependabot alert policy is another reason to keep repository maintenance visible in a backlog.
What GitHub's Dependabot inactivity change means for maintainers