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.96) (envelope-from ) id 1vVtIZ-009TTW-0L for pgsql-www@arkaria.postgresql.org; Wed, 17 Dec 2025 15:18:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vVtIY-00DfKT-0A for pgsql-www@arkaria.postgresql.org; Wed, 17 Dec 2025 15:18:42 +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.96) (envelope-from ) id 1vVtIX-00DfKI-2f for pgsql-www@lists.postgresql.org; Wed, 17 Dec 2025 15:18:42 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vVtIV-001FUL-2F for pgsql-www@lists.postgresql.org; Wed, 17 Dec 2025 15:18:42 +0000 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-649728a2228so7958411a12.3 for ; Wed, 17 Dec 2025 07:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765984714; x=1766589514; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XL6Ur5eedK7of2dhTCcvTYPCk7YtAg1wMa3/M540Dp8=; b=NfFf2VlZAHh/IjCCPwNcfzf5lS+7GtBvJ0CcP9TfUILLCr+Rrsc1IWZ1jEOsUrgC4v LVGRLCNIVNGO0I3XfbRNQlgjj0SXmXC3WOsNHb8jDNOb3ZELXGl0PnTg8Xx4pknfvRLK Ho0x2+CjsG3eIxIRyb4nmc5q6NspWxfEtgRw8UjfklH1e+Z7yeLBvIFJmUdjmkLi5D0j +QghX/knyn8yrvzsBGpvTIYPpy9ODUxbAbG9ckus08qbNjDfkGmgvUW9pbMhuzjidSca 5tYdDcRd4PMoXIStxjXCMStmBBYraLcAvP0gUT6tHWBehnNeGHM2bJZk18blMebMmIWT u9BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765984714; x=1766589514; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XL6Ur5eedK7of2dhTCcvTYPCk7YtAg1wMa3/M540Dp8=; b=lv89BG9ypr5elPMgW8AEKqW/cku5gYVV9pVCFnqnWjQGn58DBdKIBgLBYuo/FFZKlP ZCREqyNN+a5VL4L7xs6mCvJcV81f0RmhbVZ1t+oEW73iB/9KKG9IEmzmh8n0dQWrBIRx MJTco14xeM4cfLoi6/kCz2uAvYnoQyZHaXwa/ws/iDew4lOujt3KhaukGdUyQalsIKKd sZbYAyrr2N8qWj7HHWGWRNdznnQgIf6Fwb00tuxErNgGuZl/gw+Xj369UWhl2FpErb5d hI3EcjxW7Pq4VQNChlakXx+mILoklbXcxvVNHot0ZFwSwp67fwal8+nGH29NPAnedSq7 vD/Q== X-Gm-Message-State: AOJu0Yx6qTf6BnWoQGoByVT1TGF4rVLD4iWZrl6V6gBa2OLMBUR05boW LtnU8eZsP9HvRAVf+g6DrTUVJNLG9G6syuFSAgsO6sDn6Mz75I6obZklMm+WuoSflcdAXfDGa91 bfSO7d32eIthgxeGUpBKG2CoBKn6pq+rOffUy X-Gm-Gg: AY/fxX63oL7Y07OEZyF3QNLqyx5ul3et4MSI73M/h3fUx/z6kXMv/odIQXcTyERGbrw n+G67On4RXULPN7oxXnTvHnjJOW48beemAoyNkMIWmaaNPEmp1HG25vrbaDJhbEUr2m1whtynTb VoDQAo3tCos43k7fAXh9Wcl64Vse2CadPmMaaNX3NK0U0/amzaxHFPSF+7WraJWtXMrC89IFWdB c8emulv0heu5zzuGEWLTXOJ2libnDZZnsqwMI52KMmK4DauejvNq0cKwQ8/lDPEzv1aQLfr X-Google-Smtp-Source: AGHT+IE/Ic0qjuCrzZR+O1kBLeICCiyr8fL4Yz5MBPvYTOmkMn9/ykA2SXrrh6/GU+oaXuc3KinU1YRvXUQdsC8YBWM= X-Received: by 2002:a05:6402:1e94:b0:64b:42a6:3946 with SMTP id 4fb4d7f45d1cf-64b42a63e87mr2219459a12.7.1765984713780; Wed, 17 Dec 2025 07:18:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Melanie Plageman Date: Wed, 17 Dec 2025 10:18:22 -0500 X-Gm-Features: AQt7F2re5lDpn8yXTuJ95dkoXJEmZI0uhRAxYOibwCtMkgjYO14IkrNKqFv_0fA Message-ID: Subject: Re: Public contributor profile pages To: Magnus Hagander Cc: pgsql-www@lists.postgresql.org, PostgreSQL Contributors Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thanks for taking a look! A few follow-up questions before I edit the patch= : On Wed, Dec 17, 2025 at 9:03=E2=80=AFAM Magnus Hagander wrote: > > AFAICS with this patch, *every* user who visits their profile gets a Cont= ributor object created. And they do that even if they don't save their prof= ile? And the contributions part of the profile shows up for all users, whet= her they are contributors at all or not -- not just "all levels of contribu= tors". That doesn't seem right, surely only those who are recognized at *so= me* level should be getting that, and the change is to list all levels, but= not random non-contributors? (And even if it's shown for non-contributors = intentionally, we shouldn't create a database record for people just viewin= g things) What we are envisioning once we add "Contribution Badges" (or whatever we call them) is that anybody who is approved for a badge (e.g. volunteered at PGConf EU) would have that badge listed on their profile. These may or may not be considered "Recognized Contributors", and we aren't sure whether or not their names will be listed on the Contributors Profile page or another page or not linked to a main pgo page at all. But either way, it makes sense for these profiles to be publicly viewable since they were awarded to the person. Since we don't have the badges yet, we are considering the text of the "Contribution" field to be the equivalent. So anyone that lists "Contribution"s should have a publicly accessible profile. It isn't approved by a moderator like badges would be, which does make it more fraught, though. The reason I thought every user profile should have a Contributor object is that 1) it seemed easier from an implementation standpoint than creating one only once someone has edited the contribution fields of the form 2) most of the use cases for a pgo account seem related to contributing (signing up for mailing lists, etc) -- I don't know if they are used for other things like downloading postgres binaries etc. Is there a good way to avoid making the Contributor object unless they edit the "Contributions" field? Maybe there should be some kind of way of saying "I contribute to Postgres" and "Contributions" is a required field and then that makes the Contributor object and also kicks the profile to some moderation queue for the Contributors team? > Also, when making changes to a model that only changes fields that aren't= actually in the database (such as the change of help_text), instead of mak= ing a migration for that it's better to "backpatch" it into the latest exis= ting migration. Otherwise we just collect a lot of no-op migrations that ov= er time will start costing time and annoyance. The latest existing migration that includes that field or just the latest existing migration? > As for the questions - I think we should absolutely do opt-in, and I do t= hink it makes sense to auto-opt-in the current major contributors since "it= 's been like that forever and they haven't complained", but listing the oth= ers and in a more visible way there are sure to be some who might not want = it. In particular, maybe we should make the listing of *email* a separate o= pt-in/opt-out? That is you can opt-out of being listed completely, or you c= an say "list me, but not my email"? So there would be a separate opt-in for being listed on the recognized contributor page and for having a public individual contributor profile? And we would only auto opt-in major contributors to the public individual contributor profiles? And email display would be separately opt-in and if you opt-in it displays on both the individual contributor profile page and on the main recognized contributor profile page for major contributors and we would auto opt-in email display for major contributors? > I've thought a bit about it and I do think listing the profiles with the = username in the URL as you have done is in the end good. I don't think peop= le would care about exposing that one -- and it's already exposed on for ex= ample the commitfest app. But based on that I would go with "does not show = at all if they don't have an account". They won't be able to edit any infor= mation on it anyway, and if they care enough to do that they will create an= account. We will presumably continue to list them in the list of contribut= ors, just not provide a details page. That makes sense. Maybe we should start calling the Contributor Profiles page [1] the Recognized Contributors page or Sustained Contributors page instead of the Contributor Profiles page to disambiguate it from individual contributor profiles. If only to make spec'ing out this feature easier. > I wonder if we really need a separate "report inappropriate profile"? We = should be getting notifications for them, but in particular if we are serio= usly worried about this case, we should make the records moderated. But the= se are known contributors - I think we can trust them? I think we want people who are not recognized significant or major contributors to be able to have profiles so that they can build them up and eventually make the case for being a recognized significant or major contributor. This would significantly increase the number of people with profiles so moderation may get tricky. What does it mean that we would get notifications for them? Is "we" the contributors committee? I would be okay with having them moderated if we thought the volume would be like one a day (with more at the beginning). And maybe if it is more, we could add another community member outside the contributors committee to help moderate. - Melanie [1] https://www.postgresql.org/community/contributors/