MIME-Version: 1.0
References: 
 <CAMDzVO_iXeXVYzDAD3g=VU_snwLN3CS+rKRmJtakq9uQ=WdnHA@mail.gmail.com>
In-Reply-To: 
 <CAMDzVO_iXeXVYzDAD3g=VU_snwLN3CS+rKRmJtakq9uQ=WdnHA@mail.gmail.com>
From: Dave Page <dpage@pgadmin.org>
Date: Wed, 16 Jul 2025 10:05:32 +0100
Message-ID: 
 <CA+OCxowekq9uLgiLm_zU2mTPtMDZxGf5BmJzatURF_P8kCA3Qw@mail.gmail.com>
Subject: Re: Recognized PostgreSQL External Communications Channels
To: "Andreas 'ads' Scherbaum" <ads@pgug.de>
Cc: pgsql-www@lists.postgresql.org, stacey@haysler.sh
Content-Type: multipart/alternative; boundary="0000000000009cabb7063a0832e2"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BOCxowekq9uLgiLm_zU2mTPtMDZxGf5BmJzatURF_P8kCA3Qw%40mail.gmail.com>
Precedence: bulk

--0000000000009cabb7063a0832e2
Content-Type: text/plain; charset="UTF-8"

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...

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.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.

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

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

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.

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.

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.


> I'd like to thank Stacey Haysler who provided great input drafting this
> policy!
>

Thank you both!

-- 
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com

--0000000000009cabb7063a0832e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi</div><div><br></div><div>FWIW, it would be much ea=
sier to comment if you included the text inline in the email. With that sai=
d, some thoughts/questions below...</div><div><br></div><div>On Tue, 15 Jul=
 2025 at 22:03, Andreas &#39;ads&#39; Scherbaum &lt;<a href=3D"mailto:ads@p=
gug.de">ads@pgug.de</a>&gt; wrote:<br></div><div><div class=3D"gmail_quote =
gmail_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><div><b=
r>Hello,<br><br>one of the results of the PGConf.Dev 2025 Community Summit =
is<br>&quot;Communication Channels&quot; (1) and how to officially recogniz=
e such channels.<br><br>Attached is a draft for a<br><br>&quot;Recognized P=
ostgreSQL External Communications Channels&quot;<br><br>Policy. The meeting=
 in Montreal discussed listening recognized channels<br>on the <a href=3D"h=
ttp://postgresql.org" target=3D"_blank">postgresql.org</a> website.<br></di=
v></div></blockquote><div><br></div><div>1) At the moment, we have taken th=
e position (rightly or wrongly) that any communication channel that include=
s multiple PostgreSQL people is automatically subject to the CoC. There hav=
e been CoC incidents centered around private communications and at least on=
e Telegram channel which was setup by a community member for general chatte=
r on any subject. Having a list of &quot;recognised&quot; channels will - w=
hether we like it or not - change that. It will implicitly set a boundary o=
n what channels the CoC applies to. That could effectively exclude the Tele=
gram channel, or private communications which one could argue are effective=
ly a mailing list created through use of a persistent set of addressees.=C2=
=A0</div><div><br></div><div>I&#39;m not suggesting that&#39;s a bad thing =
- in fact, I think we do need some boundaries to prevent overreach and ensu=
re that people know where the CoC applies and where it does not (part of th=
e 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 inc=
luded multiple PostgreSQL community members, as well as people who have not=
hing to do with PostgreSQL at all. Arguments have been made that the CoC wo=
uld apply to that gathering, which might have meant that the community memb=
ers in attendance would be prevented from making a joke that would have bee=
n considered perfectly acceptable in a pub in the UK but that the other att=
endees would have been able to make, either because they didn&#39;t care ab=
out or know of the CoC, or because it was recognised that it wouldn&#39;t a=
pply to them as they weren&#39;t part of the community.</div><div><br></div=
><div>My point is that we need to recognise that this proposed policy and t=
he resulting list may have far wider reaching consequences that initially e=
nvisaged, and to be mindful of that.</div><div><br></div><div>2) Some platf=
orms do not allow multiple owners/administrators. Does that mean they canno=
t be recognised?</div><div><br></div><div>3) If an owner/administrator step=
s down, does the channel automatically become un-recognised? Perhaps a grac=
e period is required?</div><div><br></div><div>4) I find the way the doc ta=
lks about owner/administrators and then moderation a little confusing, to t=
he point that I had to read it a couple of times until I realised it wasn&#=
39;t talking about 3 different groups of people. Perhaps the terms owner an=
d moderators would be better? That would likely solve my point 2 above in s=
ome cases as well, where platforms allow one owner but multiple moderators.=
</div><div><br></div><div>5) I think the terms of service section needs som=
e thought. As written, if a service explicitly allows (for example) hate sp=
eech, 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 m=
ust apply.=C2=A0</div><div><br></div><div>6) Although there is the universa=
l 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.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div>I&#39;d like to thank Stace=
y Haysler who provided great input drafting this policy!</div></div></block=
quote><div><br></div><div>Thank you both!</div><div>=C2=A0</div></div><span=
 class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"g=
mail_signature"><div dir=3D"ltr">Dave Page<div>pgAdmin: <a href=3D"https://=
www.pgadmin.org" target=3D"_blank">https://www.pgadmin.org</a></div><div>Po=
stgreSQL: <a href=3D"https://www.postgresql.org" target=3D"_blank">https://=
www.postgresql.org</a></div><div>pgEdge: <a href=3D"https://www.pgedge.com"=
 target=3D"_blank">https://www.pgedge.com</a><br><div></div><div><br></div>=
</div></div></div></div></div>

--0000000000009cabb7063a0832e2--