Creating and Reading GitHub Issues
This repo uses two conventions beyond GitHub’s built-in issue fields: an Issue Type
(Task / Bug / Feature) and a custom single-select Priority field (Urgent / High /
Medium / Low). Type and Priority carry that information instead of labels — the only labels
in regular use are the component: * ones below.
Component labels
Each issue should get one component: * label indicating the area it touches:
| Label | Scope |
|---|---|
component: proposals |
Proposal creation/listing/editing |
component: voting |
Voting (table + Quick Voting) |
component: scheduling |
Sessions, session grid, scheduling phase |
component: admin |
/admin backend |
component: attendees |
Attendee list, profiles, RSVPs on profiles |
component: 1-on-1s |
1-on-1 meetings: booking, availability, column |
component: auth |
Login, passwords, protected accounts |
component: infra & dev |
CI, testing, tooling, perf, security, upgrades |
component: notifications |
Email and in-app notifications |
component: ui/ux |
Cross-cutting styling/layout/accessibility |
component: other |
Reviewed, no suitable component |
gh issue create/edit can set labels directly (no GraphQL needed):
gh issue edit 123 --add-label "component: scheduling"
Neither field is exposed by gh issue create/gh issue edit/gh issue view — both require the
GraphQL API (gh api graphql).
Reading an issue’s type and priority
gh issue view --json doesn’t expose either field. Use REST instead:
gh api repos/schellingboard/schellingboard/issues/123 --jq \
'{type: .type.name, priority: (.issue_field_values[]? | select(.issue_field_name=="Priority") | .single_select_option.name)}'
IDs needed for mutations
Repo id, issue type ids, and the Priority field/option ids (stable, but re-fetch if unsure):
gh api graphql -f query='
{ repository(owner: "schellingboard", name: "schellingboard") {
id
issueTypes(first: 10) { nodes { id name } }
} }'
gh api graphql -f query='
{ repository(owner: "schellingboard", name: "schellingboard") {
issueFields(first: 20) { nodes { ... on IssueFieldSingleSelect { id name options { id name } } } }
} }'
Known values as of 2026-07-22 (double-check if a query above disagrees):
| Name | ID |
|---|---|
| Repo | R_kgDOO4ASpA |
| Type: Task | IT_kwDODU0pG84Bqq5u |
| Type: Bug | IT_kwDODU0pG84Bqq5v |
| Type: Feature | IT_kwDODU0pG84Bqq5w |
| Priority field | IFSS_kgDOAhz4lg |
| Priority: Urgent | IFSSO_kgDOA7KbIA |
| Priority: High | IFSSO_kgDOA7KbIQ |
| Priority: Medium | IFSSO_kgDOA7KbIg |
| Priority: Low | IFSSO_kgDOA7KbIw |
Creating an issue with type and priority set
gh api graphql -f query='
mutation($repo: ID!, $title: String!, $body: String!, $type: ID!, $prioField: ID!, $prioOpt: ID!) {
createIssue(input: {
repositoryId: $repo, title: $title, body: $body, issueTypeId: $type,
issueFields: [{ fieldId: $prioField, singleSelectOptionId: $prioOpt }]
}) { issue { number url } }
}' \
-f repo=R_kgDOO4ASpA \
-f title="Issue title" \
-f body="$(cat body.md)" \
-f type=IT_kwDODU0pG84Bqq5w \
-f prioField=IFSS_kgDOAhz4lg \
-f prioOpt=IFSSO_kgDOA7KbIw
Changing type/priority on an existing issue
Get the issue’s node id first (number is not a valid GraphQL id):
gh api graphql -f query='{ repository(owner: "schellingboard", name: "schellingboard") { issue(number: 123) { id } } }'
Then:
# Type
gh api graphql -f query='
mutation($issue: ID!, $type: ID!) {
updateIssueIssueType(input: { issueId: $issue, issueTypeId: $type }) { issue { number } }
}' -f issue=<issue node id> -f type=<type id>
# Priority
gh api graphql -f query='
mutation($issue: ID!, $field: ID!, $opt: ID!) {
setIssueFieldValue(input: { issueId: $issue, issueFields: [{ fieldId: $field, singleSelectOptionId: $opt }] }) { issue { number } }
}' -f issue=<issue node id> -f field=IFSS_kgDOAhz4lg -f opt=<priority option id>
Body format conventions
Match existing issues’ style:
- Sections as needed, in this rough order:
## Overview/## Current behavior/## Proposed behavior(or## Proposed change/## Proposed fix) /## Why/## Impact/## Notes - Small bugs/tasks can just be a short paragraph — headers aren’t mandatory.
- Reference file:line for code-specific bugs (e.g.
`app/actions/user-auth.ts:130`). - Keep it succinct; this is a scheduling app issue tracker, not a spec document.