 Hi, I have seen many requests for tutorials on how to develop Blender in the last couple of weeks and with this video I want to try to show how to generate a process of fixing a bug in Blenderworks, for me at least. Instead of trying to explain how everything works abstractly, I decided it would be good idea to just record myself and explain later on where I did what I did. This is the added benefit that I don't even know which bug I am going to fix, so I don't know the code and everything seems a bit more real. In the time-lapse in the background you see how I am going through the bug tracker and trying to decide which bug I am going to fix. This is an important first step because you have to try to guess how hard it will be to fix a certain bug and if you are capable of doing it because obviously some bugs are much harder to fix than others and especially for making a video out of it should be a bug that I am actually able to fix within a certain time frame. After a couple of minutes I decided to take a closer look at this bug which is that the syntax highlighting within Blender's text editor is wrong when you use the add sign for matrix multiplication instead of for a Python decorator. As with any bug, the first step is to reproduce it locally. That usually means that I create a smaller blend file that I just open after every change I do to the source code to check if the bug was fixed or not or also to trigger the debugger within a certain code segment or whatever. There is also a reason why it is often very helpful when the bug report already contains a very smaller blend file that I can just use instead of having to build my own. Fortunately in this case it is very easy to build my own. Using this dot blend file I can start to find the code that actually has to be fixed. Usually I don't even know which source file has to be fixed so I just look for related files. In this case you see how I type different file names and try to find a file that relates to the text editor. One thing to note is that every space type like text editor in the 3D view has a file space underscore in the editor name and it is often a good idea to just start there when you look for the drawing functions and whatever for a certain space type. So this is what I am doing here at first. Every one of these space type files contains one function at the bottom which initializes a struct which contains all the information about this specific space type and usually there are many function pointers which give a good starting point to find the code related to your bug. The next step is then to make sense of these functions. Usually that means just reading through the code and checking which other functions are called and in which other things are done and taking a look at the structs that are used and often there are some comments that may or may not have but at least you have to get a feeling for how the function works. In this case I noticed that the format line function was actually never called by setting some breakpoints so I guess that the actual syntax highlighting was probably done somewhere else so I started looking what other code could do the syntax highlighting if not the drawing function itself. The next common thing to figure out where certain things are done in the source code is to go into Blender and for a certain property that is related to the area you find the Python data path and you search for it within Blender source code. Then you get to some RNA file and the RNA system basically describes the relationship between the Python API and Blender's internal structs so that way you find the struct that contains information about syntax highlighting in this case. Now you can see me making sense of the code again by reading it and by setting breakpoints but most importantly also by changing it and predicting how the change will affect the behavior of Blender and then going into Blender and seeing if my change actually changes the behavior I expect because that way I can confirm if I understand the code correctly. Now I'm doing something that's not strictly necessary to fix the bug but it's usually a good idea to just search online for the topic that you are working on and just getting a sense of it how what others are doing in the same area and just broadening your understanding of the topic a bit. Finally I found the right function in Blender that needs to be fixed and I confirmed that by changing it a little bit and seeing that it affects the right thing when I open Blender again. Also notice that Blender does not implement a full Python parser to do the syntax highlighting so there probably can't be a perfect solution here without rewriting everything. It is because to really decide if an add sign belongs to a magic multiplication or to a Python decorator you need some more information from the abstract syntax tree which we don't have. Now I'm checking the diff to see if it looks like I expected it to look like and then I submit the patch for code review. We use a tool called Archonist for submitting code reviews etc. It simplifies the process a bit but you can also just upload a normal biff file or just copy paste the diff into the submit patch form on developer.blender.org. After I submitted the patch to code review I stopped recording because I didn't know how long it would take. Usually it takes a couple of hours for a small patch just like these but it can also take much longer. Sometimes also very fast like a few minutes but in most cases for me it takes a couple of hours. The full review took roughly 4 hours. You can click on the link in the description to read it yourself if you're interested but I will go over the process of merging it into master now. There are a couple of ways to merge it into master now. I usually do it manually by just squashing merging the bug fix branch or feature branch into master and then committing it and pushing it. There are also more automated ways with the Archonist tool again but I've actually never used them. Finally you can see that the initial bug report and the code review are closed now. That happens automatically because I put the term fixed with the bug report identifier into the commit title and then fabricated everything automatically. That's it. I hope you learned something from this video. I certainly did by watching my process for the first time again. The general process is the same for most bug fixes. Interestingly when you look at all the bug fix commits you will see that most of them are very short. So the difficulty is just to find the few lines that need to be fixed. Hopefully this video helps to get some ideas on how to start fixing a bug within code that you don't know beforehand.