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.
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.
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).
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.
1. topic grouped channel
2. instant messaging channel
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".
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.
> --
Best,
tison.
