Changes

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).

A merger can replace himself because it is a task that requires strong technical knowledge, history and anticipatory vision of course, but little mobilization.

A merger can be replaced because it is a task that requires strong technical knowledge, history and anticipatory vision of course, but a little mobilization compared to size of the project (2 half day per week).

On the other hand, where the project is at risk is the lack of FDK (because it relies on a smaller team and it is an activity which requires a large investment of work). This is where the “bus factor” is located on a community project: on the FDK (I’ll let you see the definition of Bus Factor on Wikipedia). The idea of releasing more often (reminder: making a version stable is exponential to the amount of evolution of this version) is the solution taken by many projects to make stabilization easier, to the point of pushing the system into "rolling" release, monthly, or weekly by some.  

On the other hand, where the project is at risk is the lack of FDK (because it relies on a smaller team and it is an activity which requires a large investment of work). This is where the “bus factor” is located on a community project: on the FDK (I’ll let you see the definition of Bus Factor on Wikipedia). The idea of releasing more often (reminder: making a version stable is exponential to the amount of evolution of this version) is the solution taken by many projects to make stabilization easier, to the point of pushing the system into "rolling" release, monthly, or weekly by some.