Re: Using chat/instant messaging responsibly in Incubation

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Justin,

Thank you for sending this message; it is very helpful.

I agree that this emphasis on mailing list communication is important,
especially as a podling prepares to graduate and maintain the same
communication approach as a TLP.

Regarding your questions:

1. I believe chat is the primary channel for seeking help and asking
questions. It is a great help in building the user community, but less so
for the developer community.
2. I agree that it is often difficult to follow all discussions happening
on chat when you are offline, which can create transparency risks.
3. I recall some projects attempting to "digest" Slack activity, but I'm
not sure how much it helped. However, this is definitely an area to explore
as chat is arguably the preferred communication channel today.

Regards,
JB


On Sun, Nov 30, 2025 at 3:10 AM Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> We already have guidance on communication expectations. [1][2] Mailing
> lists are the primary space for project decisions, voting, and long-term
> record keeping. Instant messages in Slack or other platforms can be useful
> for coordination and faster conversation, but they must support the lists,
> not replace them. Anything that affects technical direction or governance
> needs to be summarised back to dev@, so the whole community can
> participate and audit the outcome. Note, this topic has recently come up on
> the board list.
>
> I thought we could look at how and indeed if podlings apply this in
> practice.
>
> Questions to explore
> - Where has chat helped with newcomer support, rapid problem-solving, or
> community building?
> - Where has it created transparency risks, exclusion across time zones, or
> fragmentation of discussion?
> - What are good patterns for summarising chat back to dev@ so decisions
> remain public, archived, global, and accessible?
> - How do podlings ensure tools do not disadvantage people with limited
> bandwidth, blocked services, or lower English fluency?
>
> Kind Regards,
> Justin
>
> 1.
> https://cwiki.apache.org/confluence/display/INCUBATOR/Communication+in+Apache+Projects
> 2.
> https://cwiki.apache.org/confluence/display/INCUBATOR/International+and+Cultural+Awareness
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: Using chat/instant messaging responsibly in Incubation

[Julian Hyde <jh...@gmail.com>]

If a project uses a particular communication tool, I would be happy if that tool produces a read-only archive, accessible on the Apache site without password. 

(Write access to the tool is nice but is not strictly necessary. I don’t want to set the bar so high that the only tool that complies is “email in English”. It’s not 1995, and only graybeards are happy with email.)

If the tool reaches that bar, then Google can implement search, translation and all the rest. 

It is also sufficient for me as a user to know whether it’s worth the effort of installing that tool. Whether the conversations I am interested in are happening in that particular walled garden. 

Julian

> On Dec 9, 2025, at 05:10, Jarek Potiuk <ja...@potiuk.com> wrote:
> 
> * 100% with JBO -> and it is also well reflected in the new page
> https://cwiki.apache.org/confluence/display/INCUBATOR/Using+Emerging+Technology
> - that "properties" matter, not the tool itself.
> 
> One small thing to add though - this can be - unfortunately - easily used
> to simply undermine some options and efforts. There might be some details
> and flaws of some tools that you can always pull out from your pocket to
> say "this tool is bad - because this and this - we can't use it. Full
> stop.". This is following a 0/1 approach and - something that we often see
> in ASF - where you weaponize a single word and build the whole narrative
> around that with arguments "against" rather than constructively propose
> solutions that might work-around some of the issues.
> 
> For example - we use slack now - both for ASF and individual PMC - because
> of convenience, popularity, etc.. But if you literally approach the
> criteria we have, we should not do it even if one person says "I do not
> want to agree to Slack TOS". That one single person - if we approach things
> with 0/1 and a very strict approach of full inclusivity and 100%
> transparency etc. -  might block convenience, usability, community building
> opportunities for the reminder of the community. I think we should
> recognise that there are cases where we - as a community - deliberately
> make the decision where in some cases convenience and community building
> opportunities are more important than the beliefs and needs of single
> individuals. We should not neglect those of course, we should recognize and
> acknowledge those beliefs and needs. And in a number of cases we should
> respond to those and provide workarounds, rules of use of those tools that
> address it.
> 
> For example - we should never exclude those people from decision making,
> This is 100% important.
> But is it important to not use slack for some announcements, organising
> community work around certain areas, where everyone involved in this area
> is "OK" with that tool where productivity and community building gets huge
> gains from using the tools ? I don't think so.
> 
> Sure it can lead to something of a "tyranny of the majority" and people
> might feel suppressed because they are not participating in those areas.
> But I think if the community is clear about it, and when anyone can say "I
> do not want to sign TOS" and the answer of the community "this is the
> option you can use to participate - it's less convenient, you might not
> participate with the same frequency/speed/convenience/whatever - but here
> is the option for you individually and anyone else with the same concerns"
> - this is perfectly fine. Otherwise it might easily turn into "tyranny of
> the minority" - which is equally bad, or sometimes even worse than "tyranny
> of the majority".
> 
> J
> 
>> On Tue, Dec 9, 2025 at 1:35 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> 
>> Hi Justin,
>> 
>> I completely agree with your points. From a community standpoint,
>> regardless of the specific chat or instant messaging tool used, it must be
>> open to everyone and accessible offline or asynchronously. Any
>> requirement—such as a login, specific language, or region lock—that
>> prevents a portion of the community from participating is unacceptable.
>> 
>> My main point is that the tool itself doesn't matter; the features do. In
>> essence, any tool is acceptable as long as it provides the same core
>> features that the mailing lists provide for communication and
>> record-keeping.
>> 
>> Regards,
>> JB
>> 
>> On Sun, Dec 7, 2025 at 10:23 PM Justin Mclean <ju...@classsoftware.com>
>> wrote:
>> 
>>> Hi,
>>> 
>>> These are all interesting points.
>>> 
>>> When it comes to accessibility, I mostly agree that bandwidth and English
>>> fluency are less of a barrier than before. Still, I want to point out one
>>> issue I keep running into: region-locked platforms. For example, some
>>> projects use WeChat for discussions, which I can't access. Even for
>>> globally accessible platforms, I usually have to sign up or create an
>>> account, which means I need to use another client, which is a barrier to
>>> entry.
>>> 
>>> From the Incubator and ASF values perspective, this is one area where we
>>> should make sure that core project discussions always have a globally
>>> accessible home.
>>> 
>>> I’m not arguing against using these platforms for social interaction; I'm
>>> only saying that decisions, direction, and governance-level discussions
>>> must always land somewhere globally reachable and archived.
>>> 
>>> Kind Regards,
>>> Justin
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>> 
>>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Using chat/instant messaging responsibly in Incubation

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

* 100% with JBO -> and it is also well reflected in the new page
https://cwiki.apache.org/confluence/display/INCUBATOR/Using+Emerging+Technology
- that "properties" matter, not the tool itself.

One small thing to add though - this can be - unfortunately - easily used
to simply undermine some options and efforts. There might be some details
and flaws of some tools that you can always pull out from your pocket to
say "this tool is bad - because this and this - we can't use it. Full
stop.". This is following a 0/1 approach and - something that we often see
in ASF - where you weaponize a single word and build the whole narrative
around that with arguments "against" rather than constructively propose
solutions that might work-around some of the issues.

For example - we use slack now - both for ASF and individual PMC - because
of convenience, popularity, etc.. But if you literally approach the
criteria we have, we should not do it even if one person says "I do not
want to agree to Slack TOS". That one single person - if we approach things
with 0/1 and a very strict approach of full inclusivity and 100%
transparency etc. -  might block convenience, usability, community building
opportunities for the reminder of the community. I think we should
recognise that there are cases where we - as a community - deliberately
make the decision where in some cases convenience and community building
opportunities are more important than the beliefs and needs of single
individuals. We should not neglect those of course, we should recognize and
acknowledge those beliefs and needs. And in a number of cases we should
respond to those and provide workarounds, rules of use of those tools that
address it.

For example - we should never exclude those people from decision making,
This is 100% important.
But is it important to not use slack for some announcements, organising
community work around certain areas, where everyone involved in this area
is "OK" with that tool where productivity and community building gets huge
gains from using the tools ? I don't think so.

Sure it can lead to something of a "tyranny of the majority" and people
might feel suppressed because they are not participating in those areas.
But I think if the community is clear about it, and when anyone can say "I
do not want to sign TOS" and the answer of the community "this is the
option you can use to participate - it's less convenient, you might not
participate with the same frequency/speed/convenience/whatever - but here
is the option for you individually and anyone else with the same concerns"
- this is perfectly fine. Otherwise it might easily turn into "tyranny of
the minority" - which is equally bad, or sometimes even worse than "tyranny
of the majority".

J

On Tue, Dec 9, 2025 at 1:35 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Hi Justin,
>
> I completely agree with your points. From a community standpoint,
> regardless of the specific chat or instant messaging tool used, it must be
> open to everyone and accessible offline or asynchronously. Any
> requirement—such as a login, specific language, or region lock—that
> prevents a portion of the community from participating is unacceptable.
>
> My main point is that the tool itself doesn't matter; the features do. In
> essence, any tool is acceptable as long as it provides the same core
> features that the mailing lists provide for communication and
> record-keeping.
>
> Regards,
> JB
>
> On Sun, Dec 7, 2025 at 10:23 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > These are all interesting points.
> >
> > When it comes to accessibility, I mostly agree that bandwidth and English
> > fluency are less of a barrier than before. Still, I want to point out one
> > issue I keep running into: region-locked platforms. For example, some
> > projects use WeChat for discussions, which I can't access. Even for
> > globally accessible platforms, I usually have to sign up or create an
> > account, which means I need to use another client, which is a barrier to
> > entry.
> >
> > From the Incubator and ASF values perspective, this is one area where we
> > should make sure that core project discussions always have a globally
> > accessible home.
> >
> > I’m not arguing against using these platforms for social interaction; I'm
> > only saying that decisions, direction, and governance-level discussions
> > must always land somewhere globally reachable and archived.
> >
> > Kind Regards,
> > Justin
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>

Re: Using chat/instant messaging responsibly in Incubation

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Justin,

I completely agree with your points. From a community standpoint,
regardless of the specific chat or instant messaging tool used, it must be
open to everyone and accessible offline or asynchronously. Any
requirement—such as a login, specific language, or region lock—that
prevents a portion of the community from participating is unacceptable.

My main point is that the tool itself doesn't matter; the features do. In
essence, any tool is acceptable as long as it provides the same core
features that the mailing lists provide for communication and
record-keeping.

Regards,
JB

On Sun, Dec 7, 2025 at 10:23 PM Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> These are all interesting points.
>
> When it comes to accessibility, I mostly agree that bandwidth and English
> fluency are less of a barrier than before. Still, I want to point out one
> issue I keep running into: region-locked platforms. For example, some
> projects use WeChat for discussions, which I can't access. Even for
> globally accessible platforms, I usually have to sign up or create an
> account, which means I need to use another client, which is a barrier to
> entry.
>
> From the Incubator and ASF values perspective, this is one area where we
> should make sure that core project discussions always have a globally
> accessible home.
>
> I’m not arguing against using these platforms for social interaction; I'm
> only saying that decisions, direction, and governance-level discussions
> must always land somewhere globally reachable and archived.
>
> Kind Regards,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: Using chat/instant messaging responsibly in Incubation

[Justin Mclean <ju...@classsoftware.com>]

Hi,

These are all interesting points.

When it comes to accessibility, I mostly agree that bandwidth and English fluency are less of a barrier than before. Still, I want to point out one issue I keep running into: region-locked platforms. For example, some projects use WeChat for discussions, which I can't access. Even for globally accessible platforms, I usually have to sign up or create an account, which means I need to use another client, which is a barrier to entry.

From the Incubator and ASF values perspective, this is one area where we should make sure that core project discussions always have a globally accessible home.

I’m not arguing against using these platforms for social interaction; I'm only saying that decisions, direction, and governance-level discussions must always land somewhere globally reachable and archived.

Kind Regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Using chat/instant messaging responsibly in Incubation

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

Yep. Very good topic.

> - Where has chat helped with newcomer support, rapid problem-solving, or
community building?

100% with JBO.

I also think the issue with mailing lists for newcomers is that it is
(unlike it was in the early days) intimidating and too "official" for many
new contributors - especially the younger generations. It also has an
interesting side effect, I often - literally - use "write it in a ne
devlist thread" - when I see people who effortlessly spam us in "easier to
use" channels with their "fantastic new ideas" (discussed already thousands
of times) and demanding attention while not bringing any values and not
otherwise contributing. I often comment "Ok. This is an important topic -
this has been discussed in THIS MAILING LIST THREAD - please continue
discussion there or open a new thread there". In the vast, vast, vast
majority of cases that is the LAST time we hear from that person. This is
actually a great filter I have for such people - if they actually DO
continue, they are serious and we start paying more attention.  So I also
treat those "easier" channels as a way how we can channel essentially
"spam".  I treat it a bit as a contributor's assesment funnel -> there are
far many people in those conversations and they are far more fragile and
worth archiving outside of the devlist.

Also - there is the other way round - if someone goes to the devlist and
starts asking trivial questions, asking for help etc. we immediately send
them to continue that on slack or GitHub Discussions. This also makes it
clear what caliber of discussions go to the mailing list and what caliber
go to other places. We also made it very clear on Airflow's website with a
community page https://airflow.apache.org/community/ - we not only split
the page into two panes "Want to contribute?" , "Are you a user?" - but we
also did NOT list the different channels, we deliberately guided the
channels to use to be the result of an action you want to make.

I think it is super important (and this should be in the "job description"
of every committer and PMC member) to continuously remind and redirect
people to the right channels if they are using wrong ones. This also serves
as continuous education and re-education - this "job" never ends.

> - Where has it created transparency risks, exclusion across time zones,
or fragmentation of discussion?

I don't think we ever had any serious issues with exclusions - even across
time zones. Our community is very, very distributed (basically our
#internal-airflow-ci-cd is now a follow-the-sun model of support that
whoever is available fixes things that break in our CI in - literally an
hour or so). So that naturally slows down even slack conversations. This is
even less of a problem with Github Discussions which are somewhere
in-between Slack and mailing lists. But also what is important (and again -
that's never-ending job of every single PMC member and committer) - if any
of such discussions goes to a dangerous "this is important" territory, we
relentlessly do "Hey, Let's move that discussion to the devlist" - and the
person doing so will create a thread summarising what has been so far
discussed in Slack. The important part is actually that it DOES happen
regularly. Sometimes I do it deliberately - even if the discussion is on
the border of being "important" - just to show that it is happening and
that others can follow. This is really like a drill on a submarine. You
have to do it from time to time so that new community members know how it
works, and old community members recall that this is what we usually are
doing and do not get too "lazy". I saw that if you repeat it once or twice,
new active contributors are picking it up and start doing it on their own.
I think in this case "do it early, do it often" applies very well.

> - What are good patterns for summarising chat back to dev@ so decisions
remain public, archived, global, and accessible?

As above. Make it absolutely normal, expected and frequent that discussions
are moved to the devlist when they are important. Make sure to summarize
what has been discussed elsewhere - with link to those discussions if
applicable (sometimes you bring private discussions this way with the
permission of other participants - so that it's not always possible - but
you at least mention who you discussed it with and what have you discussed
so far) - make sure this is also an expectations if someone does not do it
- both pinging them in the discussion, or asking for summary if they have
not provided it. Make it just a "norm" that it's happening. And important -
do not treat it as something "wrong". It's perfectly, perfectly fine and
normal that such discussions start in private or non-devlist channels.
Often you just want to get a quick feedback from a few people before you
formulate things in a way that can be discussed in public, or you don't
realise that the discussion is important enough when you start it. Or you
just had a friendly chat with your friend from the project about your
vacations and weather and your discussion naturally slipped into "the code
you were thinking about to write" or else. If you make an impression that
"discussing things outside" is wrong - those discussions might never make
it to the devlist, but it will not make those discussions disappear.
Unfortunately some of the ASF members (especially those who were in the ASF
at the beginning when they were just a group of friends) do not recognize
that it's no longer the case and treat "all discussions outside of the
devlist" as wrong. But I think it's wrong. We are humans, those discussions
happen, there is no way around it. But if you make them welcome and expect
that they will brought to the devlist when they are ripe-enough and you do
not treat it as something "wrong" - this will make those discussion to
actually find their way to devlist IMHO.

> - How do podlings ensure tools do not disadvantage people with limited
bandwidth, blocked services, or lower English fluency?

English fluency is less and less of a problem with AI and translation built
in in most services. Bandwidth is also not that big of an issue (I have not
heard a single complaint about it - but of course it might be survivorship
bias). The blocked services are more of a political thing, that we cannot
do much about, other than helping people with VPNs and such. But this one
is a tough one.



On Mon, Dec 1, 2025 at 2:31 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Hi Justin,
>
> Thank you for sending this message; it is very helpful.
>
> I agree that this emphasis on mailing list communication is important,
> especially as a podling prepares to graduate and maintain the same
> communication approach as a TLP.
>
> Regarding your questions:
>
> 1. I believe chat is the primary channel for seeking help and asking
> questions. It is a great help in building the user community, but less so
> for the developer community.
> 2. I agree that it is often difficult to follow all discussions happening
> on chat when you are offline, which can create transparency risks.
> 3. I recall some projects attempting to "digest" Slack activity, but I'm
> not sure how much it helped. However, this is definitely an area to explore
> as chat is arguably the preferred communication channel today.
>
> Regards,
> JB
>
>
> On Sun, Nov 30, 2025 at 3:10 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > We already have guidance on communication expectations. [1][2] Mailing
> > lists are the primary space for project decisions, voting, and long-term
> > record keeping. Instant messages in Slack or other platforms can be
> useful
> > for coordination and faster conversation, but they must support the
> lists,
> > not replace them. Anything that affects technical direction or governance
> > needs to be summarised back to dev@, so the whole community can
> > participate and audit the outcome. Note, this topic has recently come up
> on
> > the board list.
> >
> > I thought we could look at how and indeed if podlings apply this in
> > practice.
> >
> > Questions to explore
> > - Where has chat helped with newcomer support, rapid problem-solving, or
> > community building?
> > - Where has it created transparency risks, exclusion across time zones,
> or
> > fragmentation of discussion?
> > - What are good patterns for summarising chat back to dev@ so decisions
> > remain public, archived, global, and accessible?
> > - How do podlings ensure tools do not disadvantage people with limited
> > bandwidth, blocked services, or lower English fluency?
> >
> > Kind Regards,
> > Justin
> >
> > 1.
> >
> https://cwiki.apache.org/confluence/display/INCUBATOR/Communication+in+Apache+Projects
> > 2.
> >
> https://cwiki.apache.org/confluence/display/INCUBATOR/International+and+Cultural+Awareness
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>