 within the OpenJS Foundation. We have impact, growth, at-large, and emeritus projects. If you are a member of a project within that category and you want to come and introduce the project that I asked you to come up and like cue and then once it's your turn we can just give let's give you the microphone and do like quick three-minute or so intro to the project who's involved with the project what some of the goals of the project are if there's any specific requests or calls for participation or needs or whatever that the project has then we'll give you a moment to to make that request of the room. So reasonable makes sense. Thank you Christian for your enthusiastic money. So we have five impact projects. Node, OBS, Appium, jQuery, Dojo, and Webpack. So if you are here on behalf of any of those projects or want to make any announcements on any of those projects let me ask you to come forward. I'm Christian. Can you come talk to about Appium for a second? Since yeah, since that since Jonah and Dan are here. I mean what should I talk about? Yeah we started Appium a while ago to support testing on mobile because it's really different every Android and iOS different have native automation strategies. You can use them but if you want to write a test it works for both at the same time. It's going to be automatic and Appium tries to overcome this problem by providing a test interface based on the workflow protocol which is a REST API kind and they can send HGP requests. We can do it with any language and it allows you to run mobile tests on Android and iOS at the same time and scale it up as you wish. The Appium ecosystem is quite large because there are many modules that try to support different native automation strategies and I think currently Jonah and Dan Graham they're on top of they're streaming the project more or less and yeah if you want to get a vote let them know that we know how to take it. Thank y'all. Is there anyone here on the behalf of Webhack? Because I know Dojo is in the jQuery department. No sad, okay. I'll just quickly I don't think I need to introduce what jQuery is. No, okay good. But if you want to reach out to that project the representatives are Dave Mephan and Timmy Will. I think largely they're working on infrastructure and just that basic kind of routine release management and that sort of stuff but those guys are the reps for jQuery. On the Dojo side, Dojo is another modern web framework which is very popular within enterprises. The wonderful Dylan Sheiman and also Matt Gadd are representatives from that project to the OpenJS Foundation. They did send their regrets but awesome team and Webhack probably another project I don't need to introduce. Sean Larkin and even Stinsberg are the representatives to the CBC from Webhack. Let's see moving on to our next category. We have six growth level projects within the OpenJS Foundation and super quickly. Growth projects are projects that have some key objectives that they're trying to reach maybe like for example to grow the number of contributors or to increase the number of like you know highly invisible limitations that sort of stuff. We have six wonderful growth projects. Architect, intern, Node-RED, web driver, web hint and I know some books from those projects are here so if you are a maintainer or contributor to one of those projects and you want to come up and introduce it please come forward. I know you're here so only. Okay so it was just explaining Ethereum so Web.io is the client to run tests for instance for mobile on Ethereum or to run browser automation tests and you can compare it with Selenium but Web.io has a different design. It's more framework that you know takes care of a lot of tasks that you would do normally if you use things like Selenium. It's a cool framework. You can run tests synchronously and yeah if you're going to get involved with the project we have one maintainer, one of the student committee here in the room as well so that's exciting. I haven't been seeing him and so far yeah if you want to get involved let me know. It's exciting. Thank you. Question? Yes. How do I contact you to just talk to you after the session if I want to get involved in Ethereum or like what would be a good way to reach out and get involved? Just come to the reception and say hello to me or send me a Twitter message or all the ways get hot whenever you're night. Hi I'm Chris. I work on MOGA which is a testing framework. We are always looking for more maintainers and help with that sort of thing. I've also worked, I don't think Nick is here but I've worked on Node-RED. Node-RED is a it's like a flow-based low-code programming platform originally was written to essentially work with a lot of IT devices and it works really well for that. Works really well with MQTP in that sort of thing and there's a really big ecosystem around creating custom integrations and flows and setup and that tool can be found at Node-RED.org. That's all I know. Okay so that leaves Architect which is helmed by Brian LaRue and the company's company Begin. Also Chris Borgers is representing that project on the CPC so you can reach out to either of those persons. Architect is a serverless framework and if you want to get involved with that project. Intern is another project from the Dojo team so again you can reach out to Nat Gad and Dylan Simon to learn a bit more about that but it's a test stack for JavaScript and TypeScript. Let's see then WebHint. Anton Maleta, I don't think, I think he's here this weekend in Berlin but I don't think he's at this event and he's at Microsoft and he represents that project on the CPC and it's very active there. It's a linting tool. I think these are pretty common projects though so we'll see. I'll probably don't need too much info about them. All right at large so we have 15 at large projects which I kind of liked that the kind of the bell curve I think for our projects but at large projects are mostly projects that are in like maintenance mode. They're still actively used but they don't necessarily have lots of resource requirements or needs from the foundation so they're kind of trucking along and if they need something they can or they have an objective that they want to get more foundation resources to reach then they can upgrade to a growth status but these projects are kind of doing their own thing and happy to do it. We have 15 as I said, ESLint, Esprima, Express, LibuV, Lowdash, Marco, Message Format, Moment, Globalize, Grunt, Hospital Run, Pet, QD Unit, GeriScript and Interledger. If there are folks from any of those projects who would like to come forward and chat about what you're working on or then maintain your communities. Hi Emily, maintainer for Message Format which is a language for localization working with plurals and all sorts of interesting things that you might want to do with the text in whatever you're working with. I think your description earlier is right, we're doing pretty well at the moment. The other main missing from there is Alex Sexton who originally started that project but I think most of the code is more of the code is now mine than his. But yeah, I also mess around with all sorts of other localization things in JavaScript because it's certainly in sort of fun. Very important. I'm excited by the number of those types of projects that we have in Foundation 2. Oh yeah, the actual reason why I'm here is because I ended up getting on to the Cross-Project Council for the OpenJS. Other recs from any out-large projects? In the interest of time, I won't describe too many of them other than to share a couple of things I think the maintainers would appreciate. First off, I want to shout out to the Moment team and Maggie Pintu as frequently represents the now I guess OpenJS Foundation at TC39, formally the JS Foundation at TC39. On that note, the project is really looking to get a lot of its work kind of brought into the spec and wrap up another project that I think is interested in support to kind of conclude or move on from its work is actually Hospital Run, which is a really cool application that is it's a offline first application actually. They are looking for new maintainers. So if you are interested in working on a real-world app that does a project that really helps a lot of people, definitely talk to me about Hospital Run because they would love your assistance. Let's see. And then last but not least, we have five emeritus projects which are so-called because we value their contributions to the ecosystem but they are functionally concluded. So we're not really recommending that people adopt these projects or use these projects but that being said we feel like the word emeritus really does convey some respect and some appreciation for the time and effort that they put in. And so just a quick shout out and pour one out for jQuery UI, jQuery mobile. So this was intended to be sort of short and sweet just so we can kind of- yes. I am missing Jed. I'm sorry. I just- Jed should be, I think, was- did Jed adopt an emeritus? That's right, yeah. So that makes it six. See, I told you I had almost all of the members. There we go, poor Jed. There we go, Jed. That was Alex too. Alex is still there. Okay, so that's sort of just kind of recounts the JANS Foundation projects. You know, a little bit later we'll be having a session for the CPC itself. So if there are specific questions from this group about the CROSS Project Council, I definitely recommend attending that session. But if there are questions or ideas about any of these projects, like if I can go to the floor, we can conclude early. We can have a dance party. Yeah, you are. You're still dancing. Okay, cool. All right, well that's all I had. So this session is focused on JASAP and like- so coming from the Node Content and City Node Foundation, I'm curious, like, you know, what would be as part of the community committee in Node, how, you know, how y'all would be interested in getting their base in Node 1. I'd like to do that work and help with that. I don't know what that looks like for y'all, but that's something I'd be interested in helping with and just kind of building relationships around. So if you're interested in that, definitely either chat now or I'd love to talk to you as well. I love that. You know, one of the reasons why we did a merger was so that our project communities could collaborate more closely together. And I think this is a prime opportunity to do that this week. So strong was one part. How do you see this growing? I'm not with that. It's a merchant in the OpenJAS Foundation. Do you see, like, there being more projects onboarding and, like, how do you encourage more projects to join this? Because, like, I think from a sort of more user perspective, like, I know sort of that the JS Foundation existed and that's in the OpenJAS Foundation, but I'm like, if it would bring up a project, I think it's still sort of, like, unclear how you can get into that and contribute to it. Yeah. That's a great question. So one of the things that we are also hoping to solve here is that when there were two foundations, Node, JS Foundation, and the JS Foundation, it was a bit confusing for people who had projects that were looking for a third place, so to speak, which one they should go to. And it just wasn't obvious, so I think that kept a lot of people from potentially joining either group. So we're hoping that the merger also makes it more clear that there's really one ecosystem and we care about all of it. So that's one kind of another book full. Through this transition process, we have sort of had to figure out and negotiate right based on how the JS Foundation used to do project onboarding, what worked with that, what didn't work with that, what makes sense for the Node community, like, how do we sort of kind of combine our processes in a way that makes sense. So the conversation around project onboarding is very much active and alive. You'll probably, if you go to our OpenJS Foundation bootstrap, not bootstrap anymore, cross-project council repo, you can see a couple of different issues in PRs that are like proposals for how we do project onboarding moving forward. We do have a bunch of projects that are starting to talk to us now because it makes more sense, like, oh, we go to the OpenJS Foundation. And we're working with them to figure out what process makes the most sense for that community and how to have these conversations in an open but also respectful way. So, yeah. Hi, everyone. I'm Manuel from Package Minded Men's Team. I would like to understand how you evaluated the at-large project, the 15 at-large project, because, for example, in our team, we have found it difficult to define how to evaluate the project well, based on lots of, for example, based on issues and something like that. So I would like to know the logic you applied. Thank you. So on the categories, we did ask the projects to opt in to the category that they felt suited them. We didn't apply any metrics when we were combining them. That is something that I think the CPC will take on within the year to sort of figure out, okay, how do we really define what an impact project is, what the goals of a growth project should look like, that kind of thing. But at large, these 15 at-large projects opted in to that stage. And we will probably reevaluate on an annual basis whether all of the projects that are at-large should really be there, or are there some that need to be emeritus or growth, or if they want to move on to impact. Quick re-question. I don't think so. Hi, everyone. My name is Abel Nassim. I'm from Boston. I work at Boku. And I'm sorry to ask you a really hard question, Jordy. This is my first collaborator summit. I'm here because I have a problem. I want to talk to you guys about it later. But so hello, everybody. So my hard question is, how have you guys kind of, how are you consolidating these two different shifts of culture, right, where you have like, no, yeah, there might be like, team A, team B, team C, but team A, B, T, like they're all on our go. And they have one governance body at the end of the day versus like all of these distributed modules that are like, or package it with the libraries that kind of have their own governance and their own way of doing things in their own. And I'm just curious, like how, I mean, just from, from a management perspective, it's like having like going from like one problem child to like 20 problem children. And now we're having 21 problem children. So I'm just curious. Sorry for the hard. My favorite problem child. Yeah. My house is like, answer. So, well, it's hot. I don't think it's so straightforward. It may not be as obvious for people who aren't super involved in note, but note itself, as you mentioned, has lots of different teams. But the way in which node works is like, we have the TSC and the Com-Com, which are two separate like top level committees, and then we'll have a combination of different teams and working groups. A subtle difference that you don't really know unless you've shown up to know that even we get it wrong. Sometimes we're like, let's make a working group about this, but we've really been a team. And the biggest difference is like, a team is a coordinated group of people working on a problem. Whereas a working group is a group that has been chartered to oversee a particular thing and they own it. So a good example of the difference here would be like, release and build our working groups. Release owns releasing node. The TSC cannot go to the release team and even question what they're doing without de-chartering the team. Build owns build. The TSC can't show up and tell the build team how to manage the resources without de-chartering their team. The result of this is that even node itself between the Com-Com and the TSC and our various chartered working groups is a collection of different cultures, which is maybe not even totally obvious. Each within that has their own governance. So the modules came, for example, and I was talking with earlier, has drafted their own complete governance model that's different than any other team or working group would be able to do. So from a different culture perspective, and I don't even think node recognize that at first, we're actually already set up to have all of these kind of like smaller teams. I do think that thinking about how do we support and help lots of different teams that have different needs starts challenging some base assumptions we have. The collaborator summit was a really great example of that. Node has a travel budget. I won't ask people to raise their hands because they don't want to put you on the spot about like whether or not you took funding, but a non-trivial number of people in this room had their travel completely sponsored by the foundation and it wasn't only Node.js. But one of the things that we realized was perhaps this collaborator summit should really just be its own chartered working group under the cross-project council that has its own budget that's not specific to node. So it's not just like this node specific thing. So we do definitely have to like question some of these things. But to me, I think that this challenge of like scaling all these bits will actually make all the processes and things that we have in place far more robust and reliable. Like just a general abstraction thing like you solve for one, two, or many. So like we hadn't solved for one and now we're like immediately moving to solving for many. But when we figure out how to solve these problems for many, it will be much better. You know like right off the bat one thing that I can say is like the TSC of Node used to like more or less directly report to the board of directors of the foundation and not everyone who's on the TSC who's more focused on the technical direction of the project cares about all the things that have to do with running a foundation. It's not necessarily why they've come there. That resulted in a splitting our evidence of through a technical steering committee and a poor technical committee for a while. And there's so many acronyms it's very confusing. But we never really got the best measure of like having a committee that's focused on it. Now at the cross-project council we have a community elected governing body that has an egalitarian governance structure where anyone from any project can come and participate. So it doesn't have the same barriers that a meritocratic governing body has. But that it's focused on solving these problems. So the TSC can be far more focused on maintaining Node's technical infrastructure. And when we like need money for a thing, we can just ask the cross-project council and the few reps from Node who care about that can go to the project council and advocate for it. A very practical example would be changes to our charter. Our charter used to be chartered by the board and any changes we wanted to make to our charter would have to go to a board meeting. And it's frustrating. So it would mean that like we would need to have those changes. We would need to have those changes approved as a full request. That full request would have to go to legal. Legal would have to review it and rubber stamp it all between board meetings that happen on a monthly basis. Now we'll be able to just take charter changes to one of our weekly or weekly cross-project council meetings. And as long as we aren't making what we call substantial changes, like you never even need to go to the board. So yes, I think that like at face value, these things seem more complicated. But this extra layer of abstraction that we can have because we have more people working together is actually going to create an ecosystem and process that's far more for point two and far better quit to support individual projects than just a foundation focused on one project. Sorry if that was more than you asked for. That was like a really, it's on, it's on. Yeah, okay. Thank you, Miles. I was like, it really caught my attention and I really appreciate it, like the thought that you put into that. I had so many things that I was talking about while you were talking. And the first thing like I was like, oh wait, I had this moment where you said working group and then you started talking about it in this way that was very primitive. That like, I was like, man, I'm becoming a super nerve because now I'm becoming pedantic because you said working group and you're like, well, working group means this thing for, you know, and like it means this thing for no, and like now like does it mean the same thing universally? Even across standards bodies, working groups mean different things in the web world, you know, just like maybe more familiar to me than, you know, so it's just really funny. Like, so I guess as a fresh perspective, I would say that like to the folks here who obviously didn't care about to kind of question your own bias, as well as like do some exercises that are collaborative and intentionally painful with all of the new people and all of the new projects together around kind of redefining terms and normating constant things, right? Because I think that there's a lot of like things you take for granted, like there's conventions and, you know, things that are just the way we do things that are also just kind of transparent, not necessarily obvious. And that's not constructive to like, onboarding and welcoming new members of the community. Yeah, we've definitely done some painful and warming already that it's going to pretty positive. I think one thing to just wrap up so that the next session can start is just Amel, that the projects do you get to maintain their own governance system within the project. So we're not mandating a specific type of individual project governance. It's just the CPC operational structure, which we hope over time will become kind of invisible, because we'll just get these teams worked out and then we'll just be focused on providing services to the project in a really fluid way. So anyway, thanks everyone for your questions and for your time. I'm going to hand it over to Amel for the next session. Appreciate ya.