Category:RoadMap: Difference between revisions

m
no edit summary
mNo edit summary
Tags: Visual edit Mobile edit Mobile web edit
mNo edit summary
Tags: Visual edit Mobile edit Mobile web edit
Line 51: Line 51:


However, today the number of enhancement proposed (and which are integrated) is greater than the number of fixes or stabilization (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 enhancement proposed (and which are integrated) is greater than the number of fixes or stabilization (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 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, correct regressions, but also during the development phases to reduce technical debt for example). Linus Torvald also call them <nowiki>'''the Mainteners'''</nowiki>
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, correct regressions, but also during the development phases to reduce technical debt for example). Linus Torvald, from the Linux project,  also call them <nowiki>''</nowiki>'''The Mainteners'''<nowiki>'''</nowiki> (vs The developers).


The Merger 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 (2 half days per week only).
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 (2 half days per week only).


On the other hand, what the project is at risk on is the lack of FDK (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 FDK (I’ll let you see the definition of Bus Factor on Wikipedia).
On the other hand, what the project is at risk on is the lack of FDK (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 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. So why not doing the same in Dolibarr to increase the stability and to reduce the workload ?
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. So why not doing the same in Dolibarr to increase the stability and to reduce the workload ?


For Dolibarr, a monthly or even quarterly pace is unfortunately too fast because it is necessary to give the community time to analyze, comment, test and fixe on PR (volunteers working at their own pace, this need a more important delay). This is due to the community mode of the project (which is not necessary in a constrained scheduled proprietary projet).
For Dolibarr, a monthly or even quarterly pace is unfortunately too fast because it is necessary to give the community time to analyze, comment, test and fixe on PR (volunteers working at their own pace, this need a more important delay). This is due to the community mode of the project (which is not necessary in a constrained scheduled proprietary projet).