Where new issues go

A product manager creating an issue does not always know which repository it belongs in, and a support person filing one from a customer’s message knows even less. Pealboard asks once, here, and remembers the answer as the workspace’s default repository: where an issue goes when the person creating it, or a portal’s request type, names no repository of its own.

The suggestion

Pealboard proposes one, in order:

1. A connected repository named issues, roadmap, product, planning, tracker or support — the name teams already give the one repository they track work in.
2. Failing that, once the first sync has run, the connected repository with the most open issues.
3. Failing both, nothing. The picker is still there; choose one yourself, or select Decide later.

A match is shown as Suggested: repository. reason. Accept it, or select Choose a different repository to pick another from the ones you just connected.

If none of your repositories fit

Select Create an issues repository on GitHub. It opens GitHub’s own new-repository page, with the name filled in.

Pealboard does not create repositories. The GitHub App does not ask for GitHub’s Administration permission, so it cannot create one on your organization or account, even this one. After you create it on GitHub, add it to the Pealboard App’s repository list — Settings → GitHub → Change repositories on GitHub — and it appears here on the next sync.

Deciding later

Select Decide later and nothing is written. A workspace with no default repository is a valid, ordinary state: Create and edit an issue asks for a repository every time instead of pre-filling one, and a portal’s request type needs one of its own if the workspace never gets a default.

Changing it afterwards

Settings → Workspace → Default repository, admin role or above. Changing it only affects what happens next — an issue already created, and a request type that already resolved its own repository, do not move.

Next

The first sync.