Thoughts on alternative communication channels for our communities

[Roman Shaposhnik <rv...@apache.org>]

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.

Re: Thoughts on alternative communication channels for our communities

[Willem Jiang <wi...@gmail.com>]

On Thu, Feb 24, 2022 at 2:06 AM tison <wa...@gmail.com> wrote:

> Of course, it requires more community members who can answer user questions.
>
> To sum up, you CAN have multiple channels for answering user questions and
> collect best practices. Whether or not it's fragmented is up to (1) whether
> or not you conclude FAQ into (central) docs and (2) whether or not you can
> covered all of those channels so that users get them all responsive.
>

I agree we can provide multiple channels for user engagement.
I think we can focus on a main entry for knowledge sharing, and
other channels for information sharing.
Sometimes we just start a small talk or send a link of FAQ in the
instance massage channel.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Roman Shaposhnik <ro...@shaposhnik.org>]

Hi tison!

On Wed, Feb 23, 2022 at 7:06 PM tison <wa...@gmail.com> wrote:

> Hi Roman,
>
> I noticed your summary and focus on user-facing channels. Comments inline.
>
> Roman Shaposhnik <ro...@shaposhnik.org>于2022年2月22日 周二23:32写道：
>
> > Thanks for all the feedback so far. If I were to summarize what's been
> > expressed
> > on this thread so far, it seems that we're all agreeing that:
> >    1. Even if mailing lists appear to be clunky in 2022 they are still
> > appreciated
> >     as THE channel for any kind of "official" ASF business to be
> conducted
> >     (e.g. major decision points, voting, etc.). In that sense -- whatever
> > other
> >     channels may have been used to build consensus -- the final (or
> > official
> >     if you will) closure is expected to happen on a mailing list.
>
>
> Yes. Actually communication happens in various way, public or private,
> despite of the rules we set up or encourage. But we still need a single
> source of truth for catching up decisions and mailing list works well in
> this direction.
>
>     2. There are TONS of alternative communication channels for developers
> >     and users to explore and it is unlikely that we will have any
> semblance
> >     of convergence there -- these are too fragmented by geographical,
> > cultural,
> >     language and other preferences.
> >
> > Now, if I were to make an observation, I'd split our constituency in 3 of
> > the
> > usual concentric circles: PMC, Developers/Committers, Users.
> >
> > It sounds like making sure that all official PMC business to be conducted
> > on the
> > mailing list is not only desirable from the ASF's perspective but also
> > [mostly]
> > appreciated by the PMCs themselves. That leaves Developers/Committers and
> > Users.
> >
> > My biggest problem is actually with users -- it seems that having all
> these
> > extra
> > communication channels makes it more difficult for newcomers to find good
> > entry points re: engaging with the projects -- or maybe not. That's still
> > not clear
> > to me and I would love to hear more feedback.
> >
> > What do ppl think?
> >
> > Thanks,
> > Roman.
>
>
> I think the challenge here for the wider community of developers and users
> are somehow the same - community members who are less involved tends to use
> the channel they're familiar with and responsive.
>
> Why GitHub issues and discussions mentioned many times? It's because that
> the actual development activities happens there for those projects and
> questions or discussion thrown there get responses. The point that you
> don't have to create a new account is important as mentioned above in this
> thread.
>

I am actually curious about those -- what has been everyone's experience
with Googling for things in GH issues/threads?

Now let's think of a typical journey of a user. The most frequently asked
> question is "How do I do X". It should be almost covered by documents, and
> when documents cannot solve the question, communication requirements occur.
>
> No matter what channel it provides, a user@ mailing list, an Q&A GitHub
> discussion, or a user forum, what users want eagerly is to get response and
> answered. Always a project's README should tell where you can ask a
> question and make sure it's THE channel you put an eye on.
>

Honestly, for me that question always starts with a google query -- so I
guess the real issue is whatever provides the best Google's score and shows
up sooner will win. That's on the R/O side. So I think that is fine. But if
a user decides to participate -- I believe then it becomes highly dependent
on the user's previous experience, age, background, etc. Not sure we can do
much here -- but it would be useful to see some kind of a study tracking
what makes new users engage in the quickest possible way when they try
doing it for the first time.


> Users preference matters here since the cost here may be too high to just
> ask a question but subscribing a mailing list and receiving all
> notification. Especially younger users may be even lack of knowledge to
> subscribe a mailing list (it's common in China).
>

Exactly. So... let me ask you this: do you know a project or two in ASF that
does it the best for its Chinese users? I'd really love to learn from those
experiences.


> This can be something like "friction". Users used to ask on StackOverflow
> won't be willing to switch to another channel for one question.


> On communication tools topic, I always sort out channels into 2×2 kinds.
>

I really like your split, btw.


>
> 1. topic grouped channel
>

I guess email would qualify here for ASF.


> 2. instant messaging channel
>

I guess we have ASF's Slack -- but that's about it.


>
> multiples
>
> 1. user channel
> 2. developer channel (can be further diveded into ecosystem developer,
> kernel Developer and maintainers)
>
> I think a community should grow all of them in the real world. But keep one
> topic grouped channel as SSOT of decisions.
>
> You should build instant messaging channel just like IRC in the early days,
> because if operated properly, it strengthens connections and closed short
> topic effectively.
>
> However, topic grouped channel is required also because tough discussions
> require more time and focused (by topic). Instant messaging can hardly
> achieve it even if threads are supposed, because the mindset is to
> "chatting".
>

In your opinion what's the best alternative/augmentation to email when it
comes
to topic grouped channels?


> Users wants their questions to be answered, in the way they are familiar
> with. Apache Flink resolves most possible input channel.
>
> 1. user@ mailing list. And for Chinese users, user-zh@. Note that the
> latter reflects "in the way they're familiar with".
> 2. Vendors' solution engineers answer questions on StackOverflow.
> 3. Contributors from China answer questions in DingTalk, WeChat, or Feishu.
> 4.  ...
>
> Of course, it requires more community members who can answer user
> questions.
>
> To sum up, you CAN have multiple channels for answering user questions and
> collect best practices. Whether or not it's fragmented is up to (1) whether
> or not you conclude FAQ into (central) docs and (2) whether or not you can
> covered all of those channels so that users get them all responsive.
>

Thanks,
Roman.

Re: Thoughts on alternative communication channels for our communities

[tison <wa...@gmail.com>]

Hi Roman,

I noticed your summary and focus on user-facing channels. Comments inline.

Roman Shaposhnik <ro...@shaposhnik.org>于2022年2月22日 周二23:32写道：

> Thanks for all the feedback so far. If I were to summarize what's been
> expressed
> on this thread so far, it seems that we're all agreeing that:
>    1. Even if mailing lists appear to be clunky in 2022 they are still
> appreciated
>     as THE channel for any kind of "official" ASF business to be conducted
>     (e.g. major decision points, voting, etc.). In that sense -- whatever
> other
>     channels may have been used to build consensus -- the final (or
> official
>     if you will) closure is expected to happen on a mailing list.


Yes. Actually communication happens in various way, public or private,
despite of the rules we set up or encourage. But we still need a single
source of truth for catching up decisions and mailing list works well in
this direction.

    2. There are TONS of alternative communication channels for developers
>     and users to explore and it is unlikely that we will have any semblance
>     of convergence there -- these are too fragmented by geographical,
> cultural,
>     language and other preferences.
>
> Now, if I were to make an observation, I'd split our constituency in 3 of
> the
> usual concentric circles: PMC, Developers/Committers, Users.
>
> It sounds like making sure that all official PMC business to be conducted
> on the
> mailing list is not only desirable from the ASF's perspective but also
> [mostly]
> appreciated by the PMCs themselves. That leaves Developers/Committers and
> Users.
>
> My biggest problem is actually with users -- it seems that having all these
> extra
> communication channels makes it more difficult for newcomers to find good
> entry points re: engaging with the projects -- or maybe not. That's still
> not clear
> to me and I would love to hear more feedback.
>
> What do ppl think?
>
> Thanks,
> Roman.


I think the challenge here for the wider community of developers and users
are somehow the same - community members who are less involved tends to use
the channel they're familiar with and responsive.

Why GitHub issues and discussions mentioned many times? It's because that
the actual development activities happens there for those projects and
questions or discussion thrown there get responses. The point that you
don't have to create a new account is important as mentioned above in this
thread.

Now let's think of a typical journey of a user. The most frequently asked
question is "How do I do X". It should be almost covered by documents, and
when documents cannot solve the question, communication requirements occur.

No matter what channel it provides, a user@ mailing list, an Q&A GitHub
discussion, or a user forum, what users want eagerly is to get response and
answered. Always a project's README should tell where you can ask a
question and make sure it's THE channel you put an eye on.

Users preference matters here since the cost here may be too high to just
ask a question but subscribing a mailing list and receiving all
notification. Especially younger users may be even lack of knowledge to
subscribe a mailing list (it's common in China).

This can be something like "friction". Users used to ask on StackOverflow
won't be willing to switch to another channel for one question.

On communication tools topic, I always sort out channels into 2×2 kinds.

1. topic grouped channel
2. instant messaging channel

multiples

1. user channel
2. developer channel (can be further diveded into ecosystem developer,
kernel Developer and maintainers)

I think a community should grow all of them in the real world. But keep one
topic grouped channel as SSOT of decisions.

You should build instant messaging channel just like IRC in the early days,
because if operated properly, it strengthens connections and closed short
topic effectively.

However, topic grouped channel is required also because tough discussions
require more time and focused (by topic). Instant messaging can hardly
achieve it even if threads are supposed, because the mindset is to
"chatting".

Users wants their questions to be answered, in the way they are familiar
with. Apache Flink resolves most possible input channel.

1. user@ mailing list. And for Chinese users, user-zh@. Note that the
latter reflects "in the way they're familiar with".
2. Vendors' solution engineers answer questions on StackOverflow.
3. Contributors from China answer questions in DingTalk, WeChat, or Feishu.
4.  ...

Of course, it requires more community members who can answer user questions.

To sum up, you CAN have multiple channels for answering user questions and
collect best practices. Whether or not it's fragmented is up to (1) whether
or not you conclude FAQ into (central) docs and (2) whether or not you can
covered all of those channels so that users get them all responsive.

> --
Best,
tison.

Re: Thoughts on alternative communication channels for our communities

[XiaoYu <xi...@apache.org>]

I agree with Ted Liu that many projects need a free way to
communicate, but also to be common (English) and public.

SO I think github discussions are a very good choice.

Michael Sokolov <ms...@gmail.com> 于2022年2月25日周五 20:52写道：
>
> Just my personal perspective as an aging white man, but if substantial
> portion of project discussions moved to an ephemeral communications
> channel, it would be on the one hand freeing since I wouldn't feel the
> obligation to wade through the tons of email when I catch up every few
> days, but on the other hand sad, because I would probably just not read the
> messages, and become ever more disconnected. Perhaps that's natural. Times
> change. C'est la vie
>
> Or maybe I just don't understand how it would work on the Apache Twitter
> channels of the future, but that's my concern.
>
> On Tue, Feb 22, 2022, 10:32 AM Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> > On Mon, Feb 21, 2022 at 10:19 AM Zhiyuan Ju <ju...@apache.org> wrote:
> >
> > > 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 :)
> > >
> >
> > Thanks for all the feedback so far. If I were to summarize what's been
> > expressed
> > on this thread so far, it seems that we're all agreeing that:
> >    1. Even if mailing lists appear to be clunky in 2022 they are still
> > appreciated
> >     as THE channel for any kind of "official" ASF business to be conducted
> >     (e.g. major decision points, voting, etc.). In that sense -- whatever
> > other
> >     channels may have been used to build consensus -- the final (or
> > official
> >     if you will) closure is expected to happen on a mailing list.
> >
> >     2. There are TONS of alternative communication channels for developers
> >     and users to explore and it is unlikely that we will have any semblance
> >     of convergence there -- these are too fragmented by geographical,
> > cultural,
> >     language and other preferences.
> >
> > Now, if I were to make an observation, I'd split our constituency in 3 of
> > the
> > usual concentric circles: PMC, Developers/Committers, Users.
> >
> > It sounds like making sure that all official PMC business to be conducted
> > on the
> > mailing list is not only desirable from the ASF's perspective but also
> > [mostly]
> > appreciated by the PMCs themselves. That leaves Developers/Committers and
> > Users.
> >
> > My biggest problem is actually with users -- it seems that having all these
> > extra
> > communication channels makes it more difficult for newcomers to find good
> > entry points re: engaging with the projects -- or maybe not. That's still
> > not clear
> > to me and I would love to hear more feedback.
> >
> > What do ppl think?
> >
> > Thanks,
> > Roman.
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Michael Sokolov <ms...@gmail.com>]

Just my personal perspective as an aging white man, but if substantial
portion of project discussions moved to an ephemeral communications
channel, it would be on the one hand freeing since I wouldn't feel the
obligation to wade through the tons of email when I catch up every few
days, but on the other hand sad, because I would probably just not read the
messages, and become ever more disconnected. Perhaps that's natural. Times
change. C'est la vie

Or maybe I just don't understand how it would work on the Apache Twitter
channels of the future, but that's my concern.

On Tue, Feb 22, 2022, 10:32 AM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:

> On Mon, Feb 21, 2022 at 10:19 AM Zhiyuan Ju <ju...@apache.org> wrote:
>
> > 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 :)
> >
>
> Thanks for all the feedback so far. If I were to summarize what's been
> expressed
> on this thread so far, it seems that we're all agreeing that:
>    1. Even if mailing lists appear to be clunky in 2022 they are still
> appreciated
>     as THE channel for any kind of "official" ASF business to be conducted
>     (e.g. major decision points, voting, etc.). In that sense -- whatever
> other
>     channels may have been used to build consensus -- the final (or
> official
>     if you will) closure is expected to happen on a mailing list.
>
>     2. There are TONS of alternative communication channels for developers
>     and users to explore and it is unlikely that we will have any semblance
>     of convergence there -- these are too fragmented by geographical,
> cultural,
>     language and other preferences.
>
> Now, if I were to make an observation, I'd split our constituency in 3 of
> the
> usual concentric circles: PMC, Developers/Committers, Users.
>
> It sounds like making sure that all official PMC business to be conducted
> on the
> mailing list is not only desirable from the ASF's perspective but also
> [mostly]
> appreciated by the PMCs themselves. That leaves Developers/Committers and
> Users.
>
> My biggest problem is actually with users -- it seems that having all these
> extra
> communication channels makes it more difficult for newcomers to find good
> entry points re: engaging with the projects -- or maybe not. That's still
> not clear
> to me and I would love to hear more feedback.
>
> What do ppl think?
>
> Thanks,
> Roman.
>

Re: Thoughts on alternative communication channels for our communities

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Mon, Feb 21, 2022 at 10:19 AM Zhiyuan Ju <ju...@apache.org> wrote:

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

Thanks for all the feedback so far. If I were to summarize what's been
expressed
on this thread so far, it seems that we're all agreeing that:
   1. Even if mailing lists appear to be clunky in 2022 they are still
appreciated
    as THE channel for any kind of "official" ASF business to be conducted
    (e.g. major decision points, voting, etc.). In that sense -- whatever
other
    channels may have been used to build consensus -- the final (or official
    if you will) closure is expected to happen on a mailing list.

    2. There are TONS of alternative communication channels for developers
    and users to explore and it is unlikely that we will have any semblance
    of convergence there -- these are too fragmented by geographical,
cultural,
    language and other preferences.

Now, if I were to make an observation, I'd split our constituency in 3 of
the
usual concentric circles: PMC, Developers/Committers, Users.

It sounds like making sure that all official PMC business to be conducted
on the
mailing list is not only desirable from the ASF's perspective but also
[mostly]
appreciated by the PMCs themselves. That leaves Developers/Committers and
Users.

My biggest problem is actually with users -- it seems that having all these
extra
communication channels makes it more difficult for newcomers to find good
entry points re: engaging with the projects -- or maybe not. That's still
not clear
to me and I would love to hear more feedback.

What do ppl think?

Thanks,
Roman.

Re: Thoughts on alternative communication channels for our communities

[Zhiyuan Ju <ju...@apache.org>]

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 <bd...@apache.org> 于2022年2月18日周五 21:38写道：

> Hi,
>
> Le mer. 16 févr. 2022 à 13:50, Roman Shaposhnik <rv...@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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Re: Thoughts on alternative communication channels for our communities

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Tue, Mar 1, 2022 at 9:23 PM Bertrand Delacretaz <bd...@apache.org>
wrote:

> Le mar. 1 mars 2022 à 20:12, Mark Thomas <ma...@apache.org> a écrit :
> > ...Why re-invert the wheel?
> >
> > https://matrix.org/ ...
>
> Would we need to run our own Matrix servers if we want to make it an
> alternative for our projects?
>
> Using https://matrix.org/docs/projects/server/synapse ?
> (which is written in Python - good thing for us as that's ASF infra's
> default language)
>

I'd be very much in favor of ASF offering its own medium for "real time
communications"
to augment Slack. Today the foundation doesn't have anything that would fit
that
description other than IRC (and I really think that's not enough these
days). I have
a lot of issues with us relying on Slack (including forcing ppl to have
accounts there).

So the way I see it is this: foundation offering email and Matrix would
provide an MVP
for independent channels of communications for our communities (and then we
can
even do things like
https://matrix.org/docs/projects/bridge/matrix-appservice-slack)

Thoughts?

Thanks,
Roman.

Re: Thoughts on alternative communication channels for our communities

[Bertrand Delacretaz <bd...@apache.org>]

Le mar. 1 mars 2022 à 20:12, Mark Thomas <ma...@apache.org> a écrit :
> ...Why re-invert the wheel?
>
> https://matrix.org/ ...

Would we need to run our own Matrix servers if we want to make it an
alternative for our projects?

Using https://matrix.org/docs/projects/server/synapse ?
(which is written in Python - good thing for us as that's ASF infra's
default language)

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Mark Thomas <ma...@apache.org>]

On 01/03/2022 19:02, Dave Fisher wrote:
> I want to go back to here with an idea.
> 
>> On Feb 18, 2022, at 5:38 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
>>
>> -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.
> 
> Pony Mail is a convenient way to review any mailing list. What if we require that any alternative like Slack or anything be able to produce either an email or an mbox and become a “pseudo mailing list"? If this is so then I think that given a Slack api it would possible to make use of some combination of Apache products to create the connector.
> 
> - Apache Pulsar could stream and has connectors.
> - Apache POI has MBox capability.
> - Apache James has mail capability.
> 
> I wonder if this is work that could be done in the Pony Mail podling.

Why re-invert the wheel?

https://matrix.org/

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Dave Fisher <wa...@apache.org>]

I want to go back to here with an idea.

> On Feb 18, 2022, at 5:38 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> 
> -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.

Pony Mail is a convenient way to review any mailing list. What if we require that any alternative like Slack or anything be able to produce either an email or an mbox and become a “pseudo mailing list"? If this is so then I think that given a Slack api it would possible to make use of some combination of Apache products to create the connector.

- Apache Pulsar could stream and has connectors.
- Apache POI has MBox capability.
- Apache James has mail capability.

I wonder if this is work that could be done in the Pony Mail podling.

All the Best,
Dave

Re: Thoughts on alternative communication channels for our communities

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

Le mer. 16 févr. 2022 à 13:50, Roman Shaposhnik <rv...@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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Geertjan Wielenga <ge...@googlemail.com.INVALID>]

I'm involved with Transposit (transposit.com), where they're creating a
DevOps orchestration hub, including very strong Slack integration since
more and more orgs are using Slack as their primary communication mechanism
over e-mail and anything else.

With my Apache NetBeans hat on, if we in the Apache NetBeans community were
to be working in Slack, we'd be able to use Transposit to send incoming
issues to Slack, prioritize and assign them there, while also automating
our release processes from Slack, e.g., call a Slack command to initiate a
release with buttons for the release manager to click to initiate the
actions that require human intervention.

Transposit is interested in making itself available for free to Apache
projects, which will make sense once I've explored the potential completely
and set up a few stable runbooks for the Apache NetBeans community.

However, all this is predicated on scope for Apache communities to work
with their Apache projects in the same way as they work with their projects
at the places where they work -- via Slack.

Gj

On Wed, Feb 16, 2022 at 2:17 PM Gary Gregory <ga...@gmail.com> wrote:

> My assumption using Slack is that it is a convenience but that decisions
> MUST be reflected on a mailing list.
>
> Gary
>
> On Wed, Feb 16, 2022, 08:13 Trevor Grant <tr...@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 <ga...@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 <rv...@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.
> > > >
> > >
> >
>

Re: Thoughts on alternative communication channels for our communities

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Feb 27, 2022 at 9:13 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> >
> >
> > Do any of the mentioned alternatives fulfill those requirements?
> >
>
> I think most - with very little investment on taking backup (same as we do
> with ponymail today).
>
> Two examples:
>
> * http://apache-airflow.slack-archives.org/ Apache Airflow public slack.
> searchable and owned by us: Developed by one of our PMC members in his free
> time. Solves "public", "owned", "searchable". With little effort can be
> made offline-usable (it's a simple web app that loads the backup of slack
> messages), It even looks nice. The only thing it lacks currently is support
> for thread display.
>

This is VERY nice! I'd really like to see some kind of a public
searchability on all popular ASF slack channels.


> * For Github discussion as I mentioned before it's just making sure you
> subscribe to emails (same as current Ponymail backup).
>
> I think it's not a matter of "limitation" of certain media, bit more a
> question of a little "investment" into some popular solutions to make them
> fulfill the requirements we have and a way that INFRA provides instructions
> and possible some little infrastructure and possibly "verification" for
> those popular media used by different PMC. Same as currently providing
> support for Ponymail (which is essentially a 3rd-party tool as well),
>
> It is more effort to support more solutions - yes, but INFRA can also tap
> into support of the PMCs that want to use different tools to help with
> making the effort to make it "blessed".
>

Yeah, I'm thinking that perhaps what is emerging from this thread is a
requirement to have some tooling that would allow ANYTHING -> ASF ML flow
(just for archive and searchabililty purposes). Or will this be too useless
for more "real time" style communications?

Thanks,
Roman.

Re: Thoughts on alternative communication channels for our communities

[Matt Sicker <bo...@gmail.com>]

Another chat solution to consider is Zulip [0]. Zulip's UI encourages
all chat messages to go under an appropriate thread which makes it a
bit easier to use for asynchronous communication. I think one of the
difficult aspects of using something like Slack or IRC for development
is a lack of nice threading which makes them more of a synchronous
communication tool rather than an asynchronous one. Using threads in
Zulip, it becomes a lot easier to navigate the chat without having to
read several days of chatter to find the topic you were looking for.

For what it's worth, I'm at that age near the line between people who
are used to using email and people who are used to using instant
messaging and group chats. I believe that a lack of good threading in
chat UIs is what tends to lead to the "always online" requirement to
keeping up with the chat, though most chat apps support threading at
this point, so I could be wrong.

Another issue with people and mailing lists these days are those who
don't know or care to tame their inbox. There's a reason why
smartphone notifications are used for marketing and such these days;
many people's inboxes are bursting with tens of thousands of unread
messages. It's been the double edged sword of simple and open
protocols: ease of abuse.

[0]: https://zulip.com

On Mon, Feb 28, 2022 at 6:04 AM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> >
> >
> > This is much easier to manage on any channel than "talking to the
> > group" which is IMO required for Apache-style development.
> >
> > What I mean is:
> > -Everybody sees the topics of all conversations fly by
> > -It's easy to ignore specific or most conversations
> > -It's easy to catch up after N days of absence while the rest of the
> > team has been active, by quickly skimming the thread's subject lines
> > -It's easy to use Precise Quoting in replies to enable deep conversations
> >
> > To me, the lack of first-class discussion threads, including a subject
> > line, in most chat-style channels makes it hard to support that style.
> >
>
> Yeah. I understand that - and Agree that "subject" is important in the
> "slower" conversations. Having #channels in slack somehow addresses it for
> "broader" topics, but in last few weeks many times in the conversations
> there I wrote: "Hey we've started this GitHubDiscussion here, let's move
> the discussion there" if we felt the need to "upgrade" casual chat
> to "meaningful discussion". And we did.
>
> That's why I also agree that for example slack might not be the "only" form
> of conversation for everything. It's one of the ways.
>
> I am also absolutely for deep discussions, analysis and all the arguments
> you mentioned. And GitHubDiscussions falls squarely in all the criteria you
> mentioned - including super easy reference to code (including automatically
> displaying snippets of code), issues, mentioning other users in-line,
> referring other discussions (autocompletable as you type so that you do not
> have to look it up and copy & paste), being able to use emoticons (yeah I
> am almost 50 but I think they make discussion more fun), easy quoting (and
> what I stress again) - ability to correct typos and update your comments
> in-line when you find out more with the right UPDATE: statements, adding
> checkboxes that you can check-off as the discussion progress etc. etc. are
> all there.
>
> I am very proficient in using devlist for some of that. I can personally do
> it rather easily and I've learned the etiquette when I started to
> use devlist more often. But it is all so much easier and more approachable
> using tools like GHDiscussions.
> Email has a lot of friction and simply many people are excluded by default
> and we "lose" their participation. I've been an Engineer and CTO of a
> mobile app development company and I know a lot about good, convenient UI
> and decreasing friction and how important it is.
>
> I think 20 years ago "devlist" as a 'common mechanism' was a great choice
> and facilitated "let's give everyone the possibility to participate". But
> from what I hear from people today (and feel myself), it has changed for
> many communities and if anything it "prevents participation" - it stopped
> fulfilling some of the basic premises it was started with.
>
> J.
>
>
>
> >
> > -Bertrand
> >
> > ---------------------------------------------------------------------
> > 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: Thoughts on alternative communication channels for our communities

[Jarek Potiuk <ja...@potiuk.com>]

>
>
> This is much easier to manage on any channel than "talking to the
> group" which is IMO required for Apache-style development.
>
> What I mean is:
> -Everybody sees the topics of all conversations fly by
> -It's easy to ignore specific or most conversations
> -It's easy to catch up after N days of absence while the rest of the
> team has been active, by quickly skimming the thread's subject lines
> -It's easy to use Precise Quoting in replies to enable deep conversations
>
> To me, the lack of first-class discussion threads, including a subject
> line, in most chat-style channels makes it hard to support that style.
>

Yeah. I understand that - and Agree that "subject" is important in the
"slower" conversations. Having #channels in slack somehow addresses it for
"broader" topics, but in last few weeks many times in the conversations
there I wrote: "Hey we've started this GitHubDiscussion here, let's move
the discussion there" if we felt the need to "upgrade" casual chat
to "meaningful discussion". And we did.

That's why I also agree that for example slack might not be the "only" form
of conversation for everything. It's one of the ways.

I am also absolutely for deep discussions, analysis and all the arguments
you mentioned. And GitHubDiscussions falls squarely in all the criteria you
mentioned - including super easy reference to code (including automatically
displaying snippets of code), issues, mentioning other users in-line,
referring other discussions (autocompletable as you type so that you do not
have to look it up and copy & paste), being able to use emoticons (yeah I
am almost 50 but I think they make discussion more fun), easy quoting (and
what I stress again) - ability to correct typos and update your comments
in-line when you find out more with the right UPDATE: statements, adding
checkboxes that you can check-off as the discussion progress etc. etc. are
all there.

I am very proficient in using devlist for some of that. I can personally do
it rather easily and I've learned the etiquette when I started to
use devlist more often. But it is all so much easier and more approachable
using tools like GHDiscussions.
Email has a lot of friction and simply many people are excluded by default
and we "lose" their participation. I've been an Engineer and CTO of a
mobile app development company and I know a lot about good, convenient UI
and decreasing friction and how important it is.

I think 20 years ago "devlist" as a 'common mechanism' was a great choice
and facilitated "let's give everyone the possibility to participate". But
from what I hear from people today (and feel myself), it has changed for
many communities and if anything it "prevents participation" - it stopped
fulfilling some of the basic premises it was started with.

J.



>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Re: Thoughts on alternative communication channels for our communities

[Bertrand Delacretaz <bd...@apache.org>]

Hi Jarek,

Le dim. 27 févr. 2022 à 23:11, Jarek Potiuk <ja...@potiuk.com> a écrit :
> ...I use slack for async communication a lot. Including
> underrepresented in IT Outreachy (https://www.outreachy.org/)  interns that
> I am mentoring - from India, Peru and Nigeria that I am interacting with
> them over the last 3 months of their internship Most of that is
> asynchronous because I live in Poland which is about 12 hours apart from
> both India and Peru. And we have different holidays schedules...

I think what you're describing is 1:1 async communications, or "1 to
very small group".

This is much easier to manage on any channel than "talking to the
group" which is IMO required for Apache-style development.

What I mean is:
-Everybody sees the topics of all conversations fly by
-It's easy to ignore specific or most conversations
-It's easy to catch up after N days of absence while the rest of the
team has been active, by quickly skimming the thread's subject lines
-It's easy to use Precise Quoting in replies to enable deep conversations

To me, the lack of first-class discussion threads, including a subject
line, in most chat-style channels makes it hard to support that style.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Matt Sicker <bo...@gmail.com>]

I believe it is a technical issue. Otherwise, I could disable GitHub
notifications for anything in the Apache org and rely entirely on
emails sent to either dev@ or commits@ or whichever list a project
uses for notifications. While you can reply to a commit email from
gitbox and have it go straight to dev@, the equivalent functionality
for GitHub notifications isn't there.

On Thu, Mar 3, 2022 at 8:32 AM Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le jeu. 3 mars 2022 à 14:46, Jarek Potiuk <ja...@potiuk.com> a écrit :
> >
> > Yep.
> >
> > The Apache Git Service emails have no chances to work. You have to
> > subscribe to the project notification by creating an account in GitHub
>
> This is what several people in this thread said (IIUC) would be
> unacceptable for participation in the ASF (although, as I mentioned in
> my reply earlier today, this fence is already in place in some projects).
>
> > and
> > providing the email address where you will receive notifications. It
> > would not be possible otherwise by GitHub to know who you are (you receive
> > an individually generated reply-to address)
>
> Isn't this a technical issue that could in principle be solved with a
> bridge between the ASF login, passing on an authentication token
> (as many sites do through one's Google account)?
>
> Regards,
> Gilles
>
> >
> > On Thu, Mar 3, 2022 at 2:27 PM Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > > Hi.
> > >
> > > >>> [...]
> > >
> > > > > > * Point 2. But even if I missed it - for Github Discussions it is
> > > enough to
> > > > > > reply to the email you get - with your personal email. You must have
> > > missed
> > > > > > the point as well. It's full interaction, you "reply-to" and your
> > > entry is
> > > > > > part of the discussion. Does it qualify as interaction ?
> > > >
> > > > > Next time I wish to intervene in GH discussion, I'll try it. ;-)
> > > > >
> > > >
> > > > Feel free [...]
> > >
> > > So I did try, FTR:
> > > I got this notification from the "issues@commons.a.o" ML:
> > >   https://markmail.org/message/iiiszn4g5ul35edr
> > > to which I replied:
> > >   https://markmail.org/message/ws43ryyvztnrcgb5
> > > This latter email does *not* become part of the GH discussion:
> > >
> > > https://github.com/apache/commons-collections/pull/281#discussion_r818409462
> > >
> > > Actually it's no surprise (that it does not work the way you
> > > implied above), since mails (from "issues@") have this footer:
> > > ---CUT---
> > > This is an automated message from the Apache Git Service.
> > > To respond to the message, please log on to GitHub and use the
> > > URL above to go to the specific comment.
> > > ---CUT---
> > >
> > > Hence, unless they log in into GH, an ASF contributor cannot
> > > comment on changes to an ASF code.
> > > [For all purpose, I'm shut out from GH-initiated discussions because
> > > my (ML) reply will likely be missed by people who have (some time
> > > ago already, and without consensus) started to consider that the
> > > authoritative forum is GH.]
> > >
> > > Regards,
> > > 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: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Le jeu. 3 mars 2022 à 14:46, Jarek Potiuk <ja...@potiuk.com> a écrit :
>
> Yep.
>
> The Apache Git Service emails have no chances to work. You have to
> subscribe to the project notification by creating an account in GitHub

This is what several people in this thread said (IIUC) would be
unacceptable for participation in the ASF (although, as I mentioned in
my reply earlier today, this fence is already in place in some projects).

> and
> providing the email address where you will receive notifications. It
> would not be possible otherwise by GitHub to know who you are (you receive
> an individually generated reply-to address)

Isn't this a technical issue that could in principle be solved with a
bridge between the ASF login, passing on an authentication token
(as many sites do through one's Google account)?

Regards,
Gilles

>
> On Thu, Mar 3, 2022 at 2:27 PM Gilles Sadowski <gi...@gmail.com> wrote:
>
> > Hi.
> >
> > >>> [...]
> >
> > > > > * Point 2. But even if I missed it - for Github Discussions it is
> > enough to
> > > > > reply to the email you get - with your personal email. You must have
> > missed
> > > > > the point as well. It's full interaction, you "reply-to" and your
> > entry is
> > > > > part of the discussion. Does it qualify as interaction ?
> > >
> > > > Next time I wish to intervene in GH discussion, I'll try it. ;-)
> > > >
> > >
> > > Feel free [...]
> >
> > So I did try, FTR:
> > I got this notification from the "issues@commons.a.o" ML:
> >   https://markmail.org/message/iiiszn4g5ul35edr
> > to which I replied:
> >   https://markmail.org/message/ws43ryyvztnrcgb5
> > This latter email does *not* become part of the GH discussion:
> >
> > https://github.com/apache/commons-collections/pull/281#discussion_r818409462
> >
> > Actually it's no surprise (that it does not work the way you
> > implied above), since mails (from "issues@") have this footer:
> > ---CUT---
> > This is an automated message from the Apache Git Service.
> > To respond to the message, please log on to GitHub and use the
> > URL above to go to the specific comment.
> > ---CUT---
> >
> > Hence, unless they log in into GH, an ASF contributor cannot
> > comment on changes to an ASF code.
> > [For all purpose, I'm shut out from GH-initiated discussions because
> > my (ML) reply will likely be missed by people who have (some time
> > ago already, and without consensus) started to consider that the
> > authoritative forum is GH.]
> >
> > Regards,
> > Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Jarek Potiuk <ja...@potiuk.com>]

Yep.

The Apache Git Service emails have no chances to work. You have to
subscribe to the project notification by creating an account in GitHub and
providing the email address where you will receive notifications. It
would not be possible otherwise by GitHub to know who you are (you receive
an individually generated reply-to address)

On Thu, Mar 3, 2022 at 2:27 PM Gilles Sadowski <gi...@gmail.com> wrote:

> Hi.
>
> >>> [...]
>
> > > > * Point 2. But even if I missed it - for Github Discussions it is
> enough to
> > > > reply to the email you get - with your personal email. You must have
> missed
> > > > the point as well. It's full interaction, you "reply-to" and your
> entry is
> > > > part of the discussion. Does it qualify as interaction ?
> >
> > > Next time I wish to intervene in GH discussion, I'll try it. ;-)
> > >
> >
> > Feel free [...]
>
> So I did try, FTR:
> I got this notification from the "issues@commons.a.o" ML:
>   https://markmail.org/message/iiiszn4g5ul35edr
> to which I replied:
>   https://markmail.org/message/ws43ryyvztnrcgb5
> This latter email does *not* become part of the GH discussion:
>
> https://github.com/apache/commons-collections/pull/281#discussion_r818409462
>
> Actually it's no surprise (that it does not work the way you
> implied above), since mails (from "issues@") have this footer:
> ---CUT---
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
> ---CUT---
>
> Hence, unless they log in into GH, an ASF contributor cannot
> comment on changes to an ASF code.
> [For all purpose, I'm shut out from GH-initiated discussions because
> my (ML) reply will likely be missed by people who have (some time
> ago already, and without consensus) started to consider that the
> authoritative forum is GH.]
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Re: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Hi.

>>> [...]

> > > * Point 2. But even if I missed it - for Github Discussions it is enough to
> > > reply to the email you get - with your personal email. You must have missed
> > > the point as well. It's full interaction, you "reply-to" and your entry is
> > > part of the discussion. Does it qualify as interaction ?
>
> > Next time I wish to intervene in GH discussion, I'll try it. ;-)
> >
>
> Feel free [...]

So I did try, FTR:
I got this notification from the "issues@commons.a.o" ML:
  https://markmail.org/message/iiiszn4g5ul35edr
to which I replied:
  https://markmail.org/message/ws43ryyvztnrcgb5
This latter email does *not* become part of the GH discussion:
  https://github.com/apache/commons-collections/pull/281#discussion_r818409462

Actually it's no surprise (that it does not work the way you
implied above), since mails (from "issues@") have this footer:
---CUT---
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
---CUT---

Hence, unless they log in into GH, an ASF contributor cannot
comment on changes to an ASF code.
[For all purpose, I'm shut out from GH-initiated discussions because
my (ML) reply will likely be missed by people who have (some time
ago already, and without consensus) started to consider that the
authoritative forum is GH.]

Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Jarek Potiuk <ja...@potiuk.com>]

>
>
> I'm not trying to argue about others's people preference; any tool
> can be used.  It's just that I don't think that "it's newer/graphical" is
> a reason for change.
>

It's not. I think main reason is it is more accessible, allows to edit your
answers and correct typos, works in the browser without having an apache
account.

Two years ago, we used Slack for synchronous GSoC meetings
> (which had its merits).
>

Slack 2 years ago and. now (especially with their thread support) is much
more async-friendly. Do check it out. 2 years is a long time.


> So, in addition to dropping the MLs, is the plan to force everyone
> to subscribe to GitHub?
>

No. I was pretty clear about it - let every PMC choose what's best for
them. There is no need for everyone to join. Just the community,


> There are ASF subscription requirements associated with various
> roles (committers, PMC, etc.).
>

The problem is that this is actually very egalitarian. We have almost 2000
contributors in Airflow and < 50  committers. 1950 of our community members
on GitHub (not even including the 10,000 of attendees who participated in
Airflow Summit last year) do not have ASF accounts.
Do you think it is wise to exclude them? I certainly don't. I think our
community is FAR bigger than those who subscribe to devlist. And excluding
them by default is well, stupid.


> GitHub/Slack/etc. are not yet among them so it seems weird that
> those channels could bypass the official ones.


Surely. If you want to limit to 50 people out of 2000 contributors, then
yeah . Sticking to official ones makes sense. But I want to include more
people.

Yes. [I asked for clarification about this, earlier in the thread.  Did
> INFRA
> eNover advertised that it would work?]


I hope.


> Next time I wish to intervene in GH discussion, I'll try it. ;-)
>

Feel free , As I mentioned many times - I think it differs by community. I
am the last one to impose "one solution to rule them all" on all
communities. Sounds too, well "Sauronish" ?  I think embracing diversity is
a thing. And enabling each PMC to be able to choose sounds like Apache Way
(as long as the expectations are met).

>
> Do you mean that those people don't have an email address, or cannot
> click on a subscription link in a browser?
>

Or maybe they feel intimidated by it ? I think technical capabilities are
less of a problem, but empathy and human emotions, habits are more
important. Just recognising that different people have different needs,
expectations, fears and many other emotions is important, I think. People
are not robots.

Re: Thoughts on alternative communication channels for our communities

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Feb 27, 2022 at 11:59 PM Gilles Sadowski <gi...@gmail.com>
wrote:

> Le dim. 27 févr. 2022 à 23:11, Jarek Potiuk <ja...@potiuk.com> a écrit :
> >
> > >
> > > It rather seems to me that tools targeted to synchronous
> > > communication are quite bad for asynchronous usage.
> > >
> >
> > I quite disagree, I use slack for async communication a lot. Including
> > underrepresented in IT Outreachy (https://www.outreachy.org/)  interns
> that
> > I am mentoring - from India, Peru and Nigeria that I am interacting with
> > them over the last 3 months of their internship Most of that is
> > asynchronous because I live in Poland which is about 12 hours apart from
> > both India and Peru. And we have different holidays schedules. Heck -
> > another mentor for the project is in Israel where Sunday is a working day
> > and Friday is not. VAST majority of our communication is done by Slack.
> >
> > Could you please explain what are your experiences that are somehow bad?
> > What are the success/failure stories you can share ? Please. some
> examples.
> > I can provide a dosen of those that led to successes and failures and
> > learning from those.
>
> I'm not trying to argue about others's people preference; any tool
> can be used.  It's just that I don't think that "it's newer/graphical" is
> a reason for change.
>
> Two years ago, we used Slack for synchronous GSoC meetings
> (which had its merits).
> However, the issue here (IIUC) is to replace "If it did not happen
> on the ML, then it did not happen" (where "ML" is the _primary_
> channel, not a mere "read-only", after the fact, archive of a decision
> taken elsewhere).
>
> >
> > But to be perfectly clear the Github Discussions example I've shown is
> 100%
> > asynchronous - apparently you missed that point.
>
> So, in addition to dropping the MLs, is the plan to force everyone
> to subscribe to GitHub?
>
> > > Assuming that I'm only subscribed to some project's "dev@" ML, how
> > > can I interact with either of those solutions?
> > >
> >
> > * Point 1 - I have not seen "no need to subscribe to interact" as a
> > requirement. I probably missed it. But I am sure you can point me in the
> > right direction.
>
> There are ASF subscription requirements associated with various
> roles (committers, PMC, etc.).
> GitHub/Slack/etc. are not yet among them so it seems weird that
> those channels could bypass the official ones.
>
> > * Point 2. But even if I missed it - for Github Discussions it is enough
> to
> > reply to the email you get - with your personal email. You must have
> missed
> > the point as well. It's full interaction, you "reply-to" and your entry
> is
> > part of the discussion. Does it qualify as interaction ?
>
> Yes. [I asked for clarification about this, earlier in the thread.  Did
> INFRA
> ever advertised that it would work?]
>
> > Or do we need more
> > ? What else do we need?
>
> Next time I wish to intervene in GH discussion, I'll try it. ;-)
>
> > > I still fail to understand the reason for looking for alternatives toth
> > > MLs for managing ASF projects...
> > >
> >
> > Maybe the many thousands of people who do not know how to subscribe -
> from
> > China - as mentioned before, in the thread. I am not sure if that's
> enough
> > of an argument for you.
>
> Do you mean that those people don't have an email address, or cannot
> click on a subscription link in a browser?
>

From what I understand -- those people just don't feel comfortable being
compelled doing that.

Imagine if you were asked to follow a Gopher link? Kind of the same (btw,
amazingly Gopher is actually not quite dead in 2022).

Now, you may find it ridiculous -- but it is actually very much a thing
(especially in the countries that did NOT have robust internet
participation in the 80s-90s).

Thanks,
Roman.

Re: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Le dim. 27 févr. 2022 à 23:11, Jarek Potiuk <ja...@potiuk.com> a écrit :
>
> >
> > It rather seems to me that tools targeted to synchronous
> > communication are quite bad for asynchronous usage.
> >
>
> I quite disagree, I use slack for async communication a lot. Including
> underrepresented in IT Outreachy (https://www.outreachy.org/)  interns that
> I am mentoring - from India, Peru and Nigeria that I am interacting with
> them over the last 3 months of their internship Most of that is
> asynchronous because I live in Poland which is about 12 hours apart from
> both India and Peru. And we have different holidays schedules. Heck -
> another mentor for the project is in Israel where Sunday is a working day
> and Friday is not. VAST majority of our communication is done by Slack.
>
> Could you please explain what are your experiences that are somehow bad?
> What are the success/failure stories you can share ? Please. some examples.
> I can provide a dosen of those that led to successes and failures and
> learning from those.

I'm not trying to argue about others's people preference; any tool
can be used.  It's just that I don't think that "it's newer/graphical" is
a reason for change.

Two years ago, we used Slack for synchronous GSoC meetings
(which had its merits).
However, the issue here (IIUC) is to replace "If it did not happen
on the ML, then it did not happen" (where "ML" is the _primary_
channel, not a mere "read-only", after the fact, archive of a decision
taken elsewhere).

>
> But to be perfectly clear the Github Discussions example I've shown is 100%
> asynchronous - apparently you missed that point.

So, in addition to dropping the MLs, is the plan to force everyone
to subscribe to GitHub?

> > Assuming that I'm only subscribed to some project's "dev@" ML, how
> > can I interact with either of those solutions?
> >
>
> * Point 1 - I have not seen "no need to subscribe to interact" as a
> requirement. I probably missed it. But I am sure you can point me in the
> right direction.

There are ASF subscription requirements associated with various
roles (committers, PMC, etc.).
GitHub/Slack/etc. are not yet among them so it seems weird that
those channels could bypass the official ones.

> * Point 2. But even if I missed it - for Github Discussions it is enough to
> reply to the email you get - with your personal email. You must have missed
> the point as well. It's full interaction, you "reply-to" and your entry is
> part of the discussion. Does it qualify as interaction ?

Yes. [I asked for clarification about this, earlier in the thread.  Did INFRA
ever advertised that it would work?]

> Or do we need more
> ? What else do we need?

Next time I wish to intervene in GH discussion, I'll try it. ;-)

> > I still fail to understand the reason for looking for alternatives toth
> > MLs for managing ASF projects...
> >
>
> Maybe the many thousands of people who do not know how to subscribe - from
> China - as mentioned before, in the thread. I am not sure if that's enough
> of an argument for you.

Do you mean that those people don't have an email address, or cannot
click on a subscription link in a browser?

>
> Lots of love.

Thanks. :-)

Best regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Jarek Potiuk <ja...@potiuk.com>]

>
> It rather seems to me that tools targeted to synchronous
> communication are quite bad for asynchronous usage.
>

I quite disagree, I use slack for async communication a lot. Including
underrepresented in IT Outreachy (https://www.outreachy.org/)  interns that
I am mentoring - from India, Peru and Nigeria that I am interacting with
them over the last 3 months of their internship Most of that is
asynchronous because I live in Poland which is about 12 hours apart from
both India and Peru. And we have different holidays schedules. Heck -
another mentor for the project is in Israel where Sunday is a working day
and Friday is not. VAST majority of our communication is done by Slack.

Could you please explain what are your experiences that are somehow bad?
What are the success/failure stories you can share ? Please. some examples.
I can provide a dosen of those that led to successes and failures and
learning from those.

But to be perfectly clear the Github Discussions example I've shown is 100%
asynchronous - apparently you missed that point.


> Assuming that I'm only subscribed to some project's "dev@" ML, how
> can I interact with either of those solutions?
>

* Point 1 - I have not seen "no need to subscribe to interact" as a
requirement. I probably missed it. But I am sure you can point me in the
right direction.

* Point 2. But even if I missed it - for Github Discussions it is enough to
reply to the email you get - with your personal email. You must have missed
the point as well. It's full interaction, you "reply-to" and your entry is
part of the discussion. Does it qualify as interaction ? Or do we need more
? What else do we need?


> I still fail to understand the reason for looking for alternatives toth
> MLs for managing ASF projects...
>

Maybe the many thousands of people who do not know how to subscribe - from
China - as mentioned before, in the thread. I am not sure if that's enough
of an argument for you.

Lots of love.

J.

Re: Thoughts on alternative communication channels for our communities

[Bertrand Delacretaz <bd...@apache.org>]

Le mar. 1 mars 2022 à 23:05, Bill Cole <bi...@apache.org> a écrit :
> ...I would actively oppose anything at the foundation level that requires
> contributors to have *any* account with *any* specific 3rd party for
> full participation...

Good point, agreed, and that needs to be part of our requirements if
we want to allow more channels for official communications of our
projects.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Bill Cole <bi...@apache.org>]

On 2022-03-01 at 14:58:03 UTC-0500 (Tue, 1 Mar 2022 14:58:03 -0500)
Rich Bowen <de...@community.apache.org>
is rumored to have said:

> On 2/28/22 17:00, Tomasz Urbaszek wrote:
>> This is just idea but Github is common to every project. It's 
>> something we
>> all have, so why not start there?
>
> Nope. Github is *not* common to every project. And moreover, requiring 
> a Github account to participate (fully participate) in an Apache 
> project is *not* something that I feel comfortable endorsing.

+1

I would actively oppose anything at the foundation level that requires 
contributors to have *any* account with *any* specific 3rd party for 
full participation. It's not just about GitHub/Microsoft, it's about the 
concept of dependency.




-- 
Bill Cole

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Rich Bowen <rb...@rcbowen.com>]

On 2/28/22 17:00, Tomasz Urbaszek wrote:
> This is just idea but Github is common to every project. It's something we
> all have, so why not start there?

Nope. Github is *not* common to every project. And moreover, requiring a 
Github account to participate (fully participate) in an Apache project 
is *not* something that I feel comfortable endorsing.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Le lun. 28 févr. 2022 à 23:01, Tomasz Urbaszek <tu...@apache.org> a écrit :
>
> I'm reading this discussion from the beginning (thanks to ML). I can be
> mistaken but there are two issues:
>
> 1. A community communication channel. A place where users can interact,
> discuss and seek help. This should be a place for users and the community
> should use whatever serves best.
> 2. Decision making channel. In this case we seek for an ability to archive
> and search (dev@ mailing list) but we also seek engagement from wider
> community (not offered by dev@ list).

So IIUC, we already have everything (because I don't agree with the
"not offered by list" statement). :-}
People can chat informally (towards achieving any set task) anywhere.
But decisions must be put to discussion and made on the appropriate
mailing list (which can then be mirrored to other channels), if only to
assume "lazy" consensus.

>
> In case of 1 we have poor chance to unify things (for example Slack vs
> WeChat).

And that might be why the "old" ML is still there.  New tools come...
and go.

> In case of 2 we can take advantage of the fact that every project
> now is on Github. For example what Apache Superset is doing looks
> impressive: https://github.com/apache/superset/projects/7 They still do the
> voting on mailing list
> https://lists.apache.org/thread/t2yc69rm60o7mlrp114r9rmdm96k7cwg but we may
> consider using some bots for handling this integration (possibly in both
> directions).
>
> Issues and discussions can be deleted. In this case we can consider using
> pull requests that support the same (or at least similar) threading
> functionality as issues/discussions. We have nice tool for tracking
> changes, reviewing and suggesting. This is more similar to what Kubernetes
> is doing for theirs "enchantment proposals":
> https://github.com/kubernetes/enhancements/pull/1353.

I'm not sure what that conversation is meant to illustrate; IMHO
it's full of visual noise without any significant advantage over a
discussion thread on a ML (that can contain URLs).
[Of course it's fine for GH users to use GH tools in order to work
on GH repositories (as per your point 1 above).]

>
> This is just idea but Github is common to every project. It's something we
> all have, so why not start there?

Because, IMO, a GH account should not be a requirement in order
to work on an ASF project.
Until the ASF decides that it stops supporting non-GH contributors,
a certain confusion is entertained by assuming that everyone is, or
should be, there.

> In fact maybe we can take some lessons from "newer" communities like CNCF
> projects that are no longer ML centric?

I see that they still use them:
  https://lists.cncf.io/g/main/subgroups
[I didn't dig further to check whether the various communication channels
are integrated.  Again: If integration (with the MLs) would work at the ASF,
I'd be fine: My issue is with shutting ML-people out.]

Best regards,
Gilles

>>> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Tomasz Urbaszek <tu...@apache.org>]

I'm reading this discussion from the beginning (thanks to ML). I can be
mistaken but there are two issues:

1. A community communication channel. A place where users can interact,
discuss and seek help. This should be a place for users and the community
should use whatever serves best.
2. Decision making channel. In this case we seek for an ability to archive
and search (dev@ mailing list) but we also seek engagement from wider
community (not offered by dev@ list).

In case of 1 we have poor chance to unify things (for example Slack vs
WeChat). In case of 2 we can take advantage of the fact that every project
now is on Github. For example what Apache Superset is doing looks
impressive: https://github.com/apache/superset/projects/7 They still do the
voting on mailing list
https://lists.apache.org/thread/t2yc69rm60o7mlrp114r9rmdm96k7cwg but we may
consider using some bots for handling this integration (possibly in both
directions).

Issues and discussions can be deleted. In this case we can consider using
pull requests that support the same (or at least similar) threading
functionality as issues/discussions. We have nice tool for tracking
changes, reviewing and suggesting. This is more similar to what Kubernetes
is doing for theirs "enchantment proposals":
https://github.com/kubernetes/enhancements/pull/1353.

This is just idea but Github is common to every project. It's something we
all have, so why not start there?
In fact maybe we can take some lessons from "newer" communities like CNCF
projects that are no longer ML centric?

Bests,
Tomek

On Mon, 28 Feb 2022 at 20:20, Jarek Potiuk <ja...@potiuk.com> wrote:

> >
> >
> > Will someone be granted commit access, and become PMC
> > member without providing an email address?
> >
>
> Why not if the mailing list is not mandatory? But I think it's not a matter
> of
> "having" a mailing address. It's more about subscribing and actively
> discussing
> using the devlist. Those two are completely different and not
> really related IMHO.
>
>
> > Not everyone interested in the development of FLOSS is willing
> > (or having the time) to become a community manager in every
> > new channel that pops up.
> >
>
> But there is no such need. It's enough that (when the community agrees on
> a channel) - all people from that community will know and use it. And they
> are
> already on this channel (see below).
>
> Should we have to jump through (other) no less arbitrary hoops
> > instead?
> >
>
> By all means yes. If the community decides, some people in the community
> will have to jump through some hoops (possibly). But more often than not
> those will be either very small hoops (the UI, ease of use for many of the
> solutions, lack of friction had greatly improved over the last 20 years)
> or everyone has done it already.
>
> In the case of Airflow (if we talk about switching to Github Discussions)
> what we are talking about is ~ 1900 people having to subscribe to the
> devlist and learn to use it vs. exactly 0 (!) people having to subscribe to
> the
> GH issues/discussions and learning to use it (we all already do it daily
> anyway - it is just not "blessed" as the "official channel").
>
> Looks like no brainer.
>
>
> > Regards,
> > Gilles
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
> >
>

Re: Thoughts on alternative communication channels for our communities

[Jarek Potiuk <ja...@potiuk.com>]

>
>
> Will someone be granted commit access, and become PMC
> member without providing an email address?
>

Why not if the mailing list is not mandatory? But I think it's not a matter
of
"having" a mailing address. It's more about subscribing and actively
discussing
using the devlist. Those two are completely different and not
really related IMHO.


> Not everyone interested in the development of FLOSS is willing
> (or having the time) to become a community manager in every
> new channel that pops up.
>

But there is no such need. It's enough that (when the community agrees on
a channel) - all people from that community will know and use it. And they
are
already on this channel (see below).

Should we have to jump through (other) no less arbitrary hoops
> instead?
>

By all means yes. If the community decides, some people in the community
will have to jump through some hoops (possibly). But more often than not
those will be either very small hoops (the UI, ease of use for many of the
solutions, lack of friction had greatly improved over the last 20 years)
or everyone has done it already.

In the case of Airflow (if we talk about switching to Github Discussions)
what we are talking about is ~ 1900 people having to subscribe to the
devlist and learn to use it vs. exactly 0 (!) people having to subscribe to
the
GH issues/discussions and learning to use it (we all already do it daily
anyway - it is just not "blessed" as the "official channel").

Looks like no brainer.


> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Re: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Le lun. 28 févr. 2022 à 19:09, Rich Bowen <rb...@rcbowen.com> a écrit :
>
>
>
> >> I still fail to understand the reason for looking for alternatives to
> >> MLs for managing ASF projects...
>
> It's less a question of us looking for alternatives, and more a question
> of observing the broader open source community and seeing that the
> younger/newer participants in this space want something different,
> expect something different, and are turned off by the current state of
> things.

Talking with newcomers may be more effective on alternative
channels, but if/when tools are introduced and their purpose
explained, the usage of a ML is not going to be the most
difficult ability to acquire for contributing to an ASF project.

Will someone be granted commit access, and become PMC
member without providing an email address?

> > Honestly -- I don't think we have a choice. At least I don't that we have
> > when it comes to users. Those will engage with us in whatever manner
> > they seem to perceive as most natural and it seems that in 2022 email
> > is definitely not the first thing that comes to the users' mind.
> >
> > So... the choice we have to make is to -- either meet our users where
> > they seem to be looking for us (or at least half-way) OR agree that
> > we will be forever cut off from quite a number of them.
>
> Yes, this is 100% it. I've long said that to reach our audience, you
> have to go where they are, and engage with them there. "Just subscribe
> to the mailing list", while an acceptable answer 10 years ago, is like
> speaking a foreign language today.

Not everyone interested in the development of FLOSS is willing
(or having the time) to become a community manager in every
new channel that pops up.

> The process (email this cryptic address, wait for the cryptic response
> that you get, and follow the instructions in it, and hope for the best,
> then email this *other* address to talk to us) is just too involved,
> unintuitive, and just seems intentionally byzantine, to the people we're
> trying to engage with today. It makes sense to me, because I've been
> doing it for almost 30 years. But we need to listen to our audience,
> because they are no longer interested in jumping through arbitrary hoops
> when they can just go ask on Reddit instead.

Should we have to jump through (other) no less arbitrary hoops
instead?

Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Jarek Potiuk <ja...@potiuk.com>]

Just to clarify "official Apache docs" not "official Airflow docs".

BTW. This is case in the point - > I realized I made a mental mistake and
put "Airflow" in my message where I meant "Apache" and now I have to
correct it this way. In Github Discussion I would just correct it and
no-one would notice.

On Wed, Mar 2, 2022 at 6:39 PM Jarek Potiuk <ja...@potiuk.com> wrote:

>
>>
>>   1. make sure foundation itself provides an MVP for at least two
>>      styles of communication channels ("topic grouped channels"
>>      and "instant messaging channels"). We've got email and perhaps
>>      Matrix could be a good enough answer to the 2nd requirement.
>>
>
> That would be great. My slack relationship is a bit of love-hate and
> especially when recently they enabled it for a month in "full" version
> and then started to annoy us with "do you really want to lose all that
> - do pay" was a bit crossing the line (and we can expect more of it).
> Having a good "modern" replacement "blessed" by the ASF would
> be fantastic. Matrix looks cool and ASF promoting free and distributed
> and modern communication tool for that seems like a great idea.
>
>   2. The best we can do on everything else is simply collect a sort
>>        of FAQ advising our communities on places they should consider
>>        monitoring/engaging so that they "go where [users] are" to your
>> point.
>
> Anything else I am missing?
>>
>>
> I thought a bit about this and I think I realized something.
>
> I think what I miss is something in-between those two emails/async-
> at least for some of the communities and for some parts (see below)
>
>  I think email is great to do really "official" communication and
> particularly
> information that relates to the community. Everything that is related to
> the community -
> is all fine to be discussed on the mailing list (establishing processes and
> communication rules, deciding on project policies etc).
> And if we treat it this way, this is good and I never saw any problem
> with it.
>
> But I think other media (particularly GitHub Discussions and GitHub
> Issues) **might** be better for some communities to make even
> important decisions about the *code* not about the community.
>
> I think we are really at the place where many of the projects require
> anywayw GitHub account, otherwise you can neither discuss nor change
> anything related to the code. And I think we should embrace the fact
> that GitHub tools are simply better suited to discuss any code related
> stuff and even make decisions there. This already happens for small
> things (basically in every PR) and this is extremely blurry when the
> decision is big-enough to bring it to the devlist. The motto "if it did
> not happen on the devlist - did not happen" is not even mentioned
> anywhere in the official Airflow docs (or I could not find it) but we
> keep on hearing (and I was myself saying that multiple times).
> If somebody asks me now about a new feature or "Concept" change
> in the code - I have no way currently to explain when the feature
> is "big enough" to be discussed on the devlist or whether it is
> enough to get it approved in PR or issue.
>
> "Community over code" is actually there in Airflow official docs and main
> motto.
>
> Maybe we should simply (as the official approach of the ASF
> make it a totally viable possibility for the projects to use those:
>
> * when you discuss about community and the way it works "if it did not
> happen
> on the devlist - it did not happen"
>
> * but when you discuss code - "if it did not happen on the <choose your
> medium here that fits our criteria> it did not happen".
>
> I think I would be perfectly fine with that. That is maybe not perfectly
> black-
> whilte criteria (code and community discussions have some overlap) but it
> is much "clearer" to me than any other criteria I could apply even now
> to what we do.
>
> WDYT?
>
> J.
>
>

Re: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Le mer. 2 mars 2022 à 18:40, Jarek Potiuk <ja...@potiuk.com> a écrit :
>
> >
> >
> >
> >   1. make sure foundation itself provides an MVP for at least two
> >      styles of communication channels ("topic grouped channels"
> >      and "instant messaging channels"). We've got email and perhaps
> >      Matrix could be a good enough answer to the 2nd requirement.
> >
>
> That would be great. My slack relationship is a bit of love-hate and
> especially when recently they enabled it for a month in "full" version
> and then started to annoy us with "do you really want to lose all that
> - do pay" was a bit crossing the line (and we can expect more of it).

What did you expect, indeed?
How long until GH will go that path?

> Having a good "modern" replacement "blessed" by the ASF would
> be fantastic. Matrix looks cool and ASF promoting free and distributed
> and modern communication tool for that seems like a great idea.
>
>   2. The best we can do on everything else is simply collect a sort
> >        of FAQ advising our communities on places they should consider
> >        monitoring/engaging so that they "go where [users] are" to your
> > point.
>
> Anything else I am missing?
> >
> >
> I thought a bit about this and I think I realized something.
>
> I think what I miss is something in-between those two emails/async-
> at least for some of the communities and for some parts (see below)
>
>  I think email is great to do really "official" communication and
> particularly
> information that relates to the community. Everything that is related to
> the community -
> is all fine to be discussed on the mailing list (establishing processes and
> communication rules, deciding on project policies etc).
> And if we treat it this way, this is good and I never saw any problem
> with it.

Great. :-)

> But I think other media (particularly GitHub Discussions and GitHub
> Issues) **might** be better for some communities to make even
> important decisions about the *code* not about the community.

:-(
See below.

>
> I think we are really at the place where many of the projects require
> anywayw GitHub account, otherwise you can neither discuss nor change
> anything related to the code. And I think we should embrace the fact
> that GitHub tools are simply better suited to discuss any code related
> stuff and even make decisions there. This already happens for small
> things (basically in every PR) and this is extremely blurry when the
> decision is big-enough to bring it to the devlist. The motto "if it did
> not happen on the devlist - did not happen" is not even mentioned
> anywhere in the official Airflow docs (or I could not find it) but we
> keep on hearing (and I was myself saying that multiple times).
> If somebody asks me now about a new feature or "Concept" change
> in the code - I have no way currently to explain when the feature
> is "big enough" to be discussed on the devlist or whether it is
> enough to get it approved in PR or issue.
>
> "Community over code" is actually there in Airflow official docs and main
> motto.

Although the motto is meant (I assume) to highlight the importance
of having a community (of individuals) for the long-term survival of a
programming project, use of "over" is misleading as it can actually be
used for dividing a community (rather than try and reach consensus).
[A better (IMHO) one would be "Community around code".]

>
> Maybe we should simply (as the official approach of the ASF
> make it a totally viable possibility for the projects to use those:
>
> * when you discuss about community and the way it works "if it did not
> happen
> on the devlist - it did not happen"
>
> * but when you discuss code - "if it did not happen on the <choose your
> medium here that fits our criteria> it did not happen".

That should just be the reverse:
 * community -> whatever tool is in fashion (for some part of the community)
 * code -> ML

Indeed, this is what happens already for a long time; taking an
ASF conference as an example. Some people can attend, and
some cannot; yet the former group is not allowed to come back
to the official forum (ML) claiming that they decided <something>
during their meeting at the conference.

>
> I think I would be perfectly fine with that.

Thus establishing GH preeminence, forcing every ASF contributor
to be a GH client and being entirely dependent on it.
Not a thing I look forward to.

Regards,
Gilles

> That is maybe not perfectly
> black-
> whilte criteria (code and community discussions have some overlap) but it
> is much "clearer" to me than any other criteria I could apply even now
> to what we do.
>
> WDYT?
>
> J.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Jarek Potiuk <ja...@potiuk.com>]

>
>
>
>   1. make sure foundation itself provides an MVP for at least two
>      styles of communication channels ("topic grouped channels"
>      and "instant messaging channels"). We've got email and perhaps
>      Matrix could be a good enough answer to the 2nd requirement.
>

That would be great. My slack relationship is a bit of love-hate and
especially when recently they enabled it for a month in "full" version
and then started to annoy us with "do you really want to lose all that
- do pay" was a bit crossing the line (and we can expect more of it).
Having a good "modern" replacement "blessed" by the ASF would
be fantastic. Matrix looks cool and ASF promoting free and distributed
and modern communication tool for that seems like a great idea.

  2. The best we can do on everything else is simply collect a sort
>        of FAQ advising our communities on places they should consider
>        monitoring/engaging so that they "go where [users] are" to your
> point.

Anything else I am missing?
>
>
I thought a bit about this and I think I realized something.

I think what I miss is something in-between those two emails/async-
at least for some of the communities and for some parts (see below)

 I think email is great to do really "official" communication and
particularly
information that relates to the community. Everything that is related to
the community -
is all fine to be discussed on the mailing list (establishing processes and
communication rules, deciding on project policies etc).
And if we treat it this way, this is good and I never saw any problem
with it.

But I think other media (particularly GitHub Discussions and GitHub
Issues) **might** be better for some communities to make even
important decisions about the *code* not about the community.

I think we are really at the place where many of the projects require
anywayw GitHub account, otherwise you can neither discuss nor change
anything related to the code. And I think we should embrace the fact
that GitHub tools are simply better suited to discuss any code related
stuff and even make decisions there. This already happens for small
things (basically in every PR) and this is extremely blurry when the
decision is big-enough to bring it to the devlist. The motto "if it did
not happen on the devlist - did not happen" is not even mentioned
anywhere in the official Airflow docs (or I could not find it) but we
keep on hearing (and I was myself saying that multiple times).
If somebody asks me now about a new feature or "Concept" change
in the code - I have no way currently to explain when the feature
is "big enough" to be discussed on the devlist or whether it is
enough to get it approved in PR or issue.

"Community over code" is actually there in Airflow official docs and main
motto.

Maybe we should simply (as the official approach of the ASF
make it a totally viable possibility for the projects to use those:

* when you discuss about community and the way it works "if it did not
happen
on the devlist - it did not happen"

* but when you discuss code - "if it did not happen on the <choose your
medium here that fits our criteria> it did not happen".

I think I would be perfectly fine with that. That is maybe not perfectly
black-
whilte criteria (code and community discussions have some overlap) but it
is much "clearer" to me than any other criteria I could apply even now
to what we do.

WDYT?

J.

Re: Thoughts on alternative communication channels for our communities

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Mon, Feb 28, 2022 at 7:09 PM Rich Bowen <rb...@rcbowen.com> wrote:

>
>
> >> I still fail to understand the reason for looking for alternatives to
> >> MLs for managing ASF projects...
>
> It's less a question of us looking for alternatives, and more a question
> of observing the broader open source community and seeing that the
> younger/newer participants in this space want something different,
> expect something different, and are turned off by the current state of
> things.
>
> > Honestly -- I don't think we have a choice. At least I don't that we have
> > when it comes to users. Those will engage with us in whatever manner
> > they seem to perceive as most natural and it seems that in 2022 email
> > is definitely not the first thing that comes to the users' mind.
> >
> > So... the choice we have to make is to -- either meet our users where
> > they seem to be looking for us (or at least half-way) OR agree that
> > we will be forever cut off from quite a number of them.
>
> Yes, this is 100% it. I've long said that to reach our audience, you
> have to go where they are, and engage with them there. "Just subscribe
> to the mailing list", while an acceptable answer 10 years ago, is like
> speaking a foreign language today.
>

+1000! Which brings me to: I guess the outcomes of this thread I see
seem to be:
  1. make sure foundation itself provides an MVP for at least two
     styles of communication channels ("topic grouped channels"
     and "instant messaging channels"). We've got email and perhaps
     Matrix could be a good enough answer to the 2nd requirement.

  2. The best we can do on everything else is simply collect a sort
       of FAQ advising our communities on places they should consider
       monitoring/engaging so that they "go where [users] are" to your
point.

Anything else I am missing?

Thanks,
Roman.



> The process (email this cryptic address, wait for the cryptic response
> that you get, and follow the instructions in it, and hope for the best,
> then email this *other* address to talk to us) is just too involved,
> unintuitive, and just seems intentionally byzantine, to the people we're
> trying to engage with today. It makes sense to me, because I've been
> doing it for almost 30 years. But we need to listen to our audience,
> because they are no longer interested in jumping through arbitrary hoops
> when they can just go ask on Reddit instead.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Re: Thoughts on alternative communication channels for our communities

[Rich Bowen <rb...@rcbowen.com>]

>> I still fail to understand the reason for looking for alternatives to
>> MLs for managing ASF projects...

It's less a question of us looking for alternatives, and more a question 
of observing the broader open source community and seeing that the 
younger/newer participants in this space want something different, 
expect something different, and are turned off by the current state of 
things.

> Honestly -- I don't think we have a choice. At least I don't that we have
> when it comes to users. Those will engage with us in whatever manner
> they seem to perceive as most natural and it seems that in 2022 email
> is definitely not the first thing that comes to the users' mind.
> 
> So... the choice we have to make is to -- either meet our users where
> they seem to be looking for us (or at least half-way) OR agree that
> we will be forever cut off from quite a number of them.

Yes, this is 100% it. I've long said that to reach our audience, you 
have to go where they are, and engage with them there. "Just subscribe 
to the mailing list", while an acceptable answer 10 years ago, is like 
speaking a foreign language today.

The process (email this cryptic address, wait for the cryptic response 
that you get, and follow the instructions in it, and hope for the best, 
then email this *other* address to talk to us) is just too involved, 
unintuitive, and just seems intentionally byzantine, to the people we're 
trying to engage with today. It makes sense to me, because I've been 
doing it for almost 30 years. But we need to listen to our audience, 
because they are no longer interested in jumping through arbitrary hoops 
when they can just go ask on Reddit instead.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Feb 27, 2022 at 10:55 PM Gilles Sadowski <gi...@gmail.com>
wrote:

> Le dim. 27 févr. 2022 à 21:13, Jarek Potiuk <ja...@potiuk.com> a écrit :
> >
> > >
> > >
> > > Do any of the mentioned alternatives fulfill those requirements?
> > >
> >
> > I think most - with very little investment on taking backup (same as we
> do
> > with ponymail today).
>
> It rather seems to me that tools targeted to synchronous
> communication are quite bad for asynchronous usage.
>
> >
> > Two examples:
> >
> > * http://apache-airflow.slack-archives.org/ Apache Airflow public slack.
> > searchable and owned by us: Developed by one of our PMC members in his
> free
> > time. Solves "public", "owned", "searchable". With little effort can be
> > made offline-usable (it's a simple web app that loads the backup of slack
> > messages), It even looks nice. The only thing it lacks currently is
> support
> > for thread display.
> > * For Github discussion as I mentioned before it's just making sure you
> > subscribe to emails (same as current Ponymail backup).
>
> Assuming that I'm only subscribed to some project's "dev@" ML, how
> can I interact with either of those solutions?
>

You can't really. But at least the ML gets all the traffic (so it is
solving 1/2 of the problem).


>
> > I think it's not a matter of "limitation" of certain media, bit more a
> > question of a little "investment" into some popular solutions to make
> them
> > fulfill the requirements we have and a way that INFRA provides
> instructions
> > and possible some little infrastructure and possibly "verification" for
> > those popular media used by different PMC. Same as currently providing
> > support for Ponymail (which is essentially a 3rd-party tool as well),
> > It is more effort to support more solutions - yes, but INFRA can also tap
> > into support of the PMCs that want to use different tools to help with
> > making the effort to make it "blessed".
>
> I still fail to understand the reason for looking for alternatives to
> MLs for managing ASF projects...
>

Honestly -- I don't think we have a choice. At least I don't that we have
when it comes to users. Those will engage with us in whatever manner
they seem to perceive as most natural and it seems that in 2022 email
is definitely not the first thing that comes to the users' mind.

So... the choice we have to make is to -- either meet our users where
they seem to be looking for us (or at least half-way) OR agree that
we will be forever cut off from quite a number of them.

Thanks,
Roman.

Re: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Le dim. 27 févr. 2022 à 21:13, Jarek Potiuk <ja...@potiuk.com> a écrit :
>
> >
> >
> > Do any of the mentioned alternatives fulfill those requirements?
> >
>
> I think most - with very little investment on taking backup (same as we do
> with ponymail today).

It rather seems to me that tools targeted to synchronous
communication are quite bad for asynchronous usage.

>
> Two examples:
>
> * http://apache-airflow.slack-archives.org/ Apache Airflow public slack.
> searchable and owned by us: Developed by one of our PMC members in his free
> time. Solves "public", "owned", "searchable". With little effort can be
> made offline-usable (it's a simple web app that loads the backup of slack
> messages), It even looks nice. The only thing it lacks currently is support
> for thread display.
> * For Github discussion as I mentioned before it's just making sure you
> subscribe to emails (same as current Ponymail backup).

Assuming that I'm only subscribed to some project's "dev@" ML, how
can I interact with either of those solutions?

> I think it's not a matter of "limitation" of certain media, bit more a
> question of a little "investment" into some popular solutions to make them
> fulfill the requirements we have and a way that INFRA provides instructions
> and possible some little infrastructure and possibly "verification" for
> those popular media used by different PMC. Same as currently providing
> support for Ponymail (which is essentially a 3rd-party tool as well),
> It is more effort to support more solutions - yes, but INFRA can also tap
> into support of the PMCs that want to use different tools to help with
> making the effort to make it "blessed".

I still fail to understand the reason for looking for alternatives to
MLs for managing ASF projects...

Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Jarek Potiuk <ja...@potiuk.com>]

>
>
> Do any of the mentioned alternatives fulfill those requirements?
>

I think most - with very little investment on taking backup (same as we do
with ponymail today).

Two examples:

* http://apache-airflow.slack-archives.org/ Apache Airflow public slack.
searchable and owned by us: Developed by one of our PMC members in his free
time. Solves "public", "owned", "searchable". With little effort can be
made offline-usable (it's a simple web app that loads the backup of slack
messages), It even looks nice. The only thing it lacks currently is support
for thread display.
* For Github discussion as I mentioned before it's just making sure you
subscribe to emails (same as current Ponymail backup).

I think it's not a matter of "limitation" of certain media, bit more a
question of a little "investment" into some popular solutions to make them
fulfill the requirements we have and a way that INFRA provides instructions
and possible some little infrastructure and possibly "verification" for
those popular media used by different PMC. Same as currently providing
support for Ponymail (which is essentially a 3rd-party tool as well),

It is more effort to support more solutions - yes, but INFRA can also tap
into support of the PMCs that want to use different tools to help with
making the effort to make it "blessed".

J.

Re: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Le jeu. 17 févr. 2022 à 17:58, Matt Sicker <bo...@gmail.com> a écrit :
>
> [...] 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.

Does that exist today?
What happens in the "Commons" project, is that an email generated
in the GitHub eco-system is sent from e.g. "issues@": If a "reply", it
will be sent back to that ML, not GH (IIUC)...

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

Do any of the mentioned alternatives fulfill those requirements?
Many people listed the concrete (objective) advantages of the
(so-called "old") ML technology over other ways of communication
"back then" (snail mail, phone calls, etc.).
Several aspects of the new/fashionable tools blatantly contradict
one or more of the above requirements.
And none match them all for the intended purpose.
Or did I miss something?

Regards,
Gilles

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

Re: Re: Thoughts on alternative communication channels for our communities

[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

[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

[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

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

回复：Re: Thoughts on alternative communication channels for our communities

[Liu Ted <te...@yahoo.com.INVALID>]

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: Thoughts on alternative communication channels for our communities

[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: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

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

Re: Thoughts on alternative communication channels for our communities

[Mark Thomas <ma...@apache.org>]

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/



On 16/02/2022 16:15, Jarek Potiuk wrote:
> 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 <gi...@gmail.com>
> wrote:
> 
>> Le mer. 16 févr. 2022 à 14:16, Gary Gregory <ga...@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 <tr...@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 <ga...@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 <rv...@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-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: Thoughts on alternative communication channels for our communities

[Jarek Potiuk <ja...@potiuk.com>]

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 <gi...@gmail.com>
wrote:

> Le mer. 16 févr. 2022 à 14:16, Gary Gregory <ga...@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 <tr...@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 <ga...@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 <rv...@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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Re: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Le mer. 16 févr. 2022 à 14:16, Gary Gregory <ga...@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 <tr...@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 <ga...@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 <rv...@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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Gary Gregory <ga...@gmail.com>]

My assumption using Slack is that it is a convenience but that decisions
MUST be reflected on a mailing list.

Gary

On Wed, Feb 16, 2022, 08:13 Trevor Grant <tr...@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 <ga...@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 <rv...@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.
> > >
> >
>

Re: Thoughts on alternative communication channels for our communities

[Trevor Grant <tr...@gmail.com>]

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 <ga...@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 <rv...@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.
> >
>

Re: Thoughts on alternative communication channels for our communities

[Gary Gregory <ga...@gmail.com>]

Slack chat and video helped us tremendously on the Log4j team especially
since Log4Shell.

Gary

On Wed, Feb 16, 2022, 07:50 Roman Shaposhnik <rv...@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.
>

Re: Thoughts on alternative communication channels for our communities

[Phil Steitz <ph...@gmail.com>]

Really thoughtful and insightful message, Rich.  I agree with your main 
point and see kind of the same thing in the mirror.  That said, I agree 
with the requirements that Mark Thomas has posted several times (which 
thankfully, are easily found in the list archives :). I have one comment 
on diversity inline below.

On 2/22/22 8:41 AM, Rich Bowen wrote:
> I've been thinking about this topic for the last few months, and have 
> become more and more convinced that it's more than *just* a 
> generational issue. It's also an inclusion issue.
>
> I recently wrote the following in an email to a colleague:
>
> <QUOTE>
> I have long had very strong opinions about the *right* way to have 
> conversations in open source communities - it's via email, because it 
> gives you a permanent record, gives people not in your time zone time 
> to respond without urgency, and includes people from different 
> languages/cultures because it doesn't require immediate response.
>
> Ten years ago, if you asked a project "where do I talk to you" the 
> answer was "here's our mailing list, and our IRC channel
>
> Now, you hear more Slack, "in the Github issues", Matrix, and so on.
>
> I have done two interviews (ie, podcast interviews) now in which we've 
> talked about this issue, and the person agreed with my perspective, 
> that there is a *right* answer, and kids these days don't get it, and 
> will understand when they're older.
>
> In both cases, the person was a white man of a certain age. 
> Ironically, both of them were named Greg.
>
> I am slowly coming around to the perspective that this is not only a 
> generational thing (email, and IRC especially, are old-people-tech) 
> but may also be more about diversity than I understand. Very 
> consistently, at least at Red Hat, the white men over 30 agree with my 
> perspective and EVERYONE ELSE thinks that more synchronous discussion 
> venues are preferable.

There is a diversity issue here that we don't usually recognize as 
such.  Some of us are not generally available during any kind of 
predictable working hours.  Pushing essential communication and 
interaction into synchronous venues excludes us.

Phil
>
> At the same time, I strongly believe that I am *right*, because having 
> a searchable permanent archive is just so valuable for communities.
>
> But, at the same time, I recognize that this is canonical "Tyranny Of 
> The Dead"[1] problem, and means that the decision that [Community 
> Leader] sent to the mailing list in 2002 is The Answer Which May Not 
> Be Challenged. The fact that I, also, think that it's right just means 
> (maybe?) that I'm part of the problem.
> </QUOTE>
>
> I feel like this issue is a larger question for the entire open source 
> ecosystem.
>
> --Rich
>
> [1] https://www.amazon.com/dp/B001QREWQ4 - The Tyranny Of The Dead is 
> the notion that most important decisions in the world have already 
> been made, by dead white men, and we are not "allowed" to challenge 
> them. (Yes, that is a gross oversimplification.)
>
>
>
> On 2/16/22 07:50, Roman Shaposhnik 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-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: Thoughts on alternative communication channels for our communities

[Peter Kovacs <pe...@apache.org>]

Am 23.02.22 um 13:37 schrieb Jim Jagielski:
>
>> On Feb 23, 2022, at 1:32 AM, Peter Kovacs <pe...@Apache.org> wrote:
>>
>> Imho the kids from today communicate more asynchroneus then the generation is 30+ is used to. (General speaking, not just the Open Source Group activist point of view)
> I'd be curious about how you think that... The generation 30+ *had* to communicate async: they wrote letters, long-distance phone calls were outrageously expensive (we else recalls waiting until the late evening to call a friend in another state because that was when the rates were cheaper?), etc...

It is not about the availability. It is about frequency and preference.

If you have the choice between talking or using messaging. What is your 
Preference? Mine is talking, even if I message to much.

I say young people decide using messaging over a direct talk at default.

A friend of mine is teacher, he complained once that his pupils don't 
even use a dialog form. They just inform themself with log status 
messages. Thanks to their helicopter parents (I hope you understand what 
I mean).

Phillip: "I am at the scoolbus at 3"

Veronique: "I have the crackers."

Phillip: "I have the orange juice."


Maybe this is just Gossip. But I have asked a friend of mine why she 
record a message after message with her best friend that was on the same 
event.

She said that both can listen to the conversation when their times allow 
it and the can focus on on other things. I hope you get the Idea.

>   
>
> I still state that a preference for synch communications screams privilege and exclusivity.
I do not say that you are wrong. ;)
>
> Cheers!
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Jim Jagielski <ji...@jaguNET.com>]

> On Feb 23, 2022, at 1:32 AM, Peter Kovacs <pe...@Apache.org> wrote:
> 
> Imho the kids from today communicate more asynchroneus then the generation is 30+ is used to. (General speaking, not just the Open Source Group activist point of view)

I'd be curious about how you think that... The generation 30+ *had* to communicate async: they wrote letters, long-distance phone calls were outrageously expensive (we else recalls waiting until the late evening to call a friend in another state because that was when the rates were cheaper?), etc...

I still state that a preference for synch communications screams privilege and exclusivity.

Cheers!

Re: Thoughts on alternative communication channels for our communities

[Peter Kovacs <pe...@apache.org>]

Not that I know the discussion. Sorry from throwing in an argument from 
the sideline. ;)

What about look into delta Chat [1]?

It is the try to combine Mail with modern chat approach. Just because 
email has been a good feature it does not mean it can not go with time. 
Just an idea.

Am 22.02.22 um 23:30 schrieb Jim Jagielski:
>
>> On Feb 22, 2022, at 10:41 AM, Rich Bowen <rb...@rcbowen.com> wrote:
>>
>>   Very consistently, at least at Red Hat, the white men over 30 agree with my perspective and EVERYONE ELSE thinks that more synchronous discussion venues are preferable.
Imho the kids from today communicate more asynchroneus then the 
generation is 30+ is used to. (General speaking, not just the Open 
Source Group activist point of view)
>>
> Maybe because the current generation never needed to worry about the effects of synchronous communication over geographical diverse ares, because most/many/"all" of the people they collaborate with are in very similar time zones. Or maybe its because they are always online.
>
> Let's recall that IRC was a thing the same time that Email was. Heck, back then we had IRC, email and NNTP, so it's not like we lacked for communication alternatives. Email didn't "win" because it was all we had, but because it was the best suited for the requirements we based things around: ease of archival, ease of threading, and async friendly. I'll be honest, if NNTP was not such a pain to install and maintain, I bet that would have given Email a run for its money.
>
> IMO, baselining a primary communication system that requires either everyone be in the same timezone, approximately, or that everyone be online at all hours, screams privilege to me. There are huge sets of populations that don't enjoy the luxury of having high-bandwidth smart devices with them 24x7 in order to engage w/ open source projects. Basically, by doing so, you self-select an extremely privileged group and disenfranchise the other 90-95%.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
[1] https://delta.chat/en/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Rich Bowen <rb...@rcbowen.com>]

On 2/22/22 17:30, Jim Jagielski wrote:
> 
> 
>> On Feb 22, 2022, at 10:41 AM, Rich Bowen <rb...@rcbowen.com> wrote:
>>
>>   Very consistently, at least at Red Hat, the white men over 30 agree with my perspective and EVERYONE ELSE thinks that more synchronous discussion venues are preferable.
>>
> 
> Maybe because the current generation never needed to worry about the effects of synchronous communication over geographical diverse ares, because most/many/"all" of the people they collaborate with are in very similar time zones. Or maybe its because they are always online.
> 
> Let's recall that IRC was a thing the same time that Email was. Heck, back then we had IRC, email and NNTP, so it's not like we lacked for communication alternatives. Email didn't "win" because it was all we had, but because it was the best suited for the requirements we based things around: ease of archival, ease of threading, and async friendly. I'll be honest, if NNTP was not such a pain to install and maintain, I bet that would have given Email a run for its money.
> 
> IMO, baselining a primary communication system that requires either everyone be in the same timezone, approximately, or that everyone be online at all hours, screams privilege to me. There are huge sets of populations that don't enjoy the luxury of having high-bandwidth smart devices with them 24x7 in order to engage w/ open source projects. Basically, by doing so, you self-select an extremely privileged group and disenfranchise the other 90-95%.

Yes, I think that this is correct. And not only does it disenfranchise 
those outside of the timezone, it also deprives oneself of their company 
- ie, it makes *everyone* poorer, and creates an echo chamber.

I think it also leads to a lot of 
reinventing/renegotiating/relegislating, because there's no record to go 
back to. That, coupled with a desire to always be on the newest, 
shiniest thing, leads to a lot of wasted, duplicated effort.

But, of course, when I was younger I also thought I didn't need to defer 
to the wisdom of experience, so maybe this really is just a generational 
thing, which each generation needs to learn over. I honestly don't know. 
It just seems like a valuable thing to investigate.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Jim Jagielski <ji...@jaguNET.com>]

> On Feb 22, 2022, at 10:41 AM, Rich Bowen <rb...@rcbowen.com> wrote:
> 
>  Very consistently, at least at Red Hat, the white men over 30 agree with my perspective and EVERYONE ELSE thinks that more synchronous discussion venues are preferable.
> 

Maybe because the current generation never needed to worry about the effects of synchronous communication over geographical diverse ares, because most/many/"all" of the people they collaborate with are in very similar time zones. Or maybe its because they are always online.

Let's recall that IRC was a thing the same time that Email was. Heck, back then we had IRC, email and NNTP, so it's not like we lacked for communication alternatives. Email didn't "win" because it was all we had, but because it was the best suited for the requirements we based things around: ease of archival, ease of threading, and async friendly. I'll be honest, if NNTP was not such a pain to install and maintain, I bet that would have given Email a run for its money.

IMO, baselining a primary communication system that requires either everyone be in the same timezone, approximately, or that everyone be online at all hours, screams privilege to me. There are huge sets of populations that don't enjoy the luxury of having high-bandwidth smart devices with them 24x7 in order to engage w/ open source projects. Basically, by doing so, you self-select an extremely privileged group and disenfranchise the other 90-95%.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org

Re: Thoughts on alternative communication channels for our communities

[Rich Bowen <rb...@rcbowen.com>]

I've been thinking about this topic for the last few months, and have 
become more and more convinced that it's more than *just* a generational 
issue. It's also an inclusion issue.

I recently wrote the following in an email to a colleague:

<QUOTE>
I have long had very strong opinions about the *right* way to have 
conversations in open source communities - it's via email, because it 
gives you a permanent record, gives people not in your time zone time to 
respond without urgency, and includes people from different 
languages/cultures because it doesn't require immediate response.

Ten years ago, if you asked a project "where do I talk to you" the 
answer was "here's our mailing list, and our IRC channel is on Freenode 
for more immediate support needs."

Now, you hear more Slack, "in the Github issues", Matrix, and so on.

I have done two interviews (ie, podcast interviews) now in which we've 
talked about this issue, and the person agreed with my perspective, that 
there is a *right* answer, and kids these days don't get it, and will 
understand when they're older.

In both cases, the person was a white man of a certain age. Ironically, 
both of them were named Greg.

I am slowly coming around to the perspective that this is not only a 
generational thing (email, and IRC especially, are old-people-tech) but 
may also be more about diversity than I understand. Very consistently, 
at least at Red Hat, the white men over 30 agree with my perspective and 
EVERYONE ELSE thinks that more synchronous discussion venues are preferable.

At the same time, I strongly believe that I am *right*, because having a 
searchable permanent archive is just so valuable for communities.

But, at the same time, I recognize that this is canonical "Tyranny Of 
The Dead"[1] problem, and means that the decision that [Community 
Leader] sent to the mailing list in 2002 is The Answer Which May Not Be 
Challenged. The fact that I, also, think that it's right just means 
(maybe?) that I'm part of the problem.
</QUOTE>

I feel like this issue is a larger question for the entire open source 
ecosystem.

--Rich

[1] https://www.amazon.com/dp/B001QREWQ4 - The Tyranny Of The Dead is 
the notion that most important decisions in the world have already been 
made, by dead white men, and we are not "allowed" to challenge them. 
(Yes, that is a gross oversimplification.)



On 2/16/22 07:50, Roman Shaposhnik 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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org