Introduction
Last week I wrote about taking my first nervous steps into the DebConf/MiniDebConf websites project as part of my Outreachy application. If that week was about figuring out where everything lived and how to even get the project running, this week was about something deeper: learning what it actually feels like to contribute to software that real people depend on.
I'll be honest , I started this week unsure of myself. The contribution phase is competitive, and it's easy to look at experienced contributors and wonder whether your small changes matter. By the end of the week, two of my merge requests had been merged into the project, I had worked through a full round of the mentor's feedback on real code, and I had learned to pause and discuss a design before rushing to write it. It was the kind of week that quietly changes how you see yourself as a developer.
Seeing my work merged — twice
The first big moment was seeing my Yoruba translation for the certificates app get merged into wafer-debconf.
On paper, it's a small contribution ,a translation file. But Yoruba is my native language, and there was something meaningful about adding it to a project that has been running and evolving for over a decade, used by a global free software community. It wasn't just code getting accepted; it was a small piece of my own language and identity becoming part of something bigger. I sat and looked at the merged status for longer than I'd like to admit.That was my first ever merged contribution in an open source.
The second merge meant even more to me, because it was my first real code change to get accepted , this time around, not a translation, but an actual change to how the application behaves.
I had submitted a merge request to make the certificate validation page work without JavaScript. When the mentor merged it, he left a comment saying it looked good, and mentioned he'd open a follow-up issue to improve how the page looks,but suggested leaving that for other newcomers to pick up. That small gesture told me a lot about the spirit of this community: it's not about one person doing everything, it's about keeping the door open for the next person.
The feedback that taught me how the project really works
That second MR didn't get merged on the first try, and I'm genuinely glad it didn't.
When the mentor, Antonio Terceiro, first reviewed it, he left a list of requested changes. I'll admit my first reaction was a small sinking feeling ,the kind you get when you thought you were done and suddenly you're not. But I made myself slow down and read each comment properly, and something shifted. Every single comment was teaching me something about how the project is actually built.
The main points were:
- My validation view needed to be a
BuildableDetailView, not a plain view. The reason was something I had never considered: the DebConf websites get exported to static HTML after the conference, so they can be archived cheaply without a running server or database. My original approach queried the database on every request , which means it would simply break on the archived static version of the site. - Because of that, each certificate needed its own URL, like
/certificates/validate/<validation-key>/, so that every validation page could be exported as its own static file. - Invalid certificates should return a proper 404 instead of rendering an "invalid" page.
- The user-facing text needed translation marks, so it could be localized — exactly like the translation work I'd done earlier in the week.
Reading those comments, I realized the feedback wasn't criticism of me. It was a window into years of accumulated design decisions that I simply hadn't been aware of. You can't learn that from a tutorial. You learn it by submitting something imperfect and having someone who knows the system explain why it needs to be different.
Implementing the changes (and a debugging rabbit hole)
Once I understood why the changes mattered, the how became much clearer. I reworked the view to use BuildableDetailView, restructured the URL so each certificate had its own path, removed the "invalid" branch so missing certificates returned a clean 404, and wrapped the user-facing strings in translation marks.
But the implementation didn't go smoothly, and I think that's worth being honest about.
At one point, the validation page kept throwing errors no matter what I changed. I'd fix something, reload, and get the same failure. It was frustrating in that specific way where you start to doubt whether you understand anything at all. After a lot of digging, I discovered the real problem: the application was loading an old, installed copy of the code from the virtual environment instead of the source files I was actually editing. My changes were correct they just weren't the ones being run.
The fix was to reinstall the package in editable mode and clear out the stale copy that was quietly shadowing my work. It cost me a few hours, but I came out of it understanding Python's editable installs and Django's template loading far better than I would have from any amount of reading. Sometimes the bugs that waste your afternoon teach you the most.
After the fixes, I tested every case locally: a valid attendee certificate, a valid speaker certificate showing the talk title, and an invalid key that correctly returned a 404.
Seeing all three behave exactly as expected, after the frustration earlier ,was one of the most satisfying and gratifyin, moments of the week.
Learning to discuss before building
The other thing I worked on was a feature to let users opt in to appearing on the public attendee list. Some people like to see who's coming before they register themselves, so the idea was to let individuals choose to be listed.
This one taught me a different kind of lesson ,not about code, but about judgment.
A maintainer pointed out something I hadn't fully thought through: if you let arbitrary users make their profiles public, you create a spam vector. Someone could create fake accounts with spammy names or links that then appear on the public site. He said a conference needs to be able to completely disable the feature, and pointed me to a related discussion about handling abusive content.
My instinct a week ago would have been to immediately start coding a fix. Instead, I did something I'm proud of: I stopped, thought about it, and wrote out a plan. I proposed adding a setting that defaults to "off," so the feature stays completely disabled unless a conference deliberately turns it on. Then I asked the maintainer whether that matched what he had in mind before I wrote a single line.
It's a small change in behaviour, but it feels significant to me. Real engineering isn't just writing code quickly , it's knowing when to pause and make sure you're building the right thing.
What I learned this week
- How static site generation (via django-bakery) fundamentally changes the way you have to design views
- The difference between a plain Django view and a
BuildableDetailView, and why it matters for archived sites - How Python editable installs work, and how a stale installed copy can silently shadow your source code
- That code review is not a judgment of your worth , rther it's one of the fastest ways to learn the shape of a real project
- The value of discussing a design before implementing it, especially when there are concerns you might not have considered
What's next
I'm continuing to iterate on my open contributions and waiting to hear back on the attendee opt-in design before I implement it. The contribution phase is competitive, and there are moments it feels daunting, but I'm trying to focus less on comparing myself to others and more on doing each piece of work carefully and learning from every bit of feedback.
If I could tell other Outreachy applicants one thing, it would be this: don't be discouraged when a maintainer or mentor sends back a list of changes. I used to think a perfect first submission was the goal. Now I think the real goal is the conversation that happens afterward ,because that's where the actual learning lives.
This article is part of my Outreachy contribution phase for the DebConf/MiniDebConf websites project under Debian. If you're considering applying, I hope sharing my experience with you, the wins and the frustrating afternoons makes the path feel a little less intimidating.
Top comments (0)