Issues? What Issues?

Issues? What Issues?

Every project has its quirks, bugs, and bright ideas waiting to be organized.
That’s where GitHub Issues come in — they’re our project’s to-do list, bug tracker, idea board, and accountability system all rolled into one.

Let’s learn how to use them like pros — with a bit of Professor Solo flair, of course.

---

🧠 What an Issue Really Is

A GitHub Issue is a public (or private) record of something that needs attention.
It could be a bug, a new feature, a question, or a reminder for your future self.

Type	Example
🐛 Bug	“Navbar doesn’t collapse on mobile”
💡 Feature	“Add dark mode toggle”
🧰 Task	“Update README with install steps”
🤔 Question	“Should we switch from Flexbox to Grid?”

💡 Professor Solo’s Pro Tip:
An Issue isn’t a complaint — it’s a conversation starter.

---

🧱 Step 1: Creating an Issue

1. Go to your repo on GitHub
2. Click the Issues tab
3. Hit New issue
4. Add a clear title and a detailed description
5. Optionally assign it to someone (even yourself) or add labels like bug, enhancement, or help wanted

Example:

Title: Navbar doesn’t collapse on mobile
Description:

Steps to reproduce:
1. Open the site on a mobile browser
2. Tap the hamburger menu
Expected: menu expands
Actual: nothing happens

💡 Professor Solo’s Pro Tip:
Write issues so anyone could pick them up — including future-you.

---

🧭 Step 2: Labels and Organization

Labels are visual tags that help categorize and prioritize work.
You can color-code them for clarity:

Label	Meaning
🟥 bug	Something is broken
🟩 enhancement	A new feature or improvement
🟦 documentation	Docs need updating
🟨 question	Needs discussion or clarification

We can create custom labels too — maybe student-submission, accessibility, or urgent.

---

🧩 Step 3: Linking Issues to Commits or PRs

One of GitHub’s slickest tricks is automatic linking.
When we reference an issue number in a commit or PR, GitHub connects them.

Example:

git commit -m "Fix navbar toggle on mobile (Fixes #12)"

When this commit merges into main, Issue #12 automatically closes.
We can also use keywords like Closes, Resolves, or Addresses.

💡 Professor Solo’s Pro Tip:
This trick keeps our history tidy — no need to manually close issues one by one.

---

🧱 Step 4: Using Issues for Solo Projects

Even if we’re flying solo, Issues make great project planners.
Use them like a personal Kanban board:

📝 TODO: Add About page
🚧 IN PROGRESS: Style contact form
✅ DONE: Fix header alignment

We can reference them in commits, check them off in comments, or even use GitHub’s “Projects” view to drag and drop progress.

---

🤝 Step 5: Issues in Teamwork

In collaborative repos, Issues are the conversation hub.
Each Issue can have its own thread where team members discuss solutions, assign owners, and track progress.

Role	Example
Reporter	“The images aren’t loading.”
Developer	“I’ll take this one — likely a path issue.”
Reviewer	“Fix confirmed in branch fix/image-paths.”

Communication lives right where the problem started — alongside the code.

---

⚙️ Step 6: Milestones (Optional but Cool)

Milestones group Issues together toward a common goal — like a project phase or release version.

Examples:

• v1.0 Launch
• Accessibility Overhaul
• Midterm Sprint

💡 Use milestones sparingly — they’re great for clarity, not clutter.

---

✅ Mission Check: No Issue Too Small

We can now:

1. Create Issues to track bugs, features, or questions
2. Use labels and milestones for organization
3. Link Issues to commits and PRs automatically
4. Use Issues for solo productivity or team collaboration
5. Keep our project communication clean and traceable

---

💡 Professor Solo says:

“Every Issue is an opportunity — not a problem.
Own it, tag it, and make it part of the process.”