 Hi, welcome to this EsmarConf 2023 panel discussion on the benefits and challenges of taking part in a hackathon. This session was pre-recorded because the speaker availability and now you're watching on YouTube. Automatic subtitles should be available now and we'll work hard to get these manually verified as soon as possible. If you have any questions from our presenters, you can ask them via the atES hackathon Twitter account by commenting on the tweet about this session. If you've registered for this conference, you can also comment and chat with other participants in our dedicated Slack channel. We will endeavor to answer all questions soon after the event. We would also like to take time to draw your attention to the code of conduct available at EsmarConf website at www.esmarconf.org. This panel discussion will include members from previous hackathons and they'll be speaking about what it means to take part in a hackathon and what can be produced collectively. My name is Trevor Riley and I am the head of reference and research services at NOAA Central Library. I will be the moderator today. Today we have panel members including Adam Dunn, Matthew Granger, and Allison Bethel. So we will start by allowing folks to introduce themselves and we'll start with Adam. Adam, can you introduce yourself and then also give us an idea of what hackathons you've been involved in in the past? Sure. So thanks for having me. My name is Adam Dunn. I'm a professor of biomedical informatics at the University of Sydney and I'm also the head of biomedical informatics and digital health at the university which is in the School of Medical Sciences and the Faculty of Medicine and Health. I am originally a computer scientist but that was a very, very long time ago and I think the first hackathon I was actually involved in if I'm looking through my records was around 2018 where I was a judge, not a participant and then I was involved in the evidence synthesis hackathon in Canberra in 2019 where I was a participant of sorts and have since then also been a judge on hackathons, contributed data to hackathons, judged hackathons and so on. So rarely a participant and often a judge. That's interesting. I haven't heard much about judging in hackathons but maybe we can type into that a little bit too. Matt, same question in terms of how did you get started in hackathons and introduction? Hi, thank you. Thank you for having me. I'm Matt Granger. I'm a researcher at the Norwegian Institute for Nature Research at NINA based in Trondheim in central Norway. I'm an ecologist by training but also have a strong interest in evidence synthesis and making tools to help people. I started off at the ES hackathon in 2018 in Stockholm with working on the Evia Atlas project there and from there I've carried on doing several different hackathons all to do with evidence synthesis, all in that realm. Awesome. So it's a nice mix of health sciences and ecology. I like it. And we have our last panel member, Alison Bethel. And Alison, what role have you played in hackathons and what got you started and introduction as well? Thanks Trevor. So yeah, I'm Alison Bethel and I'm an information specialist, so a bit different to Matt and Adam. And I work for the University of Exeter, the medical school, and I work in a team called the evidence synthesis team. So we undertake evidence synthesis, systematic reviews, evidence and gap maps, that kind of thing. And my role is to find the evidence as an information specialist. And I got involved in the hackathon. The first one was in 2019 at Canberra, like Adam. And I got involved through, I won't bore you with the long story, I was at a conference in Paris on environmental evidence through one of my colleagues, Ruth Garcide, some projects I was involved in with her. But prior to becoming an information specialist at Exeter University, I did work as a librarian at the Environment Agency. So that's how I ended up involved in the environmental field. And while I was at the conference, I met and saw some presentations by Martin Miske and Neil Hedaway. So we had some chats afterwards and then that's how I kind of got involved in the hackathon. And I was involved last year, presenting a workshop on searching. That's wonderful. It's really interesting everybody is not too new, but also doesn't have a long experience in hackathons. So this is great. I think a lot of our viewers will really love to hear the feedback on this session. So let's do around Robin here and talk about the difference between maybe a hacker and a coder. So being a part of a hackathon, what role, if you can dive a little bit deeper into what role you've played in the hackathon and whether you see yourself as a strictly doing in terms of hackathons, a hacker or a coder and what that might mean to you. Let's start with Alison. Yeah, actually not a coder. That's not my bag at all. So the role I played in 2019, it was interesting because he had the coders in one room and then he had the others in the other room. So there's a lot of discussion about evidence synthesis and Adam can probably pitch in here as well because he's in the room too. Talking about the process of evidence synthesis and systematic reviews and at what points perhaps that a tool or coding would be able to help within that whole process, I would say. Yeah, I don't know if Adam wants to add more I'm happy to jump in next and for sure. Yeah, so I was in the same position. Even though I'm originally a computer scientist, I probably wouldn't call myself a coder anymore. It's been a long time since I've really had any chance to do any real coding. But yeah, no, I was in that room. I actually joined the evidence synthesis hackathon and went along with a software engineer from my group, Paige Martin, and so she was involved in the coder's room essentially and working on at least one or two tools I think as part of the hackathon. But interestingly, we think about the products that come out of these hackathons and one of the products that came out or tools, things that came out of the evidence synthesis hackathon in 2019 was a paper that Alice and I are both co-authors on, which was on a new ecosystem for evidence synthesis published in Nature Ecology and Evolution. And that was really established in that room as we were having discussions on what needs to happen in to make changes, I guess in how we do evidence synthesis. I believe it was also a relatively successful hackathon from the perspective of tool building, because I think some of the tools that were built in the room at the time were also went on to quite a lot of success. So you don't have to just be coding when you're at a hackathon. I think that's the really good fun part of hackathons is that everyone has something to contribute to and you don't have to be the best coder, you don't have to be the most knowledgeable. But there's a little bit you can do and it's joining together and working together. And I enjoyed that. That's why I became addicted to a hackathon. Events was because of that. In Socom, we had real computer scientists who had built the tool before we'd even stopped talking about it. And the academics were able to talk a lot about what things should be and the tool was being built as we're doing it. So it's a really good way of collaborating. I really enjoyed it. Yeah, and I remember I was used to tell repeatedly, tell Neil and Shinichi that it was probably the most fun experience I'd had traveling for a conference or hackathon for anything for the last few years. It was actually really a lot of fun. And that same year, I actually was a judge in a hackathon in Malaysia, which was digital health related. And in this case, the hackathon was actually for a whole bunch of students from across computer science and medicine to get together and build solutions to problems in the real world. And I was there to help decide which of the tools was the best and would actually receive funding to be built for real. So that was quite amazing as well. But I wanted to pause for a second and ask Trevor, you haven't told us yet what your hackathon experience is and whether or not you're a co-dehacker or otherwise. I don't think that's fair. I'm the moderator, but no. I went back and actually listened to some panels from last year, maybe the year before. And I was listening to Martin Westgate about his work and all the packages he's worked on. And he talked about feeling like you step into a room and everybody says they feel like they're unqualified to be there. And I think that was the epitome of what I felt when I put forward an idea for what will be site source. And we've got a session at this year's conference. And I had no R experience at all. I think I had run searcher maybe one time unsuccessfully. And so I ended up using the Shiny. I don't see myself as a coder. I think I would say a coder is somebody who is doing it every day. And maybe somebody who's a hacker is doing it more collaboratively. It's just a piece. They're a piece of the puzzle. And so yeah, that's where I see myself as maybe a hacker borrowing, learning constantly. Really in that regard. And yeah, my first experience was last year's hackathon, which was all virtual, completely different from I think any of the earlier hackathons. But it was the way that I was able to get in the door, because I probably wasn't able to travel to Europe to do some just for coding anyway. So I think that this new environment actually brings more people in. And we may be able to get more hackers involved. So but that being said, like how I got involved, you know, I had an idea. I really wanted to see it through. And Neil helped make that happen. But what made you all say yes to getting involved in projects? Because it's not something small, right? It's a substantial amount of time. It can be long term projects. So what made you say yes and continue saying yes to these projects? And let's let's start with Matt, because, you know, you've been on so many of these projects. I think that the reason I said yes was to learn more about code and learn more about instances at the time. The reason I continue to say yes is because it's really good fun. And you do get some outputs, you know, there are academic outputs and tools that are developed. And that's nice to be able to feel that you can actually make a difference and help people. That's why I continue to say yes. And Adam and Allison, you have any thoughts on that initial yes, maybe? And then and then that continuation with projects as well? Me, I think in Evidence Synthesis, the search lends itself really well doing the search to having some kind of coding or app to help you do it. And I have lots of ideas. Because having done it for over 10 years, I keep thinking, oh, if only I could do X, you know, and I don't have the skills. So being linked up with other people who have the skills and also the dialogue between people is really interesting. Although when you come back from it, you know, it is like we were saying earlier, Trevor, sometimes you have to think of it as a very long term thing, you know, because everyone's doing it kind of on top of their day job. I think I was probably a little bit reluctant to join Ian and because I didn't think I'd be able to contribute anything. But the reason I said yes in the first place was because of the people, because I like the people. And so they asked me. And of course, I had to say yes, because they were very nice. I left the 2019 hackathon just blown away by the amount of work that actually gets done. And just by comparison, I also am an interim trustee. And I sit on the membership panel for a society called Society of Research Synthesis Methodology. And, you know, it's a fine meeting where everybody presents their ideas. And I learn a lot of interesting things and I meet some quite amazing, brilliant people from around the world. But, you know, it's not quite the same as leaving there, knowing that the tools that were built during those days are going to be used for forever, hopefully, or for a very long time in the future. It's a different kind of experience to turning up for an annual meeting or a conference. And, you know, not that those are bad, but this is just a lot more fun. I think one thing I'd like to add is the collaborative kind of aspect to that is really important. As well as everything being open access as well. I think that is one of the drivers, I think, for still being involved in it. Yeah, I think it is, it's pretty exciting to know that those tools are going to be open, are going to be used by the community. Yeah, it's really fantastic. And being able to meet other like-minded people who really do want to move this area forward. So that's great. So along with these positive aspects of hackathons, what would you say are some challenges that you have faced during hackathons, and how have you overcome those challenges? And Adam, do you want to start this one? Yeah, for sure. Look, there wasn't a particular challenge that needed to be overcome with the evidence synthesis hackathon that I attended. But there was something that I was thinking about when we were planning for this panel. And it was that the hackathons that I felt didn't work as well were the ones where everybody was trying to answer exactly the same research question and then just do it better than everybody else. And those are the ones that were judged and where people weren't coming up with new innovative solutions that would just achieve the best accuracy on this particular machine learning problem. And so they would all compete with each other to produce the best solution. There'd be some prizes at the end of it. The people who got the best solution were then invited to write it up. And they didn't work very well. The solutions weren't great. I feel like the experts in a room could have easily done a better job without having to run a hackathon. And the ones that worked particularly well were the ones where it was go for it. There are a million different problems that we need to solve. Pick one that suits you and that you're interested in, join together with other people that have the same problem and build something cool and fun. And so I think if there was a challenge, it would be the framing of what we're meant to do in the hackathon and the way to solve that. It would be to change the framing to be build cool tools. That's a great tagline. I like that. Build cool tools. But in terms of the judging, if I can jump in before others just continue along this line of thought, how were they judged? Were you looking at the concept, the idea and judging that? Or was it really just based on what the output was at the end of the hackathon? In one of the ones that I judged before, not one in Malaysia. It was actually another university in Australia. It was based on half on the performance of the model in a machine learning model at the end of the day. And it was also half based on the quality or creativity of the solution. So it was those two things. But everybody was answering the same question. And they were there to get the prize money. It was kind of a bit like a shared task, if you know from computer science, that's the way people compete in shared tasks to get the best performance. And so I felt like that didn't work as well as a much more free and open approach. Thanks, Adam. And Matt and Allison, in terms of challenges that you have encountered during projects and how you've overcome them, can you think of any specifics? There's personal challenges. So as we've already mentioned, not feeling good enough. Because there's always someone in the room who's a lot better at coding than you are. And I have more knowledge about evidence than you are. But it's about letting those go and realizing that you do have a role to play. And even if it's just testing someone's code, you can do something to help writing documentation, whatever it might be. I found that a bit of a challenge at the start, I think. But when you realize that people are very, very friendly and very, very open and they don't really care if you can't code that well, then actually it's less of a challenge. It's more of a personal thing to get over. Yeah, I think probably the same for me, but also being the only information specialist in the room that can handle that was a bit of a challenge for me, I think. Because my experience was so different, I guess, to others. Other people obviously search, but don't spend their whole day doing it. But no, there are other librarians and information professionals involved in it. So I think that makes, I'm involved in a project that Trevor maybe mentioned earlier. So that makes the conversations a little bit easier because we both understand the same language, we're speaking the same language. So I think that's certainly helpful. I think it's one of the things about evidence synthesis, isn't it, that we tend to be extremely multidisciplinary. By the nature of what we're trying to do, you're going to have people from every different kind of discipline in the room, coding experience or not coding experience. I mean, a lot of the people in the area, we're all using R. And I'm certainly not an R coder. And I think the nice thing about having people who work in areas like information, as an information specialist in other areas where you're kind of forced to be a conduit for lots of different disciplines at once. In order to be able to do a good job of searching, you kind of need to be an expert in every other discipline at the same time. And so I think that having people in the room who are good conduits between different areas is a really valuable thing. And I think we need more of those people at Hackathons for sure. This is great. I think going off the personal challenges and also playing that unique role, what Matt said about, again, just maybe not feeling adequate enough or not feeling like you have enough to bring to the table. But really, the ideas you're bringing from your unique roles, like the ideas that Allison is bringing as an information professional, I'm a librarian as well. And we deal with particular parts of the evidence synthesis process, but we're deep in it every day. And so I think that that can bring a lot of value. So that's really interesting. It reminds me a little bit about the Seth Godin shipping creative work. I don't know, throw that out there for anybody who is feeling like they are not bringing enough to the table. It's a fantastic book to read. Let's see. So when we're thinking about Hackathons, we're normally thinking about developing tools, right? But what might be some other useful things that Hackathons can create or can come out of Hackathons? Adam, you spoke a little bit about the paper that you and Allison had co-authored. Can you talk more about that and maybe talk about maybe some other aspects of Hackathons that you think are good in terms of creation? Yeah, for sure. I'd love to hear Allison's take on what she found the experience like. I remember at the 2019, the room was filled with some relatively loud people, and I feel like I might have been one of those loud people. So I'd be interested to hear what Allison thought about the experience of coming up with these kind of ideas that we need to do to be able to shape the future of evidence synthesis. It's something that I've been thinking about a lot for a long time. I've been writing papers in the area since 2011. It was a really interesting experience to have ideas from all around the world, from every different discipline. This is how we do it. This is, no, you're wrong. We need these standards. No, let's just do this. It was a really interesting kind of debate that we had around ideas. I guess if you think about it from a large scale, the ideas that we were discussing and debating in that room, it would have been great if we were able to have those discussions right in the same room where people were building tools. Because for my money, the best tools that we can build right now are the ones that improve the synthesizability of primary research that make things more robust and fairer. There's certainly tools that you can build that help you fix a single tiny part of the process, but the best tools are the ones that break those processes open. And I think that's a lot of the stuff that we were talking about in the other room. And it'd be nice if there was some more cross fertilization with those things as well, I think. But anyway, look, I talked too long. I want Alison to answer. No, I probably didn't drive much more. I remember you see there were loud voices, but then we were split up into groups. So in the smaller groups, people felt, me perhaps, felt more comfortable to speak within a smaller group. Because I guess someone who with less experience like myself being there, you kind of defer to those like yourself, Adam, who you've been thinking about this for a long time. And actually what you're saying, you go, oh, yes, that's true. So it's just in one way, it's voicing for other people that's thinking anyway. So I don't think I don't I don't really recall that being an issue. I think everyone felt their voice, their voice was valid. Yeah, which is, you know, that collaborative approach. Yeah. And I think, you know, one of the other things that we, we should be discussing more about and some of the things that I know are of interest to other people in the evidence synthesis hackathon is really around the other, the things that we can do to support better quality evidence synthesis in the community for everyone. So we often think about things like checklists and standards and tools that don't require any code at all. And those kinds of things can be really, really useful. But I think they're useful when they're in tandem with that with the kinds of tools that make that are available and that are easy to use for everyone. You know, we know there are right ways to do systematic reviews. And we also know that probably less than 1% of systematic reviews actually follow all of those rules, right? So I want to see the tools, I want to see the ideas, the checklists and the standards that wouldn't say democratize systematic reviews or evidence synthesis or meta analysis, but but at least make it easier for everyone to do the right thing. And I think those are the things that can really come out of hackathons when you get those people talking about ideas and the people building tools alone. No, I like that. I think in terms of hackathons sometimes it's like this is a hackathon for evidence synthesis go and without maybe some more guidance on let's make things more useful for people, right? Like let's let's take what we have already and improve the shiny app so that, you know, folks can really, you know, do the work without knowing are I think that that was one of the big things I was worried about last year when we got started is not knowing everything. You know, I had reached out to Eliza Grimes, you did that searcher right and I said, hey, really, I love your package. I can't use it. And then she put together shiny and it was it made it opened up my world and that really like brought me in. So I think that that's that's right on Adam in terms of like bringing these tools opening them up and that that cross collaboration that Allison had mentioned too. I think I think that might be something that is particular or a bit special about the evidence synthesis hackathon as well. I mean, Matt, is your you've been to a bunch of these. Is your is your feeling that the kind of the openness and the making it available to as many people as possible to do the right thing as part of the what would you call it the ethos or the or the or the undercurrent of the entire hackathon. Definitely, I would say it is the ethos of VS hackathon is to make tools that people can use that aren't reliant on someone's coding skills or even even their understanding systematic reviews to a certain extent, maybe we try and make sure that people have some background knowledge available. Neil will make a video to go with the tool to help people to understand why they're doing it and what they're doing. I think all that is yeah, it's a really important aspect of it. And I think it's easy for us to forget about that. But as a team, we're often very, as you said, interdisciplinary different types of people coming together. And I think that's important because the problems we face may quite be quite similar across different fields, but there's some things that are worse or better in other disciplines than others, you know. And I think it's an understanding of that whole. Yeah, the whole array of different problems you might face is really useful when you come to design these tools for a bigger group of people. It's not just for health professionals or ecologists or whoever it's for everyone who uses evidence synthesis tools. Yeah, I wonder, I wonder how many what proportion of hackathons are like that because, you know, I have all be a limited experience with hackathons, but I've certainly been a hackathons where it's been a competition to find the most commercializable tool that everybody's keeping secret within their little super group of talented coders because they know at the end of the hackathon, there's an opportunity for funding for their idea and it's going to help them become successful and rich or whatever it is that they want to do. And I know that the evidence synthesis hackathon is absolutely not like that. So I wonder how many hackathons are like that. And if there's maybe something a little bit special about the evidence synthesis hackathon. But saying that if someone does want to give us some money, then please do. Okay, I'm going to pull up my checkbook here, Matt. But in terms of in terms of making a hackathon successful, right, like last last year when we were fully remote and we did this hackathon, it was really challenging, right? I think that in terms of the new normal, right? Working across, you know, entire continents across the world, you know, we're really challenged by not being able to sit in the same room. The hackathon for site source was maybe a couple hours and then everybody kind of went their own ways and it's been over an entire year just going, you know, weekly meetings and bi-weekly meetings. How can we make hackathons in this more modern world where we're collaborating in different time zones? How can we actually make them more successful and then also ensure that they continue into the future? Because these aren't, you know, one's getting paid here, right? No one is required to continue along with the project. What would you say keeps bringing people to the table and how can we continue to make these successful? Matt, do you have insight into, I mean, you've created so many packages through the evidence of the hackathons. Do you have any insight into, you know, which of those, how it worked in terms of keeping those projects going and continuing to develop them? What do you feel was the common denominator in terms of the success? Yeah, I think the main thing is having a driving force and for site source, Trevor, you're the driving force behind that. Your reminding us that we should be doing something and sorry I haven't, but we should be doing more and you're there just that constant reminder of the process. I think having tools like GitHub, for example, has allowed people to work together, but not necessarily at the same time, which is quite useful for these sort of, yeah, remote hackathons, but there is something to be said for having a short period of time in place together. I think that brings maybe, yeah, it sort of brings things closer together faster. I think there's a different experience between the two. I've enjoyed both approaches and I think, yeah, the world we're in now, I can't really afford to fly off to America or fly to Australia. I can get a train to Stockholm, but that's about it. But it's, yeah, I think it's pretty better for the environment and better if we work together using systems online. GitHub is one that I know very well, so that's something that I'm very comfortable with. There's obviously a barrier there of learning how to use GitHub, but I think you can probably talk about that Trevor, how you've actually learned to do that. And I think that's something that does help these sort of disparate groups of people to work together in the same thing. I think we all have the same goal is to get a good product done, so that helps as well. Everyone's motivated. You go. All right. Yeah, Alison, Adam? I was just reflecting on what you were saying and I wondered if, I think it is harder when people aren't in the same room, but I wondered if there was an opportunity like Matt said, if you get a train to Stockholm, I can too. So maybe there are centres in different places all at the same time and it's a bit of a hybrid thing, but you've got protected time, then if people come to one institution, say in Europe, it's easy for people in Europe to get to or in Australia, in the States or something like that, but all in the same week or something, that's potential. It's a hybrid and it's not a hybrid and you're not on your own, then it's just a suggestion really. Hybrid is really tough. We run, so I'm a convener for a network called Digital Health Informatics Network. It's got a thousand people in it and we run a conference every year called Digital Health Week and it started at University of Sydney and has grown to include University of Melbourne, University of New Zealand and will continue to grow to include lots of universities around Australia. The beautiful thing about the conference is that it was free this year and it's usually very cheap to turn up to and submit papers to. Hybrid is really tough, so we try and hold in-person events at each of the locations on different days and it's just a struggle to get a whole bunch of people in a lecture theatre and then have twice as many of those people online watching and all that sort of stuff. Hybrid can be tough, but I was actually thinking about there was that paper that was written about the impact of working online on innovation. And if I remember correctly, the conclusion of that paper was that working online has made it harder for people to be innovative, but it's actually quite useful for just getting stuff done. And so I wonder if maybe the right way to think about this is not should we meet or should we not meet for a hackathon, it's about how can we structure an in-person hackathon to be most useful because you don't need to just get stuff done at a hackathon, but what you do need is the time to sit and discuss ideas and come up with innovative solutions because according to the paper at least, that is what's required is that in-person discussion and talking to come up with these innovative new ideas. And then when it's time to get stuff done, of course, you can do that from the luxury of your own home at whatever time you like and then just push those changes through to GitHub, easy. So I think maybe the structure of hackathons just needs to be rethought about in terms of what you spend, what kinds of things you prioritize during a hackathon. I think it's probably one way to think about it. Yeah, I'm going to leave the coding at home and just bring the ideas almost. I like that. I mean, I've never been to a conference to actually listen to the talks. It's always to go out to dinner with friends. That's it. It's the only reason to go to a conference. It is one nice aspect. It leads into another question. If you could develop a new structure then, Adam, I think I'd like to continue down that line of thought. If you could create a new structure for a hackathon from the ground up, what might it look like? Is it going to be purely conversation, logistics for how the project is going to continue into the future? What would be the main parts that you would want a hackathon to cover then? I'm clearly not qualified to answer that question. I think I've been to a few that worked and a few that didn't. I know what parts I enjoyed. I was just happy to be there, to be honest. I'll leave that for the experts. I don't think I'm an expert either. I think some of the aspects that are really good is the community feeling. Either that's online or in person, I think it's having a community and feeling like a community is really important for me at least in engaging in these projects. If you can maintain that whichever way you can, in person, and as Adam said, maybe these subgroups of people internationally would be very useful. You still need a component of online work to get that global connectivity. Covid has taught us one thing is that we can work online, we can meet online, and we're sat here on Zoom now talking across different continents, so we can do it. It may not be as touchy-feely and we may not be able to have a beer together, but we can at least get stuff done and it's good stuff we're doing. All right, awesome. I know Matt, I would definitely like to buy you a beer for all of the work you've done on Sight Source. All right, so let's wrap up with one last question. For our viewers who may be considering taking part in the hackathon, what advice would each of you give a listener, and this could be from your own unique perspective as an information professional, or any way you'd like it, but what advice would you give somebody? We'll start with Matt. I was just going to say just do it. Just join up. Don't be frightened. You can't break things. You can't ruin the whole project. Anything you can, any small part of what you give, it's going to be really useful and really helpful, so don't worry about your skill levels or anything like that. Just apply and go for it. I think if I was going to give any advice, it would be to leave your work at home, to sort of embrace the opportunity to spend dedicated amounts of time on this, and that doesn't just mean during the day. It also means networking at night and hanging out with everybody and talking to them if you're in person. I think there's also something important there about your obligation to make sure that the environment is an inclusive, safe, respectful one as well. I think it's really important that if you're a participant in a hackathon, that you make sure that the environment is like that for everybody else, that you don't just leave it up to the organisers to make sure that they set that culture and that tone, but that you live and act in that tone as well. It was the beauty of the evidence synthesis hackathon. I always felt included and safe and respected in my opinions and how I was and who I was. I think that that was always the case. I hope that was the case for everybody at the hackathon as well. I think that's kind of one of the things that I would suggest people to remember when they're visiting a hackathon for sure. Yeah, I don't think I can add anything else. Like Matt said, just go for it. You will have something to offer, I think. And from what Adam said there, people will listen to you. All right, awesome. I think Matt, just do it. I like that. Even if you're just going to show up to listen, because you could be right, you could be very intimidated about the entire process, but if you just join in and listen, there's going to be one thing that you can at least provide some insight into from your perspective. And whether or not it gets taken up, you're still hearing how the process works and how people take on different roles. And you also learn a lot about even good coders, good hackers, right? They are coming and saying like, well, I don't really know how to build a shiny app or I don't know how to do this part, but I know how to do that part. And so you can understand how people have their own niches even within that process. So I think that I love the idea, just do it. If you're thinking about it, I'm really thankful to have had the time to spend with you all today. And I hope that the listeners have gotten a lot out of it. Just to wrap things up, I think a lot of what we talked about is that community aspect. From the discussion, hearing everybody talk about that constant learning, just putting yourself out there and how a lot of this is shifting too. We kind of have an understanding of what a hackathon is, but evidence that a hackathon is something different too. It's not something that you're going to be judged on. It's really about producing those tools for the community and how everybody has a seat at the table. And I love that, Adam, about just making sure you are acting always in a way to include people and help them up because that's what we need more of that across the board. So I love that. And in terms of Allison's perspective of being an information professional as a librarian, I've got the same thing too. It's like you're approaching it from such a what feels like a weird perspective when you're hearing everybody else talk. But we each have that. And I think it's important to keep that in mind that everybody has something to bring to the table. So any last words before we wrap up from anyone? All right, awesome. So thank you for everybody joining this panel on the benefits and challenges, taking part of the hackathon. We hope you enjoyed it as much as we did. And thank you to Adam, Matt and Allison. And we'll see you at our next session. Thank you.