Unlike many projects on GitHub, the Go project does not use its bug tracker for general discussion or asking questions.
We only use our bug tracker for tracking bugs and tracking proposals going through the [Proposal Process](https://go.dev/s/proposal-process).

For asking questions, see:

* [The golang-nuts mailing list](https://groups.google.com/d/forum/golang-nuts)

* [The Go Forum](https://forum.golangbridge.org/), a web-based forum

## Before filing an issue

If you are unsure whether you have found a bug, please consider asking in the [golang-nuts mailing
list](https://groups.google.com/forum/#!forum/golang-nuts) or [other forums](https://golang.org/help/) first. If
the behavior you are seeing is confirmed as a bug or issue, it can easily be re-raised in the issue tracker.

## Filing issues

Go is the work of thousands of contributors. We appreciate your help!

To contribute, please read the contribution guidelines at https://go.dev/doc/contribute.

Note that the Go project uses the issue tracker for bug reports and
proposals only. See https://go.dev/wiki/Questions for a list of
places to ask questions about the Go language.

[rf]: https://reneefrench.blogspot.com/

Go's emphasis on backwards compatibility is one of its key strengths.
There are, however, times when we cannot maintain complete compatibility.
If code depends on buggy (including insecure) behavior,
then fixing the bug will break that code.
New features can also have similar impacts:
enabling the HTTP/2 use by the HTTP client broke programs
connecting to servers with buggy HTTP/2 implementations.
These kinds of changes are unavoidable and