OpenSource Together

Command Palette

Search for a command to run...

Chapter 3: Reading and Understanding Issues

Issues are where most open source work begins.

They are used to report problems, propose ideas, and discuss changes.

This guide helps you read issues with context and confidence.


What Issues Are Used For

Issues are used to:

  • report bugs
  • request features
  • propose improvements
  • discuss ideas
  • track work

They are shared problem spaces, not task lists.


Not All Issues Are the Same

Issues can represent very different things.

Common types include:

  • bug reports
  • feature requests
  • questions
  • design discussions
  • maintenance tasks

Understanding the type of issue helps you respond appropriately.


Reading an Issue With Intent

When opening an issue, focus on:

  • the problem being described
  • the context provided
  • the expected outcome
  • any constraints mentioned

Do not jump to solutions immediately.


Understanding the Problem Statement

A good issue explains:

  • what is happening
  • what was expected
  • why it matters

If this is unclear, the issue may need clarification before action.


Looking for Context and History

Many issues reference:

  • previous issues
  • pull requests
  • discussions
  • documentation

Follow these links to understand the full picture.


Reading Comments Carefully

Comments often contain:

  • clarifications
  • alternative approaches
  • maintainer decisions
  • scope adjustments

The most important information is not always in the first message.


Identifying Maintainer Signals

Maintainer comments often signal:

  • whether the issue is accepted
  • priority level
  • preferred direction
  • potential blockers

These signals guide whether and how to engage.


Understanding Labels

Labels help categorize issues.

Common labels include:

  • bug
  • enhancement
  • documentation
  • discussion
  • good first issue
  • help wanted

Labels provide quick orientation but are not always complete.


Good First Issues

Good first issues usually:

  • have clear descriptions
  • are limited in scope
  • include guidance or context
  • are low-risk changes

They are designed to reduce onboarding friction.


Issues to Be Careful With

Be cautious with issues that:

  • are very broad
  • lack clear goals
  • involve major refactors
  • have heated discussions
  • show unresolved disagreement

These require more context and experience.


When to Comment on an Issue

It is appropriate to comment when:

  • asking for clarification
  • confirming interest
  • sharing relevant information
  • proposing a small, scoped approach

Avoid commenting just to say “I’ll work on this” without context.


Understanding Ownership and Assignment

Some projects assign issues formally.

Others rely on informal signals.

Before starting work:

  • check if someone is already working on it
  • ask if the issue is available
  • respect existing claims

Coordination prevents duplicated effort.


Issues as Learning Tools

Even without contributing, reading issues teaches:

  • how decisions are made
  • what problems matter
  • how trade-offs are discussed

Issues are a window into project thinking.


Accepting Uncertainty

It is normal to feel unsure when reading issues.

At this stage:

  • you are building familiarity
  • you are not expected to have answers
  • observation is valuable

Understanding grows with exposure.


What You Should Be Able to Do Now

You should now be able to:

  • identify different types of issues
  • understand the problem being discussed
  • recognize maintainer signals
  • decide whether an issue feels approachable

That is enough to move forward.


Reflection

Ask yourself:

  • Which issues feel clear?
  • Which feel confusing?
  • What information is missing?

These observations help you grow as a contributor.

Earl Grey Badge

You've Completed Chapter 3

Well done! You've learned about reading and understanding issues.

Next Up

4: Creating Your First Issue