Isoken’s Outreachy Journey

It’s been about a month since I wrapped up my Outreachy internship, but my journey with Debian is far from over. I planned to keep contributing and exploring the community, and these past few weeks have been busy

For the openQA project, we decided to explore how accurate local language installations are and see if we can improve the translations. While exploring this, I started working on automating a test for a specific bug report: Debian Bug #1111214

This is a test I had started by writing a detailed description of the installation process to confirm that selecting the Spanish_panama locale works accurately. I spent time studying previous language installation tests, and I learned that I needed to add a specific tag (LANGUAGE-) to the “needles” (visual test markers).

Since the installation wasn’t in English anymore, taking the correct screenshots and defining the areas took quite some time. I used the following command on the CLI to run the test:

`openqa-cli api -X POST isos ISO=debian-live-testing-amd64-gnome.iso DISTRI=debian-live VERSION=forky FLAVOR=gnome LANGUAGE=spanish_panama ARCH=x86_64 BUILD=1311 CHECKSUM=unknown`

While working on this, I got stuck at the complete_installation step. Because the keyboard layout had changed to Spanish, the commands required to confirm a successful install weren’t working as expected. Specifically, we had an issue typing the “greater than” sign (>).

My mentor, Roland Clobus, worked on a clever maneuver for the keys (AltGr-Shift-X), which was actually submitted upstream to openSUSE.

In this step, I also had to confirm that the locale was correctly set to LANG=”es_PA.UTF-8″. I had to dig into the scripts and Linux commands to make this work. It was a bit intimidating at first, but it turned out to be a great learning experience. You can follow my progress on this Merge Request here. I’m currently debugging a small issue where the “home” key seems to click twice in the final step, and after that, the test would be complete .

Beyond the code, I’ve been getting more involved in the social side of Debian:

• Debian Women: I attended the monthly meeting and met Sruthi Chandran. I’ve always seen her name as an Outreachy organizer, so it was great to meet her! She is currently running for Debian Project Leader (DPL). We also discussed starting technical sessions to introduce members to packaging, which I am very excited to learn.
• DebConf Preparation: I am officially preparing for my first DebConf! My mentors, Tassia and Roland, along with my fellow intern Hellen, have been incredibly supportive in guiding me through the application and presentation process.

So you want to join Outreachy but you don’t understand it, you’re scared, or you don’t know what open source is about.

Free and Open Source Software (FOSS) refers to software that anyone can use, modify, and share freely. Think of it as a community garden; instead of one company owning the “food,” people from all over the world contribute, improve, and maintain it so everyone can benefit for free. You can read more here on what it means to contribute to open source.

Outreachy provides paid internships to anyone from any background who faces underrepresentation, systemic bias, or discrimination in the technical industry where they live. Their goal is to increase diversity in open source. Read their website for more. I spent a good amount of time reading all the guides listed, including the applicant guide and the how-to-apply guide. 

I know newcomers are scared or unsure and would prefer answers from previous participants, but the Outreachy website is actually a goldmine, almost every question you have is already answered there if you look closely. I used to hate reading documentation, but I’ve learned to love it. Documentation is the “Source of Truth.”

• My Advice: Read every single guide on their site. The applicant guide is your roadmap. Embracing documentation now will make you a much better contributor later.

Now for the part most newcomers have asked about is the initial essay. I know it’s tempting to use AI, but I really encourage you to skip it for this. Your own story is much more powerful than a generated one. Outreachy and its mentoring organizations value your unique story. They are strongly against fabricated or AI-exaggerated essays.

For example, when I contributed to Debian using openQA, the information wasn’t well established on the web. When I tried to use AI, it suggested imaginary ideas. The project maintainers had a particular style of contributing, so I had to follow the instructions carefully, observe the codebase, and read the provided documentation. With that information, I always wrote a solution first before consulting AI, and mine was always better. AI can only be intelligent in the context of what you give it; if it doesn’t have your answer, it will look for the most similar solution (hallucinate). We do not want to increase the burden on reviewers—their time is important because they are volunteers, too. This is crucial when you qualify for the contribution phase.

There are two main stages:

• The initial application: Here you fill in basic details, time availability, and essay questions (you can find these on the Outreachy website).
• The contribution phase: This is where you show you have the skills to work on the projects. Every project will list the skills needed and the level of proficiency.

• A lot of people will try to create buzz or even panic; you just have to focus. Once you’ve gotten the hang of the project, remember to help others along the way.
• You can start contributions with spelling corrections, move to medium tasks (do multiple of these), then a hard task if possible. You don’t need to be a guru on day one.
• It’s all about community building. Do your part to help others understand the project too; this is also a form of contribution.
• Lastly, every project mentor has a way of evaluating candidates. My summary is: be confident, demonstrate your skills, and learn where you are lacking. Start small and work your way up, you don’t have to prove yourself as a guru.

• Watch this: This step-by-step video is a great walkthrough of the initial application process.
• Sign up for the email list to get updates: https://lists.outreachy.org/cgi-bin/mailman/listinfo/announce
• Be fast: Complete your initial application in the first 3 days, as there are a lot of applicants.
• Back it up: In your essay about systemic bias, include some statistics to back it up.
• Learn Git: Even if you don’t have programming skills, contributions are pushed to GitHub or GitLab. Practice some commands and contribute to a “first open issue” to understand the flow: https://github.com/firstcontributions/first-contributions

The most important tip? Apply anyway. Even if you feel underqualified, the process itself is a massive learning experience.

Twelve weeks ago, I stepped into the Debian ecosystem as an Outreachy intern with a curiosity for Quality Assurance. It feels like just yesterday, and time has flown by so fast! Now, I am wrapping up that journey, not just with a completed project, but with improved technical reasoning.

I have learned how to use documentation to understand a complex project, how to be a good collaborator, and that learning is a continuous process. These experiences have helped me grow much more confident in my skills as an engineer.

As I close this chapter, I am leaving a permanent “Proof-of-Work” in the Debian repositories:

• Full Test Coverage: I automated apps_startstop tests for Cinnamon, LXQt, and XFCE, covering both Live images and Netinst installations.
• Synergy: I used symbolic links and a single Perl script to handle common application tests across different desktops, which reduces code redundancy.
• The Contributor Style Guide: I created a guide for future contributors to make documentation clearer and reviews faster, helping to reduce the burden on reviewers.

In this final month, things became easier as my understanding of the project grew. I focused on stability and finishing my remaining tasks:

• I spent time exploring different QEMU video options like VGA, qxl, and virtio on KDE desktop environment . This was important to ensure screen rendering remained stable so that our “needles” (visual test markers) wouldn’t fail because of minor glitches.
• I successfully moved from familiarizing to test automation for the XFCE desktop. This included writing “prepare” steps and creating the visual needles needed to make the tests reliable.
• One of my final challenges was the app launcher function. Originally, my code used else if blocks for each desktop. I proposed a unified solution, but hit a blocker: XFCE has two ways to launch apps (App Finder and the Application Menu). Because using different methods sometimes caused failures, I chose to use the application menu button across the board.

I don’t want my journey with Debian to end here. I plan to stay involved in the community and extend these same tests to the LXDE desktop to complete the coverage for all major Debian desktop environments. I am excited to keep exploring and learning more about the Debian ecosystem.

This journey wouldn’t have been possible without the steady guidance of my mentors: Tassia Camoes Araujo, Roland Clobus, and Philip Hands. Thank you for teaching me that in the world of Free and Open Source Software (FOSS), your voice and your code are equally important.

To my fellow intern Hellen and the entire Outreachy community, thank you for the shared learning and support. It has been an incredible 12 weeks.

Hi there, I’m more than halfway through (8 weeks) my Outreachy internship with Debian, working on the openQA project to test Live Images.

My journey into tech began as a software engineering trainee, during which I built a foundation in Bash scripting, C programming, and Python. Later, I worked for a startup as a Product Manager. As is common in startups, I wore many hats, but I found myself drawn most to the Quality Assurance team. Testing user flows and edge-case scenarios sparked my curiosity, and that curiosity is exactly what led me to the Debian Live Image testing project.

In my previous roles, I was accustomed to manual testing, simulating user actions one by one. While effective, I quickly realized it could be a bottleneck in fast-paced environments. This internship has been a masterclass in removing that bottleneck. I’ve learned that automating repetitive actions makes life (and engineering) much easier. Life’s too short for manual testing .

One of my proudest technical wins so far has been creating “Synergy” across desktop environments. I proposed a solution to group common applications so we could use a single Perl script to handle tests for multiple desktop environments. With my mentor’s guidance, we implemented this using symbolic links, which significantly reduced code redundancy.

Over the last 8 weeks, my technical toolkit has expanded significantly:

• Perl & openQA: I’ve learnt writing with Perl for automation within the openQA framework and I’ve successfully automated apps_startstop tests for Cinnamon and LXQt
• Technical Documentation: I authored a contributor guide. This required paying close attention to detail, ensuring that new contributors can have faster reviews and merged contributions
• Ansible: I am learning that testing doesn’t happen in a vacuum. To ensure new tests are truly automated, they must be integrated into the system’s configuration.

Working on this project has shaped my perspective on where I fit in the tech ecosystem. In Open Source, my “resume” isn’t just a PDF, it’s a public trail of merged code, technical proposals, and collaborative discussions.

As my mentor recently pointed out, this is my “proof-of-work.” It’s a transparent record of what I am capable of and where my interests lie. 

Finally, I’ve grown as a team player. Working with a global team across different time zones has taught me the importance of asynchronous communication and respecting everyone’s time. Whether I am proposing a new logic or documenting a process, I am learning that open communication is just as vital as clean code.

Hurray! I have officially reached the 6-week mark, the halfway point of my Outreachy internship. The time has flown by incredibly fast, yet it feels short because there is still so much exciting work to do.

I remember starting this journey feeling overwhelmed, trying to gain momentum. Today, I feel much more confident. I began with the apps_startstop task during the contribution period, writing manual test steps and creating preparation Perl scripts for the desktop environments. Since then, I’ve transitioned into full automation and taken a liking to reading openQA upstream documentation when I have issues or for reference.

In all of this, I’ve committed over 30 hours a week to the project. This dedicated time has allowed me to look in-depth into the Debian ecosystem and automated quality assurance.

Reviewing my 12-week goal, which included extending automated tests for “live image testing,” “installer testing,” and “documentation,” I am happy to report that I am right on track. My work on desktop apps tests has directly improved the quality of both the Live Images and the netinst (network installer) ISOs.

I have successfully extended the apps_startstop tests for two Desktop Environments (DEs): Cinnamon and LXQt. These tests ensure that common and DE specific apps launch and close correctly across different environments.

• Merged Milestone: My Cinnamon tests have been officially merged into the upstream repository! [MR !84]
• LXQt & Adaptability: I am in the final stages of the LXQt tests. Interestingly, I had to update these tests mid-way through because of a version update in the DE. This required me to update the needles (image references) to match the new UI, a great lesson in software maintenance.

One of my favorite challenges was suggested by my mentor, Roland: synergizing the tests to reduce redundancy. I observed that some applications (like Firefox and LibreOffice) behave identically across different desktops. Instead of duplicating Perl scripts/code for every single DE, I used symbolic links. This allows the use of the same Perl script and possibly the same needles, making the test suite lighter and much easier to maintain.

During the contribution phase, I noticed how rigid the documentation and coding style requirements are. While this ensures high standards and uniformity, it can be intimidating for newcomers and time-consuming for reviewers.

To help, I created a contributor guide [MR !97]. This guide addresses the project’s writing style. My goal is to reduce the back-and-forth during reviews, making the process more efficient for everyone and helping new contributors.

For the second half of the internship, I plan to:

1. Assist others: Help new contributors extend apps start-stop tests to even more desktop environments.
2. Explore new coverage: Move beyond start-stop tests into deeper functional testing.

This journey has been an amazing experience of learning and connecting with the wider open-source community, especially Debian Women and the Linux QA team.

I am deeply grateful to my mentors, Tassia Camoes Araujo, Roland Clobus, and Philip Hands, for their constant guidance and for believing in my ability to take on this project.

Here’s to the next 6 weeks

Thinking about who I am addressing is a challenge, but it is an important one. As I write, I realize I’m speaking to three distinct groups: my friends and family who are new to the world of tech, newcomers eager to join programs like Outreachy, and the technical experts who maintain and sustain the projects I work on.

To my friends and family: Free and Open Source Software (FOSS) refers to software that anyone can freely use, modify, and share. Think of it as a community garden, instead of one company owning the “food,” people from all over the world contribute, improve, and maintain it so everyone can benefit from it for free.

Contributing to an open source project isn’t just about writing code. It could involve going over a ton of documentation and understanding a specific coding style. You have to set up your environment and learn to treat documentation as a “source of truth,” even if it’s something you help modify and improve later.

Where I come from, this world is fairly unknown, and it seemed quite scary at first. However, I’ve learned that asking questions and communicating are your best tools. Don’t be afraid to do your part by investigating and reading, but remember that the community is there to help you grow.

For the past few weeks, I’ve seen the importance of checking software quality before a release.

Imagine you download a new desktop environment, try to open the calculator or the clock, and it crashes or refuses to start. How annoying is that? Or worse, you download software and can’t even install it successfully. My work on creating tests for Debian using openQA is aimed at preventing these experiences. We simulate real user actions to make sure that when someone clicks “Open,” the application actually works.

In general, FOSS has empowered people to access and build technology freely. Whether you are here to use the software or you have the expertise to modify and explore it, there is a place for you in this community.

I’m writing this for you, whichever audience you belong to, to show that complex systems become less intimidating when you begin by asking questions.

That’s right: everyone struggles. You could be working on a project only to find a mountain of new things to learn, or your code might keep failing until you start to doubt yourself. I feel like that sometimes, wondering if I’m good enough. But in those moments, I whisper to myself: “You don’t know it yet; once you do, it will get easy.”

While contributing to the Debian openQA project, there was so much to learn, from understanding what Debian actually is to learning the various installation methods and image types. I then had to tackle the installation and usage of openQA itself. I am incredibly grateful for the installation guideprovided by Roland Clobus and the documentation on writing code for openQA.

Even with amazing guides, I hit major roadblocks. Initially, I was using Windows with VirtualBox, but openQA couldn’t seem to run the tests properly. Despite my mentors (Roland and Phil) suggesting alternatives, the issues persisted. I actually installed openQA twice on VirtualBox and realized that if you miss even one small step in the installation, it becomes very difficult to move forward. Eventually, I took the big step and dual-booted my machine to Linux. Even then, the challenges didn’t stop. My openQA Virtual Machine (VM) ran out of allocated space and froze, halting my testing. I reached out on the IRC chat and received the help I needed to get back on track.

When I’m struggling for information, I follow my go-to first step for research, followed by other alternatives:

1. Google: This is my first stop. It helped me navigate the switch to a Linux OS and troubleshoot KVM connection issues for the VM. Whether it’s an Ubuntu forum or a technical blog, I skim through until I find what can help.
2. The “Upstream” Documentation: If Google doesn’t have the answer, I go straight to the official openQA documentation. This is a goldmine. It explains functions, how to use them, and lists usable test variables.
3. The Debian openQA UI: While working on the apps_startstop tests, I look at previous similar tests on openqa.debian.net/tests. I checked the “Settings” tab to see exactly what variables were used and how the test was configured.

1. Salsa (Debian’s GitLab): I reference the Salsa Debian openQA README and the developer guides sometimes; Getting started, Developer docs on how to write tests

I also had to learn the basics of the Perl programming language during the four-week contribution stage. While we don’t need to be Perl experts, I found it essential to understand the logic so I can explain my work to others.

I’ve spent a lot of time studying the codebase, which is time-consuming but incredibly valuable. For example, my apps_startstop test command originally used a long list of applications via ENTRYPOINT. I began to wonder if there was a more efficient way. With Roland’s guidance, I explored the main.pm file. This helped me understand how the apps_startstop function works and how it calls variables. I also noticed there are utility functions that are called in tests. I also check them and try to understand their function, so I know if I need them or not.

I know I still have a lot to learn, and yes, the doubt still creeps in sometimes. But I am encouraged by the support of my mentors and the fact that they believe in my ability to contribute to this project.
If you’re struggling too, just remember: you don’t know it yet; once you do, it will get easy.

Hello, my name is Isoken, I’m a software engineer and product manager from Nigeria. I am excited and grateful to begin this journey as an Outreachy intern working on the project “Debian Images Testing with OpenQA”. 

I am particularly drawn to helping solve problems for people; it keeps bugging me till I can find a way to help. This interest in problem-solving and improving quality is what drew me to this project.

OpenQA is an automated test tool that simulates a user’s interaction by looking at the screen and sending actions like mouse clicks and keyboard inputs. It takes screenshots and compares the image to known reference images to verify if the system is behaving correctly.

During the contribution phase (which was 4 weeks), I got to know about Debian software, it’s different mode of installation and available different desktop environments, at first I felt intimidated as most of it was new to me, but the setup material and docs for the project made it easy for me, the fact that it looked like a gradual process, getting to know the program, registering the steps in mind and then take notes of every step and visuals, writing it in a way another developer would understand (this is called detail level 3), and then translate it to test code level 1.

I contributed to improving the installation documents and a detail level 3 doc for a bug report on the system locale being incorrect. This strengthened my documentation skills and ability to adjust to the writing style of the project.

I also started working on app start-stop tests for two desktop environments. I was able to explore, check the applications, and note their differences and similarities. It was really interesting to me; this was where I started writing on coding level 1, and my tests started passing. I will spend the next few weeks continuing on it and hopefully creating a way to synergize the tests and make it easy to maintain later on.

I am also grateful for the assistance from other candidates during the contribution stage and the privilege of having the mentors, Tassia Camoes Araujo and Roland Clobus, and Philip Hands, to guide and correct me through the internship period. I will share my progress regularly here on the blog. You can follow the progress of the work here on the main repo. 

Wish me luck on the rest of this journey