Next commitfest app release is planned for March 18th

On 04.03.25 02:21, Jelte Fennema-Nio wrote:

1. Major change: The homepage is revamped completely! It now shows a
dashboard of open patches where you are author/reviewer/committer if
you are logged in. These patches are ordered & grouped in a hopefully
useful way. If you're not logged in it will show you the current
commitfest. See screenshot for an example. The old list of all
commitfests is moved to the /archive (which has a button on the
homepage). Peter Geoghegan suggested adding a "dashboard" of this
kind. Feedback on this is very welcome, but depending on the
complexity I don't know when I'll get to it. I'll be a bit more busy
the next few weeks and also have some holidays planned.

I don't know if I like that. I can see the point of getting to the
action quicker, but this sort of obscures the hierarchy of the site and
the data. Before it was like, select a commitfest, select a filter,
here are some patches. Now it's like, here is some stuff. Where did it
come from, how does it relate to the other stuff, how do I get to an
overview of all the stuff and the hierarchy of stuff.

How does one get back to the old homepage? I figured it out, you click
the "Archive" button. Why is that a button? Also, the row of buttons
is now seemingly a mix of actions on the current commit fest mixed with
site navigation. See above, what is the hierarchy of information and
the context of actions. This is a bit confusing.

On Tue, 4 Mar 2025 at 10:22, Peter Eisentraut <peter@eisentraut.org> wrote:

I don't know if I like that. I can see the point of getting to the
action quicker, but this sort of obscures the hierarchy of the site and
the data. Before it was like, select a commitfest, select a filter,
here are some patches. Now it's like, here is some stuff. Where did it
come from, how does it relate to the other stuff, how do I get to an
overview of all the stuff and the hierarchy of stuff.

I'm curious if there was anything specific that you used the old
homepage for. Especially things you did often that are now harder to
do. The only things I used on the homepage were:
1. Going to the "In Progress" and "Open" commitfest (usually with one
of the links that filter for patches related to me).
2. Going to the most-recently "Closed" commitfest to move/close my
previously submitted patches.
3. Search for commitfest entries by Message-ID

I agree that the new homepage now hides the hierarchy of the site, but
I'd say that most people using it probably don't really have to know
about that hierarchy. At least not care so much that it should be on
the initial page. I definitely have never clicked on a link for a
commitfest that's older than a year.

How does one get back to the old homepage? I figured it out, you click
the "Archive" button. Why is that a button? Also, the row of buttons
is now seemingly a mix of actions on the current commit fest mixed with
site navigation.

That's primarily to mirror the style of the commitfest page a bit.
i.e. Most of the buttons there are also links, i.e. "New patch" and
all the items under "Shortcuts"

See above, what is the hierarchy of information and
the context of actions. This is a bit confusing.

I do agree that it would be nicer to separate them. I'll look into
improving/replacing the navigation bar. But do you think these buttons
are so confusing, that this new homepage should be blocked on that?

On 2025-Mar-04, Jelte Fennema-Nio wrote:

1. Major change: The homepage is revamped completely! It now shows a
dashboard of open patches where you are author/reviewer/committer if
you are logged in. These patches are ordered & grouped in a hopefully
useful way. If you're not logged in it will show you the current
commitfest. See screenshot for an example. The old list of all
commitfests is moved to the /archive (which has a button on the
homepage).

I think showing different pages on the same URL depending on whether
you're logged in or not is not great UX. The idea of this dashboard
sounds very good to me, but it shouldn't replace the initial page (list
of commitfests). Maybe put this in a URL such as
https://commitfest.postgresql.org/you
or
https://commitfest.postgresql.org/me
or something easily reachable like that.

This also allows you to provide a standardized URL for one to look at
the activities of others, so if I visit
https://commitfest.postgresql.org/you/petere
I can see Peter's stuff.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Tom: There seems to be something broken here.
Teodor: I'm in sackcloth and ashes... Fixed.
/messages/by-id/482D1632.8010507@sigaev.ru

On Tue, Mar 4, 2025 at 4:05 PM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:

On 2025-Mar-04, Jelte Fennema-Nio wrote:

1. Major change: The homepage is revamped completely! It now shows a
dashboard of open patches where you are author/reviewer/committer if
you are logged in. These patches are ordered & grouped in a hopefully
useful way. If you're not logged in it will show you the current
commitfest. See screenshot for an example. The old list of all
commitfests is moved to the /archive (which has a button on the
homepage).

I think showing different pages on the same URL depending on whether
you're logged in or not is not great UX.

+1. The default should be what we see today, and there should be some
way to see the patches in which a particular person is involved.

--
With Regards,
Amit Kapila.

On Tue, 4 Mar 2025 at 13:36, Amit Kapila <amit.kapila16@gmail.com> wrote:

On Tue, Mar 4, 2025 at 4:05 PM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:

I think showing different pages on the same URL depending on whether
you're logged in or not is not great UX.

+1. The default should be what we see today, and there should be some
way to see the patches in which a particular person is involved.

I'm quite surprised that people seem to love the content of the
current homepage so much. Could someone explain why they want to see
this full list of commitfests as the first page you see? I feel like
I'm missing something here.

To be clear, I'm totally fine with moving the dashboard to a different
URL, definitely for now at least. But I personally would like to have
a homepage that shows me information that I come to the site to see,
not just a bunch of links to which a new link gets added each month.

Also having a homepage that shows completely different info for logged
in users and non-logged in users is pretty common. e.g. GitHub shows
you a similar dashboard when you're logged in, but shows a page with
generic information and a signup/signin link when you're not.

On Tue, Mar 4, 2025 at 5:35 AM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:

The idea of this dashboard
sounds very good to me, but it shouldn't replace the initial page (list
of commitfests). Maybe put this in a URL such as
https://commitfest.postgresql.org/you
or
https://commitfest.postgresql.org/me
or something easily reachable like that.

+1 for this design.

I did think putting something on the home page was reasonable when I
first heard about it, but I think this is a better idea.

--
Robert Haas
EDB: http://www.enterprisedb.com

On 04.03.25 02:21, Jelte Fennema-Nio wrote:

6. The "latest email" column now shows "time since" (e.g. 1 week ago)
instead of an exact timestamp. You can still see the exact timestamp
by hovering over the cell.

Another small complaint: I don't like this style of relative times. (I
have also complained about it for the buildfarm status in the past.) I
suppose both styles are useful like 50% of the time, but I'll tell you
some of my reasoning:

1) It is often more useful to eyeball whether a patch was last updated
in 2025-01-XX or 2025-02-XX or 2025-03-XX. It doesn't really matter how
many days or weeks that was, it matters more where in the commitfest
cadence the update happened.

2) Similarly, for recently updated entries it is more useful to see
whether something was updated this week or last week. "3 days ago"
could be earlier this week, or last week, or just before the weekend, so
effectively 1 day ago. This is sometimes useful, and the relative
specification hides that.

3) The mental overhead of analyzing something like "3 months, 3 weeks
ago", which is non-decimal, negative, and does not consistently align
vertically, is just a lot.

On Tue, 4 Mar 2025 at 16:29, Peter Eisentraut <peter@eisentraut.org> wrote:

Another small complaint: I don't like this style of relative times. (I
have also complained about it for the buildfarm status in the past.) I
suppose both styles are useful like 50% of the time, but I'll tell you
some of my reasoning:

So it's currently using Django its default "timesince" function. I
think we can probably modify that a bit to fit better with the
commitfest purpose.

1) It is often more useful to eyeball whether a patch was last updated
in 2025-01-XX or 2025-02-XX or 2025-03-XX. It doesn't really matter how
many days or weeks that was, it matters more where in the commitfest
cadence the update happened.

I'm not entirely sure what your intent here is. Do you actually just
want to know the month part, then Dec, Jan, Feb could work.

Or are you using the month part as a proxy for knowing how many
commitfests ago the last update was. If so, what would be good
descriptions then? And when would the cutoff from relative times be
for these more coarse descriptions? e.g. use "ago" if something is
less than a month ago. And then go for commitfests, instead of months.
So 1 commitfest ago, 2 commitfests ago etc.

2) Similarly, for recently updated entries it is more useful to see
whether something was updated this week or last week. "3 days ago"
could be earlier this week, or last week, or just before the weekend, so
effectively 1 day ago. This is sometimes useful, and the relative
specification hides that.

How about simply using the names of the week days instead of n days
ago. So on a Wednesday each previous day would be called the
following:
- yesterday
- last Monday
- last Saturday
- last Sunday
- last Friday
- last Thursday
- 1 week ago

3) The mental overhead of analyzing something like "3 months, 3 weeks
ago", which is non-decimal, negative, and does not consistently align
vertically, is just a lot.

Yeah, I agree with this. Two levels of precision is a bit excessive.
Although I'm not sure that the alignment problem actually applies
because this column is right-aligned.

I'll make sure to remove that.

On 04.03.25 11:33, Jelte Fennema-Nio wrote:

I'm curious if there was anything specific that you used the old
homepage for. Especially things you did often that are now harder to
do. The only things I used on the homepage were:
1. Going to the "In Progress" and "Open" commitfest (usually with one
of the links that filter for patches related to me).
2. Going to the most-recently "Closed" commitfest to move/close my
previously submitted patches.
3. Search for commitfest entries by Message-ID

I agree that the new homepage now hides the hierarchy of the site, but
I'd say that most people using it probably don't really have to know
about that hierarchy. At least not care so much that it should be on
the initial page. I definitely have never clicked on a link for a
commitfest that's older than a year.

I think the option of having a list of things that I'm involved in as an
author *or* reviewer is actually very useful and something I have wanted
from time to time. But that is apparently not accessible using the
normal search/filter mechanism, because that is *and*. If that were
somehow available, then I could just bookmark something like

commitfest.postgresql.org/current/?author=-3&reviewer=-3&option=or

You could even, if people like this overall idea, make this a redirect
from commitfest.postgresql.org/. Because then I have context and this
makes sense in the hierarchy of the site, and I can work from there to
adjust the filters.

The problem now is that the home page is a unicorn. You can't get to
that listing in any other way, and you can't make similar listing by
starting from that listing and making adjustments to the filter.

I still think, however, that the homepage should provide overview and
not bombard you with too much content immediately. What is a
commitfest, which commitfest exists, how many have existed, when is the
next one, is there a next one, I think that helps people get context.
After all, we want them to get used to the system and stick around.

Another possible concern is that if you log in and have no patches and
have not signed up to review anything, then the default listing just
show you nothing?

How does one get back to the old homepage? I figured it out, you click
the "Archive" button. Why is that a button? Also, the row of buttons
is now seemingly a mix of actions on the current commit fest mixed with
site navigation.

That's primarily to mirror the style of the commitfest page a bit.
i.e. Most of the buttons there are also links, i.e. "New patch" and
all the items under "Shortcuts"

Ok, but "New patch" still feels like an action, and "Shortcuts" is a
drop-down. But "Archive" is really just a link to a different page
without any (current or future) state changes. You could also imagine
"Archive" as an action, like "archive this", in which case a button
would be more appropriate.

On Mon, Mar 3, 2025 at 8:21 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:

1. Major change: The homepage is revamped completely! It now shows a
dashboard of open patches where you are author/reviewer/committer if
you are logged in. These patches are ordered & grouped in a hopefully
useful way. If you're not logged in it will show you the current
commitfest. See screenshot for an example. The old list of all
commitfests is moved to the /archive (which has a button on the
homepage).

This looks very much like what I had in mind. Thanks!

Peter Geoghegan suggested adding a "dashboard" of this
kind. Feedback on this is very welcome, but depending on the
complexity I don't know when I'll get to it. I'll be a bit more busy
the next few weeks and also have some holidays planned.

But here you say that you *haven't* worked on what I had in mind,
which is confusing.

Are you saying that you have yet to implement a version of this that
shows everything (every patch that isn't closed out) for all
commitfests? What you've come up with only works for the current
commitfest, and not the next one?

--
Peter Geoghegan

On Tue, 4 Mar 2025 at 17:31, Peter Geoghegan <pg@bowt.ie> wrote:

Peter Geoghegan suggested adding a "dashboard" of this
kind. Feedback on this is very welcome, but depending on the
complexity I don't know when I'll get to it. I'll be a bit more busy
the next few weeks and also have some holidays planned.

But here you say that you *haven't* worked on what I had in mind,
which is confusing.

Are you saying that you have yet to implement a version of this that
shows everything (every patch that isn't closed out) for all
commitfests? What you've come up with only works for the current
commitfest, and not the next one?

I meant to say: I roughly implemented what Peter G described... Ideas
to further improve it are very welcome, but it might take a while
until I'm able to do that.

On Tue, Mar 4, 2025 at 12:02 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:

On Tue, 4 Mar 2025 at 17:31, Peter Geoghegan <pg@bowt.ie> wrote:

Peter Geoghegan suggested adding a "dashboard" of this
kind. Feedback on this is very welcome, but depending on the
complexity I don't know when I'll get to it. I'll be a bit more busy
the next few weeks and also have some holidays planned.

But here you say that you *haven't* worked on what I had in mind,
which is confusing.

Are you saying that you have yet to implement a version of this that
shows everything (every patch that isn't closed out) for all
commitfests? What you've come up with only works for the current
commitfest, and not the next one?

I meant to say: I roughly implemented what Peter G described... Ideas
to further improve it are very welcome, but it might take a while
until I'm able to do that.

Got it.

From the looks of the screen shot that you posted (can't seem to find
the same dashboard view on https://commitfest-test.postgresql.org?),
this is *exactly* what I had in mind -- I don't know what I said that
you haven't fully taken into account here? It's just a screen shot,
but as far as it goes it looks great.

Did you mean that you have general doubts about the general quality of
the dashboard code? As in, the code itself is rough? Seems unlikely
that that was what you meant, since you also seemed to say that you're
planning another release (i.e. deploying to production) on March 18.

I'm fairly neutral on the question of whether or not the homepage
should just be the dashboard for logged in users. Though I do think
it's important that the new dashboard is highly discoverable, so that
people know that it exists without having to be told about it.

It'd be nice if at some point you also added the ability to
star/favorite/like patches -- I'm thinking of something that worked a
little bit like starring a gmail thread. Any such patches would appear
towards the end of the dashboard page, in its own section,
independently of whether I as a user am involved or not involved in
the patch. This would be private information, visible only to the
individual user that favorited the patch -- a mere bookmark.

--
Peter Geoghegan

On 4 Mar 2025, at 17:13, Jelte Fennema-Nio <me@jeltef.nl> wrote:
On Tue, 4 Mar 2025 at 16:29, Peter Eisentraut <peter@eisentraut.org> wrote:

Another small complaint: I don't like this style of relative times. (I
have also complained about it for the buildfarm status in the past.) I
suppose both styles are useful like 50% of the time, but I'll tell you
some of my reasoning:

So it's currently using Django its default "timesince" function. I
think we can probably modify that a bit to fit better with the
commitfest purpose.

My preference would be not have any relative times or dates at all and just
show the date as is.

--
Daniel Gustafsson

On Tue, 4 Mar 2025 at 18:25, Peter Geoghegan <pg@bowt.ie> wrote:

From the looks of the screen shot that you posted (can't seem to find
the same dashboard view on https://commitfest-test.postgresql.org?),

The dashboard is only available if you login. You probably have to
create an account to do so, because the staging auth and prod auth
systems are separate. Then you can mark yourself as author/reviewer of
a few patches to see what it would look like.

this is *exactly* what I had in mind -- I don't know what I said that
you haven't fully taken into account here? It's just a screen shot,
but as far as it goes it looks great.

I think I grouped & ordered things slightly different than you
described. There are 4 groups (all of which are in the screenshot).
And then within each group patches are ordered like this:
1. Lowest max of "failing since", "needs rebase since", "time since
its commitfest was closed" at the top. NULLs (i.e. healthy patches)
are first.
2. If 1 tied (usually nulls) ordered by their commitfest startdate
(most recent startdate first)
3. If 2 ties, then patches are ordered by "most recent email"

So patches with failing CI in the "in progress cf" will sort below
healthy patches in the "open cf". I don't think you necessarily said
that, but this seemed nice to me. And it's easy to spot which patches
are for which CF because of the color coded CF labels.

This kind of sorting is possibly worth tweaking a bit after people
start using this and running into annoyances or unexpected sorts in
practice. Some other thing that's missing is the ability to "filter by
commitfest".

Did you mean that you have general doubts about the general quality of
the dashboard code? As in, the code itself is rough?

Nah, that's not what I meant.

It'd be nice if at some point you also added the ability to
star/favorite/like patches -- I'm thinking of something that worked a
little bit like starring a gmail thread. Any such patches would appear
towards the end of the dashboard page, in its own section,
independently of whether I as a user am involved or not involved in
the patch. This would be private information, visible only to the
individual user that favorited the patch -- a mere bookmark.

Yeah, I had similar ideas.

On Tue, Mar 4, 2025 at 3:06 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:

So patches with failing CI in the "in progress cf" will sort below
healthy patches in the "open cf". I don't think you necessarily said
that, but this seemed nice to me. And it's easy to spot which patches
are for which CF because of the color coded CF labels.

I agree that that's a nice detail. You might as well have a default
sort order that is as useful as possible. But, overall, the important
point to me about this dashboard view is that it emphasizes the actual
workflow of the individual user -- it groups and sorts things that are
definitely relevant to the individual user in one way or another,
based on what they're currently blocking on. In short, it mirrors the
kinds of questions I already tend to ask myself when I'm using the CF
app.

It seems obvious to me that you understand where I'm coming from
already. The things that you added seem like clear improvements,
because they take this general idea further. Prominently placing "Your
still-open patches in a closed commitfest" was a particularly useful
addition that I didn't suggest.

In summary, I have zero complaints about anything I've seen. At least
right now. ;-)

This kind of sorting is possibly worth tweaking a bit after people
start using this and running into annoyances or unexpected sorts in
practice. Some other thing that's missing is the ability to "filter by
commitfest".

It is probably worth tweaking. But I'd consider what you have here to
be a huge improvement.

It'd be nice if at some point you also added the ability to
star/favorite/like patches -- I'm thinking of something that worked a
little bit like starring a gmail thread. Any such patches would appear
towards the end of the dashboard page, in its own section,
independently of whether I as a user am involved or not involved in
the patch. This would be private information, visible only to the
individual user that favorited the patch -- a mere bookmark.

Yeah, I had similar ideas.

Obviously I could bookmark patches myself, using my browser. I don't
think that I'll ever actually do that, though -- I'm likely to just
forget about the bookmarks (they have to be important bookmarks that I
return to again and again, without any reminders). Whereas if I can
star/favorite/like patches, it's unlikely that I'll forget about them
forever -- they'll be on the dashboard view, right at the end. They're
tracked in a way that is just prominent enough to prevent that, but
not so prominent as to cause annoyance (that's the idea, at least).

If I later decide that I actually do want to forget about a patch
forever, then it should be equally easy to unlike/unfollow a patch.
ISTM that there is value in a workflow that makes that into an active
choice.

--
Peter Geoghegan

On Tue, 4 Mar 2025 at 17:15, Peter Eisentraut <peter@eisentraut.org> wrote:

I think the option of having a list of things that I'm involved in as an
author *or* reviewer is actually very useful and something I have wanted
from time to time. But that is apparently not accessible using the
normal search/filter mechanism, because that is *and*.

Yeah I totally agree. It's not so simple as to just add "or" though,
because you would still want e.g. a filter by a patch status to be an
AND.

The problem now is that the home page is a unicorn.

There are two reasons I did that:
1. This new homepage includes open patches from *all* commitfests. And
there's currently no page with that information.
2. I didn't want to risk breaking people's existing workflows in this
final CF of the year. Once people are happy with it, I definitely plan
to also add sorting/filtering (as an option) to the normal commitfest
pages.

and you can't make similar listing by
starting from that listing and making adjustments to the filter.

I think you're either wrong, or I misunderstand what you meant here.
You definitely can filter patches on the homepage using the same
filter controls. It's just AND again on top of the homepage filters.

Another possible concern is that if you log in and have no patches and
have not signed up to review anything, then the default listing just
show you nothing?

Yeah, that's bad. It should at least show some info in that case.

On Tue, 4 Mar 2025 at 11:35, Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:

https://commitfest.postgresql.org/me

I've restored the original homepage and moved this new dashboard
(minus the "Archive" link) to /me:
https://commitfest-test.postgresql.org/me/

On Mon, Mar 3, 2025 at 8:21 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:

As always, please test out the current staging website[1] to give some feedback.
HTTP auth user and password are both pgtest.

So, that worked for me, but then it wants me to log into my
postgreql.org account, and that doesn't seem to work.

Also I wanted to highlight the work Jacob Brazeal is doing again. He
has been working on an AI-powered summarization and patch review
recommendation engine[2]. I definitely recommend people to take a look
at that and leave some feedback.

Thanks for highlighting this.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Tue, Mar 4, 2025 at 3:50 PM Robert Haas <robertmhaas@gmail.com> wrote:

On Mon, Mar 3, 2025 at 8:21 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:

As always, please test out the current staging website[1] to give some feedback.
HTTP auth user and password are both pgtest.

So, that worked for me, but then it wants me to log into my
postgreql.org account, and that doesn't seem to work.

Same here. I'd quite like to see the dashboard view for myself (not
just a screenshot), so it'd be nice to figure this out.

Also I wanted to highlight the work Jacob Brazeal is doing again. He
has been working on an AI-powered summarization and patch review
recommendation engine[2]. I definitely recommend people to take a look
at that and leave some feedback.

Thanks for highlighting this.

I tried this out, and was pleasantly surprised to see what seemed like
useful summaries of discussions that I was directly involved in.

For example, the thread about adding "Index Searches: N" to EXPLAIN
ANALYZE that we were involved with was summarized as:

"Main Issue: The main outstanding issue is where to store the state
that tracks the number of index searches (IndexScanDesc, BTScanOpaque,
or a global counter)."

This single line summary was spot on. The summary of my nbtree skip
scan patch series was also quite good.

I'm not sure if I'll ever actually use this tool day to day, or even
week to week. But I just might. In any case I'm glad that somebody is
experimenting with it.

--
Peter Geoghegan