Eventyay: How we are building eventyay with the power of community and AI

Transcript

Cool. So, uh I'm going to uh be speaking mostly about event A and how uh we built a global community that is now actively being accelerated by AI. So uh rather than only showing the features I'll cover the contribution behind the platform the engineering failures that we faced uh that we can only see when we are conducting and like working with an actual event and why maintainers and contributors remain the center for even after coding begins and ends. go.

Uh okay. So, uh to get started, event covers more than just ticket sales. It begins with submissions uh and speaker reviews. It moves into registrations, payments, tracking uh ticket uh and check-in, badge printing, exhibited workflows and followup even after the event. So when these are separate products, organizers must synchronize data and solve integration problems on the event day. Our goal is to create one extensible event stack with APIs and plug-in allowing communities to apply and adapt whenever to whatever kind of event that they are conducting. This is

why architecture and interoperability matters just as much as the individual features. But no single team built all of this. There are a lot of people behind this and we basically break it down into four phases when we think of building the architecture for an event. So moving on, Fossia has a global contributor community and programs like Google Summer of Code. Programs like Google Summer of Code provide a structured on ramp. But the goal is not simply getting a pull request merge during a program or during one of the contribution runs. A healthy path is to move from discovery to first

contribution to review to ongoing maintenance and eventually mentorship back to new contributors. In my own experience, reviewing and deploying event changes taught me as much as writing the initial feature that I started uh when I was building it. The evente as an ecosystem improved by many contributors from around the world working on architecture uh integrations and operations over the time. This collaborations let us expand the platform without turning everything into a single monolithic structure.

Uh I don't see the slide. Okay. Uh so yeah, one of the main things that has helped us throughout is an active collaboration that we have had with the contributors all around. So, one of the main things that we do is we make sure that we have a peer-to-peer review call at least two weeks per week during the entirety of of Google Summer of Code programs where we get all the contributors into a single meeting so that no one feels left out and we get to speak one-on-one with each other and

each other helps to review each other's PR. So the contributors who start the program as learners by the end of the program they become the mentors themselves to onboard new people and to uh get new contributors and AI has been playing a very crucial role in this because unlike previous times reviewing a PR is not a very complex task or raising a PR is not a very complex task. So over the past few months we have been getting a ton of spam PS. People are just making up things and putting ps and hair has been helping us a lot to review them. But before I get to the AI part uh the ecosystem of eventia has been

expanded rapidly you uh in the past few months and most importantly we have expanded our plug-in ecosystems with a bunch of new plugins. Uh, one of the main areas of expansion is team shifts. It is a complete end-to-end volunteer management system. This lets organizers manage volunteers and assign shifts and responsibilities to volunteers at the event. Next up, we have V editor. It is a complete end toend postevent video content management system. So if you are an organizer who has ever organized an event and had the issue of dealing with video management after the event, we have V editor to take care of it. And we have expanded the capabilities of

exhibition. It can now handle sponsorship managements as well. And we also have the social media and hub Hubspot uh plug-in to integrate CRM operations and other social media operations. Now let's take a look at the moment when architectures and features meet reality. Development is calm compared with a registration desk at a busy conference. People arrive in waves. Someone's QR doesn't scan. A ticket is registered for the wrong person. A badge printer disconnects. A volunteer needs to find an attendee immediately. At that point, the code is not an abstract PR. It is the experience of an attendee and the

responsibility of the team operating the event. We learned that a successful check-in system has to be forgiving, fast, and simple to operate even under stress. That changed how we evaluated our engineering decisions. At a high level, the flow scan, validate, redeem, get a badge, confirm, but each handoff can fail independently. We had to think about device initialization and authorization. How to redeem a order position, how the API responds when a request is invalid, and how the request and print a badge PDF.

In practice, proper content types, accepted headed matters. a lot of technological jargon behind and even day workflow needs explicit statuses and recovery parts at every single point of failures across these parts. So a successful API call is not enough to produce a successful badge. There are a lot of other human factors involved in getting this. The hardest lessons showed up in understanding all of these edge cases that an organizer actually has to face during one of these events. So the first step is to make these points of failures visible and actionable. A 406 response or a validation error may be technically

correct but the person at the desk needs to know what to do next. They need to understand what is the error. Second, an end-to-end testing is essential. Like any project, any software project, walking in API won't tell you whether the badge print is in kiosk mode, whether a browser block uh is requested or whether a scanner input is handled cleanly. Third, a user experience is a reliability feature. Volunteers cannot navigate complicated technical controls while hundreds of people are entering into the event. We need a clear search status feature and ways to recover from mistakes. I would emphasize that these practical lessons not evidences that

every possible offline or printer condition has already been solved. There are some things that probably are out of our hands at all times and this is precisely where we rely on AI to assist us but where human judgment still stays an essential part. AI is particularly a valuable resource to opensource newcomers because it can help them understand an unfamiliar code base before they know every module. It can locate code paths, explain how a view or a serializer is wired, draft test and help summarize a very complicated view, but it also creates a new problem. More code generated means

more reviewer burden. 10 PRs are not necessarily more valuable than one carefully debugged fix. The important questions is can you explain this change? Did you test the actual behavior? Does it fit in the architecture or will you carry it later after the merge of the PR and A should reduce repetitive work and help us learn not replace the maintainers or make review optional. The next step is to apply AI at the workflow level rather than just the editor.

Uh so AI can be used more than code generation. So our target is agentic event management. Think about assistance that help an organizer configure an event. Find schedule conflicts, draft communications, form structured session data or summarize operational issues all in one place. But the distinction matters. These are directions we are exploring. not a claim that a fully autonomous agent can run event year or all your events autonomously. Real deployments will require permissions, traceability, review checkpoints and clear boundaries. This is also why a clean plug-in and API architecture is

valuable. It gives future assistants welldefined actions and data controls rather than uncontrolled access to every part of the system. So how do we sustain the people who will maintain both the platform and these new capabilities? A community is not sustained by one hackathon or one GOG cohort. It is sustained by review cycles, approachable maintainers, documented expectations and contributors who keep coming back. Automation can help with transparency.

For example, uh one of the forious projects scrum helper can summarize GitHub activity but it cannot replace an actual conversation with a contributor and AI can help write a patch but it cannot take responsibility for a production event. The same person who joined through a beginner issue at some point may review a PR, manage a release or help others onsite like a lot of our contributors are doing here today. That is how a small group can support a larger platform. I'll close with three practical things that we can take away.

My three uh takeaways are pretty straightforward. First, build system. Model the entire user journey and boundaries between components. Second, build trust. Real world reliability and meaningful reviews matter more than commit counts. Third, build people. Mentorship ownership returning contributors are what keeps an open-source project alive. A is an important accelerator. But the strongest thing about event is still that a global community can build, review and deploy and improve the platform that runs real events. So thanks to the Fosia community and I invite all of you guys to

contribute and check out uh event. Uh you guys can scan this QR and check out event. Uh if you have any questions regarding event, we have a workshop today at 12 12:00 at the uh builder stage right outside. You guys can come check out you'll have uh all the uh developers and contributors behind event at the workshop and you can ask any questions and hopefully uh we get uh your first good contribution uh towards event and