Modules/Roles

= Module Roles =

This page explains the roles and responsibilities of contributors that are part of the various Blender Modules.

BF Blender
This is the Blender Foundation tree, from which official releases are made. Decisions are generally made in consensus by all BF Blender project members or by module owners. However if no consensus can be found the project administrators will make the decision.

Project Admins

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

Owners
Active developers who frequently contribute to parts of Blender can become module owners. 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.

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 are well documented in wiki.

Module owner and members mostly self organize. When needed, the module owner acts as the main point of contact and coordinates efforts.

Project admins approve module ownership.

Members
Module developers design and implement features, review contributions and listen to user feedback, as well as handle bugs reports.

Anyone actively contributing code to a module can be listed as a developer, there is no formal process to join. Developers are listed in their corresponding areas if their involvement is more sporadic, or as a module member if they want to be more active and involved.

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

QA
Members can also be non-developers (artists) that are pulled into the module discussions and decision-making.

Non-developers members are usually artists who will act in the QA and stakeholder role of the module. The entire module team, including the owners, ensure that stakeholders endorse and agree with features and development plans and accept them to perform a QA pass on every commit or feature that gets added.

User members are appointed by invitation by the other module members.

Responsibilities of user members:
 * 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.

Contributing
When contributing code, module members can be contacted for development questions and assigned for code reviews.

Developers committing code to areas of which they are not members should get a greenlight from the relevant module members first. Any areas not clearly covered by a module are handled by the project admins.

Once a developer has contributed good quality code, they can be given access to commit directly to the Blender repository. Code review for new features and bigger changes is still done by module members, while smaller changes can be committed directly.