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

Dmitry Dolgov <9erthalion6(at)gmail(dot)com> writes:
> 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?

Things *have* changed, if you take the long view. We didn't have
commitfests at all until around 2007, and we've changed the ground
rules for them a couple of times since then. We didn't have the CF
app at all until, well, I don't recall when, but the first few CFs
were managed by keeping patch lists on a wiki page. It's not that
people are unwilling to change this stuff, but that it's hard to
identify what will make things better.

IMV one really fundamental problem is the same as it's been for a
couple of decades: too many patch submissions, too few committers.
We can't fix that by just appointing a ton more committers, at least
not if we want to keep the project's quality up. We have to grow
qualified committers. IIRC, one of the main reasons for instituting
the commitfests at all was the hope that if we got more people to
spend time reading the code and reviewing patches, some of them would
learn enough to become good committers. I think that's worked, again
taking a long view. I just did some quick statistics on the commit
history, and I see that we were hovering at somewhere around ten
active committers from 1999 to 2012, but since then it's slowly crept
up to about two dozen today. (I'm counting "active" as "at least 10
commits per year", which is an arbitrary cutoff --- feel free to slice
the data for yourself.) Meanwhile the number of submissions has also
grown, so I'm not sure how much better the load ratio is.

My point here is not that things are great, but just that we are
indeed improving, and I hope we can continue to. Let's not be
defeatist about it.

I think this thread has already identified a few things we have
consensus to improve in the CF app, and I hope somebody goes off
and makes those happen (I lack the web skillz to help myself).
However, the app itself is just a tool; what counts more is our
process around it. I have a couple of thoughts about that:

* Patches that sit in the queue a long time tend to be ones that lack
consensus, either about the goal or the details of how to achieve it.
Sometimes "lacks consensus" really means "nobody but the author thinks
this is a good idea, but we haven't mustered the will to say no".
But I think it's more usually the case that there are plausible
competing opinions about what the patch should do or how it should
do it. How can we resolve such differences and get something done?

* Another reason for things sitting a long time is that they're too
big to review without an unreasonable amount of effort. We should
encourage authors to break large patches into smaller stepwise
refinements. It may seem like that will result in taking forever
to reach the end goal, but dropping a huge patchset on the community
isn't going to give speedy results either.

* Before starting this thread, Robert did a lot of very valuable
review of some individual patches. I think what prompted him to
start the thread was the realization that he'd only made a small
dent in the problem. Maybe we could divide and conquer: get a
dozen-or-so senior contributors to split up the list of pending
patches and then look at each one with an eye to what needs to
happen to move it along (*not* to commit it right away, although
in some cases maybe that's the thing to do). It'd be great if
that could happen just before each commitfest, but that's probably
not practical with the current patch volume. What I'm thinking
for the moment is to try to make that happen once a year or so.

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

Yeah, all this stuff ultimately gets done "for the good of the
project", which isn't the most reliable motivation perhaps.
I don't see a better one...

regards, tom lane