 I'm a UX engineer and based in Athens, Greece. I'm also a core team member at GitLab. I've been contributing for a year or so. At work, I lead the further engineering efforts and UX design. And at GitLab, I participate primarily in discussions around triage operations, developer productivity, and also response time for community contributions and mentoring and engaging other community members with their contributions. So this started about about a half a year ago. I decided I wanted to give back to open source by contributing. And GitLab seemed like a really nice project for me. Back then, I had zero experience with Ruby, Aspect, SAS, and most of the technology stuck behind GitLab. So during the first month, I was always trying to reverse engineer parts of the code and see what I can fix. I remember that every time I ran into any issue, I was thinking, could I fix this? Is this interesting for me to pick up? And this actually led from zero to one, learning a lot about front-end engineering and testing startups in an open source project. That is a production-grade project. It's worth noting that half of the contribution I've made during that time, I wasn't sure that they could make it through and make it within the product. And another thing that was also beneficial was actually learning about view components, a view in general. I was doing this for some months, and then I noticed that the front-end team at Vue actually started utilizing Vue from the front-end architecture. I had very little experience with Vue back then. And I had to try locally old changes and push for a magic quest and see what happened. And during that time, every time I ran into a magic quest from a front-end team member at GitLab, I started the review comments and some of the changes they made. So you can learn so much by reading other people's code. This is not obvious maybe at first, but almost everything I know about Vue, I've learned through reading magic quest and code reviews from the front-end team at GitLab. One of the smallest but impactful contributions that I made back then was adding the shortcut button to the markdown editor to insert the markdown table ready to use. I was actually struggling to copy and paste the markdown code every day back then. So when you start collaborating with the team members at GitLab or start contributing, you actually notice this for the very first time that you're about to enter a very welcoming community. GitLab core values are embodied in every small interaction between team members and also the guided community. So this led to receiving so much support while contributing makes you want to be more supportive in your day-to-day workflows. So I tried to bring this in at my day job and actually improve collaboration with my colleagues and the other team members. So of course, not everything looks good. Maybe contributing regularly actually can be fulfilling, but as you gradually pick up larger and more complicated issues, GitLab works asynchronously and distributes a team, a remote team. They know how to work remotely, effectively and efficiently. So when I started doing this, I was a bit hyped and maybe excited about this and started being all around the clock and responding to comments. And during weekends too, the top image here is my activity during the first month, which there were no breaks and working during weekends also. On the bottom, while more a bit intense and focused, I decided to take some breaks and actually not avoid working during the weekends and contributing during the time. So what I can advise here is that you can take it easy pace. Asynchronous collaboration takes time. Only more teams like GitLab know how to work and handle all this workload, but when you start contributing, maybe it's best to try to bring people near your time zone. This will make response time better and avoid working too much. This also led to some burnout during the first month, but we got over it soon. Another thing is that after contributing for a year or two, for a year or so, yes, I run into the design system, Pajamas, which actually powers the product and it's a collaboration between the UX and front-end teams that create reusable components in view. And realizing that this is exciting for me, I jumped into component implementation and tried to help collaborate wherever I could. This includes actively working with the front-end engineers, product designers, and getting involved in discussions about the design system and future steps. Currently, the design system powers around 400 user interface components that are used within the product. So being part of this, helping scale the design system and utilizing components within the software development lifecycle of the GitLab product is actually what fascinates me more at the moment, and I'm really enjoying this. Another thing that I noticed is that practice and contribution collaborating with Magicrest, which is the standard way of collaborating at GitLab, also enabled me to adopt this kind of workflows at my day job and every side project I work on. Having access to the Handbook, which is an open handbook that includes how engineering workflows work at GitLab. It was also eye-opening for me and I was inspired by these workflows related to code reviews and cross-fictional team members, teams. Every time I, while contributing, I had to go through the code review and Magicrest. So I was wondering if this could be something that I could adopt at work. So forking the workflows of the GitLab and adopting similar practices actually improved the development lifecycle and allowed to work more effectively across multi, cross-fictional teams. Of course, it took months to adopt the mindset of the DevOps team across teams and projects from planning, issue tracking to CICD that is build, test and deploy. So for me, it's clear that the DevOps is the new way to go and the standard new way of building and deploying modern applications. Future steps could include integrating also security in the development lifecycle, which is also important. We also tried, recently we tried a project where we actually shipped and on day one, we had around two critical vulnerabilities and 45 vulnerabilities in the front end code. That was because we didn't pay attention to dependency scanning and vulnerabilities that were published for these packages. So that's it for me. Thanks for listening. If you have any questions, feel free to ask me later.