Re: Introduce contributor badges

> On 9 Oct 2026, at 20:40, Christoph Berg <myon(at)debian(dot)org> wrote:
>
> Re: Daniel Gustafsson
>> + "badge",
>> + models.CharField(
>> + help_text='Title of this badge, e.g. "PGConf.EU 2025 Speaker".',
>> + max_length=32,
>>
>> Will 32 characters be enough for all purposes? A "Nordic PGDay 2026 Program
>> Committee" badge as an example would require more than 32, and I can imagine
>> others like that. It's good that submissions need to be creative to fit within
>> a constraint, but we also don't want to end up with needlessly abbreviated
>> badges.
>
> Thanks for the example. One goal here is to have the titles not make
> the grid of badges on the people page not explode, but it should of
> course not be too restrictive. I guess we need to bump this. (I would
> rather limit the length per moderation than technically.)

Sounds sensible, bumping the limit and making moderation stricter sounds like a
plan forwards.

>> I also fear that allowing 1MB large image files
>> opens the risk for getting detailed and feature rich submissions which will
>> look terrible in 150x150.
>
> Is that the problem of the limit? People could submit terrible things
> even at smaller scales. (Again, perhaps a question for moderation.)

They can, but it's a lot easier to mess up when working with an intermediate
representation where the end result is a product of transformation. I would
start with a more restrictive limit and possibly increase later rather than the
other way around.

>> +<p>People are listed in alphabetical order.</p>
>>
>> s/People/Contributors/ ?
>
> We deliberately don't say "Contributor" there to keep the perceived
> distance to the original now-"recognized" contributors list greater.
> Of course everyone in that list did contribute, so this is maybe
> splitting hairs...

That's a fair argument, but "people" sound very generic and more like a
decription of an unknown group. Maybe "Community members" or something else?

>> contribution = models.TextField(null=True, blank=True,
>> - help_text='This description is currently used for major contributors only')
>> + help_text='Describe what you did in the PostgreSQL community')
>>
>> When opening this up to a lot more people than the major contributors, this
>> field should probably be sanitized when saved (and possibly when read as well)
>> to keep malicious content out. Maybe that's already done today and I'm plain
>> missing that, but if not we need to do that IMO.
>
> It's already html-escaped.

Good, I missed that when skimming the pgweb code.

> I was thinking of allowing markdown in the
> future (and render only the first paragraph in the recognized
> contributors page), but then we'll have the question of links etc
> again.

Markdown would be nice as a future improvement, if it can be restricted to not
include links.

> The answer we settled on when we discussed that with Magnus was that
> post-moderation by reading the change emails is good enough. Anyone on
> that list did something positive for the community, and they will not
> want to get kicked out for doing something evil with their profile
> page.

Agreed..

>> I'll revisit the remaining parts in a follow-up look.

A few further comments from a second read-through. I am not particularly
Django-literate so I might well have missed something there.

+ re_path(r'^community/people/([^/]+)/$', pgweb.contributors.views.profile),

Shouldn't this match the regexp for allowed characters in the username?

- <p>You can edit the information that's shown on the <a href="/community/contributors/" target="_blank" rel="noopener">contributors</a> page.
+ <p>You can edit the information that's shown on your <a href="/community/people/{{user.username}}/" target="_blank" rel="noopener">profile</a> page.

Maybe nitpicking, but this will still be published on the
community/contributors page for a subset of users. Should the text reflect
that, possibly conditional on the the logged in users controbutor status?

+ <div>
+ <input type="checkbox" name="create_contributor_profile"> Create publicly visible profile page
+ </div>

To be consistent with modern HTML (where we are going with pgweb) I think the
<input> should have an id attributed and a <label> for that attribute.

+<h2>Getting added</h2>
+{% if badge.org %}
+<p>This badge is issued by <em>{{badge.org}}</em>.</p>
+{%endif%}
+
+<p>If you think you should be listed
+ here, check your <a href="/account/profile/">account profile</a> page if the
+ badge is present there and activate your contribution profile page. If not,
+ contact the badge issuing organisation and ask to be added.</p>
+
+{% if badge.contact %}
+<p>Contact information: <em>{{badge.contact}}</em>.</p>
+{%endif%}

A badge can be without both a contact and an org IIUC which, although highly
unlikely, should probably be reflected in the template. Maybe the entire
"Getting added" section should be omitted if .org and .contact are both blank?

+ <img src="{%if b.has_image %}/community/badge/{{b.slug}}/image/{%else%}/media/img/about/press/elephant.png{%endif%}">

All <img> tags must have alt attributes to keep our accessibility score.

--
Daniel Gustafsson