For me (and I think I speak for a number of Airflow people) slack is great to keep casual discussions, help users with troubleshooting or do some brainstorming, and also to make announcements and ask people for opinions. But it's non-public by default and not easy to find stuff.
For most of the "what happens in the project" however this is the kind of "short memory" storage. When I remember something happened in slack I rarely care to search for it (and when I do, the result is usually poor). Also because slack has the limits for free versions and is terribly expensive for big communities (though we have a read-only version of all archives - via a web app developed by one of our team members, so we keep and exose publicly all "public" conversation actually). We also tend to not make decisions there, but similarly as others mentioned, bring discussion to the devlist (often linking to the slack conversation though) and decide there. However there is one more interesting medium where more "substantial" and really interesting discussions happen - Github Discussions. https://github.com/apache/airflow/discussions (and GitHub Issues to some extent) - we use it for multiple purposes (including converting troubleshooting issues to discussions. More often than not, discussions about "important features" are more interesting and more people are engaged there and they will spend their time and energy there. Also because (contrary to having a GitHub account) not everyone interested reads and subscribes mailing lists. I personally believe there are a number of people who are never going to use a mailing list because it is "ancient" and "intimidating" for them - and some people literally and loudly despise it. The inability to mention people and issues, embed video, emoticons (yeah), links and images easily. But I think there is one important intimidating factor of the mailing list: the inability to correct your typos and mistakes and updating your statements after you sent it, puts many people off. BTW. Github Discussion and issues also track and expose history of changes so you cannot "remove" what you wrote - it is still there, but less easily accessible - this pretty much guarantees that you will not want to use it to modify your statement completely - but you can add corrections. And when you subscribe to changes in the project via (yes!) email - you can still see original "typoed" message there. To be perfectly honest, sometimes when I write "Please raise it as a discussion in the devlist - here is the link to how to subscribe" in many cases this feels like a "/dev/null" redirection). I did it many times and I recall maybe once or twice when a new user with a good idea (but one that was more than just a PR) actually started a thread in the devlist. Usually discussions like that simply disappear. I think GitHub Discussion/Issues fulfills a lot of the criteria of what was important for mailing lists: public, searchable, you can keep archives (via emails at the least). And it is way more approachable and modern than mailing lists. J. On Wed, Feb 16, 2022 at 2:56 PM Gilles Sadowski <gillese...@gmail.com> wrote: > Le mer. 16 févr. 2022 à 14:16, Gary Gregory <garydgreg...@gmail.com> a > écrit : > > > > My assumption using Slack is that it is a convenience > > Provided that everyone has been informed that a discussion > is going to take place there. > What about the "asynchronicity" tenet of the "Apache Way"? > > > but that decisions > > MUST be reflected on a mailing list. > > IIUC, it is not allowed that a decision _actually_ take place > elsewhere (as per "If it did not happen on the ML, then it did > not happen."). > > Regards, > Gilles > > > > > Gary > > > > On Wed, Feb 16, 2022, 08:13 Trevor Grant <trevor.d.gr...@gmail.com> > wrote: > > > > > I shared in Comdev channel on ASF Slack that on the mahout slack we > have a > > > convention that when we get to something that should be memorialized > > > someone says, "This should really be reflected back to the list". And > > > whoever says that has implicitly called "not it" for having to reflect > it > > > back- This motivates everyone to be the first to say "This should go > back > > > to the list". In the rare cases where no one says it- the original > author > > > reflects back to the list- as is the case with this email and the > comdev > > > list. > > > > > > > > > > > > On Wed, Feb 16, 2022 at 7:08 AM Gary Gregory <garydgreg...@gmail.com> > > > wrote: > > > > > > > Slack chat and video helped us tremendously on the Log4j team > especially > > > > since Log4Shell. > > > > > > > > Gary > > > > > > > > On Wed, Feb 16, 2022, 07:50 Roman Shaposhnik <r...@apache.org> wrote: > > > > > > > > > Hi! > > > > > > > > > > while the classical ASF communication culture is pretty squarely > > > > > centered around mailing lists it has become apparent in recent > > > > > years that some of our communities (especially younger ones) > > > > > prefer using alternative channels of communication. The range > > > > > is pretty wide from Slack to Telegram and WeChat (and I have > > > > > even heard of an occasional TikTok use ;-)). > > > > > > > > > > The question that originated from one of the board meetings and > > > > > the one that I'd like to pose for this forum is basically: what's > our > > > > > collective advice to these communities on these alternative (and > > > > > when I say alternative I really mean anything but a mailing list) > > > > > communication channels? > > > > > > > > > > Personally I don't think denying them is a viable strategy, but I'd > > > > > like to open up this discussion and see what others think. > > > > > > > > > > So... let's at least start with folks sharing their experience with > > > > > these alternative communication channels: the good, the bad > > > > > and the ugly. > > > > > > > > > > Personally, I don't think I have much to share -- I'm still very > > > > > much a mailing list guy when it comes to ASF. > > > > > > > > > > Thanks, > > > > > Roman. > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
