Re: commitfest.postgresql.org is no longer fit for purpose

> On Thu, May 16, 2024 at 02:30:03PM -0400, Robert Haas wrote:
>
> I wonder what ideas people have for improving this situation. I doubt
> that there's any easy answer that just makes the problem go away --
> keeping large groups of people organized is a tremendously difficult
> task under pretty much all circumstances, and the fact that, in this
> context, nobody's really the boss, makes it a whole lot harder. But I
> also feel like what we're doing right now can't possibly be the best
> that we can do.

There are lots of good takes on this in the thread. It also makes clear what's
at stake -- as Melanie pointed out with the patch about EXPLAIN for parallel
bitmap heap scan, we're loosing potential contributors for no reasons. But I'm
a bit concerned about what are the next steps: if memory serves, every couple
of years there is a discussion about everything what goes wrong with the review
process, commitfests, etc. Yet to my (admittedly limited) insight into the
community, not many things have changed due to those discussions. How do we
make sure this time it will be different?

It is indeed tremendously difficult to self organize, so maybe it's worth to
volunteer a group of people to work out details of one or two proposals,
answering the question "how to make it better?". As far as I understand, the
community already has a similar experience. Summarizing this thread,
there seems to be following dimensions to look at:

* What is the purpose of CF and how to align it better with the community
  goals.

  "CommitFest" here means both the CF tool and the process behind it. So far
  the discussion was evolving around the state machine for each individual CF
  item as well as the whole CF cycle. At the end of the day perhaps a list of
  pairs (item, status) is not the best representation, probably more filters
  have to be considered (e.g. implementing a workflow "give me all the items,
  updated in the last month with the last reply being from the patch author").

* How to synchronize the mailing list with CF content.

  The entropy of CF content grows over time, making it less efficient. For
  especially old threads it's even more visible. How to reduce the entropy
  without scaring new contributors away?

* How to deal with review scalability bottleneck.

  An evergreen question. PostgreSQL is getting more popular and, as stated in
  diverse research whitepapers, the amount of contribution grows as a power
  law, where the number of reviewers grows at best sub-linearly (limited by the
  velocity of knowledge sharing). I agree with Andrey on this, the only
  way I see to handle this is to scale CF management efforts.

* What are the UX gaps of CF tool?

  There seems to be some number of improvements that could make work with CF
  tool more frictionless.

What I think wasn't discussed yet in details is the question of motivation.
Surely, it would be great to have a process that will introduce as less burden
as possible. But giving more motivation to follow the process / use the tool is
as important. What motivates folks to review patches, figure out status of a
complicated patch thread, maintain a list of open items, etc?