Changes

* Seen another way, for an identical result in terms of evolution, the workload is multiplied by 2.  

* Seen another way, for an identical result in terms of evolution, the workload is multiplied by 2.  

* Or again, to an identical result in terms of evolution and an identical workload, the quality of stabilization is divided by 2 by releasing 2 times less often.

* Or again, to an identical result in terms of evolution and an identical workload, the quality of stabilization is divided by 2 by releasing 2 times less often.

Today the integration of new PRs is currently deliberately slowed down in order to be able to digest the integrated PRs. Indeed, the bottleneck is mainly in the number of contributors who “correct and stabilize” the integrated PRs. Let's recall the figures, evaluated during a former devcamp: On Dolibarr, for 1 PR of integrated evolution, you need to obtain approximately 2 PR of stabilization fix (2022 evaluation made on Odoo: 2.5, on erpnext: 7)

Today the integration of new PRs is currently deliberately slowed down in order to be able to digest the integrated PRs. Indeed, the bottleneck is mainly in the number of contributors who “correct and stabilize” the integrated PRs. Let's recall the figures, evaluated during a former devcamp: On Dolibarr, for 1 PR of integrated evolution, you need to obtain approximately 2 PR of stabilization fix (2022 evaluation made on Odoo: 2.5, on erpnext: 7).

 

However, today the number of developments proposed and which are integrated is greater than the number of fixes or stabilizations (standardization, security, etc.) proposed while it should be 1 PR out of 3 only to be at the balance (3 = 1 for feature + 2 for stabilization).

However, today the number of developments proposed and which are integrated is greater than the number of fixes or stabilizations (standardization, security, etc.) proposed while it should be 1 PR out of 3 only to be at the balance (3 = 1 for feature + 2 for stabilization).

In short, there is no understaffing on the merge (in fact the workload when you know the app well is quite low) but we will always have an understaffing on the Fixers, Debuggers and Technical Debt Killers that I would call with the initials, the '''FDK'''s for the following (FDKs are those who work, mainly during a beta phase, to make the application stable and/or coherent, correct regressions, but also during the dev phases to reduce technical debt for example).

In short, there is no understaffing on the merge (in fact the workload when you know the app well is quite low) but we will always have an understaffing on the Fixers, Debuggers and Technical Debt Killers that I would call with the initials, the '''FDK'''s for the following (FDKs are those who work, mainly during a beta phase, to make the application stable and/or coherent, correct regressions, but also during the dev phases to reduce technical debt for example).