Hi, tl;dr: If you want to expand the list of committers rapidly, would it make sense to have a sand-box repo for new committers which trusted committers could channel cherry-picks from? Pick your bugaboo, but I consider plausible that some volunteering committers are there on paid job assignment serving some agenda which you can't easily discover. Well, that can be good and normal with FLOSS-enlightened emplayers, but one can imagine not-so-benevolent assignments... (pick your concept of benevolence :) On +2023-03-02 12:04:44 +0100, Andreas Enge wrote: > Hello, > > in the current situation I think the suggestion is putting the horse before > the cart. In a first step before adding policy, we should make the teams > functional. While working on core-updates, I have been realising we are > already spread too thin: Some important languages have teams with one or > two members, who would effectively become bottlenecks. Other software has > no team (Qt/KDE). All in all, I also think we have too few committers. > Adding policy might completely stall the project... > > If for every trivial update of a Python package we need not only submit a > patch to the bugtracker, wait for QA, get back to the patch, resign it, > push it and close the bug, but additionally wait for one of the two Python > team members to have a look at it (or let an additional week pass), > incentives to participate will tend to zero. > > Your suggested policy can help against commits of too bad quality; but I > do not think this is our problem, our problem is rather a lack of fast > progress. > > So I think we need to add committers, add committers to teams, encourage > teams to engage in work, and if everything works smoothly, maybe add policy. > > Andreas > > -- Regards, Bengt Richter