Changes

m
Line 54: Line 54:  
In short, there is no under-staffing on the merge (in fact the workload when you know the app well is quite low) but we frequently have an under-staffing on the '''Fixers''', '''Debuggers''' and '''Killers of Technical Debt''' 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, who correct regressions, but also during the development phases who work to reduce technical debt for example). Linus Torvald, from the Linux project, also call them '''The Maintainers''' (vs The developers) and said: "''We do not have enough maintainers''". Dolibarr also miss such contributors on old released versions (when we have too much on develop version).
 
In short, there is no under-staffing on the merge (in fact the workload when you know the app well is quite low) but we frequently have an under-staffing on the '''Fixers''', '''Debuggers''' and '''Killers of Technical Debt''' 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, who correct regressions, but also during the development phases who work to reduce technical debt for example). Linus Torvald, from the Linux project, also call them '''The Maintainers''' (vs The developers) and said: "''We do not have enough maintainers''". Dolibarr also miss such contributors on old released versions (when we have too much on develop version).
   −
The '''Merger(s)''' can be replaced: Its tasks requires strong technical knowledge, history and anticipatory vision of course, but need a little mobilization compared to size of the project (i.e: load in 2024 is 2 half days per week only).
+
The '''Merger(s)''' can be replaced: His tasks requires strong technical knowledge, history and anticipatory vision of course, but need a little mobilization compared to the size of the project (i.e: load in 2024 is 2 half days per week only).
    
On the other hand, what the project is at risk on is the lack of FDK/Maintener (because it's an activity which requires a large investment of work, several full time equivalent). This is where the “bus factor” is located on a community project: on the FDKs/Mainteners (I’ll let you see the definition of "Bus Factor" on Wikipedia). The idea of releasing more often is the solution taken by many projects to make stabilization easier (remind: making a version stable is exponential to the amount of evolutions of this version, so releasing often means easier to stabilize), to the point of pushing the system into "rolling" release, monthly, or weekly by some. So why not doing the same in Dolibarr to increase the stability and to reduce the workload ?
 
On the other hand, what the project is at risk on is the lack of FDK/Maintener (because it's an activity which requires a large investment of work, several full time equivalent). This is where the “bus factor” is located on a community project: on the FDKs/Mainteners (I’ll let you see the definition of "Bus Factor" on Wikipedia). The idea of releasing more often is the solution taken by many projects to make stabilization easier (remind: making a version stable is exponential to the amount of evolutions of this version, so releasing often means easier to stabilize), to the point of pushing the system into "rolling" release, monthly, or weekly by some. So why not doing the same in Dolibarr to increase the stability and to reduce the workload ?