Bring questions back to GitHub, use GG only for announcements

[superkhau]

Our new official policy is that questions are allowed on GitHub, at least until LoopBack4 reaches GA. Users are still encouraged to post their questions on StackOverflow though.

We should apply yellow "functional-area" labels like "CLI", "Examples", "Docs" to questions as part of our issue triage process. This will make it easier for people to find unanswered questions related to their area of interest/expertise.

(See also a follow-up issue to improve Contrib docs in general: #950)

Acceptance criteria

• Update our docs to reflect our policy change: http://loopback.io/doc/en/contrib/Reporting-issues.html. Updated policy along the lines:

<!--
HELP US HELP YOU BY
- Doing a quick search to avoid duplicate issues
- Providing as much information as possible (versions, use case scenarios for features, etc.)
- Open GitHub issue as the last resort
If you have a question then please consider using a more suitable venue:
 - https://stackoverflow.com/questions/tagged/loopbackjs
 - https://groups.google.com/forum/#!forum/loopbackjs
 - https://gitter.im/strongloop/loopback
-->

---

The original description from Simon for posterity:

Flame war topic.

Pros:

• Centralize developer activity to GitHub
• Easier to search/keep history centralized
• One place to maintain/manage instead of explaining to users (which goes along with our contributor first principle)

Cons:

• WIll inflate number of actual issues on GH
• Split history (but we don't have to remove old posts from GG, so it's sort of moot)

[bajtos]

👍 ✖️ 💯

I believe this is what Node.js does too.

[superkhau]

I believe this is what Node.js does too.

Yes, they flag them via question label also.

[crandmck]

Actually, Node.js has a special repo for questions: https://github.com/nodejs/help

I suggest we do something similar. This would help separate bugs/feature requests from questions/support issues. Naturally, there would be cases where issues have to move from one repo to the other, depending on what they are and resolution, etc.

[superkhau]

@crandmck Nice find. So I guess they have the same issues we do, ie. some people still posting to issues even though they have a help repo (see https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3Aquestion).

So then I ask is there any benefit to adding more fragmentation (ie. two places to find help, etc) -- one of our main principles is community/contributor first for lb-next, not us first which leads to:

As an commmunity member, I want to ask questions in the most natural place on GitHub, which IMO is the issues tab so that I don't need to figure out what repo, where to post questions, read through whatever to figure out where to get help -- side effect is it also eases the burden of explanation for us, which is secondary.

[raymondfeng]

I still see problems using github issues for Q&A. The main purpose to have GG is that our community members can help answer questions and we know it works. We have so many repos and I don't expect our community members to watch (to be notified of issues) all repos. Mixing questions into individual repos are not good. Even we decide to have a dedicated repo for Q&A, would Google search find these discussions? Should we keep all Q&A issues open?

[crandmck]

one of our main principles is community/contributor first for lb-next, not us first ...

Yes, but the reality is we have limited time/resources, so achieving the best result for the community includes finding the best way for us to manage questions, bugs, feature requests, and so on.

We have so many repos and I don't expect our community members to watch (to be notified of issues) all repos.

This is a good point. Additionally, users may not even know which of our many repos is appropriate for an issue they are encountering. In some cases, it might span multiple repos.

So IMHO, having a unified place for questions makes sense. Then, which would be best: the GG or a separate (e.g. help) GH repo?

Advantage of GH repo is that it's easy to move issues asked in any other GH there, and xref between various issues.

From the Node repo issues tagged as question it looks like these are often not straightforward questions ("How do I do xyz?") but more often it's someone encountering something they don't expect or understand, which might be a bug, a doc issue, pilot error, or possibly just a question about how something is supposed to work.

Even we decide to have a dedicated repo for Q&A, would Google search find these discussions?

I'm certain the answer is YES, because Google crawls GH. In my experience, that's how many people stumble across old issues that address a specific situation they've encountered.

For example, here's a random Google query that happens to include some terms I know are in issues. The results include several GH issues, including closed ones.

Should we keep all Q&A issues open?

We should discuss this. Instead of closing, we could add an "answered" label, and keep them open. But since search results include both open & closed issues, and since practically speaking people turn to Google first, it may not matter too much.

[superkhau]

The main purpose to have GG is that our community members can help answer questions and we know it works.

This is the same whether it's on GG or on github issues. Why can't they answer directly in GH issues (like they do for any other project)? In fact, we can close old questions and reopen them if they come up again easily.

We have so many repos and I don't expect our community members to watch (to be notified of issues) all repos.

This is a valid concern, centralizing to strongloop/help may help mitigate this. Then again, centralizing to strongloop/loopback/issues has the same effect.

Mixing questions into individual repos are not good.

I'm half and half on this as if we monorepo like we do in loopback-next, then issues for all repos are centralized to one domain since all subpackages are part of the same repo anyways.

Even we decide to have a dedicated repo for Q&A, would Google search find these discussions?

As @crandmck mentioned, Google has us covered here as it indexes GitHub issues in search results anyways.

Should we keep all Q&A issues open?

Yes, and give community a chance to answer them. We will filter for related issues we need when relevant. A nice side effect is that the user can search our history easily to since they can just query and previous Q/A will also pop up when digging through issues (like any other project on GH).

Yes, but the reality is we have limited time/resources, so achieving the best result for the community includes finding the best way for us to manage questions, bugs, feature requests, and so on.

No, I disagree. We haven't been doing a good job managing IMO because we don't involve community enough in this process. We cannot scale if it's only up to "us" to manage the repos. Ideally, more of our burden of managing will be taken away by removing barriers and enabling community to help us. My idea is to eventually create a group of "maintainers" that can help us with labeling/organizing (not coding) and have one place to sort, which is GitHub issues. It's quite simple to say "We need help labeling + organizing GitHub issues", minimal teaching required, minimal onboarding, etc -- versus, move questions into GG, label the stuff on GH issues, move stuff to other repos, cross-referencing, etc. I'm advocating for none of that -- gonna quote Dijkstra "Simplicity is prerequisite for reliability" -- simplicity for community means reliable community IMO.

We should discuss this. Instead of closing, we could add an "answered" label, and keep them open. But since search results include both open & closed issues, and since practically speaking people turn to Google first, it may not matter too much.

No, just close questions that are answered. They still show up when users search GH issues (and on Google search results).

---

That said, that's my opinion -- all this is up for debate and we should all get together to finalize any decisions around this. ATM, it's not at the top of my list of LB next todos yet -- however, I believe @raymondfeng should at least mention it in his kickoff blog so we can get feedback from community.

[crandmck]

No, I disagree. We haven't been doing a good job managing IMO because we don't involve community enough in this process. We cannot scale if it's only up to "us" to manage the repos.

+1 for getting more community involvement. My previous statement is still true if you broaden the definition of "us" to include everyone in the project (IBM + community). However, let's be clear, even if we do get lots of external involvement, we will still own project leadership and management. IBM is simply not going to abdicate project control to others.

[superkhau]

I agree with us leading the projects and creating the environment based on best practices, etc. I'm not advocating giving full control at all, I'm advocating give SOME control to allow community to process tasks or come up with a model that allows more automony (GitHub permissions allows us to give basic repo controls).

Let's take docs for example, what if we had a docs commitee that you could manage/keep a list of people in community who want to help with only docs? We could easily give one or 2 peeps merge rights and have them merge for the rest of the group etc. Then you could spend more time just picking who is qualified to be involved in the committee, etc.

[raymondfeng]

No matter what channels we use, we need to speed/scale up on answering questions, fixing bugs, merging PRs, and implementing features. I'm keen on proactively reviewing/merging/rejecting PRs. We need to take responsibility to either help the contributor finish the last mile or take it over to complete it. I sense some of us don't have the confidence/knowledge to merge or reject PRs. It ends up having a lot of not-so-complex PRs open for long time.