On Mon, Jun 23, 2025 at 12:01 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> Yes, categories, and give each category its own line in the table.
I'm headed in the opposite direction. Let me elaborate with some very
strong opinions about the existing tags. (No one has to share my
strong opinions.)
- Help - Bikeshedding
- Good First Review
- Missing Tests
This category of tag is the best. It is completely new information,
not captured anywhere else in the UI, that is useful at the top level
and helps drive reviews forward by helping the community find
interesting things.
- Bugfix
- Security
I'm not excited about these tags, but in the absence of a bug tracker,
I'm glad we have them. Now it doesn't matter what "section" your patch
is in; if you realize it needs to be treated as a bug fix, or it gains
some sort of security caveat, you can tag them as such.
- dblink
- PL/Perl
- postgres_fdw
I don't like these at all. You can already search the patches with the
search box, so introducing a community norm that adds a bunch of
"which code did I touch" tags serves to clutter the UI and give new
CFMs an excuse to spend a bunch of time categorizing as opposed to
moving patches forward. Put the target of your patch in the entry
title somewhere -- and if it touches ten sections, I didn't really
want to see ten tags anyways.
- Backport
I am completely against this tag in particular. We have this
information already in its own Version column (though it's kind of sad
it's not sortable). If that column isn't working for people now, I
really doubt that moving the information to tags is going to help in
any way; we can either clarify the Version labels or make the meaning
discoverable.
--Jacob
