Changes

m
Line 44: Line 44:  
Dolibarr has an integration rate to merge modifications of code (we call this "'''Pull Requests'''" or "'''PR'''") of around 95% (Calculation done from PR processed vs PR suggested by developers on GitHub). Hoping to have more merged PRs (so more features), and therefore to have a rate of 98% for example is clearly utopian especially when we know that the merge rate is between 30% and 85% on other projects of equivalent size (Odoo: 30%, ERPNext 85%, measured in 2022, so after 20 years of existence).
 
Dolibarr has an integration rate to merge modifications of code (we call this "'''Pull Requests'''" or "'''PR'''") of around 95% (Calculation done from PR processed vs PR suggested by developers on GitHub). Hoping to have more merged PRs (so more features), and therefore to have a rate of 98% for example is clearly utopian especially when we know that the merge rate is between 30% and 85% on other projects of equivalent size (Odoo: 30%, ERPNext 85%, measured in 2022, so after 20 years of existence).
   −
So what is blocking the integration of more features today is the instability that each feature merge generates, and the stabilization phase that is necessary to “digest” a Pull Request for evolution. This time and workload to stabilize integrated developments is exponential with the number of integrated PRs, thus:
+
So what is blocking the integration of more features today is the instability that each feature merge generates, and the stabilization phase that is necessary to “digest” the Pull Requestws of evolution. We must know that the time and workload to stabilize integrated developments is exponential with the number of integrated PRs, thus:
    
*If we release 2 times less often (so 1 every year), the time and efforts to “stabilize” is multiplied by 4 (so slower).
 
*If we release 2 times less often (so 1 every year), the time and efforts to “stabilize” is multiplied by 4 (so slower).