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 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.
- 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.
- 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.
Roles (new names):
- Lead (formerly module owner)
- Team (developers and artists)
Possible organization scenarios:
- [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.
- [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.
- [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
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).