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 > > >>>> > >> > > >>>> > > > > >>>> > > > > >>>> > > > >
