Re: Introduce contributor badges - Mailing list pgsql-www

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

>     +        pgweb.util.fields.ImageBinaryField(
>     +            blank=True,
>     +            help_text="Square image, will be auto-scaled to 150×150. JPEG or PNG, up to 1 MB. When left blank,
theSlony logo will be used.",
 
> 
> 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"?

PostgreSQL logo is better, yes.

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

>     +        models.CharField(
>     +            blank=True,
>     +            help_text="Contact address (email, URL, other) for people who want to be added as badge holder",
> 
> Should we keep it simple and limit this to email for now?  If we encourage
> people to visit third party sites we don't control in order to control behavior
> on our site then we need to verify said sites.

This would usually be something like https://2026.pgconf.eu/contact/,
so be in community control. It's also shown at moderation time and
part of the notification emails sent when edited post-moderation (I
think, I don't get moderation email yet). So I think we don't need to
be overly restrictive here. Allowing URLs also enables events without
a persistent email address.

>     -        help_text='This description is currently used for major contributors only')
>     +        help_text='Describe what you did in the PostgreSQL community')
> 
> 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"?

Sounds good.

>     +      {%for u in holders.all%}
>     +        <li>{%if u.date_retired%}<em>{%endif%}<a
href="/community/people/{{u.user}}/">{{u.user.contributor.firstname}}{{u.user.contributor.lastname}}</a>{%if
u.date_retired%}(retired from this activity)</em>{%endif%}</li>
 
>     +      {%endfor%}
> 
> 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.

Ack.

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

>     +  If you are listed and want to claim your profile page, write a mail including your community account name to
>     +  <a href="mailto:contributors@postgresql.org">contributors@postgresql.org</a>.
> 
> Shouldn't this (and a previous instance of webmaster@) use the hidemail filter
> for consistency?

Ack.

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

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.

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

Thanks!

Christoph