Hi tison! On Wed, Feb 23, 2022 at 7:06 PM tison <wander4...@gmail.com> wrote:
> Hi Roman, > > I noticed your summary and focus on user-facing channels. Comments inline. > > Roman Shaposhnik <ro...@shaposhnik.org>于2022年2月22日 周二23:32写道： > > > Thanks for all the feedback so far. If I were to summarize what's been > > expressed > > on this thread so far, it seems that we're all agreeing that: > > 1. Even if mailing lists appear to be clunky in 2022 they are still > > appreciated > > as THE channel for any kind of "official" ASF business to be > conducted > > (e.g. major decision points, voting, etc.). In that sense -- whatever > > other > > channels may have been used to build consensus -- the final (or > > official > > if you will) closure is expected to happen on a mailing list. > > > Yes. Actually communication happens in various way, public or private, > despite of the rules we set up or encourage. But we still need a single > source of truth for catching up decisions and mailing list works well in > this direction. > > 2. There are TONS of alternative communication channels for developers > > and users to explore and it is unlikely that we will have any > semblance > > of convergence there -- these are too fragmented by geographical, > > cultural, > > language and other preferences. > > > > Now, if I were to make an observation, I'd split our constituency in 3 of > > the > > usual concentric circles: PMC, Developers/Committers, Users. > > > > It sounds like making sure that all official PMC business to be conducted > > on the > > mailing list is not only desirable from the ASF's perspective but also > > [mostly] > > appreciated by the PMCs themselves. That leaves Developers/Committers and > > Users. > > > > My biggest problem is actually with users -- it seems that having all > these > > extra > > communication channels makes it more difficult for newcomers to find good > > entry points re: engaging with the projects -- or maybe not. That's still > > not clear > > to me and I would love to hear more feedback. > > > > What do ppl think? > > > > Thanks, > > Roman. > > > I think the challenge here for the wider community of developers and users > are somehow the same - community members who are less involved tends to use > the channel they're familiar with and responsive. > > Why GitHub issues and discussions mentioned many times? It's because that > the actual development activities happens there for those projects and > questions or discussion thrown there get responses. The point that you > don't have to create a new account is important as mentioned above in this > thread. > I am actually curious about those -- what has been everyone's experience with Googling for things in GH issues/threads? Now let's think of a typical journey of a user. The most frequently asked > question is "How do I do X". It should be almost covered by documents, and > when documents cannot solve the question, communication requirements occur. > > No matter what channel it provides, a user@ mailing list, an Q&A GitHub > discussion, or a user forum, what users want eagerly is to get response and > answered. Always a project's README should tell where you can ask a > question and make sure it's THE channel you put an eye on. > Honestly, for me that question always starts with a google query -- so I guess the real issue is whatever provides the best Google's score and shows up sooner will win. That's on the R/O side. So I think that is fine. But if a user decides to participate -- I believe then it becomes highly dependent on the user's previous experience, age, background, etc. Not sure we can do much here -- but it would be useful to see some kind of a study tracking what makes new users engage in the quickest possible way when they try doing it for the first time. > Users preference matters here since the cost here may be too high to just > ask a question but subscribing a mailing list and receiving all > notification. Especially younger users may be even lack of knowledge to > subscribe a mailing list (it's common in China). > Exactly. So... let me ask you this: do you know a project or two in ASF that does it the best for its Chinese users? I'd really love to learn from those experiences. > This can be something like "friction". Users used to ask on StackOverflow > won't be willing to switch to another channel for one question. > On communication tools topic, I always sort out channels into 2×2 kinds. > I really like your split, btw. > > 1. topic grouped channel > I guess email would qualify here for ASF. > 2. instant messaging channel > I guess we have ASF's Slack -- but that's about it. > > multiples > > 1. user channel > 2. developer channel (can be further diveded into ecosystem developer, > kernel Developer and maintainers) > > I think a community should grow all of them in the real world. But keep one > topic grouped channel as SSOT of decisions. > > You should build instant messaging channel just like IRC in the early days, > because if operated properly, it strengthens connections and closed short > topic effectively. > > However, topic grouped channel is required also because tough discussions > require more time and focused (by topic). Instant messaging can hardly > achieve it even if threads are supposed, because the mindset is to > "chatting". > In your opinion what's the best alternative/augmentation to email when it comes to topic grouped channels? > Users wants their questions to be answered, in the way they are familiar > with. Apache Flink resolves most possible input channel. > > 1. user@ mailing list. And for Chinese users, user-zh@. Note that the > latter reflects "in the way they're familiar with". > 2. Vendors' solution engineers answer questions on StackOverflow. > 3. Contributors from China answer questions in DingTalk, WeChat, or Feishu. > 4. ... > > Of course, it requires more community members who can answer user > questions. > > To sum up, you CAN have multiple channels for answering user questions and > collect best practices. Whether or not it's fragmented is up to (1) whether > or not you conclude FAQ into (central) docs and (2) whether or not you can > covered all of those channels so that users get them all responsive. > Thanks, Roman.
