Обсуждение: Public contributor profile pages

Hello,

The Contributors Committee is working on a new program to recognize
specific contributions (e.g. "volunteered at PGConf.dev 2024" or
"contributed code to PostgreSQL 18"). These would be listed on an
individual contributor's profile. As a step toward that, we are
proposing to add public contributor profile pages.

Attached is a patch set which implements this by:
1) allowing all those with pgo user accounts to edit their
"contributions" (currently only enabled for recognized contributors)
2) adds a public contributor profile view accessible via
postgresql.org/community/contributors/[username]
3) links all recognized contributors on [1] to their public contributor profile

There are quite a few details to work out. A few I know of are:
- How should opting into a public profile work? What about existing
recognized contributors, do we opt them all in automatically? Or just
opt-in Major Contributors since their "Contributions" are already on a
public web page? (see patch 0003)
- How to make the public profile URL scheme work for contributors who
do not have a pgo user account? Or should it work at all?

This is my first real web patch, so I'm sure I did some things in a
non-pgweb-idiomatic (or non web-idiomatic) way and didn't think of
lots of things. I'll probably need lots of guidance.

- Melanie

[1] https://www.postgresql.org/community/contributors/

Thanks for taking a look! A few follow-up questions before I edit the patch:

On Wed, Dec 17, 2025 at 9:03 AM Magnus Hagander <magnus@hagander.net> wrote:
>
> AFAICS with this patch, *every* user who visits their profile gets a Contributor object created. And they do that
evenif they don't save their profile? And the contributions part of the profile shows up for all users, whether they
arecontributors at all or not -- not just "all levels of contributors". That doesn't seem right, surely only those who
arerecognized at *some* 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
peoplejust viewing 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
changeof help_text), instead of making a migration for that it's better to "backpatch" it into the latest existing
migration.Otherwise we just collect a lot of no-op migrations that over 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 think it makes sense to auto-opt-in the
currentmajor contributors since "it's been like that forever and they haven't complained", but listing the others and
ina 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 opt-in/opt-out? That is you can opt-out of being listed completely, or you can say "list me, but
notmy 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
theend good. I don't think people would care about exposing that one -- and it's already exposed on for example the
commitfestapp. But based on that I would go with "does not show at all if they don't have an account". They won't be
ableto edit any information on it anyway, and if they care enough to do that they will create an account. We will
presumablycontinue to list them in the list of contributors, 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,
butin particular if we are seriously worried about this case, we should make the records moderated. But these 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/

Re: Melanie Plageman
> 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?

Since the email is user-editable, and separate from the account email,
people could just leave that field empty. We just need to update the
description so they know when editing their profile. Same for all the
other fields)

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

We seem to have started using "Recognized Contributors" in the team,
even if we didn't ever consciously decide about it.

> > I wonder if we really need a separate "report inappropriate profile"? We should be getting notifications for them,
butin particular if we are seriously worried about this case, we should make the records moderated. But these are known
contributors- I think we can trust them?
 

That button looks a bit odd at the moment. Perhaps having it is
appropriate, but it should be much less prominent so the page looks
good when people show it around.

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

Maybe we could actually base our decisions on that...

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

Perhaps passive moderation is good enough, i.e. things get put live
automatically, but we can review the notifications and kick anything
bad.

Christoph

Over the holidays, I used the time to implement the badges idea. We've
discussed in the team and we are happy with how it looks like now, and
I'm attaching the version with the changes from the last contributors
team meeting.

The technical description is in the commit message, so I'm not
duplicating that here. It's obviously a larger patch, but since the
badges are new, I'm not sure it's possible to split it up.

To make rollout less disruptive, we could deploy everything, but leave
out the part that creates links to the new parts
(pgweb/util/contexts.py, anything else?). That way we could test
everything, prefill some initial badges and badge holders, and put in
the links once everything is confirmed to work.

I also plan to present the design at the dev meeting in Brussels.


Re: Magnus Hagander
> If they are not based on the recognized contributors, they should probably
> not be part of that in the data model either. But in particular, we
> shouldn't start creating empty contributor profiles before we even *knoiw*
> that it would.

That part works like this in the patch:
- badges are awarded to users (not to contributors)
- users who have at least one badge are offered to create a profile
  page (creates the contributors object)
- these users can then fill in the data fields

> So any user without any confirmation can just add themselves as a
> contributor, without even moderation, and publish data? That sounds like a
> *really* bad idea, tbh.
> 
> If it's data published by users where we have at one point added them to
> the contributors list and therefore pre-moderated to some point that is
> reasonable. But allowing random people to add records and then edit them
> and then it turns out to be published is going to be a hard no -- we've
> spent many hundreds of hours dealing with that on the wiki for example, and
> we will definitely not open up another venue for that. If it's things that
> not-specifically-approved users can add, then it *must* be moderated.

The moderation part is that people have to convince a badge-issuing
organisation to add their pg.o account as badge holder. This is
possibly a lot of organisations and people, but everyone involved
should be a recognised community member. Also, the worst harm would be
that could publish a random text on a ..../username/ sub-page that is
easily deleted again if we monitor changes. (Afaict any changes to
contributor objects are mailed somewhere. Not sure if that includes
the bio part already, but it could certainly made to be.)

> The latest one that includes that field. Doing that makes the "manage.py
> makemigration" no longer think there are any changes and stop emitting
> anything for that object.

I haven't included the migrations in the patch yet, will do that after
review of the general feature.

> > As for the questions - I think we should absolutely do opt-in, and I do
> > think 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
> > others 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 opt-in/opt-out? That is you can opt-out of being listed
> > completely, or you can 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?
> 
> When writing that I was not aware that you were intending to have both a
> "recognized contributor" and a "self-claimed contributor". That does change
> it a bit. If it's a self-claimed contributor then it doesn't make much
> sense to opt-out.

The listing is opt-in. If the user never clicks the "create a profile
page" button, their name is not shown. Not even in the list of badge
holders on the badge page.

Once we have this system, the expectation would be that anyone who
we'd want to promote to a recognized contributor would already have a
profile page created. (If not, we should ask them first why.)

> I think Christoph made a good point about this -- once the contributor
> profile requires an account, which it does in order to get published here,
> they can opt out by just changing their email to being empty. It's only for
> contributors that do not have an account connected that *we* need the email
> (so we can reach them), but with the discussed plan those wouldn't be
> listed anyway  since a username is needed in order to get listed. So that
> should leave us without needing a separate opt-out.

Contributor.email is currently still "null=False, blank=True", should
probably change that to null=True.

> Per above, if it is a field that any user can directly edit and it goes to
> publication, it must be moderated. That's a hard requirement. Before we
> made the whole "make me an editor" requirement for the wiki, for examples,
> we had upwards of 10,000 new accounts signed up every day just to post spam
> when it hit the peak.
> 
> We might need to add more moderators for it, but it needs to be moderated :)

(See above) Even if that's people who have already proven to have
contributed something useful?

> What does it mean that we would get notifications for them? Is "we"
> > the contributors committee?
> 
> Right now, there's just the one moderation team and address that gets it
> for all types of objects. But it would probably be relatively easy to split
> that up so there could be multiple moderation-and-notification teams.

That might make sense. Or some of the contributors team members get an
extra job at pgweb moderation...

Christoph

> On 19 Jan 2026, at 21:28, Christoph Berg <myon@debian.org> wrote:
>
> Over the holidays, I used the time to implement the badges idea. We've
> discussed in the team and we are happy with how it looks like now, and
> I'm attaching the version with the changes from the last contributors
> team meeting.

Thanks for working on this! Looks great!
I've setup preview version to test how things will look like. There's some generated sample data.

http://89.169.141.31:8000/community/people/alice/
ogin:moderator pwd:moderator123
orgmanager1 manager123
orgmanager2 manager123
alice alice123 -- Has 3 badges + profile page
bob bob123 -- Has 2 bandges
charlie charlie123 -- 2 badges, without profile


I'm slightly worried that user does not approve their badges.
Also do we plan to add a page where user can claim a badge so org admin can approve their claim?

And I find it a bit oxymoron: "Basic contributor, not recognized"


Best regards, Andrey Borodin.

Re: Andrey Borodin
> Thanks for working on this! Looks great!
> I've setup preview version to test how things will look like. There's some generated sample data.
> 
> http://89.169.141.31:8000/community/people/alice/

Thanks, that makes review a bit easier for everyone else I guess.

The "people" page there has a problem:
http://89.169.141.31:8000/community/people/
It's not happening here, so I can't say if that's a bug in the patch.

> I'm slightly worried that user does not approve their badges.

The idea is that the badge itself needs approval and then is trusted.
So I think the worst thing that could happen is that someone
legitimately creates a "PostgreSQL Conf Antarctica Speaker", awards it
to you, but you don't want to publicly admit that you've been there.
Anything I'm missing?

> Also do we plan to add a page where user can claim a badge so org admin can approve their claim?

I think the basic workflow is that people contribute, an organisation
creates a badge for it and awards it to these people. For example,
after the PG19 release, we would create a "PostgreSQL 19 Contributor"
badge and award it to everyone listed in the release notes. Similarly
for conference speakers.

Maybe the other way round shouldn't be too easy so badge issuers don't
get flooded with requests. That's why we put the email link there.

Perhaps we need to make sure all approved badges have clear criteria
for badge holders. For example, "Has said something useful on the
mailing list" would be very fuzzy and invite request spam too much.

> And I find it a bit oxymoron: "Basic contributor, not recognized"

That's there to make the distinction to recognized contributors clear.
Better suggestions welcome.

Christoph

Re: To Andrey Borodin
> It's not happening here, so I can't say if that's a bug in the patch.

My mail client recoded the attachment as latin1. I'll replace the "·"
there by · , that's cleaner anyway.

Christoph

Re: To Andrey Borodin
> My mail client recoded the attachment as latin1. I'll replace the "·"
> there by · , that's cleaner anyway.

New version attached, with ^ this change and rebased.

Christoph

More polishing done, now including the database migration script.

Christoph