You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Liu Ted <te...@yahoo.com.INVALID> on 2022/02/18 00:57:41 UTC
回复：Re: Thoughts on alternative communication channels for our communities
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<bo...@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 <gi...@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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Re: Thoughts on alternative communication channels for our communities
Posted by Jarek Potiuk <ja...@potiuk.com>.
Just to take the example of Github Discussions - I believe there is a way
to subscribe to all conversations (I do it and I get/read/scan through all
the email discussions happening in the Airflow project. And as Matt
mentioned - it even supports the "classic" email interface. You can just
reply to the email you receive and it will be converted into a discussion
response. So yeah. I think this is perfectly doable for discussions to
archive it in the same way as any other mailing list I think.
There are of course some problems like persistent links to discussion that
could potentially survive GitHub pulling all of it down (not a very likely
possibility, but I think such an archive should have a way to recover
original links to discussions in case they are posted in Whimsy or
elsewhere). Seems "doable" and "easy".
And I'd even argue - if such an email archive is stored in a portable way
(mbox or similar) - we don't even "Have to" implement the recovery
mechanism - just knowing that we CAN do it if needed should be enough.
I just took an example of headers and they contain all the information
necessary to recover it. Here is an example mail header from discussion
https://github.com/apache/airflow/discussions/21624 - so if you post that
links somewhere, you should be able to rebuild an index from those messages
if there is a need:
From: Giorgio Zorzi <no...@github.com>
Reply-To: "apache/airflow"
<re...@reply.github.com>
To: "apache/airflow" <ai...@noreply.github.com>
Cc: Jarek Potiuk <ja...@potiuk.com>, Mention <me...@noreply.github.com>
Message-ID: <ap...@github.com>
In-Reply-To: <ap...@github.com>
References: <ap...@github.com>
Subject: Re: [apache/airflow] Tasks failing often with no logs
(Discussion #21624)
Again - it might or might not work for others. And it is of course a
"proprietary" service so we should definitely not put "organizational
survivability" based on it being free and available. But if we protect
ourselves and know that we "CAN" move out if needed with relatively small
cost, I'd say that might be one of the acceptable solutions (among many
others).
J.
On Fri, Feb 18, 2022 at 11:51 AM Christofer Dutz <ch...@c-ware.de>
wrote:
> 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.akelyen@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 <te...@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<bo...@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
> > > <gi...@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-unsubscribe@community.apache.org
> > > > For additional commands, e-mail: dev-help@community.apache.org
> > > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
> > >
> > >
> > >
> >
>
RE: Re: Thoughts on alternative communication channels for our communities
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ha...@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 <te...@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<bo...@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
> > <gi...@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-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
> >
> >
>
Re: Re: Thoughts on alternative communication channels for our communities
Posted by Jarek Potiuk <ja...@potiuk.com>.
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 <ha...@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 <te...@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<bo...@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 <gi...@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-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
> >
> >
>
Re: Re: Thoughts on alternative communication channels for our communities
Posted by Hans Van Akelyen <ha...@gmail.com>.
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 <te...@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<bo...@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 <gi...@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-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
>