Preparing Our Group Presentation

This week, our group prepared the final presentation for our open source project. To make sure every member had the chance to share their own perspective, we divided the presentation into different sections so that each person could focus on a specific part of the project and their personal contributions.

Our group organization looked like this:

• Bella: Introduction
• Harry: Challenges
• Tianlang: Best Moment
• Willow: Lessons
• Vincent: Looking Back

For my part, I focused on looking back at my contributions to pandas throughout the semester. While preparing the slides, I realized that the presentation itself was also a reflection on my open source learning journey, not just a summary of what I did.

At the beginning of the semester, I was not familiar with pandas or large open source projects in general. The size of the codebase felt overwhelming, and even small tasks took much longer than I expected. I started with documentation PRs to learn the code structure, documentation style, contribution workflow, and CI system. These early PRs may seem simple, but they were extremely important because they helped me become comfortable with the basic process of contributing.

Later, I moved on to fixing a real bug in Series.combine_first, which was a much bigger step. This experience helped me better understand debugging, edge cases, and how to communicate with maintainers when responding to review comments. Instead of just changing code, I had to think carefully about how the fix might affect other parts of the library and how to test it properly.

Preparing the presentation made me realize that open source contribution is not only about writing code. It is also about understanding how large software projects are maintained collaboratively over time, and learning how to participate in that process respectfully and patiently.

Presentations That Impressed Me

Among the presentations this week, two groups especially stood out to me: the Frosty group and the p5.js group.

For the Frosty group, I was impressed by how user-oriented their contributions were. Brandon especially seemed very familiar with the platform and approached problems from the perspective of real users. For example, they worked on issues related to reset buttons and accent color customization. These improvements may look small technically, but they directly improve user experience, which is very important in real software projects. It reminded me that not every meaningful contribution has to be a complex algorithmic change. Sometimes, fixing the small details that users actually interact with can have just as much impact.

The p5.js group also gave a very strong presentation because their contributions were highly visual and easy to demonstrate. Since p5.js is a frontend-focused open source project, it was very intuitive to see the impact of their work directly on the webpage. This made their presentation engaging even for audience members who were not familiar with the underlying code.

One example I remember was related to language translation support. When the website failed to support certain translations, the problem immediately appeared visually on the webpage, making the issue easy to understand even for people unfamiliar with the codebase. This kind of clear, visible feedback is something that backend-heavy projects like pandas usually do not have, and it made me appreciate how different open source experiences can be depending on the project.

Reflection

This week’s presentations helped me better understand that open source projects can be very different depending on the type of software and the community behind them.

Some projects focus heavily on backend logic and debugging, like pandas, while others focus more on user interaction and visual behavior, like p5.js or Frosty. The skills required, the way contributors interact with maintainers, and even the way progress is measured can vary significantly from one project to another. However, all of these contributions are valuable because they improve the usability and quality of the project in different ways.

Listening to other groups also made me realize how much I had grown over the semester without noticing it day by day. At the start, even reading an issue thread on GitHub felt confusing. Now, I can navigate a large repository, follow CI logs, and engage with maintainers’ feedback with much more confidence.

Overall, this week felt less like a normal class presentation and more like a summary of everything we learned about open source development throughout the semester. It was a good reminder that the value of this experience is not measured only by the number of merged PRs, but also by the understanding we gained about how real software is built and maintained in the open.