About Me
I'm Guan-Ming (Wesley) Chiu, currently pursuing a Master's degree in EECS at National Taiwan University. I'm passionate about open source contributions and interested in both frontend/backend development and data engineering.
Why Apache Airflow?
Before contributing to Apache Airflow, I didn't even know about the project. It was through articles from opensource4you that I started paying attention to it. Later, I discovered that Airflow is an Apache Software Foundation Top Level Project used by many well-known companies. It seemed interesting, and since I was familiar with both React and Python, I decided to start contributing!
Contribution Statistics (2025/04/01 ~ 2025/09/30)
| Category | Count |
|---|---|
| Pull Requests (Merged) | 139 |
| Reviewed PRs (Merged) | 66 |
| Contribution Rank | #34 |
| Time Investment | ~3-4 hours per day |
On 2025/09/30, I received an invitation from the Airflow PMC to become an Airflow Committer!
Journey
After reading articles by Wei Lee and Jason, I decided to start with the Providers component, as it was less complex and a great way to familiarize myself with Airflow's architecture. I began by tackling good first issue labels and exploring old PRs to learn from others' approaches.
While exploring old PRs, I was fortunate to find #33911. I discovered that many users were relying not just on pandas but also on Polars for data handling. However, Airflow only provided get_pandas_df(), which was inconvenient for Polars users. This inspired me to continue the work in #48875, where I added a universal get_df() method allowing users to choose their preferred DataFrame library. The main changes were:
- Added
get_df()andget_df_by_chunks()supporting different DataFrame libraries - Deprecated the old
get_pandas_df()while maintaining backward compatibility
After several iterations, the PR was merged by Elad!
Besides the changes in common-sql, I needed to integrate this change across other providers. This took considerable time, and overall, I contributed 18 PRs affecting 10+ different providers. I felt a great sense of accomplishment, and it boosted my visibility in the community. Although I wasn't sure if anyone would use these changes, seeing PRs merged was incredibly satisfying and motivated me to dive deeper into open source!
Once I had a better understanding of Airflow, I shifted focus to Airflow Core, specifically working on the UI and API Server (frontend and backend). I started with bug fixes, code refactoring, and small feature implementations while gradually familiarizing myself with the entire Airflow architecture.
Key contributions during this stage:
- #49475 - Support for External Log Links API and UI
- #50309 - Added Task Group detail page
- #50443 - New Task Instance bulk actions API endpoint
- #50746 - Optimized log rendering performance with virtualized rendering, achieving ~7x speed improvement
- #51376 - Implemented RTL (Right-to-Left) language support
After about two months of accumulation, I had a deeper understanding of Airflow's architecture and gradually began participating in the development and discussions for Airflow 3.1's major features.
Eventually, I began participating in important feature development and discussions for Airflow 3.1, and gradually took on code review responsibilities to help newcomers make their first contributions. This period was when I contributed the most to Airflow. My contributions were included in the top 20 contributors for the recent 3.1 release.
I had the opportunity to participate in developing an important feature for Airflow 3.1: Human-in-the-Loop (HITL)! This feature is based on AIP-90 and provides a mechanism for users to intervene during task execution to correct AI judgments or handle steps requiring human confirmation.
In PR #53035, I was responsible for implementing the UI for AIP-90, including the display and operation interface for HITL task instances and API integration. Since the AIP only had a rough sketch of the UI without detailed UIUX design, I needed to work with the community to reach consensus on the final implementation. The discussion process was quite interesting! Everyone had their own perspectives, but all aimed to improve the UI. The discussion atmosphere was lively and positive. Through this, I learned that great open source software is built through collaboration, discussion, and collective effort.
I'm particularly grateful to Wei Lee for guiding me through this process, helping me solve many problems, and patiently discussing design choices with me. I learned a lot about frontend-backend collaboration and large-scale feature development.
Another interesting development was the Gantt Chart reimplementation! Since Airflow 3.x completely rewrote the UI from the old Flask version to React, the new UI was missing the Gantt Chart feature, making it inconvenient for users to track task execution times and dependencies.
In PR #51667, I reimplemented the Gantt Chart functionality, primarily using Chart.js with the dayjs adapter. I integrated the Gantt Chart into the Run, TI, and GroupTI pages and placed it in the left panel (a position decided after much discussion). I encountered some challenges during implementation:
- Performance Optimization: When a DAG run had 100+ task instances, I needed to ensure the Gantt Chart rendered smoothly. I referenced Chart.js documentation and forum discussions, reduced unnecessary animations, and refactored significant portions of code. Eventually, I achieved smooth rendering even with 100+ task instances.
- UI/UX Discussion: The team discussed whether to place it on the right or left panel, and debated details like tooltip design and header height. Everyone participated actively, and after multiple iterations and testing, we reached a satisfactory result.
Although this PR required nearly a month of revisions, it eventually merged into Airflow 3.1.0. I'm very grateful to Brent, Pierre, and Jens for their patient and meticulous reviews. Seeing the Gantt Chart return to the new UI was incredibly satisfying!
I was fortunate that both the HITL UI and Gantt Chart PRs were selected as PR of the Month for August 2025! As a result, I was invited to present at the Airflow Townhall for the first time to share the development process. Honestly, presenting in English at an international event for the first time was incredibly nerve-wracking - I stuttered throughout, and the live demo nearly failed (I forgot to prepare properly!). Fortunately, everything went smoothly in the end. While I don't think I presented well, I was happy to have the opportunity to share my contributions with the community!
- learn -> Becoming a Committer certainly doesn't mean I fully understand Airflow. I believe I'm currently most familiar with the UI component, and there's still much to learn in other areas.
- review -> I hope to participate more in code reviews, practice giving constructive feedback, and help guide new contributors to integrate into the community more quickly.
- design -> Participate more actively in Airflow's architectural design discussions and contribute my own ideas and suggestions.
- share -> Try to share these experiences with more people and encourage more contributions to open source!
What I Gained
- Technical Skills
- Writing code in large projects isn't just about solving immediate problems. I also needed to consider long-term maintainability, backward compatibility, and performance impact. I had to understand various design patterns and system design principles. Since many people and companies use Airflow, small changes can affect many users, requiring careful consideration of details. This practical understanding of software engineering is something I could never learn from side projects or school assignments alone.
- I could observe how different experts handle problems and implement solutions by simply opening PRs. Although the context was overwhelming initially, gradually understanding their approaches taught me that great developers consider many details and write clean code. This has been incredibly valuable for learning.
- Communication
- Beyond coding, learning how to clearly explain design motivations in PRs, how to give constructive reviews, and how to find consensus when there are disagreements is sometimes harder than coding itself. Good communication makes discussions more efficient and creates a positive community atmosphere.
- Friendships
- Besides skill improvement, I've made interesting friends through open source. We discuss technology, share what we've been working on, and joke about code reviews. Especially with the opensource4you community, everyone is incredibly helpful. Whenever I had questions, someone would help, and we'd discuss implementation together. They'd notify us about meta-issues we could work on. This feeling of working together towards a common goal while having fun is truly wonderful!
How to Start Contributing to Apache Airflow?
- Recommended Reading:
- Read Documentation: Airflow's contribution guide is very clear.
- Familiarize with the Environment: Use
breezeto set up the development environment and run basic tests. - Start with Simple Issues: Look for good first issue labels, small bug fixes, or translation maintenance.
- Write Good PR Descriptions: Clearly explain
Why / Howto help reviewers understand. - Learn from Others' PRs: Observe how others solve problems and communicate. If someone abandoned a halfway-done PR, you can continue their work. Or if you're familiar with a particular area, you can try giving reviews.
Big Thanks
- Chia-Ping, who founded opensource4you. Without it, I might never have known about Airflow or met such interesting open source friends.
- All Airflow PMC Members and Committers who provided guidance through reviews and discussions, especially Brent, Pierre, Jens, Jarek, and Elad.
- Wei Lee and Jason for their articles and insights that helped me quickly understand Airflow. They also helped me review most of my Python code (I'm really a Python beginner!).
- Roy Lee for working on frontend PRs together and having fun. You're next!