Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ucVxz-00Dl9q-NZ for pgsql-www@arkaria.postgresql.org; Thu, 17 Jul 2025 21:16:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ucVxx-005jw2-Mr for pgsql-www@arkaria.postgresql.org; Thu, 17 Jul 2025 21:16:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ucVxx-005jvk-3b for pgsql-www@lists.postgresql.org; Thu, 17 Jul 2025 21:16:34 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ucVxu-007p0p-1Q for pgsql-www@lists.postgresql.org; Thu, 17 Jul 2025 21:16:32 +0000 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-60c93c23b08so2698059a12.3 for ; Thu, 17 Jul 2025 14:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgug.de; s=google; t=1752786988; x=1753391788; darn=lists.postgresql.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=FdyihP4FzBoXOS883zTbbSqZoyENnQroeRLx/m/Letk=; b=Wqz03aBtRWgtN5vYNIaM8lVMClr1GnagL/npEq3b7W0UtIB5uU/JWR3YhXsWFDNiTq QUkyuAcau+3yC9DYYdP+HWRD+xzJCjhU+XgvmZjJV3wrWU5sBLgFyhU0DMi0YP1xktBg Gkuqanw/6am582A+sx+EbfdY6bLI+mMnn+jmw64Ai8T786qCGycuCuGG+SIyaVsx6xse XueiCPWpkgSIVye7qQTdQTrfvc0Q3Hq9++pgcNWilboIOaax2WI/H08Wo8o920xaEM/L OpkugFcV0VUIv8CtEMN10kgWORaZJuCn+JUw61uIh+Y9WZde0LwNa3GR8O+p+bKDDCBO f14A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752786988; x=1753391788; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=FdyihP4FzBoXOS883zTbbSqZoyENnQroeRLx/m/Letk=; b=wuXKxndj1Yatz89iiab0pj7MMFQCShPtLUEcgRBB6X61a6KvmwXolT8p4QO1To0j7o u8asfW3o9YoHhlGIjZkCPTyT1WSFcDrcJvQ3uKnTHNMmvPxS55rRkAHWX6pkB3qjx+7f jLUQF3WahXrf3hYwVCzAV+01k8I1b1T/mnef2ogPnV0jLjpRnPIVA+GZOjvdnDykchIU r2nyNalPxgP9ieVftDWyBRdvsf+INHOjQP4ZBnVMG7DOxxnrFrb6mGdZFLexRnwHqOMe u6kI7mhorPqmi/6AeVoWWFthxaDvOpcbefd5IjN2mHKt/vReMIh30iAjYFXEj9alWCYd mt0A== X-Gm-Message-State: AOJu0Yy7zDphLOo+SPyGk87Ia4aDh1GezDN5fLLQYT8JD0ZaI1fUjJYj 0uLGYunYC/7dRHmd28nXfLCzLUqC/McKE0P8dgfEGs8u3s7mnDGCSQa21S64L4lr9Wo= X-Gm-Gg: ASbGncvckJirDkkqZXCzfYTOPwT9d/CON+orsYk2R5MGppQt0nvodlz3tl+KTn3+r8q 9HBgNVZWr6J9pKvrMjmC1twbwQumrRmz5LaNMT1pojRPl8flpF608DRaOCJSGo8bya/t58R6PcN wZ6kn2WrLlGy4n2SO4ecJortfGHSztCzfiR5dNVjMod1Hdr0uquf/YyB0FcewbegwxY5Sq0aAK3 yKodiXvCcpHAdvnOrk82Z44X3oDlfwH1rWDcYUaHzDIpKHO4VUkZLEdU0LM5V1QIZkCPZrPCd5I nndecKJj/ty/qlFPNoXFKJIkKF2y8aJyIQ5O8a+CCfmdzTGq39CPSiw+NzorMM5YeQ+obCz6gN5 rBTqj416mWxyEDwggd19Cmmqcsag= X-Google-Smtp-Source: AGHT+IEkQFIOb1sRI7+spuJ8wgNEkbHLbFOCyPfPkj1wTUl6CvdGGFYMdGuKdkVwqyE0VHVDvGhx6A== X-Received: by 2002:a05:6402:270d:b0:60e:f46:326d with SMTP id 4fb4d7f45d1cf-61285c03a3emr7622956a12.33.1752786988129; Thu, 17 Jul 2025 14:16:28 -0700 (PDT) Received: from [192.168.0.20] ([213.220.144.201]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-611c9734069sm10594157a12.48.2025.07.17.14.16.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jul 2025 14:16:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------uHiycbRehWMYjKYgrW6r06mN" Message-ID: Date: Thu, 17 Jul 2025 23:16:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Recognized PostgreSQL External Communications Channels To: Dave Page Cc: pgsql-www@lists.postgresql.org, stacey@haysler.sh References: Content-Language: en-US From: Andreas 'ads' Scherbaum In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------uHiycbRehWMYjKYgrW6r06mN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 16/07/2025 11:05, Dave Page wrote: > Hi > > FWIW, it would be much easier to comment if you included the text > inline in the email. With that said, some thoughts/questions below... I have this in a Google Doc, if you like I can send you the link. Intentionally I did not include the link here, for a variety of reasons. > On Tue, 15 Jul 2025 at 22:03, Andreas 'ads' Scherbaum wrote: > > > Hello, > > one of the results of the PGConf.Dev 2025 Community Summit is > "Communication Channels" (1) and how to officially recognize such > channels. > > Attached is a draft for a > > "Recognized PostgreSQL External Communications Channels" > > Policy. The meeting in Montreal discussed listening recognized > channels > on the postgresql.org website. > > > 1) At the moment, we have taken the position (rightly or wrongly) that > any communication channel that includes multiple PostgreSQL people is > automatically subject to the CoC. There have been CoC incidents > centered around private communications and at least one Telegram > channel which was setup by a community member for general chatter on > any subject. Having a list of "recognised" channels will - whether we > like it or not - change that. It will implicitly set a boundary on > what channels the CoC applies to. That could effectively exclude the > Telegram channel, or private communications which one could argue are > effectively a mailing list created through use of a persistent set of > addressees. > > I'm not suggesting that's a bad thing - in fact, I think we do need > some boundaries to prevent overreach and ensure that people know where > the CoC applies and where it does not (part of the issue in the > Telegram case was indeed whether or not the CoC should apply). For > example, I have often made the point that my 50th birthday party > included multiple PostgreSQL community members, as well as people who > have nothing to do with PostgreSQL at all. Arguments have been made > that the CoC would apply to that gathering, which might have meant > that the community members in attendance would be prevented from > making a joke that would have been considered perfectly acceptable in > a pub in the UK but that the other attendees would have been able to > make, either because they didn't care about or know of the CoC, or > because it was recognised that it wouldn't apply to them as they > weren't part of the community. > > My point is that we need to recognise that this proposed policy and > the resulting list may have far wider reaching consequences that > initially envisaged, and to be mindful of that. Correct. The discussion started about where to find community (approved/recognized) channels and platforms. More specific, what is necessary in order to list such platforms on the project website. This is different from automatically including the CoC on all channels where community members are present. > 2) Some platforms do not allow multiple owners/administrators. Does > that mean they cannot be recognised? Good question. Got an example? This is a draft and can cover such platforms, I'd like to understand how this looks like. > 3) If an owner/administrator steps down, does the channel > automatically become un-recognised? Perhaps a grace period is required? Yes, makes sense. > 4) I find the way the doc talks about owner/administrators and then > moderation a little confusing, to the point that I had to read it a > couple of times until I realised it wasn't talking about 3 different > groups of people. Perhaps the terms owner and moderators would be > better? That would likely solve my point 2 above in some cases as > well, where platforms allow one owner but multiple moderators. It might be three different groups, the owner of a service, an administrator with global permissions, a moderator who can only moderate a specific channel. It does not apply to each and every service though, which indeed makes it complicated. Slack can have all three, Telegram can not. As example. > 5) I think the terms of service section needs some thought. As > written, if a service explicitly allows (for example) hate speech, > then that means we have to allow it in the PostgreSQL channel too. I > think this section needs to state instead that the most restrictive > terms must apply. Was thinking about this for a long time, but from the other end: can't really force users to violate the terms of service, if that collides with the CoC. You make a good point though. Open for suggestions to find a middle ground. > 6) Although there is the universal get-out clause at the top allowing > the core team to not recognise at will (kudos for keeping the proper > spelling there :-) ), I wonder if we should also have an explicit > clause stating that we will not recognise channels on platforms that > clearly are not appropriate for the project, for example, a platform > primarily known for extreme political discussion. That makes sense, will include it. Thanks for the feedback! -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project --------------uHiycbRehWMYjKYgrW6r06mN Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 16/07/2025 11:05, Dave Page wrote:<= br>
Hi

FWIW, it would be much easier to comment if you included the text inline in the email. With that said, some thoughts/questions below...

I have this in a Google Doc, if you like I can send you the link.
=
Intentionally I did not include the link here, for a variety of reasons.



On Tue, 15 Jul 2025 at 22:03, Andreas 'ads' Scherbaum <ads@pgug.de> wrote:

Hello,

one of the results of the PGConf.Dev 2025 Community Summit is
"Communication Channels" (1) and how to officially recognize such channels.

Attached is a draft for a

"Recognized PostgreSQL External Communications Channels"

Policy. The meeting in Montreal discussed listening recognized channels
on the postgresql= =2Eorg website.

1) At the moment, we have taken the position (rightly or wrongly) that any communication channel that includes multiple PostgreSQL people is automatically subject to the CoC. There have been CoC incidents centered around private communications and at least one Telegram channel which was setup by a community member for general chatter on any subject. Having a list of "recognised" channels will - whether we like it or not - change that. It will implicitly set a boundary on what channels the CoC applies to. That could effectively exclude the Telegram channel, or private communications which one could argue are effectively a mailing list created through use of a persistent set of addressees.=C2=A0

I'm not suggesting that's a bad thing - in fact, I think we do need some boundaries to prevent overreach and ensure that people know where the CoC applies and where it does not (part of the issue in the Telegram case was indeed whether or not the CoC should apply). For example, I have often made the point that my 50th birthday party included multiple PostgreSQL community members, as well as people who have nothing to do with PostgreSQL at all. Arguments have been made that the CoC would apply to that gathering, which might have meant that the community members in attendance would be prevented from making a joke that would have been considered perfectly acceptable in a pub in the UK but that the other attendees would have been able to make, either because they didn't care about or know of the CoC, or because it was recognised that it wouldn't apply to them as they weren't part of the community.

My point is that we need to recognise that this proposed policy and the resulting list may have far wider reaching consequences that initially envisaged, and to be mindful of that.

Correct.

The discussion started about where to find community (approved/recognized) channels and platforms.
More specific, what is necessary in order to list such platforms on the project website.
This is different from automatically including the CoC on all channels where community members are present.


2) Some platforms do not allow multiple owners/administrators. Does that mean they cannot be recognised?

Good question. Got an example?
This is a draft and can cover such platforms, I'd like to understand how this looks like.


3) If an owner/administrator steps down, does the channel automatically become un-recognised? Perhaps a grace period is required?

Yes, makes sense.



4) I find the way the doc talks about owner/administrators and then moderation a little confusing, to the point that I had to read it a couple of times until I realised it wasn't talking about 3 different groups of people. Perhaps the terms owner and moderators would be better? That would likely solve my point 2 above in some cases as well, where platforms allow one owner but multiple moderators.

It might be three different groups,

the owner of a service,
an administrator with global permissions,
a moderator who can only moderate a specific channel.

It does not apply to each and every service though, which indeed makes it complicated.
Slack can have all three, Telegram can not. As example.



5) I think the terms of service section needs some thought. As written, if a service explicitly allows (for example) hate speech, then that means we have to allow it in the PostgreSQL channel too. I think this section needs to state instead that the most restrictive terms must apply.=C2=A0

Was thinking about this for a long time, but from the other end: can't really force users to violate the terms of service, if that collides with the CoC.
You make a good point though.

Open for suggestions to find a middle ground.



6) Although there is the universal get-out clause at the top allowing the core team to not recognise at will (kudos for keeping the proper spelling there :-) ), I wonder if we should also have an explicit clause stating that we will not recognise channels on platforms that clearly are not appropriate for the project, for example, a platform primarily known for extreme political discussion.

That makes sense, will include it.


Thanks for the feedback!

--=20
				Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--------------uHiycbRehWMYjKYgrW6r06mN--