Table Of Contents
Introduction
Setting Up the Development Environment
Contributions
What I learned this week
What is next
## Introduction
Last, I started my journey as an Outreachy applicant(this is my third time of reaching the contribution phase and hopefully I get in this time around), contributing to the DebConf/MiniDebConf websites project under Debian. Outreachy is an internship program that provides opportunities to people underrepresented in tech to contribute to free and open source software. The contribution phase is highly competitive , only applicants who make meaningful contributions are considered for the internship.
I chose this project because it combines Python and Django, technologies I am actively learning, with a real-world codebase that has been running for over 10 years. The idea of contributing to software used by the global Debian community was exciting to me and mean a lot to me.
Setting Up the Development Environment
The first and foremost task was getting the development environment running on Debian(I already have Debian OS on my computer since I have contributed to Debian OpenQA last year, although I did not get selected, but I still attend their meetings and I am still very much with them. The project uses two main components: wafer, a reusable Django app for conference websites, and wafer-debconf, a set of extensions built specifically for DebConf.
Setting up involved:
Cloning the dc27 repository
Creating a Python virtual environment
Installing dependencies from the dependencies*.txt files
Running database migrations
Starting the local development server
It wasn't straightforward at first. I ran into issues with unapplied migrations and static files not loading correctly. But working through those problems taught me a lot about how Django projects are structured in production-like environments.
Contribution 1 & 2: Yoruba Translations for Certificates and MiniDebConf Apps
The first issues I worked on were translation tasks. The mentor, Antonio Terceiro, opened a meta-issue inviting contributors to translate system messages into their native languages. Since Yoruba is my native language, I took on the task for two apps: the certificates app and the minidebconf app.
Django uses a translation system based on .po and .pot files. The .pot file is a template containing all the strings that need translation. The process involved:
Copying the .pot template into a new django.po file
Filling in the msgstr fields with Yoruba translations for each msgid string
- Running python manage.py compilemessages to compile the .po file into a binary .mo file that Django reads
Some of the translations I worked on included registration form fields, navigation labels, and email notification strings. Translating technical terms into Yoruba was sometimes challenging, finding the right words that are both accurate and natural in Yoruba required careful thought.
Both translations were submitted as merge requests on Salsa, Debian's GitLab instance.
Contribution 3: Making Certificate Validation Work Without JavaScript
The third contribution for the first week was more technical. The certificate validation page on the DebConf website previously relied entirely on JavaScript to work. It used fetch() to retrieve certificate data from a static JSON file and then displayed the result. This meant the page would completely fail for users with JavaScript disabled.
The fix involved replacing the JavaScript implementation with a proper Django server-side view. Here is what I changed:
views.py — I replaced BuildableTemplateView with a standard Django View class. The new view accepts a vk (validation key) parameter from the URL query string, queries the Certificate model directly, and passes the result to the template via context.
validate.html — I removed all JavaScript and replaced it with Django template tags
({% if valid %}, {{ fullname }}, {{ certinfo }}).
settings.py — I removed CertificateValidate from BAKERY_VIEWS since it was no longer a static bakery view.
tests.py — Added a full test suite covering valid attendee certificates, valid speaker certificates, valid volunteer certificates, invalid keys, and missing parameters.
This contribution taught me the difference between static site generation (what django-bakery does) and dynamic Django views, and why server-side rendering is more robust for features that depend on database state.
What I Learned This Week
The difference between BuildableTemplateView and a standard Django View
How to write Django tests using TestCase, Client, and reverse()
The Git workflow for contributing to a project on Salsa (fork → branch → merge request)
How to read and navigate a large, real-world Django codebase which is an essential skill for anyone that wants to contribute to open source projects
What's Next
The contribution phase ends on November 9, 2026. I am planning to work on more issues from the project's improvement list before the deadline. The experience so far has been challenging but rewarding , every error message I debugged and every test that passed has made me more confident as a developer.
If you are also applying for Outreachy or just starting out with open source contributions, my advice is simple: start with the issues that match your current skills, read the codebase carefully, and don't be afraid to ask questions in the community chat.
Top comments (0)