Djangonaut Story

ABOUT THE PROGRAM

Djangonaut is a mentoring program established to guide people who want to contribute to the Django ecosystem. It runs for 8 weeks; during which, Djangonaut( the newbies) are mentored by Navigators and Captains (more experienced developers) to contribute to various open-source projects in the Django community. Read More

MY APPLICATION STORY

I learned about the Djangonaut program from Tobe; he informed me about the program in a private chat that I had neglected for some time. During a random scroll through my phone, I found the message, and ALAS! It was about 9 hours before the application deadline. I quickly rushed through the application process, drafted my statements, and prepared the required pull request to the Django repository. I applied just before the deadline but didn’t get into the program.

Some months later, after the first session, he informed me about the second session and I applied again. This time, I re-edited my essays and submitted them again. Guess what? Another rejection. To put it mildly, I was quite sad.

Applications for the third session opened; I had already given up this time because I felt like the same thing would happen again. Guess who came in again to inform me about the program? YES! Tobe!. He told me to apply again and offered to edit my application essay.

I re-edited the essays again and sent him a copy. I thought he did a brilliant job on the review (from the use of sentences; to being able to capture my thoughts succinctly. I was quite impressed and thanked him heartily). Afterward, I checked other requirements properly (especially the Django PR. Here’s a link to my PR). I applied earlier this time and eagerly waited for the response. Guess what?!

GETTING ACCEPTED AND PREPARING FOR THE PROGRAM

It was a Friday afternoon and I got a notification mail from Djangonaut Organizers. I had been accepted! I was so happy! I will contribute to django CMS for the next eight weeks and beyond!

After a couple of weeks, a link to the private Discord server was sent out, I joined and introduced myself and you knew take-off was imminent. The Navigator, Fabian, contacted the team and shared some useful resources on getting started with django CMS.

When it came time to hack on the source code, I cloned the project source from GitHub and somehow managed to get it to work with my previous Python experience; this was when I figured that it would be handy if there was a documentation guide that would clearly explain how to install django CMS from git source. I suggested the idea as an issue, got the go-ahead to create it, and submitted a pull request to solve it.

FIRST PULL REQUEST

The issue I created was a documentation fix: a typo fix and a guide detailing how to set up django CMS from git a source.

Due to the extensive documentation, setting up the documentation suite locally was straightforward. After the setup, I quickly studied the basics of Sphinx (the Python package used to couple the documentation). I had some experience with the package but had to re-read some concepts, especially hyperlink targets. I found this to be quite helpful.

I fixed the typo and verified that the rebuilt doc page showed the fix. During this process, I noticed a reference (:ref:`contributing_patch) to a named hyperlink target that wasn’t rendering so I checked the source code and found that the target it was linking to no longer existed. The un-rendering hyperlink name, contributing_patch, immediately birthed a thought in my mind; that there was a reference in the past that contained a contributing guide or at least something similar to it that had somehow gotten lost/removed from the repository over the years.
Hence, my next task was to find a file (in the git history) that contained a definition (.. _contributing_patch:) to a named hyperlink target called contributing_patch.

I did a git blame on the file that contained the failed reference to figure out the last commit that worked on the line; after that, I got the commit and started analyzing it. Here are some simple codes to show what I did:

Switch to the docs/ folder and find all the mentions of the reference in the folder

cd docs
grep -—exclude-dir=‘build’ -r ‘contributing_patch’ *

This showed a file named upgrade/3.2.rst. So, I performed another git blame on the file to find the commit associated with the line mentioning contributing_patch in it; after which, I checked out to the new commit, and performed another search in the docs/ folder to find all mentions of the reference.

git blame upgrade/3.2.rst # find the commit that mentioned the ref
git checkout 3f359b # to find out more details about the commit
grep -—exclude-dir=‘build’ -r ‘contributing_patch’ *

This was how I found an old file containing the definition of the named target (i.e. a file that contained.. contributing_patch: ). The file contained the detailed steps of setting up django CMS from the git source albeit for the project’s old version. I copied the file’s content and switched to the current git state.

The file’s content (after editing) formed the basis of the contributing guide I submitted in my pull request. I committed the changes and submitted a PR which was later merged into the django CMS repository.

NOTE TO SELF: Is this a coincidental fix? How would I have gone about it if there was no pre-existing file? Probably write a contributing guide from scratch.

LESSONS LEARNED

1. There needs to be an element of intentionality when applying to opportunities (don’t just wing it).

2. Network! Network! Network! Make friends with good people in your industry. Tobe got the opportunity and made sure to share it with me.

3. Ask for help. Those applications/blog drafts might need a fresh set of eyes.

4. Learn your tools properly especially git and get comfortable with the shell. Here is a good resource to get started with the shell.