What you'll learn
Quick Answer
An issue tracker records what needs doing, who is doing it and what state it is in. A good ticket states the problem and how you will know it is solved. Understanding the vocabulary matters more than the specific tool.
The problem trackers solve
On a small project you remember what needs doing. With eight people and forty things in flight, memory and chat messages fail — work is duplicated, forgotten, or done in the wrong order, and nobody can answer "what is the status of X?"
A tracker gives every piece of work an identity: a number, a description, an owner, a state, and a history of what happened to it.
The secondary benefit matters more than students expect: it is a record. Two years later, "why does this code check the user's region?" is answered by the ticket linked in the commit message. That is frequently the only surviving explanation.
Jira is the most common in Indian companies, particularly larger ones. GitHub Issues, Linear and Asana solve the same problem with different opinions. The tool matters less than the practice.
The vocabulary you will hear
- Issue or ticket — one unit of work. Often typed as Story, Bug, Task or Epic.
- Epic — a large piece of work containing many tickets. "Checkout redesign."
- Story — a user-facing change, conventionally phrased "As a student, I want to filter by semester, so that I can find my courses faster."
- Backlog — everything not yet scheduled, ordered by priority.
- Sprint — a fixed period, usually two weeks, with an agreed set of tickets.
- Board — the columns showing state: To Do, In Progress, In Review, Done.
- Story points — relative size, not hours. See Agile and Scrum for students.
- Blocked — cannot proceed until something else happens. Saying so early is genuinely valued.
You will also hear "groom the backlog" (review and prioritise) and "the ticket is in review" (code written, awaiting review).
What a useful ticket contains
Most tickets are bad, and bad tickets waste more time than they save.
Weak: "Fix login". Fix what? For whom? How will anyone know it is done?
Useful:
Title: Login fails silently when email contains uppercase letters
Steps: 1. Register with Asha@example.com 2. Log in with the same address 3. Observe
Expected: Logged in. Actual: "Invalid credentials", no error logged.
Notes: Registration lowercases the address, login does not.
Done when: Login succeeds regardless of case, and a test covers it.
Steps to reproduce, expected versus actual, and a definition of done. The last is the one people skip and it is what prevents a ticket bouncing between developer and reviewer.
For a task rather than a bug, state the outcome rather than the implementation. "Users can reset their password by email" leaves room for judgement; "Add a POST /reset endpoint using library X" does not.
Using it well as a junior
- Update the status. Move the ticket to In Progress when you start. It sounds trivial and it is how your team knows what is happening without asking.
- Comment when you learn something. "This is caused by the auth middleware, not the form" saves the next person an hour, including future you.
- Say you are blocked immediately. Sitting stuck for two days to avoid looking incapable is the most common junior mistake. Raising a blocker on day one is what a good team wants.
- Link the ticket in your commits and pull request. Most tools link automatically from a ticket ID in the message, which builds the historical record.
- Ask before splitting or expanding scope. Discovering more work is normal; silently doubling a ticket's size is not.
Using one on a college project
Worth doing, and GitHub Issues is free and sits next to your code.
Three practices carry almost all the benefit:
- One issue per piece of work, with a clear title.
- A board with three columns — To Do, In Progress, Done — so everyone can see the state without a meeting.
- Limit work in progress. Four half-finished features are worth less than one finished one.
It also solves a real problem in group projects: the visible record of who did what. When contribution is disputed at evaluation time, issues and commits are evidence.
And it is genuinely worth mentioning in interviews. "We tracked work in GitHub Issues and reviewed each other's pull requests" describes a way of working most graduates have never practised.