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é <[email protected]> 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 <[email protected]> > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
