Thank you @Xintong Song <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, 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 >>> >> > >>>> > >> >>> >> > >>>> > > >>> >> > >>>> > > >>> >> > >>>> > >>> >> > >>> >> >>> > >>> >>
