golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.81k stars 17.65k forks source link

Use a single GitHub topic keyword for Go in the Go repository. #19346

Closed dmitshur closed 7 years ago

dmitshur commented 7 years ago

Background

A month ago, GitHub released a new feature called Topics.

https://github.com/blog/2309-introducing-topics

Topics are labels that create subject-based connections between GitHub repositories and let you explore projects by type, technology, and more.

Since that time, many Go repositories on GitHub have started using a topic to indicate that the repository is primarily powered by (or related to) the Go programming language.

However, there seems to be a nearly equal split between the exact keyword(s) used:

  1. Some projects use only go as the keyword.
    • https://github.com/search?q=topic:go finds 2657 repositories, of them 2355 are detected to primarily use Go language (88.6%).
    • kubernetes/kubernetes uses go topic only.
    • syncthing/syncthing uses go topic only.
    • grafana/grafana uses go topic only.
    • coreos/etcd uses go topic only.
    • mholt/caddy uses go topic only.
    • gorilla/mux uses go topic only.
    • google/go-github uses go topic only.
  2. Some projects use only golang as the keyword.
    • https://github.com/search?q=topic:golang finds 3297 repositories, of them 2805 are detected to primarily use Go language (87.4%).
    • asciimoo/wuzz uses golang topic only.
    • zyedidia/micro uses golang topic only.
    • apex/apex uses golang topic only.
    • sosedoff/pgweb uses golang topic only.
    • (It's hard to find popular projects that use golang only, instead of go or both.)
  3. Some projects end up using both go and golang, because they're not sure which one they're supposed to pick, and they don't want to "miss out".
    • avelino/awesome-go uses both go and golang topics.
    • gogits/gogs uses both go and golang topics.
    • go-kit/kit uses both go and golang topics.
    • derekparker/delve uses both go and golang topics.
    • gorilla/websocket uses both go and golang topics.

Given that topics are specific keywords (rather than normal words) with no spaces allowed, it seems that both go and golang are very effective at finding projects actually related to Go, the programming language.

In other words, both topics are equally viable, and both topics have nearly zero false-positive matches. This is contrary to doing a normal search on a general search engine like google.com, where searching for just "golang" has much fewer false positives than searching for "go" (without additional words). Also, as I understand, the golang.org domain was out of necessity, since go.org is not a valid domain (because 2 letters is too short for a .org domain).

Issue

This issue is about the fact that the Go project repository on GitHub (https://github.com/golang/go) uses both go and golang topics, instead of just go:

image

It seems unnecessary and counter-productive to be undecided, and it encourages others to be uncertain which topic to use for signaling that "this is related to the Go programming language".

Given that the language is called Go, not golang, and that go is a viable topic name without false positives, I believe it should be preferable.

The Go project repository should remove its golang topic to prevent confusion and not to encourage using 2 topics for the exact same thing.

Also note that GitHub detects Go language and displays it as "Go", not "golang":

image

bradfitz commented 7 years ago

Sure, done.

That was my fault. I saw that feature appear and didn't know what it was and typed some random stuff or just clicked the suggested things.

What about the redundancy between language and programming-language?

dmitshur commented 7 years ago

Thanks.

What about the redundancy between language and programming-language?

That also seems like it could be improved slightly, but I haven't researched those topics and I don't mind it as much, because it's not acting as an example for other Go repositories to follow.

From a quick search, both seem to be about equally used:

You could go with just language, since most languages on GitHub are likely programming languages anyway, and it's shorter/simpler. But I don't have a strong preference in either direction.