Skip to content

Setting Up a Project

The defaults work. You can create a project, start adding issues, and never touch Project Settings — and for a lot of side projects, that's the right move. But when a project is going to stick around for a while, spending ten minutes up front on configuration pays off every time you triage a bug, move a card, or look back at what shipped. This guide walks through the decisions that matter and the order to make them in.

Step 1: Name and Prefix

When you create a project, two fields matter more than the rest:

  • Title — Change this anytime. Don't overthink it.
  • Prefix — The 1–4 character code that builds reference numbers (FOX-001, FOX-042). You can change it later, but existing references won't update — pick a prefix you'll still want to read six months from now.

A good prefix is short, distinctive, and easy to type. FOX, APP, WEB, ATLS. Avoid generic codes like P1 that'll blur together when you're bouncing between projects.

Step 2: Decide Your Workflow

Before you configure statuses, answer: how does work actually move through my process?

For a solo project, that might be:

To Do → In Progress → Done

For a small team with review:

Review → Ready To Do → In Progress → Test → Done

For a bug-heavy project with triage:

New → Triaged → In Progress → Verifying → Done

There's no right answer — just what matches reality. The trap is configuring statuses you think you should have ("Blocked," "Waiting on External," "On Hold") and never using them. Start with the minimum and add more when the absence of a status makes something confusing.

Step 3: Configure Statuses

Open Project Settings (⌘⇧P on Mac, or settings → Project Settings on iOS) and edit the Statuses list:

  1. Rename or delete the defaults you don't want
  2. Add the statuses from your workflow sketch
  3. Put them in left-to-right order — this becomes your board column order
  4. Assign each status to a category: To Do, In Progress, or Done
  5. Pick an icon for each

The category assignments matter. Fox uses them to drive Done Status Behavior — moving an issue into a Done-category column can automatically close it or prompt for a resolution.

Also set a Default Status — the status new issues get created with when you don't specify one.

Step 4: Set Up Issue Types

The default types (Bug, Feature, etc.) cover most projects. Add any extras your work actually needs:

  • Chore — Maintenance work that isn't a bug or a feature
  • Spike — Time-boxed investigation with no guaranteed output
  • Documentation — Docs-only changes
  • Refactor — Internal code changes with no behavior change

Each type gets an icon. Types are for filtering later — "show me just the bugs in this milestone" — so add types you'll actually use as filters, not types that describe work but never get queried.

Step 5: Customize Priorities

Priorities are the most personal attribute. Some people want just Urgent / Normal; others want five levels. The defaults (High / Medium / Low) are a fine starting point.

Each priority gets a color, which is what makes high-priority items jump out on the board. Make your highest priority bright and your lowest priority muted — your eye should find urgent work without thinking.

Step 6: Define Resolutions

Resolutions describe how closed issues were resolved. A minimal set:

  • Fixed — Completed as intended
  • Won't Fix — Intentionally closed without being addressed
  • Duplicate — Another issue already covers this

Optional additions:

  • Cannot Reproduce
  • Deferred
  • By Design

Resolutions are the single biggest thing that pays off in retrospectives — "how many of last month's bugs were actually reproduced?" — so err on the side of having them even if you think you won't use them.

Step 7: Plan Your Versions and Milestones (Or Don't)

Versions & Milestones are entirely optional. Three common patterns:

  • Flat — No versions, no milestones. Everything lives in the project. Best for small, ongoing projects.
  • Milestones only — Group issues by goal but don't track releases. Best when you have features to ship but no formal release cadence.
  • Versions with milestones inside — Track releases and the features inside them. Best for real product work with real version numbers.

Don't pick one on day one if you're not sure — Unsorted is a fine place to start, and you can always add structure later.

Step 8: Add Your First Batch of Issues

Now you're ready. Add the first few issues — titles are enough, properties can come later. If you're migrating from another tool, CSV Import can bulk-create hundreds of issues at once.

When to Revisit

Come back to Project Settings when:

  • You keep wanting a status that isn't there
  • A type or priority never gets used
  • You close issues and wish there were a better resolution for them
  • Your board feels crowded and a column-splitting helps

Fox's attributes are easy to change — the cost of editing them later is low, so don't agonize up front.

See Also