Introduction
Giselle is developed as an open-source project and is publicly available on GitHub. Anyone can contribute through code or documentation. In this article, we introduce one example of a contributor who started with OSS contributions and is now participating in the project as a team member.
Contributing as an OSS Contributor
My first Pull Request was a simple typo fix. It was my first time contributing to an open-source project, and I still remember how nervous I felt when submitting it. After that, I worked on bug fixes and small feature additions.
My first PR: fixing a typo in the component filename
What stood out to me was how thoughtful and consistent the Pull Request interactions were. Reviews were rarely delayed or left unanswered, and feedback often included clear explanations about design intent and possible improvements. This review process made it easier to understand the project and encouraged continued contributions.
A review comment with suggestions for improvement
Joining as a Team Member
After making ongoing contributions as an OSS contributor, I was invited to join the project as a team member. I am currently working on feature improvements and adding new functionality directly related to the product.
Because of my prior experience with the codebase and development workflow through OSS, onboarding was smooth and required little adjustment. The lack of a clear boundary between OSS contributions and production work is one of the defining characteristics of Giselle.
After working on several smaller tasks and getting familiar with the codebase, I took on a more substantial feature: extending the GitHub RAG system.
Extending GitHub RAG System to Support Issues
In developing this feature, having an existing foundation for GitHub RAG built around code and pull requests was a significant advantage. These resources were already managed with metadata, which made it possible to extend the system without starting from scratch.
Connecting a GitHub Vector Store (Issue) to a Vector Query node
However, working with Issues introduced a different set of challenges. Unlike pull requests, Issues do not have a clear point of completion; their state can change repeatedly through open and close cycles. In the existing system, changes to an Issue's status would trigger a full re-embedding of its content, even when only the metadata had changed.
Ideally, when an Issue's status changes, only the relevant metadata should be updated. To address this, I added a mechanism to detect state changes and update only the necessary information. This allowed us to avoid unnecessary re-embedding while still keeping the data up to date.
During this process, I initially worked by splitting the implementation into multiple pull requests. However, as unexpected design constraints surfaced, the required changes accumulated, and the final pull request became larger than intended. In retrospect, it would have been better to first implement and validate the full flow locally, and then break the work into smaller, more focused pull requests. That approach would likely have made the review process smoother.
What Giselle Values
Even small fixes or suggestions are more than welcome as a starting point. By writing code and participating in discussions, contributors naturally build a stronger connection with the project. While this article presents just one example, Giselle will continue to welcome participation in many forms through open and collaborative development.