Re: Introduce contributor badges

Re: Daniel Gustafsson
> 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.

I've staged a bump to 64 (to match the max slug length). To keep the
migrations churn down, we should bundle that with the next database
update (or when we actually run into the limit).

> While Slony was a great tool back i the day, I think you mean "Slonik logo"
> here =) I wonder though, will everyone be familiar with "Slonik" or should we
> just say "PostgreSQL logo"? 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.

Changed to "PostgreSQL logo" in the attached patch.

> This reads like focusing on the past like adding an Alumni entry, shouldn't
> this be more like "Describe your involvement in the PostgreSQL community"?

Same.

> Rather than wrapping the entry with a conditional <em> it seems like a cleaner
> solution to use the condition to set a CSS class which controls the rendering.
> This is more a nice-to-have of course.

... same.

> Shouldn't this (and a previous instance of webmaster@) use the
> hidemail filter for consistency?

None of the other static appearances of email addresses in the
codebase does that, the @postgresql.org strings are all there in
plain.

Re: Daniel Gustafsson
> >> 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.

I'm unsure here. Which size limit would you suggest?

(TBH I think we shouldn't micro-manage this. If the badge logo looks
terrible, the submitter can still swap it later.)

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

It currently looks like this:

http://localhost:8000/community/people/

People in the PostgreSQL Community

These are the fine people who have made contributions to PostgreSQL over the years.

Recognized Significant and Major Contributors are listed on the PostgreSQL Recognized Contributors page.

Bob Badgeholder · Christoph Berg · Pat Holder

... so before we say "fine people" there the heading and the URL that
already have "people" and put that into context. The wording isn't
mine, it's taken from the existing /community/contributors/ page and
frankly, "the fine community members" isn't that snappy.

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

Ack. I'll keep that for the next iteration.

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

Most URL patterns in that file don't do that either, and if someone
tries a username that doesn't exist, they just get a 404 error.

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

The form and this text is only shown if the user already has a
contributor object in the database. Was that the question?

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

Done.

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

The contact information might still be obvious from the context (like
asking the conference organizers), so I'd tend to leave it like it is.
(This is probably a question that is better answered once we have the
first concrete badges in to see how it feels in practise.)

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

Done.

Thanks for the review!

What do you think about the open ends?

Attachments:
v12-0001-Contributor-copy-editing.patch - the stuff from this mail
v12-0001-Make-contributor-badges-discoverable.patch - what will
actually put the badges live
v12-0001-Extend-badge-title-to-64-chars.patch - future database fix

Assuming v12-0001-Contributor-copy-editing.patch is ok, would you
think that we can proceed with adding some badges now? My hope would
be to have at least "PostgreSQL 18 Contributor" live for Valencia.

Timeline:
after ack: apply v12-0001-Contributor-copy-editing.patch
this week: create initial badges, add holders
have badges approved in moderation (they are still not visible)
shortly before the conference: apply v12-0001-Make-contributor-badges-discoverable.patch
later: apply v12-0001-Extend-badge-title-to-64-chars.patch

Christoph