Thank you @Xintong Song <mailto:tonysong...@gmail.com> for sharing the
experience of the Flink China community.
I'm become convinced we should give Slack a try, both for discussions
among the core developers, and as a place where the community can
reach out for help. I am in favor of using the ASF slack, as we will
need a paid instance for this to go well, and joining it is easy
enough (took me about 2 minutes). Thanks, Robert, for suggesting we go
down this route.
David
On Tue, May 10, 2022 at 8:21 AM Robert Metzger <rmetz...@apache.org>
wrote:
It seems that we'd have to use invite links on the Flink website
for people to join our Slack (1)
These links can be configured to have no time-expiration, but they
will expire after 100 guests have joined.
I guess we'd have to use a URL shortener (https://s.apache.org)
that we update once the invite link expires. It's not a nice
solution, but it'll work.
(1) https://the-asf.slack.com/archives/CBX4TSBQ8/p1652125017094159
On Mon, May 9, 2022 at 3:59 PM Robert Metzger
<metrob...@gmail.com> wrote:
Thanks a lot for your answer. The onboarding experience to the
ASF Slack is indeed not ideal:
https://apisix.apache.org/docs/general/join#join-the-slack-channel
I'll see if we can improve it
On Mon, May 9, 2022 at 3:38 PM Martijn Visser
<martijnvis...@apache.org> wrote:
As far as I recall you can't sign up for the ASF instance
of Slack, you can
only get there if you're a committer or if you're invited
by a committer.
On Mon, 9 May 2022 at 15:15, Robert Metzger
<metrob...@gmail.com> wrote:
> Sorry for joining this discussion late, and thanks for
the summary Xintong!
>
> Why are we considering a separate slack instance instead
of using the ASF
> Slack instance?
> The ASF instance is paid, so all messages are retained
forever, and quite
> a few people are already on that Slack instance.
> There is already a #flink channel on that Slack
instance, that we could
> leave as passive as it is right now, or put some more
effort into it, on a
> voluntary basis.
> We could add another #flink-dev channel to that Slack
for developer
> discussions, and a private flink-committer and flink-pmc
chat.
>
> If we are going that path, we should rework the
"Community" and "Getting
> Help" pages and explain that the mailing lists are the
"ground truth tools"
> in Flink, and Slack is only there to facilitate faster
communication, but
> it is optional / voluntary (e.g. a committers won't
respond to DMs)
>
> All public #flink-* channels should be archived and
google-indexable.
> I've asked Jarek from Airflow who's maintaining
> http://apache-airflow.slack-archives.org.
> If we can't use slack-archives.org
<http://slack-archives.org>, it would be nice to find some
> volunteers in the Flink community to hack a simple
indexing tool.
> The indexing part is very important for me, because of
some bad
> experiences with the Kubernetes experience, where most
of the advanced
> stuff is hidden in their Slack, and it took me a few
weeks to find that
> goldmine of information.
>
> Overall, I see this as an experiment worth doing, but I
would suggest
> revisiting it in 6 to 12 months: We should check if
really all important
> decisions are mirrored to the right mailing lists, and
that we get the
> benefits we hoped for (more adoption, better experience
for users and
> developers), and that we can handle the concerns (DMs to
developers,
> indexing).
>
>
>
>
>
> On Sat, May 7, 2022 at 12:22 PM Xintong Song
<tonysong...@gmail.com>
> wrote:
>
>> Thanks all for the valuable feedback.
>>
>> It seems most people are overall positive about using
Slack for dev
>> discussions, as long as they are properly reflected
back to the MLs.
>> - We definitely need a code of conduct that clearly
specifies what people
>> should / should not do.
>> - Contributors pinging well-known reviewers
/committers, I think that also
>> happens now on JIRA / Github. Personally, I'd
understand a no-reply as a
>> "soft no". We may consider to also put that in the cod
of conduct.
>>
>> Concerning using Slack for user QAs, it seem the major
concern is that, we
>> may end up repeatedly answering the same questions from
different users,
>> due to lack of capacity for archiving and searching
historical
>> conversations. TBH, I don't have a good solution for
the archivability and
>> searchability. I investigated some tools like Zapier
[1], but none of them
>> seems suitable for us. However, I'd like to share 2
arguments.
>> - The purpose of Slack is to make the communication
more efficient? By
>> *efficient*, I mean saving time for both question
askers and helpers with
>> instance messages, file transmissions, even voice /
video calls, etc.
>> (Especially for cases where back and forth is needed,
as David mentioned.)
>> It does not mean questions that do not get enough
attentions on MLs are
>> now
>> guaranteed to be answered immediately. We can probably
put that into the
>> code of conduct, and kindly guide users to first search
and initiate
>> questions on MLs.
>> - I'd also like to share some experience from the Flink
China community.
>> We
>> have 3 DingTalk groups with totally 25k members (might
be less, I didn't
>> do
>> deduplication), posting hundreds of messages daily.
What I'm really
>> excited
>> about is that, there are way more interactions between
users & users than
>> between users & developers. Users are helping each
other, sharing
>> experiences, sending screenshots / log files /
documentations and solving
>> problems together. We the developers seldom get pinged,
if not proactively
>> joined the conversations. The DingTalk groups are way
more active compared
>> to the user-zh@ ML, which I'd attribute to the
improvement of interaction
>> experiences. Admittedly, there are questions being
repeatedly asked &
>> answered, but TBH I don't think that compares to the
benefit of a
>> self-driven user community. I'd really love to see if
we can bring such
>> success to the global English-speaking community.
>>
>> Concerning StackOverFlow, it definitely worth more
attention from the
>> community. Thanks for the suggestion / reminder, Piotr
& David. I think
>> Slack and StackOverFlow are probably not mutual exclusive.
>>
>> Thank you~
>>
>> Xintong Song
>>
>>
>> [1] https://zapier.com/
>>
>>
>>
>> On Sat, May 7, 2022 at 9:50 AM Jingsong Li
<jingsongl...@gmail.com>
>> wrote:
>>
>> > Most of the open source communities I know have set
up their slack
>> > channels, such as Apache Iceberg [1], Apache Druid
[2], etc.
>> > So I think slack can be worth trying.
>> >
>> > David is right, there are some cases that need to
communicate back and
>> > forth, slack communication will be more effective.
>> >
>> > But back to the question, ultimately it's about
whether there are
>> > enough core developers willing to invest time in the
slack, to
>> > discuss, to answer questions, to communicate.
>> > And whether there will be enough time to reply to the
mailing list and
>> > stackoverflow after we put in the slack (which we
need to do).
>> >
>> > [1] https://iceberg.apache.org/community/#slack
>> > [2] https://druid.apache.org/community/
>> >
>> > On Fri, May 6, 2022 at 10:06 PM David Anderson
<dander...@apache.org>
>> > wrote:
>> > >
>> > > I have mixed feelings about this.
>> > >
>> > > I have been rather visible on stack overflow, and
as a result I get a
>> > lot of DMs asking for help. I enjoy helping, but want
to do it on a
>> > platform where the responses can be searched and shared.
>> > >
>> > > It is currently the case that good questions on
stack overflow
>> > frequently go unanswered because no one with the
necessary expertise
>> takes
>> > the time to respond. If the Flink community has the
collective energy
>> to do
>> > more user outreach, more involvement on stack
overflow would be a good
>> > place to start. Adding slack as another way for users
to request help
>> from
>> > those who are already actively providing support on
the existing
>> > communication channels might just lead to burnout.
>> > >
>> > > On the other hand, there are rather rare, but very
interesting cases
>> > where considerable back and forth is needed to figure
out what's going
>> on.
>> > This can happen, for example, when the requirements
are unusual, or
>> when a
>> > difficult to diagnose bug is involved. In these
circumstances, something
>> > like slack is much better suited than email or stack
overflow.
>> > >
>> > > David
>> > >
>> > > On Fri, May 6, 2022 at 3:04 PM Becket Qin
<becket....@gmail.com>
>> wrote:
>> > >>
>> > >> Thanks for the proposal, Xintong.
>> > >>
>> > >> While I share the same concerns as those mentioned
in the previous
>> > discussion thread, admittedly there are benefits of
having a slack
>> channel
>> > as a supplementary way to discuss Flink. The fact
that this topic is
>> raised
>> > once a while indicates lasting interests.
>> > >>
>> > >> Personally I am open to having such a slack
channel. Although it has
>> > drawbacks, it serves a different purpose. I'd imagine
that for people
>> who
>> > prefer instant messaging, in absence of the slack
channel, a lot of
>> > discussions might just take place offline today,
which leaves no public
>> > record at all.
>> > >>
>> > >> One step further, if the channel is maintained by
the Flink PMC, some
>> > kind of code of conduct might be necessary. I think
the suggestions of
>> > ad-hoc conversations, reflecting back to the emails
are good starting
>> > points. I am +1 to give it a try and see how it goes.
In the worst
>> case, we
>> > can just stop doing this and come back to where we
are right now.
>> > >>
>> > >> Thanks,
>> > >>
>> > >> Jiangjie (Becket) Qin
>> > >>
>> > >> On Fri, May 6, 2022 at 8:55 PM Martijn Visser
<mart...@ververica.com
>> >
>> > wrote:
>> > >>>
>> > >>> Hi everyone,
>> > >>>
>> > >>> While I see Slack having a major downside (the
results are not
>> indexed
>> > by external search engines, you can't link directly
to Slack content
>> unless
>> > you've signed up), I do think that the open source
space has progressed
>> and
>> > that Slack is considered as something that's
invaluable to users. There
>> are
>> > other Apache programs that also run it, like Apache
Airflow [1]. I also
>> see
>> > it as a potential option to create a more active
community.
>> > >>>
>> > >>> A concern I can see is that users will start
DMing well-known
>> > reviewers/committers to get a review or a PR merged.
That can cause a
>> lot
>> > of noise. I can go +1 for Slack, but then we need to
establish a set of
>> > community rules.
>> > >>>
>> > >>> Best regards,
>> > >>>
>> > >>> Martijn
>> > >>>
>> > >>> [1] https://airflow.apache.org/community/
>> > >>>
>> > >>> On Fri, 6 May 2022 at 13:59, Piotr Nowojski
<pnowoj...@apache.org>
>> > wrote:
>> > >>>>
>> > >>>> Hi Xintong,
>> > >>>>
>> > >>>> I'm not sure if slack is the right tool for the
job. IMO it works
>> > great as
>> > >>>> an adhoc tool for discussion between developers,
but it's not
>> > searchable
>> > >>>> and it's not persistent. Between devs, it works
fine, as long as
>> the
>> > result
>> > >>>> of the ad hoc discussions is backported to
JIRA/mailing list/design
>> > doc.
>> > >>>> For users, that simply would be extremely
difficult to achieve. In
>> the
>> > >>>> result, I would be afraid we are answering the
same questions over,
>> > and
>> > >>>> over and over again, without even a way to
provide a link to the
>> > previous
>> > >>>> thread, because nobody can search for it .
>> > >>>>
>> > >>>> I'm +1 for having an open and shared slack
space/channel for the
>> > >>>> contributors, but I think I would be -1 for such
channels for the
>> > users.
>> > >>>>
>> > >>>> For users, I would prefer to focus more on, for
example,
>> > stackoverflow.
>> > >>>> With upvoting, clever sorting of the answers
(not the oldest/newest
>> > at top)
>> > >>>> it's easily searchable - those features make it
fit our use case
>> much
>> > >>>> better IMO.
>> > >>>>
>> > >>>> Best,
>> > >>>> Piotrek
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> pt., 6 maj 2022 o 11:08 Xintong Song
<tonysong...@gmail.com>
>> > napisał(a):
>> > >>>>
>> > >>>> > Thank you~
>> > >>>> >
>> > >>>> > Xintong Song
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> > ---------- Forwarded message ---------
>> > >>>> > From: Xintong Song <tonysong...@gmail.com>
>> > >>>> > Date: Fri, May 6, 2022 at 5:07 PM
>> > >>>> > Subject: Re: [Discuss] Creating an Apache
Flink slack workspace
>> > >>>> > To: private <priv...@flink.apache.org>
>> > >>>> > Cc: Chesnay Schepler <ches...@apache.org>
>> > >>>> >
>> > >>>> >
>> > >>>> > Hi Chesnay,
>> > >>>> >
>> > >>>> > Correct me if I'm wrong, I don't find this is
*repeatedly*
>> > discussed on the
>> > >>>> > ML. The only discussions I find are [1] & [2],
which are 4 years
>> > ago. On
>> > >>>> > the other hand, I do find many users are
asking questions about
>> > whether
>> > >>>> > Slack should be supported [2][3][4]. Besides,
I also find a
>> recent
>> > >>>> > discussion thread from ComDev [5], where
alternative
>> communication
>> > channels
>> > >>>> > are being discussed. It seems to me ASF is
quite open to having
>> such
>> > >>>> > additional channels and they have been worked
well for many
>> projects
>> > >>>> > already.
>> > >>>> >
>> > >>>> > I see two reasons for brining this discussion
again:
>> > >>>> > 1. There are indeed many things that have
change during the past
>> 4
>> > years.
>> > >>>> > We have more contributors, including
committers and PMC members,
>> > and even
>> > >>>> > more users from various organizations and
timezones. That also
>> > means more
>> > >>>> > discussions and Q&As are happening.
>> > >>>> > 2. The proposal here is different from the
previous discussion.
>> > Instead of
>> > >>>> > maintaining a channel for Flink in the ASF
workspace, here we are
>> > proposing
>> > >>>> > to create a dedicated Apache Flink slack
workspace. And instead
>> of
>> > *moving*
>> > >>>> > the discussion to Slack, we are proposing to
add a Slack
>> Workspace
>> > as an
>> > >>>> > addition to the ML.
>> > >>>> >
>> > >>>> > Below is your opinions that I found from your
previous -1 [1].
>> > IIUR, these
>> > >>>> > are all about the using ASF Slack Workspace.
If I overlooked
>> > anything,
>> > >>>> > please let me know.
>> > >>>> >
>> > >>>> > > 1. According to INFRA-14292 <
>> > >>>> > >
https://issues.apache.org/jira/browse/INFRA-14292> the ASF
>> Slack
>> > isn't
>> > >>>> > > run by the ASF. This alone puts this service
into rather
>> > questionable
>> > >>>> > > territory as it /looks/ like an official ASF
service. If anyone
>> > can
>> > >>>> > provide
>> > >>>> > > information to the contrary, please do so.
>> > >>>> >
>> > >>>> > 2. We already discuss things on the mailing
lists, JIRA and
>> GitHub.
>> > All of
>> > >>>> > > these are available to the public, whereas
the slack channel
>> > requires an
>> > >>>> > > @apache mail address, i.e. you have to be a
committer. This
>> > minimizes the
>> > >>>> > > target audience rather significantly. I
would much rather
>> prefer
>> > >>>> > something
>> > >>>> > > that is also available to contributors.
>> > >>>> >
>> > >>>> >
>> > >>>> > I do agree this should be decided by the whole
community. I'll
>> > forward this
>> > >>>> > to dev@ and user@ ML.
>> > >>>> >
>> > >>>> > Thank you~
>> > >>>> >
>> > >>>> > Xintong Song
>> > >>>> >
>> > >>>> >
>> > >>>> > [1]
>> >
https://lists.apache.org/thread/gxwv49ssq82g06dbhy339x6rdxtlcv3d
>> > >>>> > [2]
>> >
https://lists.apache.org/thread/kcym1sozkrtwxw1fjbnwk1nqrrlzolcc
>> > >>>> > [3]
>> >
https://lists.apache.org/thread/7rmd3ov6sv3wwhflp97n4czz25hvmqm6
>> > >>>> > [4]
>> >
https://lists.apache.org/thread/n5y1kzv50bkkbl3ys494dglyxl45bmts
>> > >>>> > [5]
>> >
https://lists.apache.org/thread/fzwd3lj0x53hkq3od5ot0y719dn3kj1j
>> > >>>> >
>> > >>>> > On Fri, May 6, 2022 at 3:05 PM Chesnay Schepler <
>> ches...@apache.org
>> > >
>> > >>>> > wrote:
>> > >>>> >
>> > >>>> > > This has been repeatedly discussed on the ML
over the years and
>> > was
>> > >>>> > > rejected every time.
>> > >>>> > >
>> > >>>> > > I don't see that anything has changed that
would invalidate the
>> > >>>> > previously
>> > >>>> > > raised arguments against it, so I'm still -1
on it.
>> > >>>> > >
>> > >>>> > > This is also not something the PMC should
decide anyway, but
>> the
>> > project
>> > >>>> > > as a whole.
>> > >>>> > >
>> > >>>> > > On 06/05/2022 06:48, Jark Wu wrote:
>> > >>>> > >
>> > >>>> > > Thank Xintong, for starting this exciting topic.
>> > >>>> > >
>> > >>>> > > I think Slack would be an essential addition
to the mailing
>> list.
>> > >>>> > > I have talked with some Flink users, and
they are surprised
>> > >>>> > > Flink doesn't have Slack yet, and they would
love to use Slack.
>> > >>>> > > We can also see a trend that new open-source
communities
>> > >>>> > > are using Slack as the community base camp.
>> > >>>> > >
>> > >>>> > > Slack is also helpful for brainstorming and
asking people for
>> > opinions
>> > >>>> > and
>> > >>>> > > use cases.
>> > >>>> > > I think Slack is not only another place for
Q&A but also a
>> > connection to
>> > >>>> > > the Flink users.
>> > >>>> > > We can create more channels to make the
community have more
>> social
>> > >>>> > > attributes, for example,
>> > >>>> > > - Share ideas, projects, integrations,
articles, and
>> > presentations
>> > >>>> > > related to Flink in the #shows channel
>> > >>>> > > - Flink releases, events in the #news channel
>> > >>>> > >
>> > >>>> > > Thus, I'm +1 to create an Apache Flink
slack, and I can help
>> set
>> > up the
>> > >>>> > > Flink slack and maintain it.
>> > >>>> > >
>> > >>>> > > Best,
>> > >>>> > > Jark
>> > >>>> > >
>> > >>>> > > On Fri, 6 May 2022 at 10:38, Xintong Song <
>> tonysong...@gmail.com>
>> > wrote:
>> > >>>> > >
>> > >>>> > >> Hi all,
>> > >>>> > >>
>> > >>>> > >> I’d like to start a discussion on creating
an Apache Flink
>> slack
>> > >>>> > >> workspace.
>> > >>>> > >>
>> > >>>> > >> ## Motivation
>> > >>>> > >> Today many organizations choose to do real
time communication
>> > through
>> > >>>> > >> slack. IMHO, we, Flink, as a technique for
real time
>> computing,
>> > should
>> > >>>> > >> embrace the more real time way for
communication, especially
>> for
>> > ad-hoc
>> > >>>> > >> questions and interactions. With more and
more contributors
>> from
>> > >>>> > different
>> > >>>> > >> organizations joining this community, it
would be good to
>> > provide a
>> > >>>> > common
>> > >>>> > >> channel for such real time communications.
Therefore, I'd
>> > propose to
>> > >>>> > create
>> > >>>> > >> an Apache Flink slack workspace that is
maintained by the
>> Flink
>> > PMC.
>> > >>>> > >>
>> > >>>> > >> ## Benefits
>> > >>>> > >> - Easier to reach out to people. Messages
are less likely
>> > overlooked.
>> > >>>> > >> - Realtime messages, voice / video calls,
file transmissions
>> > that help
>> > >>>> > >> improve the communication efficiency.
>> > >>>> > >> - Finer-grained channels (e.g., flink-ml,
flink-statefun,
>> > temporal
>> > >>>> > >> discussion channels for specific topics, etc.).
>> > >>>> > >>
>> > >>>> > >> ## Relationship with the mailing lists
>> > >>>> > >> I think the slack workspace should be an
extension rather
>> than a
>> > >>>> > >> replacement of the mailing lists. Community
members should
>> still
>> > be
>> > >>>> > able to
>> > >>>> > >> follow what’s going on from solely the
mailing lists. That
>> means:
>> > >>>> > >> a) All the decisions, conclusions and
important opinions
>> should
>> > be
>> > >>>> > >> reflected back to the mailing lists. After
all, according to
>> the
>> > Apache
>> > >>>> > >> Way, if it didn’t happen on a mailing list,
it didn’t happen.
>> > >>>> > >> b) We should encourage people to only ask
ad hoc questions on
>> > slack.
>> > >>>> > Long
>> > >>>> > >> conversations (or ad hoc questions that
grow long) should be
>> > posted on
>> > >>>> > the
>> > >>>> > >> mailing lists, and can be referenced on
slack for a real time
>> > >>>> > discussion.
>> > >>>> > >>
>> > >>>> > >> ## Responsiveness
>> > >>>> > >> Using slack does not mean people being
pinged need to be
>> > responsive. We
>> > >>>> > >> are in an open-sourced community where all
contributors are
>> > volunteers.
>> > >>>> > >> Slack should be used to make communication
easier only when
>> all
>> > the
>> > >>>> > peers
>> > >>>> > >> are convenient. We should make it clear
that people should not
>> > expect
>> > >>>> > >> others to always be responsive.
>> > >>>> > >>
>> > >>>> > >> ## Archivability and searchability
>> > >>>> > >> One of the shortcomings that Slack is often
mentioned with is
>> > its lack
>> > >>>> > of
>> > >>>> > >> capability to archive conversations and to
search among them.
>> > There are
>> > >>>> > >> various tools that help address this
problem[1]. As a first
>> > step, we may
>> > >>>> > >> start with simply relying on reflecting
things back to the
>> > mailing
>> > >>>> > lists.
>> > >>>> > >> IMHO, if everything important is properly
reflected back to
>> the
>> > mailing
>> > >>>> > >> lists, we don’t really need the
archivability and
>> searchability.
>> > >>>> > >>
>> > >>>> > >> ## Other communities
>> > >>>> > >> AFAIK, there are many popular open-source
projects (Apache
>> > hosted or
>> > >>>> > not)
>> > >>>> > >> that have their own Slack workspace:
AirFlow [2], IceBerg [3],
>> > HBase [4]
>> > >>>> > >> etc.
>> > >>>> > >>
>> > >>>> > >> To name the Slack workspace with Apache
Flink, we would need
>> an
>> > official
>> > >>>> > >> vote and approval from the PMC members. But
before we get to
>> > that, I’d
>> > >>>> > like
>> > >>>> > >> to hear more about what you think.
>> > >>>> > >>
>> > >>>> > >> Thank you~
>> > >>>> > >>
>> > >>>> > >> Xintong Song
>> > >>>> > >>
>> > >>>> > >>
>> > >>>> > >> [1] http://apache-airflow.slack-archives.org
>> > >>>> > >> [2] https://airflow.apache.org/community
>> > >>>> > >> [3] https://iceberg.apache.org/community/#slack
>> > >>>> > >> [4]
>> https://hbase.apache.org/book.html#trouble.resources.slack
>> > >>>> > >>
>> > >>>> > >
>> > >>>> > >
>> > >>>> >
>> >
>>
>
