In the spring the number of bug-reports where that high, that Ton decided on a bug-curfew, and people where hired, the triaging process became swift and the bug numbers dropped significantly. And since the bcon2 period is reserved for bug fixing, most bugs are also fixed(unless they’re ‘parked’ eternally with a Known Issue label).
So bug-handling was improved, because it was prioritized. The same thing needs to happen with patches. Ex. right now it is common to see devs prioritizing doing their own bug-fixing instead of reviewing contributed bug-fixing-patches of a similar importance. Question is if it isn’t a better investment to do the review of the contribution, because the contributor could develop into a valuable bug-fixer or patch-reviewer? But maybe the decision in each individual case should be discussed in the thursday meetings?
Devs reviews of patches of other devs also seems like it could be better organized. It is not uncommon to see finished patches hanging for months waiting for the final acceptance from a fellow dev.
The final group of patches are contributed new-feature-patches, which often are never decided if they are found useful or not. The lack of resources is often mentioned, but new/feature green-lightning in the meaning: “yes, this is a good idea, we would like to see this committed in Blender if it meets these criterias …”, doesn’t need a code review first time around. It is mainly a decision to let the contributor know that his/her continued efforts will pay-off if they succeed in meeting the criterions described. This is quite important, as many contributors submit unfinished new-feature patches to ‘test the waters’. This would also be a natural thing to discuss in the thursday meetings, where the module teams already are gathered. If there are more module team members, it should also be decided who is going to be in charge of what part patch review, but maybe the module leader always should have the final review before it is committed? But this should ultimately be decided within the module teams(so the “neurosurgeon” doesn’t end up spending all the time on curing people with a “trivial cold”).
I know there is an argument that new-feature-patches should first be discussed elsewhere like on devtalk or right-click-select, but I’m sorry to inform you guys, that this is not working at all, since typically no devs engage in these discussions at all, and therefore doesn’t result in the needed green or red light conclusion.
Finally, it should be discussed and communicated what the actual responsibility areas of the module teams are. Ex. if a module leader of the Text Editor thinks it should be in maintenance mode only, it must be communicated to contributors, as their time is valuable too. Or if the UI team thinks that their area of responsibility is only the 3D View and the elements connected to it and ex. doing UI work on the VSE is just “rearranging the deckchairs of the Titanic”. And if the idea of consistency in the UI only means UI features in other editors than the 3d view also needs to be implemented there, but not the other way around(in recent months several new features has been implemented this way). Then this should be communicated.