Why the field type matters more than the field name
You are setting up a GitHub project and the “New field” dropdown asks you to pick a type: Text, Number, Date, Single select or Iteration.
Pick the wrong one and you end up with a column that cannot be filtered the way you need, or a planning field that fights your workflow.
This guide walks through what each field type does, what it is good at, and the checks you can run before committing to one.
All product behavior described here comes from GitHub’s own field documentation for Projects, cited in each section.
Editorial suggestions and example scenarios are labeled as such.
In GitHub Projects, the field type controls what you can put in the column and how you can filter by it.
Iteration fields support grouping and sorting.
You can group by iteration, filter to a single iteration and sort by it (About iteration fields).
A field called “Priority” behaves completely differently as freeform text than as a single select with fixed options.
The name is for humans; the type is for the tool.
So the real decision is not “what should I call this column?” but “what kind of information goes here, and how do I want to slice it later?”
Answer that first, and the type usually picks itself.
Text fields: notes and freeform context
Text fields hold freeform text, such as notes or any other unstructured information.
GitHub’s documentation shows exact-match filtering with field:“exact text” (About text and number fields).
Filtering for text without naming a field also matches item titles.
Use a text field when the value genuinely varies from item to item and you cannot predict the options in advance.
Typical editorial examples: a short risk note, a link to a design discussion, or a one-line summary of why an item exists.
Two things to keep in mind:
- Use exact-text filters for specific values; consider a single select when the team needs one shared set of options.