 Good morning, good evening, good night, good afternoon, wherever you're joining us. So here we have a subset of the committers, not unfortunately, we couldn't get everybody, but we've got a few of the committers. And this is your opportunity to rip them apart. Yeah, sounds fun. Okay, cool. So let's kick off the committers panel. There are already questions coming in. So if you have questions for the panel, please put them in the Q&A section and we will go through that. But I would like to start off by asking the committers to introduce not themselves, we'll do something slightly different, right? So instead of introducing themselves, I would request the committers to introduce someone else. And as they introduce that person, if they could highlight according to them, what was that person's biggest contribution, greatest hits to APM? Did I go first? Sure, go for it. Cool, let me introduce Micola. So the first thing when I saw Micola, you know, all of a sudden, we saw, I saw a lot of contribution, you know, coming from Micola, not in one repo in APM, APM being so many tiny repos, literally every repos we have seen Micola contributing, whether it's any specific client server and all of it, right? And I used to ask Sreeni as like, I want to know which time zone Micola is because whenever, in any time zone whenever I see, always there is to be comments on issues, reviews on pull request. And he's one patient, he's one person with a lot of patients I've seen answering to all the questions in the forum. So just not on issues and pull request reviewing but also answering in the outside forums on discuss and other stuff. So thank you Micola for all the work you've been doing for this community. Thanks, Sai. Thank you. You can go next. Hi, everyone. So, Pazu has been doing amazing job in maintaining APM's Ruby client and Python client and a lot of co contributions on APM 2.0 as well in terms of reviewing a lot of peers that are getting in. And the recent one that I like from Pazu is removing the nonstandard W3C endpoints from base driver. And that's exceptionally well Pazu. And thanks Micola as well. And Jonathan for bringing in this idea of APM 2.0 in terms of decoupling. Hi, so let me introduce Sai. He is very contributed and distributed up. Sorry, I forget the project name but he created a library to run automation tests against distributed devices. And he was very extend APM work to manage devices and test cases very well for more various devices. And there are also every introduced APM new things to other webinars. So like this time also had a workshop to introduce APM, creating APM plugin and APM drivers. So they are very good for extending APM community work to more people so that the work is very amazing for me. So yeah, I would like to also present Jonathan. There was probably no APM without Jonathan or no APM how we actually know it or how we actually see it now built based on known JS. So yeah, Jonathan was one of the first founders, probably after Dan Queller. Yeah, so I would like also to thank Jonathan for all the effort he actually invested in Dubium and still investing. I mean, I would also mention one person who unfortunately is not today with us but it would be unfair to not mention him. This is Isaac Morchi. I hope I told his name properly. So he also invested a lot into APM unfortunately he is not so active anymore but yeah I would still like to say thanks to all the people that are like working with APM like adding new features and working on current features like without you guys there would be probably no such great project so yeah thanks. Absolutely and Nick is absolutely right. You know, APM goes way beyond the committers. So many people have contributed such awesome features and there are some committers which were very active but moved on to new roles and aren't here to be recognized. Yeah, Isaac is probably the most significant. So obviously the project will always have a lot of gratitude for those people and its history. So I think I have to introduce Srinni. I think it's the only one that's not been introduced yet so I probably don't know everything that that Srinni does but in my mind Srinni has done a lot of work to maintain the Java client and help keep that up to date. I personally haven't been maintaining clients very much and I'm not a very good Java developer so I've been really thankful for Srinni and other people as well but who have helped to maintain the Java client. And then also as Kauzu mentioned Srinni together with Sai have been doing a lot of good work to help bring good practices and training to the community through workshops that they run all over the place through the consulting they do at ThoughtWorks. And also now the plug-ins that they're building to actually contribute these projects for free so that other people in the community can use them. So yeah, thanks for all your contributions Srinni. Thanks. I think that's all of us, Narash. Yes, I think that's all of us here. Cool. So thanks again everyone for introducing each other. It's always good to know how someone else views you. With that I'll try to kick off this with a couple of quick questions and then hand it over to the audience for questions. So just firing away quickly keeping being conscious of the time. So I would like each person to answer this. This is something that I would like to hear from each person. According to you, what is your favorite Appium 2.0 full request that you reviewed or you either committed ideally something that you reviewed. So if you could share what was your favorite full request that in the last few months with Appium 2.0 that came in. Sure, I can go first. I think I committed recently the client side plugins part for Appium Java client. So, Cazoo has done that in Ruby and Python, and we had this left in Appium's Java client support sometime. So that's one way where the server side plugins introducing a new endpoint would be accessible from the client side Java client as well where we have a lot of users that could benefit from. I'll probably go next. I literally loved most of the PRs which came through Appium 2.0 the reason being the architecture at an architectural level things change. So me looking into most of the PRs also helped me learn a lot of things with the entire restructure happening. And also, I really like to look into most of the PRs with Appium 2.0 is because I've been trying to help the community more to understand about the changes that are coming into 2.0 and also especially the driver and the plugin expansion. So that's something which I really loved it and I literally looked at most of the PRs to understand exactly what really is going on under the hood for us. From my side, the most interesting thing is Christopher's PR. So Christopher is not in this, in this panel now but he helped us to make distributed repository into the one repository. So previously Appium 1.x had many repository to develop Appium itself, but he integrate many things in one Appium repository to help development Appium development itself so 2.0 will be more easier to manage dependencies in Appium 2.0 development. So, and then that change was very huge. So his help very impressed me to how Appium 2.0 is going toward to more good work. Yeah, thanks Kazoo. I was actually going to say the same thing of all the other code that I reviewed. The code that Chris wrote to turn Appium into a Mono repo was probably the most interesting, also probably the most line count, because it was very big change. So I think that would be my answer as well, but to say something new I suppose some of the work that I've done I really liked adding the code to support new plugins. I think that was the most mentally challenging. There are still some bugs that I'm trying to work through. And it's pretty hard to think about how we can allow other people to write code that changes the way that Appium works without everything breaking. So we'll see if that actually happens, but that's been my favorite so far. For me it's very hard to actually find something that is favorite because I did so many, I mean at least reviewed or saw them. Probably, I mean, I like challenges and the one you probably did Jonathan was the most challenging one because there were like, I don't know how long I scroll to actually reach this VR. So did you did several iterations, I think like there was more than an iteration but whatever like this was probably the first PR to actually make this packages stuff work in driver installation all this stuff was basically one of the foundation that Appium to the zero is working on so yeah. It was the most challenging probably and that's why I like it. Okay, I think we've gone through everyone. Last question from my side. If you had a time machine, you could go back in time. What is the one thing that you would undo from Appium. I think I would go back and make some changes to Java client. Definitely want to do that because there are a lot of interfaces which we've been talking to knock that off. But if I had to go back to and do that I wouldn't, I wouldn't definitely really look into Java client to see how we can write it. And for me, if, if I could go back to, you know, even six or seven years ago. There was a time when we did an internal re architecture of Appium, I think it was for Appium 1.5. And at that time, we, we broke out all of the drivers into separate repos. We saw that we needed a better architecture that didn't kind of mix and match all the driver code. And I think we were so close to kind of seeing the idea for Appium 2.0 at that point, and it would have been very easy to just do that at that point. But instead it took like five or six more years. So I think there was a long period of development where we kept building in a direction that's going to make it a little harder to move in another direction now. I kind of wish we had done the third party drivers thing five or six years ago. You know, we, Appium wasn't as popular then we didn't really know. We didn't think that there would be any reason for other people to build drivers on Appium. That just wasn't an idea that we could see clearly. But I think that that would have been a great, a great little kind of one little extra insight that could have gotten us on our trajectory, a little faster. From Appium's Java Client perspective, long back in history, we did pull some files from Selenium's Java Client along with its commit history and brought in those into Appium's Java Client. Find the classes, probably I would have found that better now. My case is ordinary Ruby client. Only Ruby client was only one library. And currently I exposed the Ruby client core outside of Ruby client itself because Ruby client had a many hockey code because probably Ruby client was one of the oldest client for Appium. So Ruby client also have many client side some hacking implementation to, for example, parsing source page source result in the client side. So that has many legacy codes. I exactly extracted some core features outside of Appium Ruby client core. Probably even, even now, many people use the Ruby client from the order, not core, Ruby client itself, they use, many people use that, but that has many hockey code as well. So not easy to implement to recent imperial libraries. So if I can back to the past and when just a while developing Ruby client self, then I'd like to improve the architecture more. That was probably more five, six, seven years before. Very legacy. History code. Okay. Yeah, thanks, Kaz. I basically have no regrets. So if you would say like, if I move to the past six, seven years ago, I mean, probably I would be doing exactly the same because yeah, I just remember when I joined the project, there were about like eight, yeah, 800 bucks in the issue tracker. And in like very short time, we were able to decrease this amount to probably 100 and out of those like quite a few were box actually most of those were improvements or something like that. So for me, what's important is that the project is alive, people are actually using it, people are giving the feedback. And it's like nature, this natural loop when you constantly like implement something you get immediate feedback and like, you make it better, you have a possibility actually to improve it. And this is what I really like about this project probably this is not the same thing like if you're working for a big enterprise. And they're like this iteration could be a bit longer or much longer. So up to like several months. And in comparison to that in opium, if you do some changes, you can get feedback calls almost instant, like, and just push it to better and then get the feedback almost instantly from the people and this is what I really liked about the project. So that's why I don't have any regrets because most of the, like features or bug fixes or stuff that we were done to this project they were actually supported by people they were confirmed they make someone happy. This is the main thing in this project that this is making people happy. Alright, I think we are now done with all my boring questions so we could now jump in and take some questions from the audience. I see two questions so far I'm wondering, there are more questions coming in, but I'm thinking we'll let the person speak up and ask the question instead of me reading out. This will be a little bit more entertaining. So I see the first question from Amar. I'm just enabling the ability for you to speak up. Hey, am I audible? Yes. Okay, great. Thanks, Naresh. Hi everyone. So my question is basically we have two Android apps and we are testing one of the Android app or using an automated way using Appium Python. We have quite a few automated tests already in place with all of the helpers and wrappers in place but now we also want to automate the, we also want to have automated tests for the another app which is an hybrid app. So here's the idea of making use of the existing helpers and wrappers and the tests to accommodate because since the app is quite similar but a lot of workflows are different. So how do you guys suggest that we should go about, should we split the existing functions and helpers so that both can be, those helpers can be utilized for both the apps or in that case there will be minimal duplication. So hence that method or we should rewrite or completely come up with new helpers and new tests for the other app. Yeah, good question Amar. I mean, I think you already have an idea of what to do based on your question. If you, if you're using something like the, the page object approach. Yeah, you could, you could very easily have two page objects for you know, a sort of base page object for each page that handles the case for a certain app and then another page object that simply extends it and overrides functionality with differences for the other app. So that's a, that's just one way there's a lot of ways, but to have kind of a minimal description of the changes that you would need to, to automate one app versus another app. I mean, it sounds like they're similar enough that you'd want to take advantage of the same helpers and things like that, but I know it's really inside probably also as consultants have opinions on test suite organization. I'm not sure what those methods, that's in this context, probably some of the methods can be as a plugin that could be used instead of doing as a community. Okay, cool. Nirashwana. I think we'll move to the next person. So I see the next person here is Raj. So Raj, I'm going to allow you to speak up. Raj, can you speak up please looks like you're on mute. Well, maybe Raj can't speak up but I'm happy to read their question. Since Appium 2.0 is NPM based, how can it be used for the Java language bindings? Who wants to take this one? Okay, I'll go for it. Go ahead, Mykola. Go ahead. Okay, thanks. I mean, basically, the idea is that we don't change much. So for Appium 2.0, it will be exactly the same experience or very similar by client experience. So basically, you will only have to change very minimum things on the client side to use Appium 2.0. So it's mostly like server changes, ideally, ideally. Like the strategy is that you just like transparently update your Appium server and then use the same client code without any changes or with minimum changes. Like there is another challenge there that Selenium itself is moving to version four. So basically for Python, Ruby and other clients is not so like breaking change because those are dynamically typed and like changes there and also basically what Appium has on top of those is not so much. So that's why it's more or less like less painful, I would say, but for Java and .NET like change where we have like static typing and strict typing. So changes seems to be huge because some interfaces are going to be changed at some like basic foundation elements. So that's why I would rather care more about this change, like if you want to switch to Selenium 4.0 and how this is going to work with Appium Java because it's already containing like many hacks in order to make it working together with Selenium. And we know about some like known issues, but unfortunately, and we even use for example like Eclipse compiler instead of the standard Java compiler to make this working. And this is something that we don't like ourselves, but there is no other way to actually make it working together with current Selenium. Unfortunately, unfortunately, this is a result probably of miscommunication with the Selenium team, but this is how it is historically, like I don't know the initial reason for that. This is just how it is. So basically, like the next big step would be actually to make sure that Appium client works together with Selenium 4.0 and also like W3C related stuff because for example, like main changing in Appium 2.0 will be that it only supports W3C. So for you, for example, from the client side, it would be important just to make sure that you use the most recent client and you don't use some deprecated stuff because it will most likely not work anymore. Yeah, thanks, Nick. And just to add to that in case, in case the person didn't know Appium 1.x was also NPM based. So nothing is changing in the way that Appium is written or installed. So the Java client works with 2.0 the same way it works with 1.x. And another point to add is there are a few required fields which we changed in 2.0 like the base path and stuff. So very recently Manoj and Srinay added a pull request. So if you're starting your Appium server with Java client programmatically, so probably you will have some changes in those areas as well, just like if I, yeah. Cool. Jonathan, you want to read the next question? It's anonymous so I can't figure out. Yeah, yeah, sure. So this person's asking that why we use a lot of driver.execute script methods for certain special Appium commands like the mobile colon scroll command and could we perhaps get a better way of executing them. So yeah, this is a good question. I have my opinions but I'll let other people answer first. Maybe I can go first on this. So the mobile colon methods, non-standard methods in Appium. So we have the methods, I mean, apart from non-standard all the standard methods are very well defined in Appium. Since we have a lot of non-standard methods that are platform specific introduced by Android and Apple platforms. So we do handle these through the script endpoint which is under the driver.execute script. So probably there is a, that could be handled better maybe for plugins which we use driver.execute not the driver.execute script method. So yeah, Jonathan has some thought process on the way how we handle client-side plugins. Maybe something for us to look into next on the way how we add commands, I mean the special commands in which Appium plugins being in the client side. Yeah, exactly. I mean, I think there's two components to this answer. One is that there are reasons that we did it the way we did it before. And the other answer is what could we do differently moving forward. And, you know, I don't think we need to get into all the details for why we did it the way we did it before. There are some really good reasons. Primarily to make it possible for clients to access non-web driver commands without having to update clients and require people to download new clients to access new features. So basically it was a way to get people to access new features as quickly as possible. Moving forward, now that the drivers are all kind of independent. I think it makes sense for drivers to ship their own client-side plugins if they want. So mobile scroll, for example, works in the XUI test driver. Also, the UI Animator 2 driver, let's just take the XUI test driver. The XUI test driver could implement that as a full-on web driver route and it could provide a client-side plugin to ship along with the driver that people could use to have quote unquote first class access to this function. But that would just be up to the driver developer to do that. Okay, should we move on to the next question? There's one from Shyam. I'll just read it out straightforward. When will Appium 2.0 expected to be released? Next Christmas. Yeah, I'm just going to go ahead and say in two years just so that it doesn't keep being wrong. Although I will say if you caught this part of my opening keynote but I would watch that because there's a section on the work that is left to be done before Appium 2.0 can be officially released. And there's really not that much left to do in terms of development. It's mostly documentation. So that can take some time to get it right. But in terms of when Appium 2.0 is ready for you to use now. So start using it. Cool. There is a same person asking another question. So I'll try to see if Shyamla, you can speak up. Hi, my name is Shyamla. Thank you for unmuting. My question is that on iOS, I see there is no features for Appium features to trigger the deep link, application specific deep link on iOS. Is it so or will it be available in your future? I'm talking about application specific deep link. Next, you want to take us away? Yeah, so basically, there is a nice actually Appium Pro article by Jonathan about deep linking in Appium. So actually, there are like on iOS, there are like a limitation from Apple site, basically that we cannot run deep link like in Android. Let's say with IDB because it just does not provide any APIs to do this and the only API that is present there just doesn't work because of probably some internal security that we cannot work around. This is just how Apple designed it. I don't know the initial reason. So basically, you can only do it on simulator because on simulator with Xerun, SimCTL, there is a possibility to run a deep link. So if you want to test your app with linking, then use simulator for testing on your simulator. Or if you still would like to use real devices for that purpose, then probably you can use as a workaround this method when you just paste this link in the Safari address bar and launch it from there and it will probably work most likely. I mean, basically I don't know other like ways to work around this and make it reliable the same way. So yeah, that's only the question to Apple like when they provide this API to us or if they provide. Yeah, actually in the recent time my project demands that to trigger the deep link on iOS. So I was looking for solution. I could find that Xerun and to trigger the deep link through a Safari, but as it is application specific, it didn't run. So that's the reason I was looking. I was asking this question. Thanks. Looks like it's still because of the Apple security she's not habitable means like correct. Thank you for clarifying. You're welcome. There are many things that we cannot do because of Apple security limitation. Unfortunately, but yeah, this is the reality. Yeah, one other thing I mean so as Nick said on the simulator there is a method for this is you just call driver dot get or driver dot navigate whatever opens a URL. You might have to have actually previously launched your app on the simulator. I think there are some restrictions if you've never opened an app and then you try and open a deep link to it. It might be more problematic. Yeah, follow follow the app in pro article should hopefully answer some more questions. Okay, cool. Next we have a question from Shubham Shubham I'm unmuting you. My question is, if you can speak up sort of that'll be great. Now I'm out of them. Yeah, I can hear you. So my question is that what was the reason behind building a PM in Node. Well, I guess my response is a question to you. What should we have built it in. I think there are so many languages such as Java Python. But I like the most JavaScript, and I think there are so many features of Node. Yes, and which I think one of the reason but might be it's your favorite language and you have started with this. Yeah, I mean, I guess I'm the only one here who was part of making that decision. So that a very small part of it was that, you know, we were familiar with Node.js. It wasn't really my primary language my primary language at that time was was Python. But one of our goals for Appium was that we really wanted contribution from a lot of different people. And we were very familiar with the Selenium project. And it seemed to us from the outside like Selenium didn't get a lot of contribution because some of the code base was fairly complicated. And so we kind of, and Java is a language which is hard to contribute in unless you already know Java, right if you're a Python developer contributing to a Java project is very, very difficult. So we felt that choosing JavaScript would make it more approachable for people from kind of all sides, because most people know some JavaScript, if they've done any sort of web development. And JavaScript isn't a very scary language right it's, you know, it was sort of a toy language. And so it doesn't have this kind of intimidation factor like if we built Appium and Haskell or rust or go. You know, that would be kind of intimidating I think for a lot of people. Also, Appium is a server, a web server, and Node.js had great tools for rapidly developing web servers, especially compared to something like Java. And so we really wanted to get something up and running pretty quickly. So those were sort of the reasons that that we did it and then obviously node and JavaScript have evolved in tremendous ways. It's been the last nine, 10 years since Appium has been around. And so we've been always making use of those advances. And obviously had we known that Appium would become as massive as it is. Maybe we would have chosen a types language. Maybe someday we'll convert Appium to TypeScript or something like that. So there's always things that we could do differently, but I think choosing Node was was really great for the time and it has helped Appium to become what it is today. Yes. Thanks, Jonathan. Thanks, Shubhan. Initially, Appium was written in .NET, actually, right? So when Dan Cuellar did, then it would like for the first two requests, this was a .NET project. Well, yes and no. I mean, Appium at the lightning talk was .NET, but the only reason he used .NET is because he was a Windows developer and he just used it essentially to call a sub-process. And then he met with Jason Huggins and they decided that Appium should be in Python and wrote like a couple files, but then it was like clear that they weren't actually going to be developing it. So it kind of came to me to actually develop it. And so we sort of had the opportunity to choose at that point how we wanted to begin. Right, Nick. Depending on what you call Appium, the very, very first demo of Appium was .NET, which is ironic because that's our worst finding right now. Right. That is the next question. Difference between driver and plugin in layman's language? Really, I'll try to answer that. Drivers are essentially something that translates your Appium client commands, right? If it's iOS, Android, and, you know, in the keynote, Jonathan spoke about a lot of other platforms that we can automate, right? Like Chrome OS and Roku devices and stuff like that. So Appium tries to take the client command and translate them to what they can understand, what those specific platforms can understand. So that's what the driver does for us. So the driver receives that from Appium from your client, translates to what that specific platform can understand if it's Android, iOS and stuff like that. And what the plugin does here is basically plugin is something which can modify what that driver can perform if it's find elements, right? So plugins can go and probably modify or even override how a find element for that platform can be done. Yeah, probably I'll try to put it the best driver and plugin. Maybe if someone can also add something. Yeah, I think that's exactly right. I mean, drivers are for automating platforms and plugins are for everything else. Plugins can do a lot of things, so it's a little hard to narrow down exactly what they can do. Yeah, it's also even possible to like automate or create a plugin that will cover like multiple drivers. So for example, like with image recognition plugin, like you can use it with multiple drivers with iOS, with Android, with any other driver that actually supports elements finding like you can plug in this image recognition there and it will just work. So it's a nice example actually of a cross-platform plugin that is probably useless on its own. But in like combination with this specific driver, this will be really of use. All right, we are almost out of time, but there is one last question. So let's do it and then we will wrap up. So the next question is, does the APM team have a plan on maintaining the plugin ecosystem? The reason being, ideally if I develop one, can it be made under the officially available plugins? Yes, we won't maintain your plugin for you, but if it's a good plugin and if it seems useful, then we can add it to the list of plugins that people can download using the APM plugin interface. You know, we'll probably want to do a little bit of a code review and make sure that it's not like a malicious package and things like that. And like I said, we're not going to maintain third-party plugins from a code perspective and if it goes defunct, then, you know, we can remove it from the list again. But absolutely we want to make sure that plugins are discoverable and I have some ideas for how we can, you know, have a nice repository of drivers and plugins for people to find them from around the world. All right, I think that is the end of the panel, but we can use this opportunity to now just thank everyone who's helped us put this conference together and also talk about there being a lot of questions around how can I be part of the speaking panel, how can I be part of the organizing group and so forth. So we'll probably spend a few minutes just answering those questions. So first of all, yeah, I want to thank this panel here for taking the time out on a Saturday morning for few of you early morning. Appreciate that. And for a few of them pretty late on a Saturday evening, so also appreciate that. I think it's always great to have the conference closing with the panel with all the committees. That's been a tradition we do on Selenium and FDM. So, you know, it's always great to do that. Thank you for joining in. I just also want to thank all the attendees. You know, it's a Saturday. Usually it's a day off, but appreciate everyone who joined in today to the conference and over the last two days. We've started with workshops and then we had two days of a packed schedule. I think the feedback has been very positive. We also obviously look at the ratings that all the attendees have given. Plus we will be sending out a post conference survey to see if there are any other suggestions or feedback you might have to help us improve this. We certainly plan on doing the conference again, hopefully in person so that we are all in the same time zone and not spread out. But I still think this was great because we were able to bring in speakers who generally other ways would not come in. At least I heard from four speakers saying, you know, it's virtual so it's fine, but if it was in person now. In some ways, it has its advantages, but I think a lot of people would probably prefer the in person and we'll see how things unfold over the next few months. Generally our plan is we at least here in India we do apium conference one year and then selenium the next year and then apium the year again after that. So we kind of alternate between that, but we could depending on the interests we could revisit that decision, but as of now I think we've not decided whether you know it's going to be next year or not. So we will certainly announce that once we internally discuss that. I want to thank all the sponsors who've been such wonderful supporters of this conference again like I said, when we announced the conference I think it was 1000 rupees it's like less than $15. And everyone was like, you know, are you seriously can you really run a conference and in fact, we can pull off a conference and you know the goal of the conference is it's a group of volunteers. It's a nonprofit event. And it's in the spirit of open source so we want to build the community and we want to make it accessible to as many people as possible. So you know we try really hard to bring down the cost it's accessible to as many people as possible across the globe, and our sponsors play a very important role in helping us, at least financially and in many other ways in terms of marketing the event in terms of reaching out. I know each of the sponsors have reached out to their network and help spread the word. Also broad end speakers and so forth so it's a I would say it's a fantastic ecosystem we have here where we all kind of work together towards building the community. And just quickly answering the last two questions that I think people had I think video I already spoke about that in the morning 15 videos from the conference are already live on the YouTube so you should be able to go and watch the videos on YouTube 15 of them are up. Hopefully the rest of them we will get them early next week. And so all the videos are also publicly available. You know you, it's that you don't have to register or pay to watch the video. It is all publicly available on the YouTube channel. How to become a speaker. Any side Jonathan one of you want to take that up to people asking, you know, I mean it's, it's very straightforward you go to the convention website. You put in your details and your idea, and you hit the button, and then that's it. I don't know, I guess I'm being silly why doesn't someone give a real answer, but I think that's it. Generally six months. Sorry, go ahead. In case if you need any help on finding your talks. We do share the feedbacks and if you and there are certain for certain folks we did also have a couple of writers, and we find in those talks before the conference. So feel free to submit. It doesn't matter whether it is simple complex doesn't matter. We always happy to help you folks doing those. Yeah, so we use an open submission approach for speaking at the conference or about six months before the conference or whenever we all get our act together and we say okay, it's time to announce the conference we generally announce the conference and when we announce the conference we ask for two things. We do a call for proposals which basically means people can submit their ideas to present at the conference. And there is a guide that helps them in terms of what all information is required, all all submissions that you put in our publicly visible. It also keeps us honest that when we are selecting the talks we are selecting, you know, without any bias or without any favoritism, if you will. The idea is this is an open conference in the open community, and we would like to encourage as many people. Especially look for diversity both from experience speaking. So at this conference we had many first time speakers who had never presented before. And like Sunni was saying we kind of have a bit of a shepherding program where we work with them and help them present at the conference because I think that is very important for the community. We also look specifically for people from different backgrounds, different ethnic backgrounds, different regional backgrounds and I think we tried our best to be as inclusive as possible. And I think we want to get better and better at that, for sure. But yeah, you can submit your proposal and you know that's that's what we'll get you started. Once you've been part of this conference whenever we announce the next conference we do send out an update email to everyone saying the call for proposals is open but you can also check out the appium conf website. And when we also announced the conference we also call for program committee members. And so that is also if you if you're interested in being part of the program committee helping us review the proposals, give feedback to the speakers to find the proposals, we also welcome program committee members. And so you know that's the other way you can contribute to the conference and the last is obviously volunteers who we had a fantastic group of volunteers who were helping the speakers and making sure you know everything was running on time and smoothly. This is again something that personally, you know, I am a very big fan of studying things on time and wrapping up things on time. Especially in a conference if you don't do that then you have a snowball effect, and then people are completely confused what is going on right now you know it just leaves everyone in a confused state. So, you know I think pretty much every session, I would say with a margin of one or two minutes we started on time and we've tried to wrap it up on time. And so that a lot of that goes to the volunteers and the speakers for helping us keep the time and keep the program running smoothly. So yeah I think those are three different ways in which you could contribute to the conference and be part of the conference. Okay, with that signing off. Thanks again everyone. Awesome. Yes, thank you. Thanks all volunteers, speakers, attendees. It's been awesome.