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 1ucgKM-00FjEy-OI for pgsql-www@arkaria.postgresql.org; Fri, 18 Jul 2025 08:20:23 +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 1ucgKI-009GVU-MB for pgsql-www@arkaria.postgresql.org; Fri, 18 Jul 2025 08:20:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ucgKI-009GVM-4K for pgsql-www@lists.postgresql.org; Fri, 18 Jul 2025 08:20:19 +0000 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ucgKG-008PCp-0N for pgsql-www@lists.postgresql.org; Fri, 18 Jul 2025 08:20:18 +0000 Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-32b8134ef6aso19998261fa.0 for ; Fri, 18 Jul 2025 01:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1752826814; x=1753431614; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qox75h/E2DK0jdTgp6kQtlDlp5ibgp05sUe6ZrS4JXg=; b=GSxzNfcC83k40MndiA8rdLUmc/QjF2wFJUuW54ol+5X5KDxTBISt+txymcCFJEl95J 5vebuHU0EgpCkuPXHnpYq34ZPdxDhSK/V6WHpzuayKGT584eFs9dnF3nv8WsdEU7NpFY dfVVTK2toAMCyft9Coeb5eWdLI3uQjBq5ZRS9pOxP/14zPYsFiRE3m+08nhUdc+gpskx WL/JD6vV0LKO2nYJK/Zy5Szck+I6b3fHAuMJLFguRE/PjBXTOBrXzTOaVhalSv50mNgQ xXz0aJ696yHZhwRxQu7k4PtA54zjhWkCDhhBfXMkPoQpH4akVCxcT1CRZkB2w9FIG+Sn fKiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752826814; x=1753431614; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qox75h/E2DK0jdTgp6kQtlDlp5ibgp05sUe6ZrS4JXg=; b=MYwczkcmlWctUNvcKEFXpZe4RUNB+WNleY1ggqnazbpsv2Z3HnNhH6/LAtzdcY5Cgy M5E0yFDh6pPqTkikT9T3KHkilhPwV+Uu4Y6sJu53YtSCYWW56w6In/+AWs5iW5591qKl R8ORZ1R2N1GCTRMZNOMCybOZGbhKSuOqfSm8TAfGNhEZYKK8EiCyd5xNPzxWY4YLJeCx NO6WJp4Plkr0dRNJTGLnjiWwojP3PoPV7iraqEm7U5VFClnc5ml0BeS1i+Duy7xMDty3 TAgUhr9bwA/dc/bPbJYh3ArWJISyCW2Skno7SdFDpKPUCTOCBxhO1yIVvSnKXpL3OZfA GBTQ== X-Gm-Message-State: AOJu0YzOX/6SnJ/Y5uLbrv2xiDpU4vY4MZglqzAqvivig5vl+YVu9gEo G4hQWojaRtZmTU/pXfihuW2uSXpiQyocKd76xNLmb8Jpys2Vrm48BNBwXNs1GfOcYvslzo+jOwG dum8iKWRV7fwptnMvA5RjAfk9gw2V5rn05VZpeRb/ X-Gm-Gg: ASbGncsn9omeg2fyAqs6vJl9udvxVucuVSeY6AnIIE5UggI3Sqa42RhyV6if5G664hY xI2LCtw2RuWhzAelyIfEsSb3wDIKHs6wbziDxujCmMcsaN1Zw1UjFuTDBmSL7qR4NfOMZTkGnVz RTMKbPU9vd9EmXoYJStq7I4/ZDQURw0HgliJBdanLjTZlYu+BN6v6nE0+F8FyAU9H+Mt9W8kUXf VdqOiKXjw== X-Google-Smtp-Source: AGHT+IG9eUFbSRhJJKlTn7WHqBU+C555l53iHAmTE5SQ9cPR+PxKHVlp9lBy9VsA3aKF2H+t/bt6eJx8Yj3RxHc8Y7Q= X-Received: by 2002:a2e:a984:0:b0:32b:7ddd:278d with SMTP id 38308e7fff4ca-3309a466439mr14262401fa.3.1752826814182; Fri, 18 Jul 2025 01:20:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 18 Jul 2025 09:20:02 +0100 X-Gm-Features: Ac12FXwtR9OXS-IVFncygKx7Hs9d60G7vVr9CrLpIv6qpPXwQH9wDwS0g7UMfWQ Message-ID: Subject: Re: Recognized PostgreSQL External Communications Channels To: "Andreas 'ads' Scherbaum" Cc: pgsql-www@lists.postgresql.org, stacey@haysler.sh Content-Type: multipart/alternative; boundary="0000000000009cce1f063a2fcbea" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000009cce1f063a2fcbea Content-Type: text/plain; charset="UTF-8" On Thu, 17 Jul 2025 at 22:16, Andreas 'ads' Scherbaum wrote: > 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. > I've already commented now, but I think inline is best for future threads in front of a wide audience where Google Doc sharing would be problematic. > 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. > Well you and I (and Magnus) hit exactly this problem in one of our Telegram channels a while back. I forget the exact details, but there was something we found that Magnus and I couldn't do as admins, and only you could do as the owner of the channel (which at the time we thought we should have been able to do with our privs). > > > 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. > Then I think the doc should spell out what those three groups are (and how some may be the same on some platforms), and the requirements and expectations for each. I don't think that is at all clear right now (as evidenced by you now confirming you think there could be three groups). > 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. > I can't think of a case where "more restrictive applies" would force a user to violate the ToS. In my example, that would mean the service's ToS would have to *require* hate speech for example. Can you think of a counter example that would force a violation? > 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 > > -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --0000000000009cce1f063a2fcbea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, 17 Jul = 2025 at 22:16, Andreas 'ads' Scherbaum <ads@pgug.de> wrote:
=20 =20 =20
On 16/07/2025 11:05, Dave Page wrote:
=20
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.

I've already com= mented now, but I think inline is best for future threads in front of a wid= e audience where Google Doc sharing would be problematic.
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 understan= d how this looks like.

Well you= and I (and Magnus) hit exactly this problem in one of our Telegram channel= s a while back. I forget the exact details, but there was something we foun= d that Magnus and I couldn't do as admins, and only you could do as the= owner of the channel (which at the time we thought we should have been abl= e to do with our privs).
=C2=A0


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 differen= t 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.

Then I think the doc should spell out what those= three groups are (and how some may be the same on some platforms), and the= requirements and expectations for each. I don't think that is at all c= lear right now (as evidenced by you now confirming you think there could be= three groups).=C2=A0
=C2=A0
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.

I can't think of a case where "more restrictive a= pplies" would force a user to violate the ToS. In my example, that wou= ld mean the service's ToS would have to *require* hate speech for examp= le. Can you think of a counter example that would force a violation?
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
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


--
--0000000000009cce1f063a2fcbea--