 All right, so I get to set the pace for this very first time that we do lightning talks. I will try to do my best. So hi, I'm Shelly. I implement verification solutions at several open projects, and you've heard what some of them are. Eclipse OMR, Eclipse OpenJ9, and Adopt OpenJDK. And particularly, I'm interested in ensuring a free and open and fully verified Java binaries are available to the Java community. And what I'm going to try to cover in the next four and a half minutes is what is scaffolding, why would you want to do it, and why is it an art? So scaffolding as you may know refers to temporary structures or solutions to aid construction. And let's look at a simple real-world example of that. A development team wants an OpenJDK 11 testing enabled so they can find and fix problems that they're working on Java 11 features right now, and they want to find the failures, fix the failures as they're developing. The build team has not yet completed automating and publishing the builds to a location expected by test scripts for automated pickup and testing. So in this scenario, we have a couple of choices, or I'm limiting it to a couple of choices for this lightning talk. You can tell the dev team to go away, no way, wait until the build team is finished. Or you can scaffold. You can build a temporary solution which unblocks the dev team. So in this case, some temporary scripting that picks up the build from some sketchy location built likely out of pearl code and gummy bears. There are common mistakes that you can make, that projects make, and I'll quickly cover them. So you can only, you can choose to only build scaffolding, and this means you're hacking around and it doesn't scale and it becomes a rickety and demoralizing mess. So avoid this. Scenario two, mistake two, no scaffolding. So you're never trying to unblock teams and have them work in tandem. It's always serial. You're working on building the monolithic thing. You may never get completed, or it's so late that the requirements changed underneath your feet and you didn't solve the new problems. Scenario three is subtle. The mistake number three that you can make, your scaffolding falls apart before the real solution is ready. At this point, you have a choice. You can try to rebuild the scaffolding or push hard to complete the real task. This is going to be a judgment call. How close are you to building the real thing you need to build? And then scenario four is you love your scaffolding so much that you keep it. Even though you finished the real story, the real solution, you keep your scaffolding around. So congratulations. Now you have two things to maintain and go forward with. So how do you know if you did scaffolding right? You can ask yourself a couple of questions to know this. Did you achieve the goals you were trying to achieve? Did you build the thing you set out to build? And secondly, did you help people along the way? That's actually an important and subtle part of scaffolding, the notion that you're actually looking for ways to help people who depend on you. You know who depends on you and you ask them often, how can I help you? And the reason that's kind of the important story is because then it builds a community and it has people want to come back and work with you. So in these last few seconds that I have in a lightning talk, I just want to remind everyone. I know everyone here knows this already, but innovation happens in the open. And I'd love the opportunity to innovate and collaborate with all of you. Gummy bears included. So these are the details of how to get ahold of me, how to get kind of involved in the projects that I'm involved in. Some of the talks I have upcoming at several conferences that I hope to share with everyone online. Thank you so much for your attention and let's stay in touch. Find me at some of the events or in the conference later this week. All right. Thank you.