Hi Marc-André, I find this feedback very interesting :-)
As PG is a sophisticated piece of high-quality software, if that process works for them, then it may deserve trying on our side as well. Regards Antoine. Le 04/02/2019 à 12:03, M.-A. Lemburg a écrit : > I've attended FOSDEM over the weekend, where Jon Conway (one of the > PostgreSQL committers) gave a talk about, among other things, the > PG community and how it is structured: > > https://fosdem.org/2019/schedule/event/postgresql11/ > (the community part starts at around 8 min into the video) > > What struck me as interesting is that they have seen and addressed > the review bottleneck problem we're having in Python development > years ago. > > They have a core team, which pretty much resembles the steering > committee we've just voted on, with 5 members, and a group of > 28 committers. Things are much less formalized than in Python > land, but they are making great progress. > > Here's their approach to solve the review bottleneck: > > https://wiki.postgresql.org/wiki/PostgreSQL_8.4_Development_Plan > (they started this in 2008) > > with what they call "commit fests". This is a process where people > submit patches using timed slots, each author is requested to do > at least one review of another patch of similar complexity and > the authors can fix their patches as part of the review process > to get them to a level where a core dev can than take a look. > Other people can sign up as reviewers as well. > > That way the initial load of making sure the patch quality is > appropriate is scaled up a lot and their core devs only have to > deal with patches which already have passed reviews by a few > people. > > The process is described in more detail in this blog post: > > https://blog.2ndquadrant.com/managing-a-postgresql-commitfest/ > (with the experience after doing this for 8 years) > > To help them with the commit fests, they have a system in place > to manage the patches: > > https://commitfest.postgresql.org/ > > See e.g. https://commitfest.postgresql.org/22/ for the next > upcoming commit fest. > > Commit fests are done for one month each, and then leave one > month for things to settle in, get core dev responses. Patches > can be pushed back to the next commit fest in case a core dev > finds them lacking or the author doesn't respond in time. > > I also talked to Magnus Hagander, one of the PG core team members, > about their core team. They have had this since the early 2000s > and interestingly, they are mostly dealing with non-developer > questions. Their approach to decisions such as the PEP process > we have is mostly based on consensus and trust among the committers, > not formalized and thus the core team does not play into this > a lot. > > https://www.postgresql.eu/events/pgdayparis2018/schedule/speaker/1-magnus-hagander/ > > Now, all that said, while there are many similarities between > PostgreSQL and Python in how the communities work, PG does take > a more conservative approach to things - most committers and > core team members have had that status for at least 10 years, > it typically takes several years to gain committer status and > they rarely take on new people. > > Still, I think there's a lot we can learn from them and their > experience with solving the review problem. > > Thanks, > _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
