Subject: Next commitfest app release is planned for March 18th

From: Jelte Fennema-Nio <[email-masked]>
Date: Tue, 4 Mar 2025 02:21:18 +0100

The next commitfest app release is planned for March 18th and will
contain the following changes:

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.
2. Show name of a committer in the "Committer" column (instead of only
the username).
3. Fix the "Review" form so that all checkboxes can actually be
clicked. Thanks to Maciek.
4. Allow sorting patches by "failing since", this can be done by
clicking the header. This does *not* work on the staging website,
because CFbot is not sending CI updates there currently.
5. Remove "latest activity" column. This did not contain useful information.
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.
7. Searching patches by author/reviewer now isn't a dropdown with a
ton of options, but instead has become a dropdown with a search box.
This also greatly improves page load performance: By not putting all
users in the HTML as a dropdown option it's saving 600-700ms in my
testing on staging.
8. Bugfix: Correctly show CI timeout as failure.

One thing I'm wondering about 3 though: Do people actually think these
checkboxes are even useful in the first place? For people not
familiar, they add these lines to an email:
> make installcheck-world:  tested, passed
> Implements feature:       tested, passed
> Spec compliant:           not tested
> Documentation:            tested, passed

At least the first one seems not very useful, now that we have the
CFBot. Is the rest useful to anyone or do these buttons just result in
clutter.

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

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.

[1]: https://commitfest-test.postgresql.org/
[2]: https://patchwork-three.vercel.app/

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 4 Mar 2025 10:22:33 +0100

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

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Tue, 4 Mar 2025 11:33:13 +0100

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

> 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

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?

---

From: Álvaro Herrera <[email-masked]>
Date: Tue, 4 Mar 2025 11:34:58 +0100

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

> 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.
                               http://postgr.es/m/[email-masked]

---

From: Amit Kapila <[email-masked]>
Date: Tue, 4 Mar 2025 18:05:55 +0530

On Tue, Mar 4, 2025 at 4:05 PM Álvaro Herrera <[email-masked]> wrote:
> 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.

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Tue, 4 Mar 2025 14:30:21 +0100

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

---

From: Robert Haas <[email-masked]>
Date: Tue, 4 Mar 2025 09:26:40 -0500

On Tue, Mar 4, 2025 at 5:35 AM Álvaro Herrera <[email-masked]> wrote:
> The idea of this dashboard

+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

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 4 Mar 2025 17:15:24 +0100

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

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

---

From: Peter Geoghegan <[email-masked]>
Date: Tue, 4 Mar 2025 11:31:01 -0500

> commitfests is moved to the /archive (which has a button on the

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

> Peter Geoghegan suggested adding a "dashboard" of this

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

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Tue, 4 Mar 2025 18:02:25 +0100

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

---

From: Peter Geoghegan <[email-masked]>
Date: Tue, 4 Mar 2025 12:25:10 -0500

> 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

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Tue, 4 Mar 2025 21:06:29 +0100

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

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

> the dashboard code? As in, the code itself is rough?

Nah, that's not what I meant.

> individual user that favorited the patch -- a mere bookmark.

Yeah, I had similar ideas.

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Tue, 4 Mar 2025 21:37:58 +0100

On Tue, 4 Mar 2025 at 17:15, Peter Eisentraut <[email-masked]> wrote:
> 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

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.

> have not signed up to review anything, then the default listing just

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

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Tue, 4 Mar 2025 21:42:58 +0100

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

---

From: Robert Haas <[email-masked]>
Date: Tue, 4 Mar 2025 15:50:03 -0500

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

> at that and leave some feedback.

Thanks for highlighting this.

---

From: Andreas Karlsson <[email-masked]>
Date: Tue, 4 Mar 2025 22:01:25 +0100

> I'm missing something here.

What I need to see is the below (plus any future commit fests).

2025-07 (Open - 2025-07-01 - 2025-07-31)
2025-03 (In Progress - 2025-03-01 - 2025-03-31)
2025-01 (Closed - 2025-01-01 - 2025-01-31)

I am interested in the dates when commit fests open and close and to be 
able to quickly navigate to the open, the in progress and the latest 
closed one.

It can obviously be displayed in many other ways but the current way is 
pretty convenient.

Andreas

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Wed, 5 Mar 2025 00:14:36 +0100

> What I need to see is the below (plus any future commit fests).

Thanks you for describing how you use the current homepage. That's
super helpful.

> I am interested in the dates when commit fests open and close

These are the same exact 5 months every year. Maybe the homepage
should contain some basic, mostly static, info at the top like:

There are 5 commitfests for each PostgreSQL release. They take place
in the months July (the first of the development cycle), September,
November, January and March (the last before the feature freeze). A
commitfest lasts for the full month. Patches can be submitted to a
commitfest before that month has started. After a commitfest has
started new patches need to be registered for the following
commitfest. The .../No commitfest is currently in progress. The next
commitfest starts on ...

> and to be

Could you elaborate why you want to navigate to the latest closed one?
Is that to move your own patches (or ones that you are reviewing) over
to the next one? If so it sounds like that would not be necessary
anymore with the new dashboard page. If you have some other reason I'm
very curious to know.

---

From: Andreas Karlsson <[email-masked]>
Date: Wed, 5 Mar 2025 01:24:40 +0100

> commitfest. The .../No commitfest is currently in progress. The next

Yup, and I and other (in my case formerly; since this January) 
non-professional PostgreSQL developers have no chance to remember when 
the commit fests are. And I suspect some of the professionals don't 
always remember. :) And this is data I have often wanted.

> anymore with the new dashboard page. If you have some other reason I'm

Yes, to move patches over to the next commit fest.

Andreas

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 6 Mar 2025 17:11:49 +0100

On 04.03.25 21:37, Jelte Fennema-Nio wrote:
> 1. This new homepage includes open patches from*all* commitfests. And

Ok, that's interesting, but I'm even less sure why that should be the 
default view.  The whole point of chunking things into commitfests is to 
have a focused view on what to do now and what to do later.

---

From: Tom Lane <[email-masked]>
Date: Thu, 06 Mar 2025 12:08:23 -0500

> have a focused view on what to do now and what to do later.

Indeed, that choice seems completely astonishing.  You just kicked to
the curb all of the discussion at FOSDEM about how patches shouldn't
be carried forward automatically.  Effectively this means patches
will *never* go away until somebody closes them explicitly.

			regards, tom lane

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Thu, 6 Mar 2025 18:27:35 +0100

On Thu, 6 Mar 2025 at 18:08, Tom Lane <[email-masked]> wrote:
> be carried forward automatically.

I see where you're coming from, but I think you're exaggerating a bit.
The commitfest that each patch is part of is visible in the CF column
on the new page. Patches from old commitfests color-coded red, and are
sorted below new patches from future commitfests, which are again
sorted below patches of the active commitfest. Your own old patches
that you are supposed to move/close are shown at the top of your page,
to remind authors to actually do that.

To be clear: This new view does not replace the homepage anymore, it's
now a separate /me page.

> Effectively this means patches

True, but it will also cause authors to actually close/move those
patches explicitly. And if an author doesn't close/move their patch in
an old commitfest for some time, it seems completely reasonable for
someone else to close that patch as Withdrawn/Rejected (or maybe a new
status like Inactive). I'd say let's try this new view out like this
and see what problems people actually have when using it. Especially
since this is in addition to the existing views, not replacing
anything.

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Mon, 17 Mar 2025 23:11:15 +0100

On Tue, 4 Mar 2025 at 02:21, Jelte Fennema-Nio <[email-masked]> wrote:
>
> The next commitfest app release is planned for March 18th

I deployed the latest release of the commitfest app. Below is a
changelog that's slightly updated.

1. Major change: There's a new /me page which shows a dashboard of
open patches where you are author/reviewer/committer. These patches
are ordered & grouped in a hopefully useful way. Peter Geoghegan
suggested adding a "dashboard" of this kind. It's the first attempt
and can probably use some fine tuning based on feedback. So please try
it out and let me know what you think. I almost certainly won't have
time to make big changes to it in the next ~month though.
2. Show name of a committer in the "Committer" column (instead of only
the username).
3. Fix the "Review" form so that all checkboxes can actually be
clicked. Thanks to Maciek.
4. Allow sorting patches by "failing since", this can be done by
clicking the header. This will take a few days to work correctly,
since a "failing since" timestamp was not being collected before.
5. Remove the "latest activity" column. This did not contain useful
information, that "latest email" didn't already provide.
6. The "latest email" column now shows "time since" (e.g. 1 week ago)
by default instead of an exact timestamp. You can still see the exact
timestamp by hovering over the cell. If you prefer to see the exact
timestamp only, you can change this as a setting using the "edit
profile" link in the top right corner.
7. Searching patches by author/reviewer now isn't a dropdown with a
ton of options, but instead has become a dropdown with a search box.
This also greatly improves page load performance: By not putting all
users in the HTML as a dropdown option it's saving 600-700ms in my
testing.
8. Bugfix: Correctly show CI timeout as failure.

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 21 Mar 2025 17:41:03 +0100

On 17.03.25 23:11, Jelte Fennema-Nio wrote:
> and can probably use some fine tuning based on feedback.

Thanks, this is very promising.

I have a few pieces of feedback that could be addressed by additional 
rules for how things are listed in the dashboard:

- If I'm the committer for a patch but not a reviewer, and the patch is 
in "needs review" status, then the patch is formally speaking not 
actionable by me and should not be under "Patches that are ready for 
your review".  Perhaps it should be under "Blocked on others" [namely 
the reviewers], or in a different category.

- Conversely, if I'm the reviewer for a patch but not the committer, and 
the patch is in "ready for committer" status, then it's also not 
"Patches that are ready for your review".  This might similarly be 
"Blocked on others" [namely the committer].

- Also, my dashboard shows patches from past and future commitfests.  I 
don't know what I'm supposed to do with that.  The purpose of having a 
"current" commitfest is that you work on that one when it's current. 
The patches in past and future commitfests were presumably put there for 
reasons that mean that they are not currently to be worked on as a priority.

(I'm probably not representative, but my current dashboard has a 
somewhat low hit ratio because of the above points.)

---

From: Tom Lane <[email-masked]>
Date: Fri, 21 Mar 2025 13:53:27 -0400

> "Blocked on others" [namely the committer].

Both of these things would work correctly only for patches that you
have already claimed as committer.  I'm not sure about other people,
but I rarely claim a patch as committer until I'm actually on the
verge of committing it.  I might mark myself as reviewer sometime
sooner than that, in which case your second proposal would be a
net negative for me.  I don't think we should encourage committers
to claim patches early, because then they are a single point of
failure (work-stoppage) in a way that a reviewer is not.  Maybe
we need a way for committers to mark patches as things they want
to pay attention to, without thereby blocking other committers
from taking up the patch?

> "current" commitfest is that you work on that one when it's current. 

This might make sense for the patch author, but I agree it's not
appropriate for anyone else.

			regards, tom lane

---

From: Jelte Fennema-Nio <[email-masked]>
Date: Sat, 22 Mar 2025 12:15:45 +0100

> > the reviewers], or in a different category.

I think I agree with this... but is that actually a common situation?
I'd expect people to mostly "claim a patch as committer" when it's in
the "ready for committer" state.

> net negative for me.

I think probably a nice intermediary solution would be to handle
patches with an assigned committer differently. If a committer
assigned themselves as committer and it's "ready for committer", then
I don't think it should be marked as "ready for your review" for other
committers. If there's no committer, I think it should be, because
*some committer* needs to review the patch but it's unknown which one.

> I don't think we should encourage committers

Yeah I think we need a way to "star" a patch (not just for committers,
but for anyone). After creating this initial version of this dashboard
I realized it's also possible to "subscribe to updates" for a patch,
which means you'll get emails about it. I think if you "subscribe for
updates" you should also see it in your dashboard (which you currently
don't). But I also think there should be a way to "star" something, so
you see it in your dashboard without receiving email updates about it.

> appropriate for anyone else.

I'd love to hear some more thoughts on this. Especially from Peter G,
because he explicitly requested to see patches from different
commitfests in this dashboard. So I'm curious about his reasoning.
Ofcourse we can make this configurable or have two separate pages, but
I'm wondering if there's a way to change it in a way that works for
everyone.

Instead of showing all patches from all commitfests, how about we do
the following:
1. Show all open patches where you are the author, no matter which
commitfest they are in.
2. If there's currently no commitfest "In Progress", then we show all
patches (where you are not the author) both from the Previous
commitfest and the Open commitfest. I think it would be a shame if
everyone's dashboard is empty in the first week after a commitfest,
just because authors haven't moved their patches over to the Open
commitfest.
3. If there's a commitfest "In Progress", then we only show patches
(where you are not the author) from the "In Progress" commitfest to
keep reviews focussed.
4. Have a separate section at the bottom of the page with all the
patches that you are tracking, but are not matching one of the
criteria from the three rules above.

---

From: Peter Geoghegan <[email-masked]>
Date: Sat, 22 Mar 2025 10:31:17 -0400

> you see it in your dashboard without receiving email updates about it.

Right. In my view "starring" something should definitely not appear in
the "History Log" of the patch; it should be private.

> I'm wondering if there's a way to change it in a way that works for

Personally, I think it'd be most useful for the dashboard to show all
open patches. I believe that that implies that it'll only show me
patches from either the current CF, or the next CF. But thinking about
it some more...I guess that there are edge-cases, where patches can be
in limbo between being "fully open" and "fully closed". Like when a
patch from an old CF isn't brought forward, and also isn't
withdrawn/returned.

I think that we should apply an expansive definition of "active", that
still shows me things that are less than 100% officially closed.
Possibly with additional visual cues that they're in this in
between/limbo state.

> Instead of showing all patches from all commitfests, how about we do

I think that we should show all patches from all commitfests in the
"Personal Dashboard", provided that they're not closed. I probably
don't have enough experience with the current "Personal Dashboard"
yet, but so far it seems like exactly what I had in mind.

If I see something in the "Personal Dashboard" that seems like it
shouldn't be there, due to not being in either the current or next CF,
and am bothered by that, then maybe I should then take it as an
opportunity to fix the problem. As I said, maybe there should be some
additional visual cue that shows certain "Personal Dashboard" entries
are "in limbo". But please don't make entries in this state just
vanish, on the grounds that they're theoretically closed -- experience
suggests that they're probably not really closed at all.

If something appears on my "Personal Dashboard" it appears there
because I actively chose to participate, and hiding things from me on
bureaucratic grounds seems paternalistic.

-- 
Peter Geoghegan

---

From: Tom Lane <[email-masked]>
Date: Sat, 22 Mar 2025 10:49:04 -0400

Peter Geoghegan <[email-masked]> writes:
>> but for anyone).

> the "History Log" of the patch; it should be private.

+1

> open patches.

Surely not "all"?  We have that display already.  Should be more like
"patches that I have expressed an interest in or have reason to take
current or future action on".

In the case of stale patches that haven't been moved forward from a
closed commitfest, perhaps we could compromise on Jelte's suggestion
of putting those in a separate section at the bottom of the page.

However, I still think such patches should be treated differently for
the author than other people.  The author does have current action to
take on the patch, namely moving it forward or withdrawing it.

			regards, tom lane

---

From: Peter Geoghegan <[email-masked]>
Date: Sat, 22 Mar 2025 11:05:29 -0400

> current or future action on".

What I meant was "patches that I have expressed an interest in or have
reason to take current or future action on" should be interpreted in
the broadest/most permissive way possible by the dashboard. In
particular, entries should only *fully* disappear when somebody (some
individual human) has actively chosen to make a representation that
the patch is closed out. The rest (how we present that information) is
details.

> of putting those in a separate section at the bottom of the page.

If there is any gray area, then I very much want us to err on the side
of still showing *something*. I really strongly object to having
things vanish, absent a 100% unambiguous signal that that's what
should happen.

In general, the personal dashboard is (quite usefully) oriented around
what actions you as a user (or some other CF app user) needs to take
-- it is workflow oriented. It seems natural to me to handle stale/in
limbo patches (patches that are not officially closed but also aren't
in the current or next CF) in just the same way -- by presenting the
information in terms of actions that need to be taken by some
individual stakeholder.

> take on the patch, namely moving it forward or withdrawing it.

Right. So maybe for the patch author it appears either under "Your
patches that need changes from you", or in a similar section that's
just for stale patches that need to either be officially dropped or
officially moved forward to an open CF. Whereas it'd be a little
different (but not too different) for somebody who sees a patch
because they're the reviewer/committer of record (the action item for
such a person, if any, is to actually fully close the patch, or to nag
the patch author).

It probably makes sense to make stale/in limbo entries stick out like
a sore thumb. They're *supposed* to be annoying.

-- 
Peter Geoghegan

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 24 Mar 2025 10:55:04 +0100

> the "ready for committer" state.

It's probably not common, but I seem to recall that at the FOSDEM 
developer meeting it was explicitly suggested that committers sign on to 
patches earlier so that authors and reviewers have a better idea of whom 
to target their patches for.  Which is why I started doing that now.

> you see it in your dashboard without receiving email updates about it.

It would be good to able to see subscribed-to patches on the dashboard 
as well.  But let's not create two slightly different mechanisms for this.

>> appropriate for anyone else.

I don't mind seeing them, just not under "patches that are ready for 
your review".  If there were other subheadings like "future patches", 
"patches forgotten in the past" etc. it would be better.