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