2020-03-31 - Modules and Roles

Present: Dalai Felinto, Sergey Sharybin

This meeting was a preliminar exchange of ideas and feedback trying to address the module roles and how their current organization lacks compared to the project needs and the reality of the existing team.

"How do we start a project? "
“What does the project lead do?”

Plans of Action Compilation:

  • Blackbox vs glassbox: Get all the developers to agree on that.
  • Modules organization: Get feedback and consensus from everyone in that proposal. Update wiki and module pages accordingly.
  • Blender.org Project Administrators: arrange a meeting with the 5 administrators to align the communication and the vision of the project. Tentative time April 7th, 9am CEST (to check with Campbell).

Black box vs Glass Box

Black box means every module has their own rules in regard to naming, documentation, …

Glass box means everyone works in every module and they all adhere to the same set of standards.

Black box

  • Con: Communication between modules becomes time consuming. Limited to 1-dev project. Other developers are less encouraged to touch and visit that area.
  • Pro: Local changes are highly effective.

Glass box:

  • Con: Far from what we have now. In the short term adds overhead to more independent developers that work in single modules.
  • Pro: Developers are mode independent to fix things in different modules.

How to make the project more readable: “Human readable explanation of algorithms”.

Ultimately that helps to nurture “junior developers into becoming more senior”.

There must be a reliable way to find the documentation of an area. The code can centralize that, eventually pointing to the wiki for big overarching design that touches multiple areas.

Implementation plan: Document the guideline for the quality we expect for code comments, naming and documentation with examples. Peer reviewed documentation. Adhere to this for new projects (2.90 at least), and for any old area that a developer stumbles upon it.

Plan of action: Get all the developers to agree on that.

Modules Organization

Roles (new names):

  • Lead (formerly module owner)
  • Team (developers and artists)

Possible organization scenarios:

  1. [proposed way] The module “owners” are accountable for the module well being. They work as facilitators to be sure all the tasks are addressed. It is their work to create consensus within the module, and if needs be consult other modules and the chief architect.
  2. [current way] The module “owners” are directly involved with patch review on design level, and classifying reports, and the sole maintainers of the communication channels. Any design change in the area must be vetoed by them.
  3. [old way] The module “owners” come up with the designs and roadmap for an area, and the other developers tag along.

Comparison between proposed and current way:

  • Current way:
    • Con: It requires more seniority than we have. Too vertical structure for a small team (adds hierarchy overhead).
    • Pro: Business as usual.
  • Proposed way:
    • Con: Definition of “owner” shifts, needs to see if it works with the group.
    • Pro: Align module structure with the diverse team expertise.

But the module members share the responsibility for the decisions in the module, and should strive for consensus among themselves.


  • Patch review on design level
  • Patch review on code level
  • Classify reports
  • Bug fixing
  • Regular development
  • Maintain communication channels (phabricator, devtalk, blender chat)
  • Big design decisions
  • Onboarding

Proposes modules tweaks:

Optional tweaks to make the modules more clear.

  • Move Outliner from Interface to Data
  • Rename “EEVEE & Viewport” to “Viewport & EEVEE”
    • Or, remove the name of specific render engines from the module?
  • Rename “OpenSubdiv” to “Subdivision surface & Multires”
    • The fact that under the hood it is OpenSubdiv is an implementation detail
  • Remove Libmv
    • From Blender development perspective it is a detail, patches to it are to be treated as “Motion tracking”.
    • For the few percentage of contributions to the library this can be handled as part of Libmv’s developers (Sergey and Keir).

Plan of action: Get feedback and consensus from everyone in that proposal. Update wiki and module pages accordingly.

Blender.org Project Administrators

Recap of current members: Bastien, Brecht, Campbell, Dalai, Sergey.

Read the original announcement.

  • Technical decisions should be made in consensus with this team.
  • What is the expected role for the team?

The meeting digressed on how the roles here required responsibilities and team communication we are currently struggling with. The role of the administrator team is very clear, to keep the blender.org flourishing, keep it open for contributions and keep it a fun project to work.

Plan of action: arrange a meeting with the 5 administrators to align the communication and the vision of the project. Tentative time April 7th, 9am (to check with Campbell).


The current module definitions are unclear. In an ideal situation you could trace a compile unit back to a single module. There are areas where that isn’t clear. Hence making plans would involve multiple modules in many cases.

for example.

  • Where does the image editor belongs to? Modeling or Sculpt, Paint, Texture.
  • The UV editor is explicitly mentioned as part of the Modeling. As UVs are tight related to shading and texturing.

There are efforts to make the code base more modular. IMO it would also be good to reflect that as modules as that would make it easier to follow for users and developers.

About glass box/black box is a chicken and egg problem. I don’t mind going to areas I am not familiar with, but it is sometimes very unclear. But if we want to have more people involved… If we want to change this we should mention it as a target and every project should move us closer to that situation. This feel like a requirement for architectural planning and communication. The difference (on communication level) between glass and black box is more when is the communication more intensive and when does it happen. During architecture planning or during project planning.

Architectural planning will on the short term be very time consuming and could lead to a lot of re-implementation of current and near future projects.

Anyhow my two cents are use clear definition of the modules for both user and developers.


One small thing that I’ve found odd since the module concept was introduced is that there’s basically no “module” representation at the weekly meetings. I would’ve thought the existing module “owners” would at least give an overall status of the module during that time but none usually come, which is odd as that’s probably a perfect time to do it since more folks are online at that time.

Nothing grand is expected. Just a “our module’s tasks are still good for the coming release”, or “we’re literally on fire right now, might be coming in hot”, or “Hey, module foo, I noticed a lot of incoming bugs for you guys, fyi”. Something low overhead and low barrier as that would be nice to see and follow.

I wouldn’t do a roundtable call-out to each module owner during the meeting, but I figure a few would chime in each week at least on their own.


Do you think splitting the existing modules into more smaller modules might be the solution to this?

Black Box vs Glass Box

I don’t think there are many rules that are module specific. Rather there are some things for which there are no rules or clear conventions at any level, where we need to make an effort to raise quality across Blender as a whole and find some agreement where opinions differ.

Showing by example is the most important thing here I think. Comment and document an area really well so we can point to it as a reference.

Modules Organization Scenarios

The organization scenarios I find rather confusing since they are not mutually exclusive. Module owners should take more responsibility for the state of the code, docs, tracker and communication of their module.

For decision making and design, that’s something module owners do more independently as they become experts in their area. That requires initiative to not only understand the code, but also usability and user feedback.

And I think this is already happening, but it’s a continuous process and takes time. We still have many more areas than experienced developers.

The module owner might be mostly guiding contributors, or they might be doing most of the design and development themselves, or it might somewhere in between. I think the constant is that module owners should always be taking responsibility.

Which doesn’t mean they have to solve every problem. But when there is an important problem they should either solve it or communicate to e.g. Dalai that they don’t have the time or means to solve it.

Module Tweaks

Making these kinds of tweaks should be really simple, just talk to the developer involved on blender.chat and change the page 5 minutes later?

OpenSubdiv and Libmv proposed changes Sergey should be able to make by himself immediately. I don’t know the reason behind the proposed changes for Outliner and Eevee / Viewport, I see no problem with the current state.

There’s always going to be some overlap between modules, but we can just tweak it whenever there’s something we see that can be clarified.


That’s quite serious question of a semantic source.

To solve math problems, you need to improve your abilities in math.
(set tasks, get problems and solve them, gaining experience)
To solve code problems, you need to improve your abilities in programming.
To solve modeling process problems, you need to perform a lot of different types of modeling, like CAD/architectural modeling, retopology/ organic modeling, and several sub-types, like gamedev modeling, multirefrenced modeling, mesh cleanup and so on, that forms “modeling process” definition.
Those areas are completely different, they have different goals and sets different problems to solve and observe. Spending the same time, you can become an expert in only one area - in which you solve actual problems.

And also a problem with users feedback - most of users are really not about system design, artists are way more about raising skills to satisfy particular production demands. Like in classroom, majority is good for bug detecting, but advanced techniques are mastered by professor, who set himself certain tasks and solved them.

Does this mean that, for example, the owner of a modeling module needs to improve intersectoral modeling skills in order to become a semantic core for creating the best module roadmap?
This is a pretty long way to go and it is always difficult to get involved in such a wide range of tasks - from understanding and managing the code to understanding usability issues.

I’m not talking about developers becoming expert modelers. Being an expert module owner doesn’t mean you have to know everything, you just have to understand the landscape well enough and know how to find the information when you need it.