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

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/

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.
                               http://postgr.es/m/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

On 3/4/25 2:30 PM, Jelte Fennema-Nio wrote:
> 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.

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

On Tue, 4 Mar 2025 at 21:57, Peter Geoghegan <pg@bowt.ie> wrote:
>
> 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.


You have to create a *new* 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.

On Tue, Mar 4, 2025 at 4:02 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:
> You have to create a *new* 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.

How do I do that? Or can I do it?

--
Peter Geoghegan

On Tue, 4 Mar 2025 at 22:04, Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Tue, Mar 4, 2025 at 4:02 PM Jelte Fennema-Nio <me@jeltef.nl> wrote:
> > You have to create a *new* 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.
>
> How do I do that? Or can I do it?

Yes, the text above the login form contains "create" link to the
account creation page:
https://test.postgresql.org/account/signup/

On Tue, Mar 4, 2025 at 4:38 PM Jacob Brazeal <jacob.brazeal@gmail.com> wrote:
> Out of curiosity, what features would make it most useful to you? Right now it's trying to do all of the following:
> * Summarize threads
> * Help you find threads about things you're interested in, independent of what you've commented on
> * Help you find threads that need a review
> * Help you find threads to commit, if you're a committer.

Those are useful goals. The difficulty is putting it all into action.

> I think the UX is a bit confusing right now and it might not be obvious how to do all of these things. For example,
> I think your default view right now is mostly showing you patches you wrote, which is a bit of an accident (if you
> scroll down, you'll see some patches you didn't author, but are probably relevant to you.)

It'd be nice if the UI had usable hyperlinks that could be bookmarked
by my browser. One hyperlink for each of the views.

> I think we can fix all of this up in the UX, but my question to you might be:
> * What would a good default view be?

Probably "Recommended patches for you to check". Things that are on
the periphery of my interests have the greatest chance of being picked
up, I think.

> * What filters would be useful to you?

Nothing comes to mind.

> * How could we optimize your patch-review workflow, in general?

I guess it would be nice if the tooling could figure out which commits
ultimately came from a given closed-out CF entry -- without requiring
the user to update that manually when they go to mark an entry as
committed. Attributing a commit or commits to a given closed out CF
entry is squishy at times, but it wouldn't have to be perfect.

Perhaps it would be possible for the tooling to attribute bug fixes to
particular commits, where the bug first appears. That isn't always
possible, even for a human expert. But it is often fairly obvious,
even to a non-expert.

I have no idea how feasible any of this is, or what the constraints
really are. These suggestions are made based on some fairly optimistic
assumptions about how hard this would be to put into action. These are
just nice-to-haves for me, so if it was a great deal of work then it
seems hard to justify.

--
Peter Geoghegan

On Tue, 4 Mar 2025 at 20:46, Daniel Gustafsson <daniel@yesql.se> wrote:
> My preference would be not have any relative times or dates at all and just
> show the date as is.

I pushed a change that both improves the rendering of relative
datetimes and also allows people to choose to disable that and just
show the date as is. This can be configured in /account/profile/ (see
screenshot for what this looks like).

> On 4 Mar 2025, at 23:49, Jelte Fennema-Nio <me@jeltef.nl> wrote:
>
> On Tue, 4 Mar 2025 at 20:46, Daniel Gustafsson <daniel@yesql.se> wrote:
>> My preference would be not have any relative times or dates at all and just
>> show the date as is.
>
> I pushed a change that both improves the rendering of relative
> datetimes and also allows people to choose to disable that and just
> show the date as is.

Thanks, that works for me.

--
Daniel Gustafsson

On Tue, 4 Mar 2025 at 22:01, Andreas Karlsson <andreas@proxel.se> wrote:
> 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
> able to quickly navigate to the open, the in progress and the latest
> closed one.

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.

On 3/5/25 12:14 AM, Jelte Fennema-Nio wrote:
> On Tue, 4 Mar 2025 at 22:01, Andreas Karlsson <andreas@proxel.se> wrote:
>> 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 ...

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.

>> and to be
>> able to quickly navigate to the open, the in progress and the latest
>> closed one.
> 
> 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.

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

Andreas

On 04.03.25 21:37, Jelte Fennema-Nio wrote:
> 1. This new homepage includes open patches from*all* commitfests. And
> there's currently no page with that information.

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.

Peter Eisentraut <peter@eisentraut.org> writes:
> On 04.03.25 21:37, Jelte Fennema-Nio wrote:
>> 1. This new homepage includes open patches from*all* commitfests. And
>> there's currently no page with that information.

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

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

On Thu, 6 Mar 2025 at 18:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Eisentraut <peter@eisentraut.org> writes:
> > On 04.03.25 21:37, Jelte Fennema-Nio wrote:
> >> 1. This new homepage includes open patches from*all* commitfests. And
> >> there's currently no page with that information.
>
> > 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.
>
> 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.

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
> will *never* go away until somebody closes them explicitly.

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.

On Tue, 4 Mar 2025 at 02:21, Jelte Fennema-Nio <me@jeltef.nl> 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.

On 17.03.25 23:11, Jelte Fennema-Nio wrote:
> 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.

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

Peter Eisentraut <peter@eisentraut.org> writes:
> 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].

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?

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

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

            regards, tom lane

On Fri, 21 Mar 2025 at 18:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Eisentraut <peter@eisentraut.org> writes:
> > - 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.

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.

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

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.

> > - 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.
>
> This might make sense for the patch author, but I agree it's not
> 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.

On Sat, Mar 22, 2025 at 7:15 AM Jelte Fennema-Nio <me@jeltef.nl> wrote:
> 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.

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

> > > - 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.
> >
> > This might make sense for the patch author, but I agree it's not
> > 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.

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
> the following:

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

Peter Geoghegan <pg@bowt.ie> writes:
> On Sat, Mar 22, 2025 at 7:15 AM Jelte Fennema-Nio <me@jeltef.nl> wrote:
>> Yeah I think we need a way to "star" a patch (not just for committers,
>> but for anyone).

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

+1

> Personally, I think it'd be most useful for the dashboard to show all
> 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

On Sat, Mar 22, 2025 at 10:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Personally, I think it'd be most useful for the dashboard to show all
> > 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".

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.

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

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.

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

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

On 22.03.25 12:15, Jelte Fennema-Nio wrote:
> On Fri, 21 Mar 2025 at 18:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Peter Eisentraut <peter@eisentraut.org> writes:
>>> - 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.
> 
> 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.

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.

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

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.

>>> - 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.
>>
>> This might make sense for the patch author, but I agree it's not
>> 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.