Hey I’m new to open source and i really want to start contributing because i find it very interesting. The problem is that I’m not quite sure where to get started. I’ve read https://docs.djangoproject.com/en/dev/internals/contributing/ and looked at some issues at the issue tracker and I was really overwhelmed . I could understand some of the issues but then I’m really having trouble familiarizing myself with the codebase and don’t understand where to look for what. It would really be helpful if someone could mentor me and get me started. Any help would be appreciated thank you 
.
1 Like
Hey @chinmoy12c, what exactly it is that you are looking for guidance about?
I am a new contributor to Django project and have about a couple of years experience working with Django as a web developer. I just created my first Pull Request to django project. Here are the things that helped me.
- Is it in terms of understanding Django codebase?
– If so, my approach has been to jump into what I need to work on, i.e. pick a ticket from easy tickets. And if you don’t find anything unassigned, choose something that someone else is working on but try to fix it by yourself without looking at their code changes. This will give you the much needed initial exposure to code base and the initial confidence bump - Is it to set up your local dev environment?
– I found the Django contributing guide (link you shared your post) and these instructions by Carlton Gibson dcus2019sprints very helpful
Hope this helps.
2 Likes
Hey @ProProgrammer thank you so much for your help. I would implement this approach as well, one problem is that i find difficulty in pin pointing the exact code for a particular issue. Is it normal for beginners to experience this? And if so is there a defined way that i can follow? Thanks again .
Hey, yes definitely normal. When you are working through any new code base (not just Django), it’s totally normal to feel lost initially until you build a level of familiarity with code base.
The good thing about Django documentation is, at various places you can click on Source link next to the class names/function names and that will take you right into the code implementation of that particular logic.
Additionally, another method I use is, I try to understand the reasoning/thought process behind a particular implementation by using Annotate functionality of the IDE, Annotate shows me the commit ID when a particular piece of code was last changed, I go to that particular commit via https://www.github.com/django/django/commit/<commit_id> and from there I try to find the associated Pull Request or ticket number. Mostly at these places you can see the discussion that happened during a particular implementation and that discussion helps you build context.
Hence, for me the only way is to dive into code base, and start tinkering around with it.
An alternative approach is to see if there are any code walkthrough videos available. I haven’t been able to find particularly code walkthrough videos.
I have seen this video by James Bennett: https://youtu.be/tkwZ1jG3XgA titled Django in Depth
It’s an helpful insight into internal workings of Django but I would say use it as a reference instead of a tutorial. Basically I refer to parts of it when I need to understand certain things while looking at the code base.
3 Likes
Okay. Thank you for all the guidelines I’m sure these would help me a lot 
. Also thank you for the video I’ll have a look at it .
1 Like
Hey, it’s great that you’re excited to contribute!
If you find anything challenging or if you’re stuck on something, feel free to make a post here so we can help you out.
I’m also a new contributor and I was lost at first. It really helps to know that you’ll eventually find your footing in Django. It may take time, but you’ll learn so much!
1 Like
Hey @Valz yeah sure. Thank you for your support this community is really wonderful. .
1 Like
Hey I was looking at this issue
https://code.djangoproject.com/ticket/31416
and I understand that if the RemoveField be carried out before CreateModel, it would work fine. Following the code trail of makemigrations.py brought me to autodetector.py file. I think the issue can be resolved by modifying this file and somehow changing the commands order it generates? Am I on the right track?
Please do help me out here 
.
You’re definitely on the right track! Try writing an appropriate test first, then modify the files and see if your test passes.
1 Like
This is exactly what I want to start doing! I am finishing off a project then am going to start with open source. @chinmoy12c how did you get on with your first bug fix?
I got my first PR to django merged recently and I would reply to this from the view point of a total beginner. This was my PR Fixed #31645 -- Enhanced the migration warning for migrate commmand. by chinmoy12c · Pull Request #13027 · django/django · GitHub. Now you might be wondering why so late, I mean this post was from two months ago. That’s because I got frustrated and quit. DON’T BE LIKE ME.
So it was a couple of weeks ago I decided to look into open source and give it another try simply because even though I had given up, my mind did not want to accept that fact. So I went to the django bug tracker looking for an issue. After searching for a while I reached this ticket #31645 (Models have changes red alert message should say which apps/models) – Django. The ticket was about enhancing the error message of migrate command. I had no idea how to do it at first but nevertheless I gave it a try. I’m going to describe exactly what all I did and to be honest my attempts were mostly trivial, but most likely what a beginner would do.
Step 1, I had to pinpoint the code first. I had to know what file produced that output. So I thought it’s the migrate command maybe it’s in a file named similar to it? So this is literally what I did.
find . -name migrate.py
It did find the migrate.py file for me. Next was to find the code which gave the error output. So I opened my editor and searched for that exact error message.
Your models have changes that are not yet reflected in a migration, and so won’t be applied.
Run ‘manage.py makemigrations’ to make new migrations, and then re-run ‘manage.py migrate’ to apply them
I found the method that handled the error, NICE 
. Now I noticed that the method was checking for a dict changes. That was my clue, I checked the dict and it turned out it’s keys had the app names with the changes.After that it was normal old python to deal with and print the app names with the error. The patch went through some changes afterwards as well, you can check those in the PR.
Step 2, the hard part. Writing tests 
. felixxm pointed me to the file where the tests resided, and as soon as I opened that file, I was overwhelmed. Not a single statement made sense to me back then. But believe me every minute you spend reading the code you understand a part of it. There will be times when you just stare at the code without any advancement, that’s okay take a break, have some beverage and get back to it. It will make more sense, the more time you spend reading it. Eventually I understood the pattern. Most of the tests included a migrations file and then tested the migrate command accordingly. So in my case I needed a model which had changes which differed from the migrations file. So I included a migrations file, made a model inside the method with a slight change and called the migrate command. Nothing happened. Why, because the first time I called the migrate command the migrations were actually applied from the migrations file and so no error was raised. So I called the migrate command twice and in the second call the error was raised. GREAT I managed to raise the error, now all that was left was to assert it. So I used the assertion command and it failed 
. The test output said ,
Diff is 1184 characters long. Set self.maxDiff to None to see it.
So I did and checked the difference in output. The reason my test was failing was because the output was color coded. So I checked other tests and noticed that the argument I needed to use was no_color=True and it worked. 
. It went through final reviews and few changes and was merged.
This is how I made my first contribution to django. The feeling was so amazing, it made all that worth it. . Also the community is welcoming so you can always find someone for help. In my case it was felixxm . I hope this helps someone beginning with their open source journey and most the important part is DON’T GIVE UP like I did because if I hadn’t given up back then I would have made much more contributions till now. All the best
3 Likes
Amazing! Well done. I am going to go through it today, how did you go about selecting the patch to fix?
I went through many issues at first, then I selected the one which seemed doable at least or rather which wasn’t too hard to pin point.