Dev:Doc/Process/Contributing Code

提供: wiki
移動先: 案内検索

Contributing Code

If you do not have commit rights to the Blender Git repositories, contributing code is done through patches.

Before Starting

If you are contributing a small feature or fix, you can usually just go ahead, create a patch and submit it. If you plan to work on big new features, it's usually a good idea to Contact Developers in the area you plan to work in, and figure out if the feature is desired and how it should be designed, before spending a lot of time coding it.

Submitting Patches


Go to the patch Submit Patch page and upload your patch.


Submitting patches is very welcome! To make timely and proper reviews possible, we'd recommend you to check on the guidelines below.

  • Follow code guidelines: no new warnings, comment your code, add documentation, follow code style of the file you are editing.
  • Try to keep everything in a patch related to one topic. If there are two things you're fixing, e.g. adding a new hotkey and fixing a memory leak, submit two separate patches, one for each topic.
  • Patches solving bugs or compiling errors will usually get handled quickly. Note that for such patches we typically need similar info as for bug reports on how to redo the issues. Especially for more complex fixes we really need to be able to verify that ourselves.
  • Patches providing new features are more complicated to handle. A review has to be done both on functional level (does this fit with Blender's design or roadmap) and technical level (does the provided code conform to our coding style, match design and planning, and is sufficiently readable and maintainable).
  • For larger patches it's relevant to note if you seek one of the Blender project members to submit and maintain it, or whether you propose to get involved as team member to maintain/improve it in the future.
  • Provide as much relevant documentation as possible. Images, screenshots, short video clips or .blend file examples do do wonders! Attach all of this in the tracker itself, or a website which you know will remain accessible for a long while.

Finding Reviewers

Doing a good review can take a lot of time, and because many Blender developers are volunteers, we cannot make a promise you'll get such a review here! Below are tips on how to get reviews done. To get developers to review your patch, you can get in contact with them in various ways:

  • Assign or CC them when submitting the patch on
  • Subscribe to the bf-committers mailing list and send a mail that you added a patch.
  • Go on #blendercoders on and talk to developers.

To find out who exactly is responsible for some area of the code, see the Module Owners List. You can also find developers by browsing the commit history and seeing who worked on similar files.

When the patch has actual new functionality, user reviews will help a lot too. A lot of patches were tested first by providing public builds via websites like, or via forums like

Help, my patch got rejected!

First of all, we're all software developers here, and we understand code work on Blender shows a lot of commitment, and has been your time investment with all the good intentions to help us out. A rejection doesn't mean we don't like you, nor that we don't like to see actively helping out as a contributor! It's all human beings here, with personal preferences, and ideas for how to make Blender a better product.

It makes Blender as an open source project strong if we allow active developers and maintainers to make individual choices too. They're getting empowered to do development, which also implies they have get the benefit of the doubt in making tough decisions.

Nevertheless, mistakes can always happen! Here's what to do to get a patch considered after all:

  • Contact the developer list with a friendly request for (additional) reviews. Make sure the current maintainer of code at least is aware of this rejection.
  • If no result or consensus in the project team can be found, you can ask the admins of bf-blender to provide a final verdict.