Hi Jarek, I have thought of this before too as it has come up multiple times, mostly in my involvement as mentor for a new podling. I do see one problem with "simply archive the emails automatically sent" ... most of them usually are in a form where it's not easily readable what actually happens. If there was a way to not only mirror what's happening in github issues or github discussions, but also some sort of injestion that makes the resulting stream of emails easily consumable by humans, I have no objections. But if in the end we just produce a new "email grave" for emails that are only usable as an excuse, I wouldn't want to see that.
Chris -----Original Message----- From: Jarek Potiuk <ja...@potiuk.com> Sent: Freitag, 18. Februar 2022 11:11 To: dev@community.apache.org Subject: Re: Re: Thoughts on alternative communication channels for our communities I think we can use many tools but when it comes to practicalities - I also think we should consider the important factor which is how easy it is to "join" and possibly "migrate". For Airflow I think a huge benefit of GitHub discussions / Issues is that pretty much everyone is there already. No friction to join. if you do anything with Airflow - you already have an account there. Full Stop. Even If you want to raise an issue (our users are a huge part of the community) - you need to have an account. You already have some "notification" scheme set there (at the very least you get notified when you are mentioned). When you look at the numbers - our slack has 21.000 members. We have 25.000 stars on GitHub, 800 people watch what happens in the repo and we have more than 2000 contributors in GitHub. If you try to move it elsewhere - good luck with achieving 10% conversion of that. Also I perfectly understand it is different for different projects - and they are already often vested in their tools and the community is already gathering around some of those - I am by far the last to say "do as we do". What works for us, might not work for others. I personally believe we should simply embrace the diversity of tools for communication in ASF. Some projects can use Mattermost, Some free slack, Some Github. Some might focus more on the devlist and people will be comfortable there as well. I think, rather than prescribing a specific solution, we should simply set the criteria (and those were nicely laid out by Mark) and let the projects choose. Here where I see the INFRA role - is to work-out (with the help of others) some ways on how different communication media can full-fill the criteria. For example in the case of Slack - we already have a tool (generic) that allows exporting and exposing ALL archives from a free slack (automatically) - why not make the tool "blessed" by INFRA and made as a condition of using free slack by any project that wants it. Or a way to simply archive all the emails sent by GitHub Discussions and issues as a "archive owned by the ASF". Then projects could simply choose what tools they want to use - if every tool would have a set of "checkboxes" to check and a way to verify automatically if they are followed that would be enough. J. On Fri, Feb 18, 2022 at 9:22 AM Hans Van Akelyen <hans.van.akel...@gmail.com> wrote: > Hi All, > > My 2 cents on the matter, we have an application (Apache Hop) that is > mainly used by non developers so most of our questions are not of a > technical nature but more general hand-holding and troubleshooting. > Though it should be possible to do this via email you end up with a > tread of 20 mails back and forth "have you tried pressing x, and what > variables have you used,...." > These types of conversations are best handled synchronously so we were > looking at the ASF slack at first. > Our feeling was that the threshold to enter the ASF slack was too > high. You either need an invite which is a single channel user or you > need to be a committer and we would be excluding Chinese users as > slack is blocked there. > > Therefore we set up our own Mattermost server which is an open source > slack alternative with no user limitations when managing your own > infrastructure. > > Though some development stuff is also discussed there we then point to > the developers list or add a summary there for further discussion. > > Cheers, > Hans > > On Fri, 18 Feb 2022 at 01:58, Liu Ted <tedl...@yahoo.com.invalid> wrote: > > > We do need a modernized and/or complimentary communication channel. > > On many choices we have, I am also for GitHub Discussions for the > > benefits > as > > Matt Sicker described. > > Another factor to consider is there is a Great Firewall (GFW) in > > China blocking many chat apps like Slack, Discord, Telegram, etc. > > unless using VPN whereas GitHub Discussions is accesible, no VPN > > needed, which allows and welcomes more easy communications with the > > foundation when adoption > of > > the Apache Way and its projects are booming in China. > > Best regards, > > Ted LiuASF member > > > > 2022 年 2 月 18 日周五 0:58，Matt Sicker<boa...@gmail.com> 写道： I like chat > > apps, though they're definitely more suited to real-time discussion. > > Note that the ASF Slack is a paid tier which has full archives, so > > any PMCs using their own Slack instances could potentially migrate > > to the ASF one. There may be more suitable chat apps for development > > use (e.g., that have useful search functionality, threading, etc.), > > though they're probably less popular than Slack or Discord. > > > > As for the idea on GitHub Discussions, that sounds fairly > > interesting, though I've never used it before. I do like mailing > > lists for projects I'm more active in since I always check my email > > (but am not on GitHub every day), though I can totally understand > > why other people prefer using websites or apps instead (commonly > > because they don't like using email or have their own preferred > > workflows). GitHub's integration with email for its various > > notification things (where you can reply directly to the email to > > have your message posted back to GitHub) makes the concept a bit > > more of a two-way street similar to the git repositories themselves. > > > > On Wed, Feb 16, 2022 at 7:26 PM Gilles Sadowski > > <gillese...@gmail.com> > > wrote: > > > > > > Le mer. 16 févr. 2022 à 18:55, Mark Thomas <ma...@apache.org> a > > > écrit > : > > > > > > > > To repeat what I have written elsewhere on this topic in the past: > > > > > > > > Project communication channels should be: > > > > > > > > - Public. The decision making process should be open and visible to > > > > everyone. It should also be easy for people to find. > > > > > > > > - Searchable. So anyone can look-up past discussions. > > > > > > > > - Asynchronous. To enable participation from a globally distributed > > > > community. > > > > > > > > - ASF owned archive. So we always have access to past discussions. > > > > > > > > - Low overhead. Community members may not have access to powerful PCs > > > > or high-speed and/or reliable internet. The lower the > > > > overhead of > a > > > > communication channel, the greater the potential for > participation. > > > > > > > > - Usable off-line. Helps those with poor / intermittent / expensive > > > > internet access and those who are off-line for other reasons (e.g. > > > > traveling) > > > > > > > > > > > > I wonder if something like matrix[1] could be a way to enable > > > > people > to > > > > communicate via their platform of choice whilst retaining our > archived > > > > mailing lists as the canonical view. > > > > > > > > Mark > > > > > > > > > > > > [1] https://matrix.org/ > > > > > > Is INFRA investigating? > > > > > > Gilles > > > > > > >> [...] > > > > > > ------------------------------------------------------------------ > > > --- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > >
