 So today, I want to talk to you a little bit about contributing, not actually money. So I guess the contributions I'm talking about, many people will probably first think about when you're contributing to an open source project, you're contributing code or changes in that way, but that's not true. There's a lot of different ways that we can contribute to an open source project. In particular, I'm going to be focusing today on the Selenium obviously, but this kind of applies to many other projects that you'll find on GitHub, BitBucket, or various other open source platforms. So things that we're going to talk about that you can contribute to are the other items like not just code or bug fixes that pertain to maybe something that you care about or someone else's reported, but you can do things like improve the test suite of Selenium itself. We have documentation, there's SeleniumHQ.org, there's also a new, I guess, a new documentation site that we're trying to work on, but it's not quite there yet. There are helping with other people's issues on the issue tracking list, reproducing their problems, code reviewing pull requests if you feel capable enough to look at someone's proposed changes and give them feedback, also responding to the user's list like Google groups or Stack Overflow and that sort of thing. So let's talk about that first. There's various forums that Selenium uses for discussion of issues that users encounter. Maybe some of you have used some of these, but one of the things that make these forums work is other users responding and giving advice, feedback, answering questions. And that's a very important thing to contribute to the project. Our Selenium users group would probably not be as active if we didn't have very many people responding to the reposts. It would feel like a black hole otherwise, and we don't want that to happen. So having more people follow up on post the user's list, I would say you don't need to necessarily respond to everything, don't try to do that, only respond to things that you know about. A good learning tool also is looking at people's questions and going, oh, I don't know how that actually works, and either looking into it or hopefully following along and seeing if someone else gives some advice. I would highly recommend not trying to double post answers. It gets confusing to the author. So if the answer that has been provided isn't just flat out wrong, don't really add to the discussion unless you have something very important. It often gets confusing or muddled if we have multiple answers that are close, but not quite the same, and then the user doesn't know exactly what the difference is or future people coming and finding the posts might be confused also. So try it similar with Stack Overflow, but they have a better system. There's an accepted answer and there's upvoted answers. We attempted a long time ago to have our own Selenium Stack Overflow stack exchange, but that fizzled. They wanted to be in more of a QA Stack Overflow site, which I think is mainly the way you would do it. I think I believe there's an SQA Stack Overflow site, but if you go in there, there should be tags for Selenium WebDriver. You'll also find things for like Firefox driver, Chrome driver, all the various browsers and you should be able to find quickly with their interface what questions haven't been answered that you could help and contribute to. Upvoting other answers from others that have provided correct or mostly correct answers is also beneficial. We have times in the past found accepted answers by someone who posted the question, who didn't actually understand the question or the answer, and they were both kind of incorrect. And then we never get the person to change the accepted answer. So upvoting helps that, because upvoting will help promote a more correct answer. We've certainly had a few instances of that happen. There's also an IRC channel that myself, Simon even sometimes joins, and various other commuters join the IRC channel. This is a place or a forum to get more immediate feedback. We sit in there as a forum of contribution in answering questions that come in to the IRC channel. It is helpful to have people in there that know, I guess, have a more in-depth experience with SLAM that can field questions or even just generically help. We get varying ranges of questions in there from people who are a little bit confused about a particular WebDriver API, which is a seemingly easy question to people who just don't even know how to program or code, and are asking questions that don't even make sense because they just don't even know what question they should be asking. So you get these wide-ranging visitors to the IRC channel, and it's helpful to have people in there responding, encouraging, hopefully not being... There's a tone or a language that one needs to be careful about. There's a lot of people who come in here and expect things provided to them. Like, I found the IRC channel, I'm asking for support, I need support now. Myself, even Simon, are not paid to do Selenium, or not paid to be in the IRC channel. In fact, probably my work would... If they knew how much time in the past I've spent on the IRC channel answering things, my question, my commitment to the Selenium project, I've certainly spent many hours more than I probably should have in there. But that's to say, I'm not obligated to answer anyone's questions in there. When things get busy for me, I might be in the IRC channel but not answering because there's usually around 150 other people logged into the channel, and hopefully one of them can also answer. So it's not something that is expected for one person to be the user support. It's all of us. So when someone comes in and starts talking about why is Selenium so shitty? Kid you not, people will come in and say, why is it so horrible? Why doesn't it work? But we take... There's a whole other talks on how to deal with trolls, and that's what we get a lot of times. So just answering the question at its core value and ignoring every bit of, you know, adjective that they might have add to the question that they didn't need to is beneficial to the project. It's beneficial to the IRC channel. It keeps the tone pleasant and welcoming, and that's what we want to do. We actually want to keep the tone in most of these forms, very welcoming to users and very helpful. That's what we want to be seen as. We don't want to be seen as people just yelling at people for not knowing something that they didn't know. They didn't know, that's why they came to ask. So let's help them. I want to talk about now issues and bug reports as a way of contributing to the project. There are two aspects to this that I want to talk about. And the first is how to log a good issue report. I want to mention that because often is the case. Hopefully you can see this or read this. This is, I just pulled this up because this is actually one that came up during the keynote. And I already, I'll show you, I already closed it. But someone logged this bug on GitHub asking these questions, providing zero information in the bug post, and how helpful is this to the community? I actually have a handful of bookmarklets that I use. And if you guys know what a bookmarklet is, it's a snippet of JavaScript that automatically does something for you. And in this case, I have a few that, I'm sorry, this is not rendering right right now, but I have a boilerplate that says, this says right here, this is a question rather than an issue. Please send questions to the Selenium user group, which is a link. And for issues, please provide a concise reproducible test case and describe what results you are seeing and what you expect and see contributing.markdown. That's my boilerplate. If you see this and I've given this, I don't mean to offend the people, I'm trying to be nice, but these are bugs versus support form. There's other places to do that, as I talked about earlier. And so I've closed the issue. And thankfully, this user didn't take it offensively and they said, okay, thank you, great. We don't want, it causes a lot of churn for me and other developers and makes them want to not follow the bug reports as they're coming in when we get issues that we can't do anything about. So in order to provide a good bug report for us to do something, I would say, please provide all the relevant information, even if you think it doesn't actually, it's not the issue that you're looking at. It doesn't necessarily matter that maybe it doesn't seem relevant, but it is relevant to us. So a lot of times people, well, lately it's been Firefox isn't launching. All right? Which version? They didn't say. And if they say immediately 47, I'd go, well, you know, there's a bug in Mozilla and we've got issue 210 or 2110. That's already tracking that issue and we duplicate it out. Maybe some of you have already encountered that. But it's very useful to get all of those, you know, just the minutiae of detailed versions for everything. The clear and concise description, I hope this goes without saying, but sometimes people get very long-winded in their description and that's hard to read if you've gotten multiple paragraphs. If you're not able to say what the problem is in one paragraph, you please try to rephrase it and make it concise. HTML, CSS, JavaScript are a link to a page. This is so important. We're doing browser automation. We're dealing with dynamic web pages. There is no way for us to really be able to reproduce any issue if you don't provide the page that caused it. And we constantly try to reassure users, yes, Selenium has tests that make sure click works. There's no way we're shipping Selenium without click working. But we get bug reports all the time. Click does not work. Okay, which page, what HTML, what CSS, what JavaScript is on that element that causes it to not work? There are so many edge cases. It's all bloody edge cases, Simon. So JS Fiddle is actually an excellent resource for someone to quickly sketch up a page. Like you can add HTML, CSS, JavaScript, right there in a page, save the Fiddle, and now you've provided the reproducible test case or a page to everyone. I wouldn't call this a test case. It's the page to reproduce the issue on. You can do that without sharing any company secrets. Hopefully you can just get a snippet of the HTML. There's a lot of complexities in today's browsers or full stack application websites. So I understand that this is probably one of the most difficult things for people to do. But it's probably the most crucial thing. If we can't reproduce the issue, we're going to close it. There's nothing we can do if we can't reproduce your issue. Along those lines, what's extremely helpful is no matter what language you choose, it doesn't necessarily matter, but JavaScript, C sharp, Python, Ruby, JavaScript, even some of the other ones that we don't really primarily support in Selenium like PHP and Perl or even Haskell, provide us a snippet of programming script that reproduces the issue. Often you find people will, when it says steps to reproduce, they list steps, go to this page, they write it out, click this link, do this. That's not helpful or easy for us, it makes someone else do work of creating a script to then produce the issue. So please provide that script also. These two are, the HTML, CSS, JavaScript is the most crucial. The script is also just, it's helping help someone else run your, reproduce your issue and get on. The next thing, the other thing to do with bug issues that is contributing to the project is to look at the open issues and if no one's talked about it or commented on it, see if you can reproduce it. Is this a valid issue? Can you, have they given enough information for someone else who doesn't have their application, who may not know all the things that they know for how they encountered the bug? Can you reproduce it in your environment? That is another key piece that we have, probably why we have a few extra hundreds of issues is because we don't have actual reproduction on issues and just leaving a comment saying, yeah, I've reproduced it, here's how I did it. If you've done something, if you had to do something like write a script or do a JS spittle or something like that, provide that too in the bug. That's very helpful. Now you've done the work that someone else doesn't have to do. But I do wanna know, don't provide redundant feedback. Every comment does go to a few of us, every single post. I currently, I don't want to change my settings, but right now I am getting every single comment and every single issue on the Selenium repo. And I know some others do that too. So if someone just says plus one, well thanks for the spam. Like there's a like button on every comment or please provide valuable comments and valuable feedback. Otherwise you're literally spamming people with that. And I put this note about redirect users to appropriate other locations. Hopefully most of you know that the driver implementations are actually being now implemented by the browser vendors themselves. Google does their own Edge, Microsoft, Firefox, even though we're kind of half in, half out the door. Mary Annette is coming. It's not fully, I guess GA, it doesn't have everything in it. People are still encountering issues, but we're quickly coming to the precipice of not being able to use the open source Firefox driver anymore, like the latest version of Firefox 47. Doesn't work right now. We've been assured that the next point release of it should work, but 48, it's not gonna work at all. And there's no notion of the open source Firefox driver gonna to work on that version. People are gonna have to move to Mary Annette. So all these issues need to get then directed. We can't do anything about them in the Selenium GitHub repo and source. There's nothing there to work on those issues that people are gonna encounter. So we need to help redirect some users over to the bugzilla in that case. And let's say there's Safari is coming out with from Apple Safari driver. So all these various locations, we've tried to put it in the GitHub issues template, but people don't like to read all the time. So helping there. So documentation is another awesome, and actually the place where I started contributing to the Selenium project is I went to seleniumhq.org and I was like, I don't, there's lots of verbiage on there. And personally, I don't read. So slapping myself because I'm not gonna read 10 paragraphs or something. I wanna see a code example. So I went to seleniumhq.org, found the web driver docs and noticed that half of the API commands didn't have an example. There just wasn't any code. I just wanna see the code example. So that was one of the first things I did is went in and added examples and that was helped me learn Selenium initially, but also give back to the project. So I added and made sure there was examples for Java.net, Python and Ruby. If you've seen the site, you can see that there's examples for all four of them on the main API calls. So doing things like that is beneficial. We have on the seleniumhq site, there's a edit link at the very top. If you click on it, it'll help you generate a pull request. I will then see that and then hopefully merge that. So those are awesome to get. We have another repo called the seleniumhq docs. It was an effort started two, three years ago, maybe more, but we're trying to revamp the documentation. It's a slow process because documentation is probably, how important is documentation at your own company? If you are in a very enterprise level, then documentation has its own team that's funded. If you're an open source, you have people who need to volunteer to do it and how many people are going to volunteer to work on documentation. And as proof from our own project, it's very, very little. So this is always a struggling area of resource that could use help. Wiki pages too. Our Wiki is horrendously, horrendously out of date. You can do pull, well, you can't really do pull requests to the Wiki, which is difficult. You can clone it, but usually if you just log an issue with either a diff or a delta or something, explaining how to edit the Wiki, I'll apply the change as quickly as I can or delete the page. If you point out a page that is horrible, I often will do that. Code review, pull requests. We actually have a whole bunch of pull requests that maybe haven't gotten review or just are sitting there kind of stale. It helps move some of them along if you go ahead and chime in on maybe giving some feedback or thinking that something is good to go. It's sometimes difficult because we don't, we have insulin and we have so many different languages, so many different aspects of the project. I in particular really only look at Java and Python. I have some things in Ruby or .NET. I ignore it because I don't have expertise there and I'm not gonna do anything about it. So it's helpful if you have a subject matter expertise to help continue getting pull requests in better shape. If you notice a pull request doesn't have tests for what it's changing, maybe add a comment about that. We do have tests and thinking of tests. This is probably an accurate portrayal of what most projects are like. We have unit tests that cover a lot of things, but maybe it's not all together perfect. We could use some more coverage. You are, as Selenium users, you are hitting edge cases that we can't necessarily preconceive. If you've got an edge case and you want to add it to the Selenium test suite, you can. We also are, it's kind of in early phases still, but over at Mozilla Andreas is adding a test suite for the W3C spec itself. So if you want to make sure that your particular case, your tricky element that needs clicking on or needs hovering over, if you want to make sure that that continues to work, it would be awesome to have that in the test suite that all the browser vendors use to make sure that their driver is okay to ship. So imagine Microsoft and Safari and Mozilla testing to make sure your widget works before they ship any changes. So that's crucial and could be a very good value add for both Selenium as a project and you as a user consumer. I guess the last thing, the last contribution type of thing is your code changes or pull requests. And these are even more awesome if done well. We do love to see pull requests, but if you're doing something new or that would be considered feature-like, come and talk to us first because it gets to feel almost personal sometimes. People take it too personally when we close pull requests on them because they're trying to do something that doesn't align with the values of the project or something that we feel could be done elsewhere or differently. So it's nice to come to the IRC channel when we're there and talk to us, say, hey, I'm trying to do this. And guess what? I wanna propose a change to this area of code. Come and talk to us. We don't like closing pull requests without merging them, but we often have to just because they're trying to do something that doesn't quite fit with the project or how this W3C spec is moving forward. But one thing I could say with your pull requests is try to leave a concise description of what you're changing and most importantly, why you're changing it. Sometimes that is lost in translation just from your dip. Hopefully you're doing this at your work too, but Slame project likes tests. So if you're changing something, please make sure there's a test that if you were to run your test beforehand it would break, but then after your change would pass. Those are very awesome to see added to the test suite. So does anyone know where the Selenium tech support is? We are Selenium tech support. Every one of us, that's it. There's no paid staff. So keep in mind that everyone, every one of you has only so much time to contribute or potentially help and so do the rest of everyone else who's providing that support. How do we make money? This is my last thing I just wanna briefly touch on. This is an awesome little get repo of how all the various ways to make money in open source. I'm actually listed, my form of making money on open source is listed in there and my form is I work for an employer who happens to allow me to work on open source in my spare time. And so I'm paid by my employer to do my job and then I carve out portions of my time to contribute to open source. That's how I make money on open source. There's more direct ways that it's, this is a awesome little repo that lists all that, but there are plenty of ways to make money off open source and hopefully you can find yourself into one of those slices. Don't necessarily like, we're all providing something that's highly valuable as seen in the industry, developers and QA with the reason why we have jobs, why we're paid. It is something valuable so we don't, it's not, that point is not lost on open source. People like Simon right now who don't get paid at all, I don't even know how he's doing it. Oh, he has more information later. But, so that was it for this talk and I want to use the rest of the time to answer any questions if you guys have some. Do we have a mic for, I'll repeat the question if you go ahead. Safari driver is not able to handle alerts is the question. Will the new Safari driver be able to handle alerts? So the current Safari driver doesn't handle alerts and that's because it's a primarily JavaScript based implementation and the Safari extension which is how it's been coded doesn't allow you access into controlling or preventing those alerts in a nice way. So that's why it doesn't work. Will Safari driver provided by Apple work with alerts? It should because that's in the W3C spec. I can't tell you for sure if it does or not because I haven't tested it but I do happen to have, I've got right here, I've got Mac OS Sierra and I'm now personally just starting to play with it. So I will be able to answer that question later today if you find me, does it handle alerts? So the question I think is, so you're having issues with starting up, so during a test execution run, your browser just stops and the same ones will work in Windows. So there's various things that could be in play. Well, okay, so there's a problems with, like I guess if I understand the problem, it's I have a test suite that crashes browsers intermittently on certain OSs. Some OSs it doesn't. And where is the issue essentially is the crux of the problem. Where is the browser crash? And well when it happens could be intermittent. So you can have quite a few things in play on these very complex issues that would take someone's, a lot of someone's time to try to troubleshoot. So it could be the browser itself. You could be hitting a bug with the browser itself for the platform, which then all of a sudden that's the browser vendors. You could be hitting a bug with how we've implemented the driver, which could be a problem if it's Safari in itself, it could be a problem with the Safari extension or the Firefox extension. Or one of those various things. So that's something that we could potentially do, but then if it's then in the future, that's going to Mozilla. So that's gonna be a Mozilla bug or that's gonna be an Apple bug. These are the really hard bugs that do require a developer full time to be investigating in. And so some of those are ones that I just, I can't. I don't have the time or energy or effort to go into those in-depth bugs of why a browser is crashing intermittently only in your test suite. So that's again an importance of providing a reproducible test suite. But yeah, okay. So also when you're talking about something with TestNG, so you're dealing with multiple moving pieces here. Well I know that you're talking about now using TestNG and using Selenium and the platform, your OS and your browser, you have multiple things that could be causing the problem. So I know you're logging issues with Selenium, you're logging issues with TestNG, you're logging issues with, say, a browser and no one else is doing anything for you. Well someone else, they're all pointing the finger elsewhere. So now you're asking volunteers to troubleshoot a really difficult thing that you also can't even pinpoint where the issue is. So to Selenium it looks like it could be a TestNG problem. The TestNG it looks like a Selenium problem. So I don't know what to really tell you or help you there other than you're gonna need to find someone to actually investigate. And you're probably not gonna get me or someone else to really dig deep into that one. Sorry. Generic question about Selenium. We are gonna have a speakers panel at the end of the conference that those are nice times to do that. If you wanna hold off on your question for a little bit maybe I could talk to you about it or I don't know what your question is though. Is there other questions right now? If I were to contribute to the Selenium core base are there any design docs for us to start? If you wanted to contribute to the Selenium code base. So there is some design docs in our Wiki pages. There is that might be or might not be out of date. There's a contributing page in Selenium HQ in the about that has some more information. Some of, oh yes, there's a workshop on Sunday. Is that Sunday? That Simon is running. That's going to be contributing to the Selenium code base. And Simon does an excellent presentation of trying to talk about the architecture of Selenium and where you would potentially need to work or what areas of code you would need to work in to fix your issue. Okay, thank you. Any other questions itself? No, I just wanted to explore what happens at the back end as well. So I just signed this workshop and applied for that. So I got a name saying you just clone the particular guitar people and then the instructions to build that particular project. So I just went to that particular link and as a beginner, I'm not able to understand any of this like the different kind of build process. No, no. Is there any getting started with Buck in the Selenium build? Hello, right. I'll just repeat, there are two main problems you're going to see. The first one is when you do a buck, when you do a build with Crazy Fun, go whatever it is and you haven't got Buck on your path. The very first thing it will try and do is download the Python execute for the text that contains Buck. If you're on a dodgy Wi-Fi connection or you're on a plane or something, that will fail and therefore nothing that requires Buck will build. The second thing that might happen is if you have Buck on your path and you have a no Buck check file in your Selenium repo, it will use whichever version of Buck is on your path. If that is not the version, the fork that we have for the Selenium project, you're likely to get a flaky build normally because a build rule type of somehow like Mozilla extension doesn't exist. That'll be the error that you see if you read the stack trace. So those are the two common problems you see. I will be going to the beginning of the bug bash when it begins and just settling down with anyone who wants to do a build using like the latest version of the source tree and I'll hopefully iron out the problems because this is the second time I've heard someone say this and I haven't seen it myself. And so there's probably just like a systemic couple of issues that need resolving and then it's all good. He says, boldly. Does that kind of answer the question? I think so. So basically, if you do encounter issues, bring them up to Simon and or myself and we can try to figure out what's going on. If it's a common thread, then we might be able to fix it. Otherwise, we just have to see. We don't know what issues you're particularly having because we don't have them when we're running. But the Selenium build is not like anything you've ever seen before. And that's because Selenium builds itself in not any way that anyone else does. It's a single build system that covers Ruby, Python, C sharp, C plus plus, Java, JavaScript, various dialects of JavaScript. Like it's all coherently held together. But it's really unusual for a project to have all those bits and pieces. And so we needed to put a whole layer of stuff on top of both rake and it's effectively rake underneath the covers. Like whenever anyone panics, it's like breath deeply, read the documentation on rake, which is a Ruby build tool, and then read the documentation on buck, which is actually pretty well documented. And between those, you can find the answer to a lot of problems, but there's like a handful of things that happen all the time. Yeah, take advantage of the fact, like Luke says that you've got contributors here. Like you've got people who use this thing day in, day out and have run into some of the rough edges and lead. And we can share our better experiences with you. So hopefully it'll get better. Sure. Any more questions? Simon, you pass her. Hi. Thanks for your all hard work and giving a piece of great software, first of all. And like, yeah, they deserve. In like, see, in the evening, I mean, like even in the lightning talk, we have a, we have been talking for the spec of finalization and that there are future implementation are coming up. So I hope you guys have a lot of backlog to build and everything. So like, there are people out there with a passion and they kind of lagging and getting started thing and everything like that. So like, I've already initiated this in the last 2014 conference with Simon, I believe, like initiating a board and things how son micro system did for Java, like a JCP and having a use official user group country-wise and geolocation-wise and having a need for them every month. I mean, like when it comes to implementation, future implementation and the thing and people may not be knowing whether it is aligned to the project team or not when they raise a full request. But if it is meant by some kind of a spec lead or something, even when this W3C standard comes in, maybe we can have a spec lead for every teacher or something. So under them we can be meant by those guys, especially you guys. Because you guys have a pain of maintaining the community with all these small, small, I agree. I did some sometimes back as well, the full request and bugs and everything. And also you have to come in and contribute to the project as well. So hopefully maintaining this such kind of a board user group would speeden up the contribution and so we can get there, create a product early in the states. So that's what I wish. So what is your vision on this? Have any idea about it? My vision on that. So I think that's a good goal that we could get to eventually. I just don't see that many people being those spec, like those individual section leads. We just don't have, I guess the resources, the manpower or however you wanna call it. We don't have enough people to potentially do that. It's surprisingly small, the W3C group for WebDriver. You mainly have a few of us, just a handful of essentially people who've been contributing to the project. And then the browser vendors themselves, like one or two representatives from each talking at any of these W3C meetings or bringing it up. But I think what you were kind of touching on is as another user who's outside of W3C group, how do I talk about or propose a change or get something in there that I see as necessary or a good feature to add to the spec. There is, I think maybe you mentioned it, but there is a W3C mailing list that is public that anyone should be able to post to for the WebDriver spec. I believe it's actually linked off the W3C spec itself. You should be able to find it and then post messages to there. That people do respond to that. The spec authors and the browser vendors who are all working on the spec do respond. Sometimes if they're not getting a response, either maybe no one cares about the topic or no one sees value in it or doesn't know how to respond appropriately to that. I would say there's another thing is to hop onto IRC and talk to people. I know time zone changes make it difficult, like most of you normally I don't speak to on IRC because when you're here on maybe normal business hours, that's my night, our 12 hour time shift. So it's really difficult, but you do get some users, especially some of the Missilians who are in London who do have some overlap time with you guys. So getting into the FreeNode IRC channel for Selenium, and there's also a W3C IRC server that has a WebDriver channel in it too, and most of the spec authors and implementers are in there. So you can communicate directly with them, although say the Microsoft people are in Pacific time, so that's 12 hour shift from here, 12 and a half. But they often will be receptive to ideas and don't be offended if someone, because the 1.0 spec is, we're really, really, really trying to get it out. Any new things are, you have a very slim chance of getting it into the 1.0 version. That's where the 2.0 version comes into play when we can start talking about it. There's another resource you can log a W3C spec bug, and you can even say this is a feature request for level two, and that would make people feel a little bit better because you're not, if you log it right now and say, this needs to happen, essentially that assumption, there's an assumption in there that you're trying to get it for the 1.0 spec, and that's just really hard to do right now, since we are trying to get it all the way shipped and published. So there's a few means of communication, but I don't think there's group or area experts that we can really rely on taking a point of communication with. There's just not enough resources there, or I don't think people would volunteer for it. Yeah, I do agree. I hope this may be continuing to do that, but it is a right thing to say. Initiate is an effort to build a community who are to cultivate their interests or their passion out there with the people and giving them boost and make them to contribute back and making them help to the core community. That's why I'm talking about, if you start doing that, I mean if you spend some time over that, probably we can cultivate more contribution out there so the backlog of the projects could be personal. That sounds good. I mean, honestly, having you help coordinate or steer people in that way, most of us have no experience with organizing that in any way. So you're talking to people who are just, we have our day jobs and then we do contributions to this, but we have never organized anything at any larger level. The web driver spec is like a tiny spec. We're, I think at the W3C conferences when all the spec authors come in and come into one convention type of conference, you see the HTML group has a huge room, lots of people in it. Our web driver group is often a corner little room with one table with chairs around it. We've got like eight, maybe 10 people sitting in that room and that's it. We're tiny. Everyone else is like huge in comparison. So the, and on top of that, I'd say almost none have experience with any other working group or spec. So if there's someone who has like yourself seemingly experienced with organizing some of these things, I'm sure they'll welcome some ideas. Talk, I'm actually just an invited expert that man Simon is the spec author. Co-editor, sorry, co-co, yeah. David Burns being the other one. So I'm just a lowly invited expert. Any more questions? I'm gonna be around at the conference at the bug bash for the most part. And then there's, I have a workshop and also there's a speakers panel at the end of the conference. So if you think of anything later, you can ask me then or find me around. But thank you.