CHAPTER 16

Issues, labels, milestones, projects

Everything the club needs to do has been living in a group chat. Group chats don't have a search function anyone trusts.

A month in, the group chat problem

Scroll back through the club's WhatsApp group and count how many separate times someone's asked "wait, are we doing the git workshop the first week of August or the second?" — Vidha's answered it four times, from memory, because the actual decision lives nowhere except everyone's individual recollection of a conversation from three weeks ago. Somewhere in that same scrollback is a real bug report about the mobile nav (already fixed, nobody marked it done), a genuine feature idea Anvesha had at 1 AM that got buried under sixty unrelated messages, and Ishaan quietly re-asking "is anyone working on the beginner docs pass?" for the second time because he can't tell if his first ask got missed or answered.

None of this is a Git problem. It's a "where do facts live" problem, and GitHub already ships the answer, sitting unused this entire time.

An issue is just a fact, written down once

Anyone can open one — bug, feature idea, question, task. Each has a title, a Markdown body, optional labels, optional assignees, an optional milestone, and a comment thread that becomes the actual permanent record of the decision, instead of forty messages nobody can find again.

the four-times-answered question, answered once, permanently

$ gh issue create --title "Confirm: Git workshop date" --body "First or second week of August?"

https://github.com/accelerate-muj/resources/issues/7

Vidha answers once, in the thread, with the actual reasoning — DSW's ten-day venue lead time means it has to be the second week if it's in-person. Now that answer has a permanent URL. Next time someone asks, the reply is a link, not a fourth retelling.

Templates — so the report already has what you need

A file at .github/ISSUE_TEMPLATE/bug.yml pre-structures what a bug report has to include, so "the mobile nav is broken, again" arrives with enough detail to actually act on:

name: Bug report
description: Something is broken
labels: ["bug", "triage"]
body:
  - type: input
    id: what
    attributes:
      label: What happened?
      placeholder: e.g. Login button does nothing on mobile
    validations:
      required: true
  - type: textarea
    id: steps
    attributes:
      label: Steps to reproduce
  - type: dropdown
    id: browser
    attributes:
      label: Browser
      options: [Chrome, Firefox, Safari, Edge, Other]

Repeat the pattern for feature.yml and question.yml. "New issue" becomes a picker instead of a blank box, and every bug report that comes in already has the reproduction steps a maintainer would otherwise have to chase down separately.

Labels — cheap, and worth using generously

Type:      bug · feature · docs · chore · question
Status:    triage · in-progress · blocked · needs-info
Priority:  P0 (drop everything) · P1 (this sprint) · P2 (soon) · P3 (maybe)
Area:      area/website · area/resources · area/dashboard
Effort:    good first issue · help wanted

That good first issue label isn't decoration — GitHub surfaces it in a dedicated filter that newcomers browsing the org can find on their own. Vidha's issue #7 from the very first chapter of this story ("add a beginner git track") carried that exact label, which is genuinely part of why Ishaan found something approachable to fix in Chapter 11 without anyone having to personally hand it to him.

Milestones — a deadline with a progress bar attached

"Website v1 — launch by August 31" becomes a milestone. Every issue and PR assigned to it rolls up into one progress view: how many closed, how many open, how close the club actually is. Far more honest than "we're basically done," which is what the group chat currently says every single week regardless of actual state.

Projects (v2) — the board that spans every repo at once

A GitHub Project is a live table-and-kanban view over any set of issues and PRs, from any repo in the org simultaneously — one board that shows a website bug, a resources doc task, and a records-adjacent planning issue side by side, instead of three separate repo tabs. Columns can be Status (Todo / Doing / Done), Priority, Assignee, or anything else you define. Automations handle the busywork: close an issue, it slides to Done; open a PR, it jumps to In Review — set once, silent forever after.

Cross-referencing, once and for all

Write this	Effect
`#7`	Links to issue/PR 7 in the current repo
`accelerate-muj/resources#7`	Links across repos
`@vidhaaaaaa`	Notifies that person
`@accelerate-muj/core-committee`	Notifies the whole team
Closes / Fixes / Resolves `#7` in a PR body	Auto-closes the issue when the PR merges — exactly what happened with Ishaan's PR in Chapter 13

Discussions — for the 1 AM idea that isn't a task yet

Anvesha's late-night feature idea isn't a task with a clear "done" state — it's a conversation that needs other people's opinions before it becomes one. That's what Discussions (Settings → Features → Discussions) are for, distinctly from issues: open-ended threads, Q&A, announcements, show-and-tell, without pretending something has a defined outcome before it actually does.

THE QUICK SORT

Has an outcome ("do X")? Issue. Is a conversation ("thoughts on X?")? Discussion. Is a Board decision that needs a permanent, restricted record? Meeting minute in the private records repo, not either of the above.

CHECK

Anvesha has a half-formed idea for a new homepage feature and wants the team's opinion before committing to anything. What should she open?

An issue implies a defined task heading toward a specific "closed" state. Her idea doesn't have that yet — it needs discussion first. A Discussion thread is built exactly for open-ended conversation that might later spawn a real issue once it's actually decided.

The venue-date issue, the bug reports, the beginner-track issue Ishaan picked up — all of it has been filed by hand, one click at a time. There's a category of work nobody should have to remember to do manually at all: running the lint check every single push, catching a broken build before it reaches review. That's next.

Branch protection GitHub Actions