Hi, hackers!
I want to share some stats and thoughts about CF.
***
The first is a graph with the numbers of committed, moved, returned, and rejected CF patches over time - [cf_items_status.png]. Credits to Dmitry Dolgov for sharing his scripts to gather this stat.
***
Besides, I noticed that we have a lot of long-living discussions. And I was curious what is the chance to get something committed after several CFs. The graph is in [num_commitfests.png]. So, most entries make it to release after just one or two commitfests.
I think that the issue here is that the commitfest application now serves two different purposes:
Firstly, we use it to track patches that we want to see in the nearest releases and concentrate our efforts on. And current CFM guideline [1] reflects this idea. It suggests, that after the commitfest closure date we relentlessly throw to RWF patches that got at least some feedback. To be honest, I was reluctant to return semi-ready patches, because it means that they will get lost somewhere in mailing lists. And it seems like other CFMs did the same.
On the other hand, we use Commitfest to track important entries that we want to remember at least once in a while. You can find many examples in the 'Bug Fixes' group of patches. They are too serious to move them to TODO list, yet too complex and/or rare to move on. And such entries simply move from one CF to another.
I wonder if we can improve the workflow somehow? Todo list was recently cleaned up, so maybe we can use it? Or we could add a special 'Backlog' section to the commitfest application.
What do you think?
***
I am also planning to update the CommitFest Checklist:
- remove references to pgsql-rrreviewers;
- add info about cfbot;
- remove the 'Sudden Death Overtime' chapter as it no longer reflects reality.
Thoughts?
[1] https://wiki.postgresql.org/wiki/CommitFest_Checklist#Sudden_Death_Overtime
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
