Thanks Zexuan. Some details were not organized in the first email, my mistake.
Our existing discussion of the places with their boundaries: 1. mail list: project questions and answers, code-related discussions, project management activities, technical discussions, release vote, etc. The boundary of the mail list are: things that are directly related to the development of the project, things that lend themselves to asynchronous discussion, and other things not listed that are stated in the Apache Way culture. 2. issue: bug report, feature, improve docs, request help, etc. The boundary of the issue are: details on the development of the implementation process after the mailing list discussion, issues arising from the user practice process, etc. issue is more suitable for tracking project development progress and solving specific problems. It is also a community portal on Github. 3. IM: now we have public Slack channels, Wechat, etc., but we never discuss specific issues here. Problem: issue have become a channel between project developers and users. When an issue is closed, it means that the discussion of the matter is over. However, we have many useful tips scattered in different issues. New users are constantly joining the community and encountering questions that previous users have encountered. These questions may be solved in the issue, but because users don't know how to use search or use the wrong keywords, they can't find the answers they want. So they will ask similar questions again. Our current approach is to distill duplicate issues and add them to the FAQ. But this solves only part of the problem. Some of the user's questions have no unique answer, or no answer at all, and these questions need to be discussed by the user. Now we also lack a channel for user-to-user communication. mail list can do this, but too few users are willing to do so due to their usage habits. Proposal: Perhaps GitHub Discussions is a better solution to the problem mentioned above. The boundary of the GitHub Discussions are: guide for newcomers to APISIX, technical articles about APISIX, experience of using APISIX, exchange of knowledge on custom plugin development, highly available solutions, etc. GitHub Discussion makes it easier for community users to find topics they are interested in, and learn from each other. The best content from GitHub Discussions, which can be fed back into the project. How to direct users to GitHub Discussions? It is a real problem. If we see questions in the issue, IM, that is suitable for discussion in GitHub Discussions, we can direct users to it. But I think it's more important that GitHub Discussions have content that users are interested in, like issue deposits, links to various learning resources related to the project, and those mentioned in the Proposal. More discussion is needed on this problem. *ZhengSong Tu* My GitHub: https://github.com/tzssangglass <https://github.com/membphis> Apache APISIX: https://github.com/apache/apisix Zexuan Luo <spacewan...@apache.org> 于2021年8月2日周一 下午4:22写道： > Is there a guideline for where the discussion happens? > Now we will have three places to discuss things: > 1. mail list > 2. issue > 3. GitHub discussion > > How can users know why to put their discussion to? > > tzssangglass <tzssanggl...@apache.org> 于2021年8月2日周一 下午12:38写道： > > > > Hi, Community, > > > > As more and more users are using APISIX, they ask a lot of questions, not > > only about bugs, features, etc., but also about non-code-related issues > > such as high availability solutions, best practices in different > scenarios, > > questions related to the technology stack derived from APISIX, etc. > > > > These issues are not suitable for hosting in issues, but rather in GitHub > > Discussions. > > > > I recommend using GitHub Discussions on the APISIX project. > > > > This is the introduction to GitHub Discussions: > > *“GitHub Discussions is a collaborative communication forum for the > > community around an open source project. Discussions are for > conversations > > that need to be transparent and accessible but do not need to be tracked > on > > a project board and are not related to code, unlike GitHub Issues. > > Discussions enable fluid, open conversation in a public forum.”* > > > > What's your opinion? > > > > Reference: > > - GitHub Discussions: https://docs.github.com/en/discussions/quickstart >
