Dev:Doc/New Developer Info

New Developer Info

This page is meant to provide new developers with information about how the Blender development process works, where to find info and how to find a good project to work on.

Communication

There are various communication channels used.

• BF-Committers Mailing List - for public discussions, where official decisions are made.
• Issue Tracker for bugs, patches and managing design tasks.
• DevTalk Forum - for general developer discussion & questions.
• IRC Chat - for informal conversation.

See the Contact page for more information.

If you want to start developing in Blender you will have lots of startup questions. You can ask them in the #blendercoders irc channel each day of the week.

When in doubt and no particular channel seems to match your question, mail the bf-committers mailing list and you will get an answer there or get redirected to the right channel.

No spamming or flaming on the lists or IRC channel is allowed. Please stay on topic in the lists, and follow good net etiquette. Also do not send html messages to the mailing lists. Html messages can be contain a variety of security problems and as such tend to be mistrusted by many people.

Weekly IRC Meeting

Meeting time The IRC meeting was moved from Sunday to Monday on an alternating schedule each week. For correct meeting time, please check the Wiki Contact page and the #blendercoders Topic message

For regular developers, every week there is a development meeting in #blendercoders every Monday. The weekly meeting is on an alternating schedule of 10 CET and 18 CET (Central European Time). Note CET will change to CEST (Central European Summer Time) over the summer. See the Weekly Meeting page for more information (including meeting notes of past meetings). The Weekly meeting is where all the developers bring each other up to speed on their various projects and make decisions on releases, merging branches, accepting features, ... .

During the meeting, please stay on topic. If you want to seek approval for project ideas, or contact another developer, log in before the meeting, hang around after or message another developer personally during meeting time.

Getting Started

Building Blender

See Building Blender.

Decisions

Blender development is structured similarly to Python's BDFL model (BDFL stands for Benevolent Dictator For Life). The idea is that the project is managed by one person, in this case Ton Roosendaal, who delegates design decisions to a group of module owners, while still maintaining a veto right of what goes into Blender.

Your First Project

Once you have blender compiled you're probably wondering where to start tinkering. If you are a Blender user then there is probably some niggling thing you would like to add or change. If you are new to Blender then you will need to take a look and see what you might work on.

There are no hard and fast rules about where to start, so find an area that interests you and start looking onto it.

The full list of wantedtodo features can be found on the Todo page.

Some hints for your first projects:

• An area of interest (even better, an area of Blender you use)
• Double check it is not already done.
• Don't choose a project that spans across many files and areas of Blender, since you may get bogged down trying to understand everything at once.

Here are some areas that can give you a foot in the door:

Small Features

Adding in small features is a good way to start getting your hands dirty, even if you don't make a patch to commit, it can evolve into something more useful, take a new direction, or spark interest in new areas to develop.

Here is a [list of quick hacks] - that core developers think could be reasonably tackled as a first blender project without a major time commitment (i.e. a task that would take a core developer less than 4 hours to accomplish, but might take quite a bit more time for a new coder who needs to learn the code base).

Bug Fixing

One of the easiest ways to get involved with coding Blender is by fixing bugs. Bug-fixing lets you focus on a small part of the Blender source rather than trying to understand it all at once. The list of current bugs is on developer.blender.org. So pick an area of interest and start fixing! When you have got it, make a patch and submit it.

Navigating the Code

Have a look at the Files structure and Code Layout diagram.

The editors directory is usually a good place - it is where most of the operators live. Have a look at the header files and structs related to what you are interested in working on. The headers usually have the best overview of what a function does. To find the struct a simple grep or other search for struct Foo.

You can also start with writing python scripts, the API for our python tools - is similar in many ways to our C API. You can often find out where some C code lives by seeing the python tool tips by hovering over a button and seeing what the operator name is. If you add a console window you can see what is output to it when you do an action, then just search the code.

Also putting a break on a function in a debugger and doing a back trace can help you find the path code took to get to your function of interest. Or you can start blender from the commandline with the -d option and every command is printed to the console.

Debugging

Have a look at Debugging for help and hints on doing debugging. If you end up not being able to solve the bug yourself, post a bug to our Bug Tracker, if it is a bug in our code.

If it is a bug in your code, load your test file and the information you have found out about the bug to pasteall.org then ask for help in #blendercoders in irc.freenode.net. If no-one can help you there you can try emailing bf-committers@blender.org.

Development Process

Steps for getting a patch into Blender

1. Find an area in Blender you want to improve upon.
2. Find whoever "owns" the code and check if he agrees with your project. See the list of module owners. Generally the best idea is to talk to the owner(s) in #blendercoders, but new developers might want to email the mailing list instead.
3. Post a design document on this wiki, creating a new page linked from the Projects page.
4. Do the actual coding :)
5. Once you have code, see the Contributing Code section on how to make a patch get it submitted, reviewed and included.

Technical Documentation

We encourage everyone to use the Blender Wiki to document code work and to share proposals. Note that we strictly apply the rule "No code gets in trunk without documentation!". Also never hesitate to include good example .blend files and tests and videos showing the feature.

People who only want to help with technical documentation are welcome too. Just use the general contact information here to get started.

Release Process

For more information about the release schedule, see Release Cycle and Current Projects to understand the schedule and times when new features can get in and releases are made.