One of the side projects I have going these days is working with a small team on a Drupal instance for Fedora called Fedora Insight. Our initial rollout is pretty conservative in its goals, as I discussed in a previous post. We wanted to create a simple platform (at the outset) where both the awesome contributors at the Fedora Weekly News, and the Marketing team, could both publish their original work, and also promote selected material from the Fedora Planet. We have lots of great places where content is available, but Insight brings some of them together in a way that’s easier for non-contributors to navigate. So Phase 1 was all about completing just those simple goals.
At the same time, we realized throughout the process that this could merely be the first step in providing some more content options for the project. And now we’re inviting you to pitch in your ideas for Phase 2 of our plans. If you have a concept for a way we could better expose or manage content through Insight, add it to the wiki page here. We are accepting ideas until May 24, 2011.
Hey wait, isn’t that date important for another reason? Oh yeah — Fedora 15 is released that day! So I guess that’s a good way to remember the deadline then.
Now, we can’t guarantee we’ll be able to make every idea a reality in Phase 2. But we’ll definitely consider each one, and then prioritize based on available people-power and the impact each goal could have if comlpeted. If you want to help do the Drupal development work required to make your idea happen, we’d love to have you on our team!
I’ve read that Hiemanshu Sharma is working on a FOSS events system that would take shape in Fedora and could be used in other FOSS projects. One of the things I asked Hiemanshu and his mentor Juan to consider was whether it might make sense to build this on top of Drupal so that it would (a) leverage a well-known framework, (b) benefit lots of people beyond the Fedora Project, and (c) maybe even be something system owners (our Insight team being just one example) could integrate with other content over time. I’m really looking forward to hearing more from them on our list about their plans and whether they’re able to leapfrog existing bits such as those in the COD project.
Our team works in an open, transparent process, like all Fedora teams. You can find information about our team, meeting schedule, communication resources, and other data on the Insight wiki page. We look forward to hearing from you.
Depending on your background, where you live, and your personal predilections, you may or may not be used to any kind of overnight noise. When staying in a hotel, this is a concern for any guest. Even if you frequently stay in hotels, each new location is an unfamiliar environment, and humans just like any animal are predisposed to be less comfortable in a place they don’t know.
Because there are railroad tracks that run nearby the Courtyard Tempe Downtown, the planning group for FUDCon Tempe wanted to do a little extra to make your stay comfortable. We bought disposable earplugs (the kind you can roll and insert) — you can pick up a pair Friday night to help you sleep easier.
It’s impossible to predict whose sleep is bothered by train noise. For example, my family stayed once at a bed and breakfast located right next to the old L&N railroad line where it ran through downtown Henderson, Kentucky. During our stay, my wife didn’t seem to have much problem sleeping through the train noise. (It’s probably fair to say she’d been conditioned over years of my snoring.) On the other hand, it really bugged me and our kids, so we gave them earplugs. Problem solved!
Anyway, just wanted to let people know that we had comfort aid available for anyone who thinks they might need it. If you decide to use earplugs, though, remember to turn your alarm device up so that you can hear it! We’ll be opening FUDCon promptly at 9:00am Saturday.
One of the hallmarks of the Fedora Users and Developers Conference, or FUDCon, is that it’s gone global. We just wrapped up another stupendous European event in Zurich this weekend, and we’re already deeply into planning another FUDCon in Tempe in January. Lots of people may also know that we make sponsorships (subsidies) available for our global FUDCon events.
But how do these sponsorships actually work, with regard to paying for stuff like airfares and lodging?
The cost of actually getting from Point A to Point B can be a hindrance for contributors. So we try to make it easier for people who are doing good work to get to FUDCon where they can collaborate in person. The way we do that is by directly buying airfares or other travel tickets. To some extent, we become a little travel agency that serves a small pool of attendees who otherwise couldn’t get to FUDCon. Sending cash advances is possible in some cases, but it’s non-optimal because of the way the accounting works. Buying directly saves time and effort, plus it’s a little more of a personal touch.
No matter the method, there’s always some work involved. It’s worth it, though, when you consider not only what contributors get out of the event, but what they put into it as well! A day of person-time to book travel for a dozen people yields a dozen people coming to FUDCon and clocking several dozen hours of learning, teaching, and good old-fashioned work. That’s a pretty phenomenal ROI before you even start counting the thanks and goodwill of colleagues that you get to send to a fantastic event!
We rely on the subsidized people to make their own hotel reservations. Most people who come to FUDCon can cut their costs by sharing a room with someone — double occupancy saves money. The logistics of finding roommates can seem complex, but I’m hoping this post makes it simpler:
At the hotel, sponsored folks should have to worry as little as possible about their lodging. We take care of the bill for anyone we’re subsidizing at checkout time — it’s that simple. Having a group set up at the hotel where the organizers can deal directly with the hotel management makes things easy for everyone, and also ensures us a good rate on the hotel.
By the way, for the upcoming Tempe event, we were able to secure a rock-bottom price on lodging for a very popular area (the Phoenix area in wintertime) because we knew there were a lot of people who would be participating in the event and would want to stay for the weekend. You can help by making your reservations as soon as possible. Our group rate ends on November 5, so visit the lodging section on the FUDCon Tempe wiki page now, and use one of the handy links to make a reservation!
We have a wiki page devoted entirely to the sponsorship/subsidy process. The decisions are made by those who show up to help plan and execute the FUDCon event, and they’re all Fedora community members who want to make sure the maximum number of participants can attend. And just like other FUDCon events, the planners work hard to include people from other regions, ensuring we have some participation from LATAM, EMEA, and APAC regions for the North American event for example.
In the specific case of the upcoming Tempe event, the planners focused on bringing in people who would commit to help plan and execute future FUDCon events in their region, regardless of whether it was held in their locale or country. That helps us spread the sparkling, rainbow-shooting unicorn magic* of FUDCon globally, and increase the community’s ability to drive and improve these events.
While we have hit our limit on subsidies for the moment, we are still looking for other ways to enhance our subsidy fund. For instance, some of the event organizers are reaching out to potential sponsors who love free and open source software, to see if they’d like to help us defray a few costs. That helps us divert more funds to sponsor additional community members. You can see our current ticket list in the Trac instance we use for planning.
If you’re interested in helping with the work of planning and organizing, why not join our mailing list and come to a meeting? We welcome community participation and you’ll find it’s a great way to help your fellow Fedora community members. See you there!
* Just seeing if you’re still reading.
I was in Raleigh, North Carolina all day yesterday. I drove down in the morning so I could appear on a panel with a couple amazing people — Chris Grams and Tom Rabon. Returning to the home office today, I’ve been reading some of the blog reports that have started rolling in from Fedora contributors who are attending (and in some cases organizing!) the FUDCon in Zurich this weekend. It looks like it’s going to be a marvelous event, and I hope everyone there enjoys it.
I was able to attend two FUDCons in Europe (both in Berlin) during my time as FPL and I can’t begin to say how valuable and important those trips were to me. I was able to meet a lot of people I only knew by their IRC nicknames, and make some lifelong friends. I imagine a lot of the people at FUDCon Zurich will be returning, long-time contributors, and others will be new folks who are looking to get involved in Fedora in some capacity, or even just curious about who we are, what we do, and how we do it.
FUDCon events are a good way for us to renew the social bonds that help reinforce and support our collaboration with each other. They’re also an ideal place to reach out to new people and show them the large and friendly nature of our community, and help them find ways to participate and “learn the ropes” of our community. That includes finding areas where we need more help, including teams where contributors have moved on, or want to step back to give others a chance to lead.
I’ve heard people often talk about the fifth foundation of Fedora — in addition to the four everyone knows: freedom, friends, features, first — being fun. I think fun makes a good addition to the list because it starts with f! However, I think it’s more accurate to say fun in the sense of being rewarding. Not everything we do is 100% fun, after all — certainly many of us have soldiered on, trying to solve a problem by fixing a bug, sweating over a translation, trying to craft a procedure in our documentation, make our websites look a little better, correct a service in our infrastructure, and so on, when perhaps we’d rather be doing something else. But when we complete that task, hopefully we feel that time spent was rewarding — even if it wasn’t completely fun. We should constantly strive to make Fedora rewarding for people who are contributing.
That brings me back to making it easy for new contributors to learn and to lead. We can’t expect everyone currently in Fedora will be here forever, after all. People’s lives, priorities, and available time change constantly. They find new jobs with different schedules and demands, they have relationships that require time and attention to nurture, and so on. We sometimes have to re-balance things that may have been rewarding in the past against other priorities so that we can continue to lead full, happy lives. This is a natural, continual process, and we can easily accommodate it in a big project like Fedora.
To do so, we should always look to provide other people easy access to participation, and easy access to lead our efforts. Depending on the same people to always be around to work on the same tasks is a certain road to burning them (and perhaps ourselves) out. There are at least two things each of us can do to prevent that from happening.
First, take a look at what you are doing in Fedora. Ask yourself, how did you learn how to do it? Could someone else do the same with a minimum of effort? Or is the knowledge required to do it scattered in many different places with an uncertain road to finding all of it? Make a plan for bringing that knowledge together, collaborate with your colleagues to make sure the plan is solid, and then execute it.
Second, look around you at other people you know or see regularly in Fedora and ask them if they need help doing the same thing. Help them document what they do, so someone else can do it too. You might just find out that it’s something you’re interested in doing, too. I know this happened with me personally in a number of areas (such as helping with the Websites team). Sometimes turning to a new challenge can give you a real boost of interest and energy that you didn’t expect!
Attrition is a natural process in any group — whether it’s a volunteer community or a company. The groups that have real staying power figure out how to meet the challenges of attrition, with tools that quickly help new members learn and do things proficiently.
What are some practices you use to prevent burnout and to make it easy for people to help you and others?
On a side note, I wanted to give some kudos to Jesse Keating, who heads up Fedora’s release engineering work, for taking on this challenge head on at Zurich. A couple weeks ago we talked about the opportunity at Zurich to get attendees looking at Fedora’s release engineering SOPs (standard operating procedures), finding remaining gaps, and enlisting people to help fill them. We have great technical people in our EMEA community who could easily understand and help document those processes, especially with one of our lead practitioners in attendance. Jesse was very bullish about this idea and I can’t wait to see the results that come out of the travel.
Similarly, we have groups of Ambassadors, packagers, translators, designers and artists, and other colleagues together in Zurich. We can accomplish a lot with all those great minds and talented hands in one place at one time — best of success to everyone!
Here’s some great news regarding lodging for the upcoming FUDCon in Tempe. We’ve secured a much better rate at a competing hotel nearby. The rate is around 60% of what we were originally expecting. That means it just got a lot more affordable for everyone to travel to FUDCon!
We’re still working out the final bits with the hotel so we can make a detailed announcement, which you can expect in the near future. Of course, we continue to encourage anyone who’s interested in helping to join us on the FUDCon planning list.
Well, we'd definitely like to erase that question mark in the title if possible, when it comes to the next North American FUDCon.
Why? Well for one thing, our last several FUDCons for North America have been held in northern locations. And since those events are held between December and February at some point, as part of our rotating schedule of premier Fedora events, that means it's can be pretty cold at FUDCon North America. (Sometimes even for the people who live in the host city.)
So when I found out some of our contributors were hip to get a conference in Tempe, Arizona, I thought to myself, Hooray! Finally a place where we won't have to wear earmuffs for FUDCon! Robyn Bergeron started the ball rolling, and has a bid page on our wiki for FUDCon NA 2011.
The remaining issues need to be ironed out, though, and they're fairly important:
Item Number Two seems especially important because we all know the pain and suffering inflicted by bad broadband on a FOSS conference. So enter one young matriculating Arizona State University freshman, Ryan Rix, who is helping track down, through the ASU LUG, faculty contacts at ASU that might be able to help us assess the state of conference space and secure an appropriate venue with decent Internet.
We'd love to bring a Fedora event to a major university like ASU, not the least of which reasons is that it's full of inquiring young engineering minds who could benefit from a nice big frothy mug of open source goodness. Sorry for the beer metaphor there… just a college flashback, I guess.
I've asked Robyn and Ryan, as the bid team, to help us get answers to these questions before June 1, so if needed we can make alternate plans.
Work is, of course, going on openly on the fudcon-planning list, so if you're interested in helping to organize the event, please sign up and introduce yourself. Thanks again to Robyn and Ryan for their continued efforts. If they approach you for assistance, and you'd like a warmer weather FUDCon NA 2011, be sure to say thanks and give a little extra.
This blog entry has a double purpose:
The Fedora Project holds a number of global Fedora Users and Developers Conference (FUDCon) events each year. Typically the Community Architecture team’s budget supports one of these large events each Red Hat fiscal quarter (with the fiscal year starting on March 1). This year we have the Latin American event, FUDCon Santiago in Chile, in Q2; the event for EMEA, FUDCon Zurich in Switzerland, in Q3; and a North American FUDCon event in Q4.
In each case, typically the event will happen sometime in the first two months of the quarter, so that we can ensure all bills are paid by Red Hat’s financial deadlines. That deadline usually comes a couple weeks before the end of quarter, so the first two months are the ideal time to actually stage an event. So the North American FUDCon event will happen in either December 2010 or January 2011. The bidders will work with the Community Architecture team to resolve the exact timing.
In the past we’ve often heard from community members that they’d love to have an event in a warmer clime during the chilly winter months. We couldn’t agree more, and now we have a way to empower our community to make that happen. FUDCon Honolulu? Maybe not, but we’re open to other possibilities! We want to find a place for the next North American event that includes:
We now have a bid process that lets interested community members propose FUDCon in their region, or even backyard. Nothing Olympic style — simply a way for excited Fedora folks in the locale to help secure event space, lodging, and other logistical details. We’ve already kicked this process off for FUDCon Zurich 2010, and are looking to start this cycle for North America as well. In the summer, after FUDCon Santiago concludes, we will kick the same process off for Latin America again for a 2011 conference.
So here’s what you need to do to get the ball rolling:
The bid process will be open for a period of approximately 2 weeks. At that point the FPL and Community Architecture teams, as major stakeholders in the event, will go through the bids and make a decision on where we’ll locate FUDCon North America.
So why have this bid process anyway?
At the Events FAD in February, we convened a crew of people interested in extending how our premier Fedora events work. For a while now, we’ve had two kinds of these events — FADs (Fedora Activity Days) and FUDCons. While FADs are quick-hit gatherings of a few people to achieve a specific, targeted purpose, FUDCon is a much larger event that can have hundreds of attendees and spans many different topics, experience levels, and goals.
Another important distinction previously separated the two. While FADs are put together by interested community members, FUDCons were typically planned by just one or two Red Hat employees — typically the Fedora project leader, sometimes with help from a member of Red Hat’s Community Architecture team. Because of a variety of financial and logistical constraints, this meant that FUDCon over the years has often ended up in one of a couple places. Most often this was Boston due to the proximity of the core of Red Hat Engineering people nearby who could provide support for the event. However, we did manage several times to move to other locations, such as Raleigh in January 2008 and Toronto in December 2009.
For the Toronto event, however, we tried a slightly different model — while Mel Chua and I provided funding and some organizational support, much of the logistical work was done by superstar (and current Fedora Board member) Chris Tyler and a crew of wonderful people on the fudcon-planning list. The event was incredibly successful in terms of number of attendees, the discussions that were had, the quality of sessions and hackfests, and costs involved.
We knew going into this event that it would be a proving ground for a new model of having the community empowered to make FUDCon even better than it can be with just one person handling all the planning. By moving to an open, transparent process, our community members got a better appreciation for the amount of work that goes into a FUDCon, and could easily participate in that work. The results were as expected — with the load spread wider, the event ran more smoothly and with less stress per person involved.
So we went forward with an events planning FAD, with the specific goal of identifying how we could make this process repeatable and scalable. That way FUDCon events could be held anywhere there was an appropriate budget and people willing to make the events happen.
Although we knew the first couple of events following this process — EMEA and North America — wouldn’t have the full preparation time we wanted to provide, we also knew both of them had far more than the six months it typically takes one or two people to plan the event. And our community members being the awesome people they are, they’ve of course proved us right again. As we go forward, the rolling nature of the schedule should be sustainable. At the conclusion of one regional event, we can start bidding for the next one. So over time these wrinkles will naturally be smoothed.
Thanks for reading, and your fellow community members are looking forward to seeing bids for FUDCon North America 2011!
I’ve been the Fedora Project Leader for a little over two years now, and now that we’re rocketing (sorry!) toward my fifth release in that role, I’m interested in branching out into other ways of championing free and open source software at Red Hat. Before I do that, I want to smoothly pass on the role of Fedora Project Leader, and make sure the next FPL can not only be fully successful, but continue to build on a process of growth and change for the future.
My peers and managers in Red Hat and the community at large have been incredibly supportive, and there’s no one driving this decision other than me. The Fedora Board, and key managers and engineers in Red Hat, are all part of the process of selecting the next FPL.
This process will naturally take some time, but I’m glad that the partnership between Red Hat and the rest of the Fedora community allows me to give people an early heads-up about these plans.
It’s important that Fedora always be able to make opportunities for fresh and energetic leadership that will help take our Project, and the distribution we make, to the next level of achievement. Regardless of what I’m doing next at Red Hat, part of my job early on will be to give as much assistance as possible to the next FPL, just as Max Spevack did for me, allowing that person to successfully take over this position, and continue leading Fedora into the future.
By the way, it might have been difficult to figure out how to write this message, except for the fact that we are all working together in a very special area of endeavor — free software. And thankfully the Fedora Project not only embraces the concept, but the practice of free software, so there is always source to look back on, recorded history to examine, and open and transparent process to draw from. In short, we have giants’ shoulders on which to stand. So of course I looked to see how our previous FPL handled the delicate matter of succession.
I’m sure no one, including Max, will mind if I took a look at that text for a starting point. Unprecedented transparency has continued to be a hallmark of the Fedora Project, and it’s a legacy we can all be proud of.
People have already posted about much of the goings-on from Day 1 of the Marketing FAD, such as the draft of our new, low-drag marketing plan, and our approach to spins, but I wanted to call out a specific area for people to notice. Back in the fall the board talked a lot about expanding the user base of Fedora, and ultimately set out four points to describe a user base that represents a wide audience of people, yet includes our current contributor base. One way to think about this user base is as a minimum bar. If, at a minimum, you fit all of these four descriptions, you are someone Fedora can make very happy — or if we’re not, then we should:
A lot of details about these descriptions are set out on the wiki and come directly out of the discussions from last fall. We spent a good deal of time at FAD day 1 describing the intersection of these very broad groups of people. I illustrated this on the board with a simple Venn diagram, with these criteria as four large circles that shared a very broad common area in the middle (the intersection).
That intersection is still a very large population of people, and we contributors are a small subgroup somewhere in the middle of that intersection. We all have particular interests in Fedora that can make it easy, if we’re not careful, to exclude a lot of people from that large population. And sometimes we may have to re-tune our own expectations or priorities to effectively serve them. (Providing a more stable update user experience is just one example.)
Does this mean that we don’t want people outside these areas to use Fedora? Let’s take some guy named Edward as an example. What if he’s not a likely collaborator, but still wants to switch to Fedora and be productive? We want him to be comfortable too. But when we make decisions about how to set up certain systems in Fedora, we want to make it easy for people to collaborate. We’ll make decisions to encourage them. Often that will have no bearing on Edward, and his experience will be no worse for it. On the other hand, there might be some tool installed that offers collaborators an opportunity in which he’s not interested. Who knows, one day Edward might change his mind and take advantage of the opportunity presented. If not, he’s welcome to ignore or uninstall that thing.
After talking about these concepts, John Poelstra popped out a nice pyramid-style graphic illustrating the concept without painful Venn diagrams. I’m hoping he’ll post it in his blog at some point. (Hint!) Mel Chua also brought up the Dreyfus model of skill acquisition and the four stages of competence. These are worth understanding as they affect our approach to users, and ability to look beyond our personal skill levels and understand how to properly on-ramp users into new contributors. It’s interesting to see how many of the conversations around change play directly into the pitfalls predicted by these models.
The beginnings of our new marketing plan are less scholastic than our previous attempt (seen for now on the wiki) but make a lot more sense in terms of broadening the user base, and more importantly, determining how future Fedora plays a part in helping more people get things done that are important to them. Getting out of our comfort zone may be difficult, but I believe it will be rewarding in the long run, and do nothing but increase Fedora’s relevance. Moreover, it will increase our ability to advance free software, pursuant to our philosophy of open collaboration.
We also collected post-mortem information about our F12 marketing efforts, where we were successful and where we were not, and everyone took back homework to complete, such as collating all the existing ideas for marketing tasks into a list we can prioritize and then assign or defer at the next couple of Marketing meetings. (That will help us ensure we’re not taking on too much and under-delivering, but rather picking the things that are really important to do, and exceeding expectations.) I drafted my homework, a general page on post-mortem information collection, after returning to the hotel.
Before that we watched the ‘Canes be outplayed by the Coyotes from the comfort of Red Hat’s swank private box at the RBC Center. We were joined by Russell Harrison’s lovely wife Doracy, and Greg DeKoenigsberg and his wife Mel stopped by as well. It would have been nice to see the home team make good, but we had fun anyway — especially Robyn and Ryan who are from Phoenix!
By the way, there’s a reason I called out open collaboration earlier. We have a great treat coming up for Day 2 — we’re being visited by Chris Grams (of New Kind), Jonathan Opp, and John Adams to talk about evaluation, growth, and spread of brand, and how to expand our opportunities to do those things in a community. Our agenda continues on the wiki today, and we’ll again be on IRC Freenode at #fedora-fad.
I attended the Events FAD 2010 that happened this past weekend, along with Mel Chua, David Nalley, Clint Savage, Jon Stanley, Dennis Gilmore, Steven Parrish, Chris Tyler, and Max Spevack.
I arrived on Thursday evening, in time to catch Max and Greg at the office and say hi. Most of the remaining short time was spent sending a few emails, trying (in vain) to find a replacement battery for my camera since I managed to leave mine at home, and checking in at the hotel.
Friday we had a massive brainstorming session on what we lovingly called “FUDCon 2.0,” where we went over past event survey results and the comments that we had gathered from blogs and other feedback mechanisms. By far the two most consistent threads running through the discussion were:
In the North American region, the most straightforward solution to allow our event to scale better is to increase the length of the technical sessions to two days. This could result in a four-day FUDCon event as opposed to a three-day event in the past. Looking far ahead, I wonder if we would benefit from a week-long event, where besides educational value we could also tap into the planning value of having so many contributors in one place. But obviously that is a much more expensive event. So first things first, and the expanded length of technical sessions allows us to hold fewer tracks at one time, but still accommodate a similar total number of talks. And that solves one of the most frequently heard complaints, which is that people can’t attend every talk they want (or in some cases need) to see.
The second problem is more subtle, and we spent much of the FAD both generating a planning calendar for future premier Fedora events, and mapping out a better process for actually producing them. In the past, a premier event like FUDCon has been arranged by a very small number of people (sometimes just one or two, like me or Max). With FUDCon Toronto 2009, we debuted a dedicated fudcon-planning list and other open processes that helped other people get involved — especially a ground team at the FUDCon location.
In the future, contributors will be able to look at a calendar far in advance of the event, propose a FUDCon location through a streamlined and simple “bid process” (it’s not the Olympics, after all!), and we can use that information to figure out where and when to assign funding. Very helpful for the Community Architecture team which takes care of the budget for these events, and because the planning would use community centered, open resources and processes such as the list and IRC, anyone in the community can get involved in the process, helping with collateral design and creation, content decisions, FUDCon Live, and so forth.
During Saturday and Sunday, snow and ice kept us at the hotel, but we assembled in the hotel’s boardroom to work on from morning to night (and into the wee hours in some cases!). During this time, I worked quite a bit on the process docs for much of this, in collaboration with the other attendees, both remote and in person — particularly the sponsorship process that we have been successfully using for several months now for premier Fedora events.
Although I didn’t get to spend much time on code-type bits, I was very happy that the FOSSLC guys joined us throughout the event to hack on freeseer, their remote A/V capture utility which we are planning to use for future events. It’s very important to us in Fedora that we achieve our free software goals with free software, and the FOSSLC folks have been very excited about getting a fully free toolchain working. Clint Savage took the lead on working with them, and that partnership has already yielded fruit, like Ogg Theora support and trading some development model information that will help freeseer grow even faster in the coming weeks. If you run an event, whether you’re interested in doing it with 100% free software or not, the FOSSLC guys do incredible work and we highly recommend them. You can see some of their work at the FOSSLC site.
As it turned out, the sun came out on Sunday, bright and clear, and with it the contractors plowing the hotel lots and other side streets. Along with the natural melting, we were all able to get out of town successfully, delayed in some cases but not discouraged. While I was sad that we didn’t get to see more of Max in person because he (along with everyone else) was snowed in, we got a lot done through online collaboration, and the FAD was time very well spent. A very sincere thank you to all those who showed up and participated, both in person and virtually — the effort you put into the event made it a great success!