Dev:Doc/Process/Module Owners

Module Owners

As developers begin working with the source code of Blender, they generally take on coding tasks that interest them. But are usually unaware of who to contact for help should they get stuck, or who to go to when they would like their code reviewed for approval.

Although the patch tracker has helped with this, there can still be some confusion about who needs to give the greenlight on including a project and thus, many worthy project stall and die before ever reaching the source.

Here is the Module Owners List for various parts of Blender.

If a project of yours does not seem to fit in any of these categories, please refer to the top level bf-blender owners for direction.

To contact developers on IRC, sunday meetings or mailing lists, see the Contact page.

Bf-Blender

This is the official Blender Foundation tree, from which the releases are extracted. New participants should join the mailing list, and can there submit patches. Current project members can endorse new developers to get repository commit access. Decisions are generally made in consensus by all committers (bf-blender project members), or when necessary by the Module Owners.

When no decision can be made in harmony, the Project Admins can force decisions.

Project Admins

• Bastien Montagne
• Brecht Van Lommel
• Dalai Felinto
• Campbell Barton
• Sergey Sharybin

Modules

A module can either be a distinct part of the code, or a distinct end user requirement we maintain. For example, a module team can be responsible for support for a platform (Windows, OS X, Linux), or for the workings of a specific editor (Outliner, Node editor), for a group of tools (Mesh editing) or for a specific library in Blender (Booleans, Cycles).

Modules in Blender are being maintained and organized by Module teams, with 'owner' and 'member' roles.

Module Owners

Active developers who frequently contribute to parts of Blender can become 'owner' of a module. Ownership means you have a lot of freedom to work on the modules, decide on implementation and design issues here, and approve or reject patches and feature requests. This based on aligning well with Blender's general design decisions, release planning and roadmap.

Owners should keep track of other module teams to make sure overlapping work is being agreed on, and make sure their own module teams agree on work that's being done.

Only current Owners can accept new owners or team members for their modules. In case no owners exist (or new modules get added) the Project Admins can approve ownership.

Responsibilities:

• Be available for regular bug fixing in the module (at least for every release)
• Make sure the module is well tested for a release
• Organize review of patches as submitted for the module
• Ensure new features or changes in modules is well documented in wiki.

Developer members

Membership of module teams means you can work on the module with svn access as well. Members make sure their work is either being reviewed or approved on by Module Owners before they commit.

Whenever possible, members are available for bug fixing, reviews and documentation as well. However, it's more of a loose commitment, based on 'being involved' more than on 'being available'.

User members

This special module membership is for non-developers, typically artists who will act in the stakeholder role of the module. The entire module team, including the owners, will have to ensure the stakeholders endorse and agree with features and development plans.

User members are only appointed by invitation by the Module Owners.

Responsibilities:

• Make sure the module is well tested for a release
• Help documenting and with release logs
• Feedback on public forums or mailing lists on feature requests.