Hi, I involved in the Apache APISIX Community since 2019, and I would prefer to keep using the mailing list than other ways. There have been some challenges like not a friendly way to discuss codes, not every volunteer or contributor watching the mailing list, and so on, but there also have advantages:
1. It's public, archived, and searchable. When the APISIX project is was not donated to the ASF, maintainers search historical mails from other ASF projects and follow the guidelines, without much help to ask "How to do this?" again and again. 2. We could use Slack to discuss things of course, but if the community is very active and there will have lots of unread messages, it's indeed a challenge for me personally. 3. I agree that many projects tend to use other tools to discuss than a mailing list, like Slack and Discord, they're ok because our goal is to keep things transparent and clear (personally think), also the project community is active and healthy. 4. As for "If it did not happen on the ML, then it did not happen.", it's our foundation's community culture, it doesn't conflict with other tools. No matter which tool we use, don't forget what's our goal :) Best Regards! @ Zhiyuan Ju <https://github.com/juzhiyuan> Bertrand Delacretaz <bdelacre...@apache.org> 于2022年2月18日周五 21:38写道： > Hi, > > Le mer. 16 févr. 2022 à 13:50, Roman Shaposhnik <r...@apache.org> a écrit : > > ...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.... > > I agree, and the risk with sticking with "if it didn't happen on the > mailing list it didn't happen" is that some projects route around > that, just play lip service to it but use other channels for their > actual work. I think that is happening today, to various degrees. > > One way to avoid that would be to replace that dogma with more > realistic criteria that can be met with other tools, similar to what > Mark Thomas mentions in this thread, letting each project select the > tools that work best for them within those boundaries. > > Things like: > -Project channels must be public, async, archived on ASF-owned > services and searchable > -Project channels must be usable with open source clients (hmmm..Slack?) > -All decisions and votes must be documented on the project's mailing > list, with links to the original discussion. > > I think such a list of criteria (to be refined) would give our > projects more leeway while respecting our actual goals in terms of > open communications. > > -Bertrand > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
