Considering the slowness and poor user experience of Google Groups (as reported by many of our users), I think this is a good idea. I've seen it work well for other projects, too.

My concern is that many more people read the forums, and they are far more likely to be able to actually answer the questions. Questions about use of the language are easy enough to answer, but many questions are about unusual use cases and libraries, for which there are people who know the answer but they aren't reading the issue tracker. If we make this change we'll need some way to encourage the people already reading the forums to also read the issue tracker.

Spitballing, applying the Question tag (or something else?) could trigger a bot to email golang-nuts notifying the forums of an interesting issue tracker question. Or a different/new forum?

Assuming the details can be sorted out, this is an excellent idea. Meet your users where they are.

How about answering quick questions in the issue, but still closing the issue and redirecting them to the wiki? I agree that a quick close is off putting, but there's no additional noise as the answer/close would still happen.

How about answering quick questions in the issue

We don't want to require that the first-level triage-er have to write (or research!) an answer. They need to be able to add some metadata (or close) quickly. But adding the label "Question" is as quick as closing it. And then gopherbot can take over and unsubscribe all the bugs-only users who are only interested in actual bugs. It can even use the gmail API to remove it from our inbox. (I have existing gmail bots that that for other things.)

tl; dr: IMO this is a bad idea. I'll elaborate

It's pretty sad to turn all those users away, though.

We're not turning them away. We are re-routing them to places (like forum.golangbridge.org or stackoverflow) that are much better suited for questions, and where there are a lot of people reading questions and answering them.

If just pasting "for questions, see https://golang.org/wiki/Questions" feels "sad" (and I agree it doesn't feel nice), you just have to write a better pre-packaged reply once (one that is more verbose, and feels "nicer"), and insert that when you close the issue.

We can automate away the email annoyance spam with bots pushing the Subscribe/Unsubscribe button automatically

but you can't automate the questions away for the people gardening from the github user interface. Also this kind of "automation" would still rely on contributors gardening the issue tracker and labelling the questions as "questions", so I'm not convinced that it would be actually possible to keep the tracker tidy and clean for people not interested in answering questions.

What really drove this home was this same exchange happening to me recently in a non-Go project. I had filed a feature request bug with a project with a proposed way to implement it

Yours was not a question, then. We already allow feature requests in the tracker, and especially so the ones with concrete implementation ideas. I don't think this experience is that relevant since on this tracker your issue would still be open. Also we're not re-routing people to abandoned internet places... we're re-routing them to places filled with people answering go questions!

The nice thing about questions in issue trackers is that they can be closed when they're resolved and you can search for open questions. That doesn't happen in forums.

This is actually a bad thing. Because users won't search among closed issue to see if their question was answered in the past. Nobody cares about or looks at closed issues. On the other hand, in a forum or on stackoverflow you usually don't "close" or "archive" valid questions, and all the threads are kept there, so users 1) actually use to search button to look for older threads, because they're not stacked away in a "closed" page 2) resurrect old threads if they want to ask more things in topic with the thread

I still don't think we'd want to promote the issue tracker as the canonical forum for questions, but I also think we should consider not turning people away who end up there.

Having a centralized database of questions/answers is a valuable thing. That's why stackoverflow is widely used. At this point for most technologies you don't even have to actually "ask" a question. You just search and find a past thread with answers. Routing people to a couple of standard places has two benefits 1) there's an high chance of the question already having an answer, you just have to search 2) if that doesn't happen, the person asks the question there, enriching the questions/answers database.

Considering the slowness and poor user experience of Google Groups

You can fix this by closing nuts and routing people to forum.golangbridge.org and stackoverflow, so it shouldn't be used as an argument for allowing questions on the issue tracker.

Ian wrote:

My concern is that many more people read the forums, and they are far more likely to be able to actually answer the questions.

I agree. I have the feeling that the people answering go questions on stackoverflow and forum.golangbridge.org are not the same that "patrol" the issue tracker.

The current separation between the issue tracker (only for bugs and feature requests/proposal) and questions/answers forums is beneficial because it allows us to keep the issue tracker a somewhat tidy, clean place that the people working on go can visit to find things to do; and it permits the kind of people that answer questions and discuss about the language (and there are many many more of these) to visit places that are exactly meant for this kind of interaction.

GitHub is superior to Google Groups for discussing code and searching for past questions. The bi-directional issue linking is nice and other places don't have that. If a bug or proposal topic is generating many questions then that shows in the issue.

If a question can't be answered in a reasonable amount of time (such as for usage of a third party library) then somewhere like golang-nuts would be more appropriate and the issue can be closed as "don't know".

What about two issue trackers? One (golang/go) for bugs and one (maybe golang/questions) for questions? That way we can have the advantages of using issue tracker for questions as well as the separation of questions and bugs.

@cherrymui, the problem is we can't move bugs between repos, so people will file questions at golang/go anyway. This issue is about deciding how we handle questions that arrive at golang/go.

You could also make a subset of the issue tracker into a quick-and-dirty q&a site: have questions.golang.org show a list of the titles of issues labeled Question that link to the issue on github and an "ask question" link that goes to the new issue form (assuming there's some way to set that up to be prefilled so it automatically gets labeled?)

Is there a chance this could inflate the number of open "issues" people see when they look at the repo?

@as I don't think that needs to be a concern here. There are currently over 3000 open issues; anybody making decisions on that basis is not going to be affected by this change.

Hi, here are my thoughts on this issue as a Gopher and Gophers Slack Admin.

I agree with Brad that it's pretty sad to reject people and turn them away from Github when they have a question. It would be nice if people could ask questions here and then drive pages like FAQ, or may lead to creating new ones.

However, currently as far as community goes, there are far less people active here, potentially answering / helping others than on other mediums, like the GoBridge Forum or the golang-nuts ML.

There's also the problem that Github really doesn't make it easy to allow people interested in helping the community to help them as there's no way to subscribe to new issues only, you can either get all the e-mails or you have to manually subscribe to the issues you are interested in (or comment on them).

And, so far I haven't mentioned the elephant in the room.
While there are vastly different opinions on Slack, we currently have 24k members signed up, roughly between 1500 - 2000 weekly active users, and we usually generate about 30000 messages per week. Besides the idle chatter that happens at times, we have a lot of questions that we answer hourly, sometimes with a successful answer within minutes of the question being asked, with topics that sometimes span outside of Go itself, such as how to configure nginx or how to design APIs. The obvious disadvantage of that community is that we often repeat the same questions / answers and all the knowledge that we have as a collective is quickly replaced by the new stream of chat.

I leave out Reddit out of this, as despite the best efforts of the admins there, a whole thread can quickly turn bad for anyone having a question that needs to be answered.

I wonder if instead of the classic link to the questions wiki page, https://github.com/golang/go/wiki/Questions , a better answer could be to just answer with the contents of the page directly. Maybe a bot command could be added to open the issue on behalf of the user on the Forum and then link it here, add the rest of the reply, apply the Go Usage Question label, then close the issue and lock it down. That way the user would not need to necessarily open a new account on the forum, unless it wants to reply to questions, and people helping out in the forum could get a chance to reply to these questions.

Finally, this is also a problem of image. When you navigate on golang.org, it's pretty hard to figure out where to get help from, or even to find the Contributing page (I always have to google for that one). I would love to have a redesigned website which puts more emphasis on helping users discover these kind of places and provide recommendations for officially endorsed support channels.

Edit 1:

To the above reply I can also add the fact that it would create a lot of noise here, which would make it harder for the Go Team / people working on supporting the Go project itself to be effective at distinguishing generic usage questions from actual Go problems / proposals.

Also Github lacks a lot of functionality, chief among which threaded replies, and a decent search feature.

Another thing to consider is that currently the issue tracker itself doesn't really like me too comments, see: #19282 (comment) as an example. Part of opening up the tracker to generic Go issues will be dealing with those nonsensical comments (or people randomly commenting on closed issues with me too and so on.

This would create too much noise for maintainers / people helping out and the current Github tooling is pretty bad at this (as mentioned earlier).

The current search defaults are is:issue is:open:

is:issue distinguishes pull requests et. al, from issues.
is:open filters on open issues

Is a question an issue?
If a question is answered, is it closed?
If it's closed, would we instruct users to clear the search tag is:open to search for questions that have already been answered before asking a new one?

A middle ground might be agreeing on a template text we all use saying something like:

Sorry, this looks like a question. We don't really use this issue tracker for general discussion. We'll keep it open, though, but label it 'Question'. Be aware that there aren't many people answering questions around here. There is a more active user community answering questions at: [LIST OF FORUMS]

This issue will be auto-closed in 30 days. If you get your answer elsewhere before then, please reply with a link to the answer and then close this bug.

If it turns out this is a bug and not a question, we can remove the 'Question' label and promote it to a bug.

Thanks!

Notably:

• it tells them there are better forums
• doesn't immediately close their issue
• still lets people help for a bit
• leaves open the possibility that the question is actually a bug (many of our bug reports are unclear)

I'm not sure what the best answer here is. I'm still spitballing.

@as label:Question <keywords> would be the standard search.

Maybe the tracker will become one of the better forums if questions are allowed. If questions become overwhelming for the people here then they could be disallowed again.

Sounds good to proposal-review.

So what happened here? #26901

Are questions allowed on the tracker or not?

Good question, I kind of forgot about this one.

If we do start allowing questions, we could easily provide a link by which the title of the issue is pre-populated. gopherbot can then do something sensible with it, which will catch most questions.

https://github.com/golang/go/issues/new?title=question:&body=

We could also provide a separate issue template for questions to ensure that people add as much relevant information as possible, structure things in a vaguely common way etc.

One request I would make; I, like a (small) number of folks, have the firehose of issues turned on, more for idle reading than anything. If questions can be asked via the GitHub issue tracker, the traffic will likely increase; by how much I'm unclear, but it would be fair to assume it will be some percentage of the existing traffic to golang-nuts, StackOverFlow, Twitter etc.

If gopherbot or something similar gained the ability to subscribe people to issues according to certain filter criteria, this would enable me to turn off the firehose, and folks more generally to more precisely specify the issue flow they are interested in. It would also help to eliminate the duplicate emails I get from GitHub about the PR associated with a Gerrit-bot linked CL (because you can't filter out PR emails from GitHub).

@andybons @bradfitz - is there a plan to implement this accepted proposal?

@myitcv It seems we need to do the following:

1. Standardize on a prefix (question: seems to be the right choice)
2. Create the Question label
3. If gopherbot sees a question: prefix it applies the Question label automatically
4. gopherbot should close idle question issues after 30 days

No one has worked on the above. Help is welcome.

It's now possible to transfer issues between repos — I strongly support having a dedicated questions repo (as @cherrymui suggested).

Not sure about API support, but it might be possible to have gopherbot automatically transfer any issues tagged/prefixed with question as well.

Oh, perfect. I saw that news but didn't think about using it for this. Great.

Yeah, I'm also down for a new "questions" or "help" (shorter) repo.

@bradfitz sounds good to me. Removed the last bullet.

@bradfitz ok then what are the rules of a new repo? Is there a repo we can emulate?

We have a bunch of misc repos under github.com/golang/*. None is like a help/Q&A site, though.

Let's just pick a name and then make it: "questions" or "help". I don't like "qa" for being too short and ambiguous with Quality Assurance and "q-and-a" etc are gross.

"questions" despite being longer is probably more encompassing, as many people are curious about something in the language or library design without it being a request for help and it's not a bug for golang/go.

Also possibilities: "discuss" or "user" or "forum".

My vote goes for "questions".

If we call it "help", we might get users who simply want others to help fix or review their code.

Is there a plan to have gopherbot close issues after inactivity, kinda like how old threads in a mailing list get buried under newer posts?

We should also update this repo's issue template saying that "if you are asking a question, please do this on the questions repo". Otherwise, the general tendency is to raise issues in the main repo itself.

It appears that transferring issues between repos requires admin rights on both repos. Almost no one has admin rights for the Go repo. I guess we could give gopherbot admin rights, and people can ask gopherbot to do the movement?

Looks like we're somewhat live with this?

https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3AQuestion

I've also submitted the following feedback to GitHub. Do the Go team collect and surface this sort of stuff in a more official capacity?

https://github.com/notifications is an excellent way of handling notifications, thank you. I have one suggestion, however.

The golang/go repo has just started accepting questions via the issue tracker (although this will not be advertised as the main place for questions to be answered). Here is the label filter:

https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3AQuestion

I want to be able to configure my notifications screen to filter out questions, i.e. not have them appear in my notifications feed.

Are you are considering such a feature?

I don't think we should be allowing questions on the issue tracker until the points in #23745 (comment) are done. That is, have @gopherbot automatically label questions and close them eventually.

Just to add my two cents: I exclusively use this issue tracker, and almost never participate in any other forums or Slack. So for me, questions would be fine, since this is the only place I help out and can answer them.

Also, a question might indicate that the relevant documentation needs improvement, as long as the person who asked the question actually read the fine manual. So I consider that a question is often a documentation bug.

Just as a quick poll, anyone who uses this issue tracker exclusively like me, please give this message a thumbs up so we can see how many people out there only use this tracker and nothing else to interact with the Go community.

After thinking about this more (and taking into account the feedback above), I believe we should encourage the community to primarily (but not exclusively) ask questions on Stack Overflow.

• The community on Stack Overflow is enormous, the SEO is quite good, and the product is designed for exactly this purpose. Adding another place to ask questions that doesn’t have adequate features to support it feels like adding unnecessary fragmentation
• As @dlsniper mentioned above, the same conversations are repeated often in Slack, indicating an issue with discovery on closed-platform chat services. This also puts an oversized burden on those answering the same questions repeatedly
• We can funnel SO questions with adequate granularity (modules-related issues, for example) into Slack/Discord channels using bots, allowing for people to monitor/contribute answers without asking people to move away from their platform of choice

What do people think?

As someone who doesn't currently use Stack Overflow, or Slack, or Discord, tell me more about what those bots could in principle do. Thanks.

After thinking about this more (and taking into account the feedback above), I believe we should encourage the community to primarily (but not exclusively) ask questions on Stack Overflow.

What do people think?

I think this is a very good idea, for the reasons I already explained above (#23745 (comment)).

I would be very happy if we could return to a state where questions on the github issue tracker are simply immediately closed with a standardized, kind, friendly message. We can come up with one, and then the people active on the tracker can add it as a saved reply. So we can be polite be default when we re-route people and it'll only take literally two mouse clicks.

encourage the community to primarily (but not exclusively) ask questions on Stack Overflow.

Since for questions databases centralization is good, I also agree we could set for a main suggestion (e.g. stackoverflow). If we do that, it may be worth including a note like "remember to search if the question was already answered" in the saved reply.

I don't have any opinion on bots that bridge SO with slack&co, but I think that's a different issue. Regardless of what it could be done to make people that patrol SO or slack happy, closing questions on the issue tracker and re-routing people to a better Q&A platform remains a good idea (even if we end up not doing this slack/discord bot thing).

I believe we should encourage the community to primarily (but not exclusively) ask questions on Stack Overflow

That sounds like a reasonable conclusion based on the points you present above.

Related follow up question. Do you anticipate therefore, Stack Overflow becoming some sort of source of truth/reference point for certain questions and answers? Or will golang.org continue to be the go-to place for definitive answers?

My only suggestion would be that some effort is put into a mechanism whereby the core Go docs (i.e. those hosted on golang.org) can be improved over time by the questions and answers in various channels, of which Stack Overflow is one. Stack Overflow, Slack and indeed any platform can serve as a useful funnel for questions, themes etc. But having the source of truth being golang.org is important to my mind. Having good support for search, well laid-out docs etc is a critical part of this.

As someone who doesn't currently use Stack Overflow, or Slack, or Discord, tell me more about what those bots could in principle do. Thanks.

You could have a channel in Slack that a bot posts new questions tagged with the go label to. This would allow those who already hang out in Slack who already are answering questions to monitor that channel instead of having to remember to visit Stack Overflow as well.

I would be very happy if we could return to a state where questions on the github issue tracker are simply immediately closed with a standardized, kind, friendly message.

I agree. We need to find the right wording so that someone asking a question doesn’t feel “turned away” but more “pointed in a better direction.”

Related follow up question. Do you anticipate therefore, Stack Overflow becoming some sort of source of truth/reference point for certain questions and answers? Or will golang.org continue to be the go-to place for definitive answers?

I don’t think SO should replace quality documentation from authoritative sources. We should be using the questions we get on any medium to inform how the docs on golang.org can be improved.

I don’t think SO should replace quality documentation from authoritative sources. We should be using the questions we get on any medium to inform how the docs on golang.org can be improved.

Great. Taking a specific example, I think it would be worth considering in what format the modules wiki could be promoted to the official docs. This does not imply/require that these docs be included as part of the official Go distribution (because I think the important bits have already made it across to the cmd/go docs), but that there should be a "sub section" of golang.org for this kind of thing: it's really a combination of FAQ, best practice, examples etc. Should be easy to navigate, search etc.

An equally important part of getting this issue "right" is the communication/messaging to those people kindly taking the time to answer these questions that the goal should be to promote the most common/best questions to this "sub section" of golang.org. If you can point people to an example of "oh and here's what we did with promoting the modules wiki" (which was driven superbly by @thepudds), then that will definitely help.

@andybons

FWIW, I think this is a good idea to turn the focus to Stack Overflow. Microsoft I think did something related when they shut down some of their forums and asked people to move to Stack Overflow instead.

Right now, my personal take is Stack Overflow answers for Go on at least some topics is typically of lower quality compared to what I see for other languages on SO.

Having more savvy eyes on SO and encouraging the broader community to focus on improving the quality of answers there would very likely drive up the quality and end up being a virtuous circle, with more people relying on it for answers and contributing there.

We need to find the right wording so that someone asking a question doesn’t feel “turned away” but more “pointed in a better direction.”

Part of routinely hitting a threshold of being "very friendly" when asking someone to go elsewhere might be "inlining" the friendliness into the issue comment itself, and doing so in a canned way. (That would be in contrast to just trying to make the Questions wiki page be extra friendly, for example).

In an earlier semi-related discussion a couple years ago, @thaJeztah supplied what I thought was a great example of what I think is a 90% canned answer that was very friendly, and which I think comes close to your desire to not wanting people to feel “turned away” but more “pointed in a better direction”. This is a Docker issue response from @thaJeztah in moby/moby#35227 (comment):

You may want to have a look at multi-stage builds as well to move the build-artefacts from a build-stage to a new stage.

Please keep in mind that the GitHub issue tracker is not intended as a general support forum,
but for reporting bugs and feature requests. For other type of questions, consider using one of;

• the Docker Support Forums - https://forums.docker.com
• the Docker community Slack channel (register here: http://dockr.ly/community)
• StackOverflow

I'm closing this issue because this is not a bug, but feel free to continue the conversation 👍

My interpretation is the first sentence there was a quick, lightweight, and partial answer that hints at specific topics that might help (but without supplying enormous detail), and then the rest of the answer I suspect is canned. The fact that the friendly canned response is "inlined" in the issue there I think helps as well. Closing with an emoji is also a nice touch.

(Side note: I know open source maintainership is hard, there are a million issues to get through, taking longer to help person X means taking time away from helping person Y and Z, etc.).

Re the quality and approachability of StackOverflow and closed communities, the Rust forum uses Discourse. It seems to have pretty good support for both Q&A topics and threads and GitHub integration, and it apparently has both a managed option and an open-source implementation. That might be worth investigating.

@bcmills we already have a Go equivalent at https://forum.golangbridge.org/

@ALTree, thanks for the reminder. I took a look at the golangbridge forum again, and was pretty disappointed at the quality of the questions and answers compared to, say, typical questions and answers on golang-nuts.

The issue tracker (and SO) makes it relatively easy to retitle issues to properly reflect the question being asked. I don't know if such a thing is possible in Discourse (or if it is possible but not enabled for new users), but if it is, that feature seems to be significantly underutilized on the golangbridge forum. At the very least, if we send questions in that direction I think we will need to raise the standards of gardening to make it easier to find existing questions and their answers.

I also took another look at the go tag on SO. I noticed a few very unfortunate patterns there.

1. Many of the questions marked “unanswered” actually did have answers, but they had been entered as clarification comments instead, and there is no supported way to promote a comment to an answer. That makes searching much more difficult on both sides: as someone with a question to ask, it's hard to find related questions with answers, and as someone attempting to answer questions, it's hard to find questions that are ready for a response (that is, that both (a) do not have an answer and (b) are not awaiting clarification from the OP).

2. Many of the questions tagged go are at best only marginally Go-related. (For example, there are many questions about how to use specific databases or libraries in Go, or how to use Go to serve specific data for a program written in some other language to consume.) Specific sub-tags such as go-modules are a bit better, but relying on those would make it harder to find and route questions that don't have a more specific label.

3. It's not at all clear to me whether there is an equivalent to our WaitingForInfo label, but if there is it does not seem to be available to most users.

Closing as we are not going to be using GitHub issues for questions.

I don't mean to resurrect closed threads, but this is very relevant: https://news.ycombinator.com/item?id=22388639

Perhaps it would be a nice middle ground once it rolls out. It could allow us to keep discussions in a single place (this GitHub repository), while keeping questions and discussion separate from bug reports and proposals.