Re: Thoughts on alternative communication channels for our communities

[Roman Shaposhnik]

On Mon, Feb 21, 2022 at 10:19 AM Zhiyuan Ju  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

[Rich Bowen]

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:


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.



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-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

[jira] [Reopened] (COMDEV-394) GSOC: Varnish Cache support in Apache Traffic Control

[Eric Friedrich (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMDEV-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Friedrich reopened COMDEV-394:
---

reopen to change label

> GSOC: Varnish Cache support in Apache Traffic Control
> -
>
> Key: COMDEV-394
> URL: https://issues.apache.org/jira/browse/COMDEV-394
> Project: Community Development
>  Issue Type: Bug
>  Components: GSoC/Mentoring ideas
>Reporter: Eric Friedrich
>Priority: Major
>  Labels: TrafficControl, full-time, gsoc22, mentor
> Attachments: Screenshot_20210312_000318.png
>
>
> *Background*
> Apache Traffic Control is a Content Delivery Network (CDN) control plane for 
> large scale content distribution.
> Traffic Control currently requires Apache Traffic Server as the underlying 
> cache. Help us expand the scope by integrating with the very popular Varnish 
> Cache.
> There are multiple aspects to this project:
> - Configuration Generation: Write software to build Varnish configuration 
> files (VCL). This code will be implemented in our Traffic Ops and cache 
> client side utilities, both written in Go.
> - Health Monitoring: Implement monitoring of the Varnish cache health and 
> performance. This code will run both in the Traffic Monitor component and 
> within Varnish. Traffic Monitor is written in Go and Varnish is written in C.
> - Testing: Adding automated tests for new code
> *Skills:*
> - Proficiency in Go is required
> - A basic knowledge of HTTP and caching is preferred, but not required for 
> this project.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (COMDEV-394) GSOC: Varnish Cache support in Apache Traffic Control

[Eric Friedrich (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMDEV-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Friedrich updated COMDEV-394:
--
Labels: TrafficControl full-time mentor  (was: TrafficControl full-time 
gsoc22 mentor)

> GSOC: Varnish Cache support in Apache Traffic Control
> -
>
> Key: COMDEV-394
> URL: https://issues.apache.org/jira/browse/COMDEV-394
> Project: Community Development
>  Issue Type: Bug
>  Components: GSoC/Mentoring ideas
>Reporter: Eric Friedrich
>Priority: Major
>  Labels: TrafficControl, full-time, mentor
> Attachments: Screenshot_20210312_000318.png
>
>
> *Background*
> Apache Traffic Control is a Content Delivery Network (CDN) control plane for 
> large scale content distribution.
> Traffic Control currently requires Apache Traffic Server as the underlying 
> cache. Help us expand the scope by integrating with the very popular Varnish 
> Cache.
> There are multiple aspects to this project:
> - Configuration Generation: Write software to build Varnish configuration 
> files (VCL). This code will be implemented in our Traffic Ops and cache 
> client side utilities, both written in Go.
> - Health Monitoring: Implement monitoring of the Varnish cache health and 
> performance. This code will run both in the Traffic Monitor component and 
> within Varnish. Traffic Monitor is written in Go and Varnish is written in C.
> - Testing: Adding automated tests for new code
> *Skills:*
> - Proficiency in Go is required
> - A basic knowledge of HTTP and caching is preferred, but not required for 
> this project.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Closed] (COMDEV-394) GSOC: Varnish Cache support in Apache Traffic Control

[Eric Friedrich (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMDEV-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Friedrich closed COMDEV-394.
-
Resolution: Later

Defer to COMDEV-439

> GSOC: Varnish Cache support in Apache Traffic Control
> -
>
> Key: COMDEV-394
> URL: https://issues.apache.org/jira/browse/COMDEV-394
> Project: Community Development
>  Issue Type: Bug
>  Components: GSoC/Mentoring ideas
>Reporter: Eric Friedrich
>Priority: Major
>  Labels: TrafficControl, full-time, mentor
> Attachments: Screenshot_20210312_000318.png
>
>
> *Background*
> Apache Traffic Control is a Content Delivery Network (CDN) control plane for 
> large scale content distribution.
> Traffic Control currently requires Apache Traffic Server as the underlying 
> cache. Help us expand the scope by integrating with the very popular Varnish 
> Cache.
> There are multiple aspects to this project:
> - Configuration Generation: Write software to build Varnish configuration 
> files (VCL). This code will be implemented in our Traffic Ops and cache 
> client side utilities, both written in Go.
> - Health Monitoring: Implement monitoring of the Varnish cache health and 
> performance. This code will run both in the Traffic Monitor component and 
> within Varnish. Traffic Monitor is written in Go and Varnish is written in C.
> - Testing: Adding automated tests for new code
> *Skills:*
> - Proficiency in Go is required
> - A basic knowledge of HTTP and caching is preferred, but not required for 
> this project.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (COMDEV-439) GSOC: Varnish Cache support in Apache Traffic Control

[Eric Friedrich (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMDEV-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Friedrich updated COMDEV-439:
--
Labels: TrafficControl full-time gsoc2022 mentor  (was: TrafficControl 
full-time gsoc22 mentor)

> GSOC: Varnish Cache support in Apache Traffic Control
> -
>
> Key: COMDEV-439
> URL: https://issues.apache.org/jira/browse/COMDEV-439
> Project: Community Development
>  Issue Type: New Feature
>  Components: GSoC/Mentoring ideas
>Reporter: Eric Friedrich
>Priority: Major
>  Labels: TrafficControl, full-time, gsoc2022, mentor
>
> *Background*
> Apache Traffic Control is a Content Delivery Network (CDN) control plane for 
> large scale content distribution.
> Traffic Control currently requires Apache Traffic Server as the underlying 
> cache. Help us expand the scope by integrating with the very popular Varnish 
> Cache.
> There are multiple aspects to this project:
>  - Configuration Generation: Write software to build Varnish configuration 
> files (VCL). This code will be implemented in our Traffic Ops and cache 
> client side utilities, both written in Go.
>  - Health Monitoring: Implement monitoring of the Varnish cache health and 
> performance. This code will run both in the Traffic Monitor component and 
> within Varnish. Traffic Monitor is written in Go and Varnish is written in C.
>  - Testing: Adding automated tests for new code
> *Skills:*
>  - Proficiency in Go is required
>  - A basic knowledge of HTTP and caching is preferred, but not required for 
> this project.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

Re: Thoughts on alternative communication channels for our communities

[Phil Steitz]

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:


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.



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-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org




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

Re: Thoughts on alternative communication channels for our communities

[Jim Jagielski]

> On Feb 22, 2022, at 10:41 AM, Rich Bowen  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-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Privacy Question - Support

[Melanie Freeman]

Hi [CompanyName} team,

Would you be able to confirm if you sell personal data to third parties? if
so, could you please provide the Do not sell my personal data link?

Thanks heaps!

Best Regards,

Melanie
melaniezfreeman

Re: Privacy Question - Support

[Zhiyuan Ju]

Hi,

I'm not sure what happened here, we don't sell personal data to any
third parties AFAIK.

Best Regards!
@ Zhiyuan Ju 


Melanie Freeman  于2022年2月23日周三 12:48写道：

> Hi [CompanyName} team,
>
> Would you be able to confirm if you sell personal data to third parties? if
> so, could you please provide the Do not sell my personal data link?
>
> Thanks heaps!
>
> Best Regards,
>
> Melanie
> melaniezfreeman
>

Re: Thoughts on alternative communication channels for our communities

[Peter Kovacs]

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  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-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org


[1] https://delta.chat/en/

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