My First Open-Source Issue: Why I Chose Not to Fix the Code

On November 5, 2026, the open-source project I maintain, go-tour-i18n, received its first GitHub Issue.

I was quite happy to see someone proactively report a problem. After all, I had invested a lot of time in this project, so having someone actually read and use it, and be willing to point out issues, is in itself something to be glad about.

However, this Issue ultimately did not result in any code changes.

I checked the corresponding course content, confirmed the official Go upstream implementation, and finally chose to close the Issue with the reason not planned.

This was not because the reporter was wrong. On the contrary, from the perspective of Go syntax, the issue pointed out by the reporter was completely correct.

It is just that this seemingly incorrect code is intentionally part of the course’s teaching content.

1. The First Issue: math.pi Should Be Changed to math.Pi

The project received Issue #1: Fix typo in example: math.pi should be math.Pi.

The reporter pointed out that an example used math.pi, but since Go is case-sensitive, the correct way to write it should be math.Pi.

They also provided a comparison between the incorrect and correct versions.

Incorrect code:

fmt.Println(math.pi)

fmt.Println(math.pi)

Correct code:

fmt.Println(math.Pi)

fmt.Println(math.Pi)

Looking purely at code correctness, there is nothing wrong with this feedback.

Identifiers in Go are case-sensitive. math.pi and math.Pi are not the same identifier.

The name of the pi constant provided by the standard library math package is Pi, so math.Pi should indeed be used in normal code.

If this were business code in an ordinary project, or an example accidentally mistyped in documentation, then fixing it would be reasonable.

However, this report did not involve ordinary code, but rather a teaching lesson in Go Tour.

This required further verification: was the example code actually written incorrectly, or was the error intentionally kept to help learners understand a specific concept?

2. After Checking the Course Content, I Found the Error Was Intentionally Designed

I did not immediately modify the code as suggested in the Issue; instead, I first checked the corresponding lesson.

This code appears in the Go Tour lesson “Exported names”.

This lesson primarily introduces an important rule in Go:

In Go, an identifier is exported—and therefore accessible from other packages—only if its first character is an uppercase Unicode letter and it resides in a scope that permits exporting.

For example, Pi in the math package is an exported constant, so it can be accessed using math.Pi.

But the example in the lesson is intentionally written as:

package main

import (
    "fmt"
    "math"
)

func main() {
    fmt.Println(math.pi)
}

package main

import (
    "fmt"
    "math"
)

func main() {
    fmt.Println(math.pi)
}

If you run it directly, a compilation error will occur.

At first glance, this does seem a bit strange: why would the official tutorial provide a piece of code that cannot compile properly?

After continuing to read the lesson description, the reason becomes very clear.

The lesson requires learners to first run the code, observe the error, then change math.pi to math.Pi, and run it again.

In other words, the entire learning process is intentionally divided into several steps:

1. Run the example containing math.pi.
2. Observe the error returned by the compiler.
3. Following the rules for exported names, change pi to Pi.
4. Run it again to confirm that the code works properly.

Through this process, the lesson allows learners to actually experience Go’s export rules, rather than just reading a text description.

If I directly changed math.pi to math.Pi, the code would compile correctly, but learners would lose the opportunity to observe the error and fix it themselves.

The code itself would become correct, but the instructional design would be broken.

3. Further Confirmation: The Official Go Upstream Also Keeps This Error

After confirming the instructional intent, I checked the project’s corresponding upstream source.

The goal of go-tour-i18n is to provide multilingual support for Go learning content, not to arbitrarily modify the technical design of the official course.

For this type of project, determining whether a piece of code should be modified cannot be based solely on whether it can run independently; its role within the original course must also be considered.

This inspection revealed the following:

• The current example is byte-for-byte identical to the corresponding file in the official golang/website upstream.
• The official upstream still uses math.pi.
• The course text explicitly requires learners to find the error and then change it to math.Pi.

These three facts combined are sufficient to confirm that this is not an error caused by translation, copying, or maintenance mistakes.

It is an intentionally preserved teaching example from the original course.

Therefore, there was no need to modify it separately in my project.

In fact, modifying it just to eliminate a surface-level compilation error could cause the local content to diverge from the official course.

For a multilingual project based on official content, this is not an ideal approach.

4. Explaining the Reason to the Reporter, Then Closing the Issue

After confirming the issue, I replied in English within the Issue.

The main points of the reply were:

First, I thanked the reporter for pointing out the problem.

I then explained that math.pi is not a typo, but an intentionally designed example in the Go Tour “Exported names” lesson.

The lesson expects learners to first run the code, observe the compilation error, and then proactively change math.pi to math.Pi.

This helps learners understand the rule in Go that exported names must begin with an uppercase letter.

I also added that this file is kept consistent with the official upstream, and the official version still uses the same instructional design.

Therefore, no code changes were needed at this time.

After providing the explanation, I prepared to close the Issue.

GitHub provides several different reasons for closing:

• Close as completed: The issue is complete, fixed, or resolved.
• Close as not planned: No plans are made to implement the corresponding changes.
• Close as duplicate: This issue is a duplicate of another Issue.

Using Close as completed was clearly not appropriate this time.

I had not made any code modifications, nor had I completed any fix.

Similarly, there was no duplicate Issue to reference.

Therefore, I ultimately chose:

Close as not planned

On November 6, 2026, Issue #1 was officially closed.

The entire handling process produced no code changes, but the issue had been clearly explained.

5. This Experience Made Me Rethink What Counts as a Bug

If you only look at the Issue title, it is easy to assume this is just a simple typo.

Even without in-depth investigation, it is clear that math.pi cannot correctly reference the pi constant from the standard library in Go code.

If I had modified the code immediately upon receiving the report, it might have only taken a few minutes.

However, doing so would have introduced a new problem: the incorrect example originally intended for teaching would have been corrected by me.

This made me feel that, when maintaining open-source projects, it is necessary to at least distinguish between two situations.

One is a genuine implementation error.

For example, the program’s actual behavior is inconsistent with expectations, or a piece of code in the documentation contains an accidental mistake. These types of issues should generally be fixed.

The other is intentionally designed special behavior.

Especially in scenarios like tutorials, exercises, and test cases, the fact that a piece of code cannot execute properly does not necessarily mean it contains a bug that needs fixing.

Sometimes, the error itself is part of the learning process.

These two situations cannot be accurately distinguished solely by whether the code runs or not.

You also need to understand the context of the code and the goal of the original design.

For go-tour-i18n, there is an additional factor: upstream content is an important basis for the project.

If you find something that seems anomalous, it is safer to first confirm the official source and original intent rather than directly making local modifications.

6. Closing an Issue Does Not Mean Ignoring Feedback

There is one more thing from this experience that left a deep impression on me.

In the past, I might have been more likely to interpret receiving an Issue as: a problem has occurred in the project and needs to be fixed as soon as possible.

But after actually handling it this time, I realized the two cannot simply be equated.

An Issue provides a problem that needs investigation, not necessarily a confirmed Bug.

Maintainers need to determine whether the problem is valid, whether it requires changes, and what handling approach truly aligns with the project’s goals.

Even if the final decision is not to modify the code, you should still try to explain the reason clearly to the reporter.

The syntax issue pointed out by the reporter this time does indeed exist; it just has a clear instructional purpose within the course.

Therefore, the final choice not to modify the code does not mean the feedback was worthless.

On the contrary, without this feedback, I probably would not have specifically re-verified this particular course design.

For projects maintaining multilingual technical documentation, such verification is itself a valuable quality check.

7. Final Thoughts

This was the first GitHub Issue received by go-tour-i18n.

The final outcome was simple:

No code was modified, no fix commits were made; I simply confirmed the design intent of the official course, explained the reason to the reporter, and then closed the Issue.

But I think this experience is still worth recording.

It reminded me that maintaining an open-source project is not about immediately modifying things upon receiving a report, but rather first confirming the problem and then deciding whether changes are needed.

Especially for technical tutorials and documentation projects, correctness is not just about whether the code runs; it also includes whether the course content achieves its original teaching purpose.

Some code that looks incorrect is there precisely to teach readers what correct code is.

Keeping math.pi this time is one such example.

Related Links

• GitHub Issue: Fix typo in example: math.pi should be math.Pi #1
• Project repository: shuijingwan/go-tour-i18n
• Official Go Tour lesson: Exported names