Bring questions back to GitHub, use GG only for announcements #47
Comments
|
👍 ✖️ 💯 I believe this is what Node.js does too. |
Yes, they flag them via question label also. |
|
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. |
|
@crandmck Nice find. So I guess they have the same issues we do, ie. some people still posting to 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. |
|
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? |
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.
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.
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.
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. |
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.
This is a valid concern, centralizing to
I'm half and half on this as if we monorepo like we do in
As @crandmck mentioned, Google has us covered here as it indexes GitHub issues in search results anyways.
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).
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.
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. |
+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. |
|
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. |
|
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 |
|
@raymondfeng I agree, but that is outside the scope of this discussion. Once we get the huge number of centralized incoming issues into GH/issues, I'm all for discussion how to reduce that number. ;) |
|
I'm actually saying the other way: switching channel won't help unless we become more proactive and responsive. |
It's not switching channel, it's removing a channel altogether. First and foremost, this discussion is to improve the community user experience, not our triage resourcing problem. |
|
I'm leaning towards centralizing help to the |
|
I would like to grow the amount of help we are receiving from our community, and I agree with @superkhau that dropping the constraint "don't ask questions on github" is at least a good experiment to try out. IMO, we should make it easy for community to follow only the part of LoopBack they are interested in. If I had only one hour per week to work on LoopBack, and my primary interest was let's say the PostgreSQL connector, then I would want an easy way how to follow only issues/patches/discussions related to this connector, without having to scan through all loopback discussions to filter out those relevant to me. If I had to spent most of my 60 minutes on filtering the issues, then I would not be able to contribute hardly anything, and thus never get the sense of accomplishing something, and subsequently get demotivated and disengage from the project. Also as was mentioned above, users often don't know whether their issue is caused by misconfiguration (and they are looking for an answer how to configure their app), or whether they discovered an issue, or perhaps a missing feature. We should encourage them to focus on describing the problem, not trying to figure out what's the right place where to post it. I took a quick look at our mailing list. It looks like we have about 1-3 posts coming each day, however most posts get less than 10 views and very often there are no answers posted afterwards. To me, this shows that using google groups for questions simply does not work - users are not getting the answers they need. What I would like to propose:
Having said that, I also agree with @raymondfeng - we need to become more proactive and responsive. This is a self-reinforcing loop - because we are not responsive, people get discouraged from participating, therefore we never get any people to help us with maintenance, and as the number of users grows, we become even less responsive, and the loop goes on. I think we need to address both parts - make it easier for people to ask and respond to questions, and also be more responsive ourselves. |
|
@bajtos I agree with everything you said. We can easily move issues around if needed. Centralizing to one location is key to this strategy to work as it'll improve the end user experience by far. I also agree with @raymondfeng with being more proactive/responsive. That is another battle we should address in a different discussion: #57 |
|
@kjdelisle @raymondfeng @ritch @bajtos @superkhau
|
|
I'm ok with the idea of letting users ask questions as GitHub Issues and definitely agree with need to be more proactive to close issues. An obvious omission and a possible go to for most people imo is StackOverflow. Any reason that's not mentioned in this thread at all? Ask people to post questions there and tag them This is what |
This is the part that's not working well and we want to move away from it:
Once people posted the question on GitHub, it's easier to answer their question right there, instead of asking them to re-post on StackOverflow, where we won't follow up with an answer. I like how Angular is recommending people to use SO and explaining why it works better for questions, I am happy to adopts the same recommendation. Just note that the SO tag is
I think that's a great solution, +1 from me. |
|
+1 from me as well on using SO as preferred forum for questions. Even so, there will always be questions asked in GH, because:
So IMHO we just need to decide on a general policy or "best practice" for inevitable cases where people do ask questions in GH issues. Currently, the policy is to just close the issue and say "Ask in GG or SO". IIUC the suggestion earlier in this discussion was to stop doing this, and answer the question directly in GH instead. It wouldn't be that much work to then cross-post the Q&A to SO, but it would add a small amount of additional work per question. I think it should be left to the discretion of the answerer/team whether to do this, depending on how useful the Q&A would be to others. |
|
IMHO.. Since we're using GitHub on a daily basis, it is easier to get our attention if questions are posted here than SO. If we direct people to ask questions in SO, then we'll need to monitor that as well, which gives extra burden to everyone because answering questions in SO has been a best-effort basis so far for us. Perhaps GG, SO and gitter fall under "helping each other out in the community" category? And we keep that as best-effort in terms of monitoring/answering questions there? |
|
+1 to just GitHub for us providing support to community. Just ask that questions be tagged appropriately (but no big deal if they aren't since we can add the tags). |
|
People have different opinions for this issue, label it as needs-discussion. let's post comments here. |
|
Summary of today's estimation meeting, we agreed that:
|
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
The original description from Simon for posterity:
Flame war topic.
Pros:
Cons:
The text was updated successfully, but these errors were encountered: