 Hi, good evening everyone. Thank you so much for joining me today. My name is Demia Jai and I'm the open source community manager at Call for Code for Racial Justice at IBM. And today I'll be talking about the power of cohorts in advancing open source contribution. And just a little bit more about myself. I've been in my current role for about a little bit over a year, so learning a lot about open source contribution and just community management in general. So I'll be sharing a little bit of some of my lessons learned through something we've done in Call for Code specifically. And just an agenda for today. So we'll be talking about what Call for Code is, as you might not be familiar with that, some of us in this room. Also what the impacts of Call for Code has been and our model. And also just talking generally about the benefits and challenges of contribution and what our approach to cohorts has been as well as best practices. So a little bit more about Call for Code. So Call for Code is a multi-year program that is created by the David Clark cause. With IBM as a founding technical partner and we've also worked with the United Nations Human Rights and the Linux Foundation to create a platform where people can contribute to tech for good projects. And we feature one of the largest tech for good competition of its kind. All around the world here. And Call for Code inspires developers to create applications for the real world that have real impact on humanitarian issues that are relevant and pressing in the world. And what we do after we've created these projects is to make them open source projects for other people to utilize. And we've worked with over 400,000 innovators who've participated in Call for Code since we started in 2018. And we have a wide reach all around the world with over 179 nations participating in contributing to Call for Code as well. And a little bit more about Call for Code through the years. So we are in our fifth year, so it's a landmark year for us. So since 2018, we've been working on addressing these humanitarian issues through our various global challenges. So in 2018, we worked and the winning solution for Call for Code was Project AL, which allows first responders and victims to stay in touch in natural disasters. In 2019, the winning solution there was a solution that protects firefighters from toxic exposure during wildfires, essentially, by providing them with predictive analytics and just being able to monitor their exposure. We've also worked with farmers with Agrily and also another project, Liquid Prep, dealing with the effects of climate change, allowing them to better manage their resources and be able to work better as they are planting and harvesting their crops as well. 2020 was a landmark year for us. Lots of things you all know were happening in the world in that time. So COVID-19, we had a special challenge related to creating issues or creating solutions that would address the issues created by COVID-19. We also launched Call for Code for Racial Justice, which is where I work specifically within Call for Code in reaction to the events that were happening in the U.S. and around the world related to highlighting systemic racism. And in 2021, we've continued our work there with climate change. And now in 2022, our global challenge theme is sustainability, which we'll hear a little bit more about from my colleague. And there's a little bit more about Call for Code. This is our deployment framework. Essentially, primarily we've worked with having a challenge, whether that's a spot challenge or a global challenge, where it's kind of a call for ideas and call for solutions around a specific topic area. And then after that, we moved to the deployment phase once a winner is chosen, where we worked to build a solution, to fortify and then to test the solution in the real world and working with real partners to actually see this solution implemented in the relevant communities there. And then we want to create sustainable solutions. So we try to find a pathway to sustainability where there can be real market adoption for these solutions as a way to ensure that they're continuing to live on. And just a little bit more about Call for Code as far as our model, because it's slightly a little unusual for open source projects. So what we have generally, and I'll talk about this in more detail later, is either a full time team or volunteer and maintainers that work on these projects. We also have dedicated Call for Code support, who are primarily part-time across our various products, and of course, open source contributors. And these, of course, some of the people who worked on our various projects from our 2022 Winner Southwater to some of our earlier solutions as well. And just a little bit about our impact with Call for Code. This is a snapshot of what we've been able to accomplish with our various projects. So we've been able to deploy our solutions, that's what these dots refer to, is where we've actually been able to deploy these solutions in communities around the world. And more specifically, for one of our projects, we've had over a thousand app downloads for that, and just generally we've had over 250 sensors deployed across our projects around the world as well. So definitely it's been encouraging to see these ideas go from initial, just an idea where a group of people are coming together to actual solutions that are now being implemented and affecting the lives of people around the world. And just a little bit more, and that's kind of one of the benefits of open source contribution is really being able to contribute to something that has effects and impact on people. And some of the other benefits of open source contribution are being able to improve skills, this is why people get involved in open source, being able to see the benefits of working on open source projects, building reputation, solving a problem in the world which we've seen definitely. And definitely overall it's definitely not about the money, it's more about the thrill of contribution that causes people to participate in these open source projects. But there are definitely some challenges with open source, as I'm sure some of you well know, specifically for both the contributors and for the maintainers. Some of the challenges within open source, this is a survey that was done over 17,000 developers surveyed by the developer nation. And some of the things that maintainers have said as far as that make open source challenging essentially boil down to a lack of support, which I have distilled a little bit further to either funding or people power. So a lack of funding has been a problem, right? So I guess in theory people could potentially work on these projects full time and if they're able to work on them full time, then they wouldn't be as overwhelmed with all the work that they'd have to do there. Another problem that people have had is just a lack of other people to share the burden with of maintainership. So definitely that can be something to be addressed as far as support. And just a bit more about the details of the challenges here. We're seeing people not being financially compensated. It can be stressful. They can feel underappreciated for the work they're doing. Users can be very demanding and expect too much of them. Again, that might be something that could be alleviated by having more people if handled right. It can be lonely, definitely that could be a thing. If you're the only maintainer or one of the few maintainers working on a project, it's hard to maybe have momentum to keep going, especially, you know, there's no one to vent to. It's just you dealing with all these users or maybe you want you and a few other people working with that. Definitely could be a major challenge as far as open source maintenance. So what we're going to talk about today is how we can use people power to address these problems. So that we can continue to create the sustainable long lasting solutions that have real impact in the world. And just a little bit more statistics about open source projects here. Unfortunately, the bottom of my one of my citations is cutting off apologies there. So 66, 60% of open source projects have only one or two maintainers. And this is a study that was done in 2015 and cited again in 2019 about this. So many projects are kind of like the Pareto principle on steroids, right, where we have just very few people contributing to these projects and maintaining them. And then even more about contributions. We see that there are 50% of contributors to popular OS projects account for only 2% of commits, which is kind of wild, right? So definitely we're seeing a lot of people doing the line share of the work both in and maintaining the projects as well as contributing to these projects. So now with this in mind and thinking a bit about maintainership and the stresses thereof, I want to talk a little bit more about call for codes approach to dealing with some of these problems and what we've tried. So just a little bit more about call for code. Again, just a little bit more detail with the slide that I shared earlier, as far as the model here, we have, as far as our full time maintainers, the products that have full time maintainers, I'd say about 30% of our projects do have some full time maintainers and the products that don't have full time maintainers, 70% of them are such. And as I mentioned before, we have dedicated support for call for codes in addition to the people who are working either part time or full time on as on the projects, the people who won the challenge. We also have our call for code staff who also work to support the projects, but we are kind of doing that on a part time basis because we are either supporting multiple projects individually or we're doing the maintainership role in addition to other responsibilities within call for code. And some more stats, we have about 80% of our projects have two or more volunteer and maintainers from what I was able to gather for just surveying our team was about maybe two to five maintainers mostly. And the asterisk is because this is assuming we take our call for code for racial justice projects in aggregate and treat them as basically one project, specifically for the call for code for racial justice projects. Currently today, I'd say most of our projects have one or two active maintainers. And all of these people are volunteer and part time maintainers as well. And just another, you know, key points about our call for code projects, these are tech for good projects that have real potential impact on the world where people can see how their contributions are making impacts, right? So definitely there's something that causes that makes people want to participate there. The mission resonates strongly, whether that's in climate change, you know, working against natural disasters, COVID-19, or racial justice, these are things that people care about, something that they feel impacts them personally, and they do want to contribute in some way. And again, like with many other open source projects, the majority of pull requests are made by just a few maintainers, regardless of the size of the contributor, contributor population in our cases, which might range from just like a fewer year to maybe 10, 20, 50 people a year, either making one time contributions, small contributions, or maybe larger contributions as well. And so again, some of the challenges that we face with call for code tonight, specifically, we'll talk about call for code for racial justice, because that's the subset of projects that has a smaller maintainer community. The challenges that we faced with call for code, even though we do have, you know, staff that work on these projects is that we still do have a small contributor community, and even though we still do have people who are being paid to work on these projects and partly through call for code and IBM, we still do have the same problems that other open source projects have. And the other problem is that we need deep engagement to advance these projects, right? So if someone comes on board, they're very excited to participate in a project, they're still like an onboarding period, of course, with all open source projects, that they need to be able to actually start being an active, productive participant in the project. And then the other issue that many open source projects face, of course, is that we have transient contributors, right, like people come in, they're excited, maybe they, you know, they're looking for a while, they might contribute, but then they drop off because they get busy with school, if their students, other things come up, projects, things happen all the time, right? So these are some challenges to finding and retaining contributors as part of an open source project, especially when you have few maintainers on the projects. So moving to what we've started to do, or what we've experimented with within call for code, we have been using cohorts, and I'll talk a little bit more about that to see to explain a little bit what that means in the, in context of call for code. So an open source cohort, as I'm defining it here, and I'm glad that's big on your screen, is that it's a group of developers and non-developers who work together on our project for the time can be, can vary. But what we've seen is between four and 12 weeks, there's a coordinated scope of work. So they're not just coming in and picking random issues. We try to find issues that they should work on. And we've worked with people, with groups that are either aligned enterprises, non-profits as well as individuals working together, or I should also have academics here as well, working together on these projects. So our past engagements have included enterprise cohorts where it's a client of IBM, for instance, with a group of people who are interested in working on our projects. We've also worked with universities, and I also would call them a cohort of sorts, so we weren't formally looking at them that way. We have people who are part of a course taking, who are planning to contribute to our projects as part of a semester and looking to get involved that way. And also I would say we have event-based cohorts, right? Because we do try to organize them. So for instance, we worked with, during Hacktoberfest, which as you may know, is a month for celebrating open source contribution. Call for code, and call for code for racial justice participated in that. And we try to organize events, onboarding, et cetera, to get people to contribute to our projects in that time period as well. And just a little bit on the benefits of call for code, you know, or these kind of, this cohort model is bringing lots of people together to work together to create a platform for great applications. So a bit more about the benefits of cohorts, you know, specifically for call for code, we've seen that it teaches people, allows people to work together on projects while meeting like-minded people. So we worked with Morgan Stanley on a cohort earlier this year, and I'll talk a little bit more in detail about how that went as well. And some benefits to a cohort model for an enterprise are definitely skills building, employee networking, and employee engagement. So this is something, if you're thinking of doing a cohort that you can pitch to enterprise clients if you have direct access to them, just talking about the potential for upskilling, the potential for employee networking, because as we've seen, people are able to work across their organization, meeting people in different capacities, different skill sets, different parts of the organization, different time zones, you know, and really get to expand their network that way, and they found it to be very valuable because now they're not working in these silos, right, and they're able to interact with people on a very collaborative project together as well. And definitely it drives employee engagement, especially because, again, when people come together to work on a joint goal, there is definitely a sense of purpose there, especially with Call for Code, where, as I mentioned before, we're driving more to humanitarian projects, which have a real impact in the world. So people feel empowered to work on things like that, as well as they feel a lot of good will towards their organization to actually create this opportunity and platform for them as employees to work together on something like this. So it's definitely a good way to engender good will within the company from employees. I can't, you know, make any claims about employee retention as a result of this, but definitely it's something that makes people look favorably upon the organization. And also, just speaking personally for myself, Call for Code for Racial Justice started as a spot challenge within Call for Code, and it was a few months worth of engagement internally, so in a way it was a cohort of itself, right? We had to come together, we worked for a while, and just seeing that our organization IBM really took something like this seriously, was able to invest the time in the program, programming to put together this platform for us to try to come together or to create solutions was something that made me see IBM in a new light. I got to learn about people around the organization, meet lots of different people. I was new at IBM at that time, so it was a great opportunity for me to meet lots of people within IBM, and it's definitely something that made me proud to be an IBMer. I feel like during the course of that cohort I heard people saying I've never been so proud to be an IBMer, just kept hearing that. I feel like I've heard it much more there than I've had in other encounters across the organization, so it's definitely something that also builds company pride, right? Like knowing that your company cares about issues that are aligned to you personally as well. And then a bit about the benefits of the open-source community. As we've been talking about the poor maintainers who are you know doing all this work, overworked, underpaid. Being able to have a cohort allows them to get contributions from new members. Also we found it creates fresh perspectives for to the project, right? Because you've been working on something for so long. It's easy just to not you know be able to see things from a different perspective, so it's good to have people who can bring fresh ideas to the project, and also in tandem also create and improve the open-source experience, right? So they might notice things that you've overlooked in terms of the documentation, coding, etc. You know maybe there you know new technologies that you should be considering. So it's just good to be able to have a diversity of thought around these projects that comes from having a cohort. So a little bit about our approach on what we've done in our cohorts, and I'll focus specifically on the enterprise projects, is that we've had you know an organizing team, which is our team, the call for code team, in addition to an enterprise team, right? And if you're working with a non-profit this could also be similar. So I think it's very good to identify who on your team can do the work, as well as if there's someone or some people on another external on the team that you're working with that can also do the work. In our team that was myself and someone else a technical lead on our team that worked together on formulating the cohort, getting things up and running, managing the cohort, and doing work around that. And then on the enterprise team you need people who can communicate internally with employees there, you know, provide their perspective, organize events, as far as we'll see the kind of events that are needed to kick off a cohort as well. So I think this is definitely something that's important to identify before starting, working on a cohort. And then a little bit about the pre-work, there is just a disclaimer, there's definitely a lot of work that goes into this and we'll talk about the trade-offs and the benefits and determining whether or not this is something that's useful for you. The pre-work that we've done and again you might find that this is not, you don't need to do all of these things depending on the state of your projects, the state of your team makeup, and the type of projects that you're trying and maybe even the audience, you might not need to do all of these things but these are the kind of things that we did. So we had info sessions and registration to drum up recruitment for the cohort ahead of time so we launched in January for instance one of our cohorts and we're doing things I think in November and December to have like you know introductions to call for coding, introductions to the kind of projects that they would be working on as part of this cohort. And also you know providing them ways to register to join the cohort and what all that it would entail which would provide lots of information to them about that. And of course with all open-source projects at all times we're also always trying to improve our documentation to make sure that it's ready in a way for more external contributors right because if you've been managing a product for a very long time and they're not many contributors it might be easy to overlook certain things so we definitely spent some time to give all of our repositories a good once over to see like what was missing what's broken what needs to be updated to ensure that things are up to date. And of course we're not going to find everything because that's kind of what we need fresh eyes for but at least making sure things make sense with something else to do. And also ensuring that our issues made sense in terms of you know how we're documenting the work to be done. It's very easy again if you're working just internally to maybe use you know just like short codes essentially or just things that are more shorthands essentially that maybe are more internal to your team and might make it harder for other people to contribute. So ensuring that these issues are up to the standard of external contributors being able to pick things up and go from there. The other work that we did was also understanding the incoming skill sets right so since we had we knew that we're working with a cohort it's not just like a random group of people finding us on github and working on the project. We try to understand the skill sets of the people coming in so we did a survey to identify what skills that they had both technical and non-technical because we also wanted to have non-technical people be able to contribute to these projects. And then based on that like based on the languages that they knew you know the other non-technical skills they had as far as project management or design thinking we're then able to think about how we might want to organize teams. And then the other thing that we did was to find the key issues to work on or maybe the key repositories so understanding what our needs were as far as roadmap understanding the level of difficulty would take for someone to be able to onboard to that project and knowing what the skill sets were. We started to organize a list of issues from our backlog that we wanted the cohorts to work on. And then we created some onboarding materials so in our case as we'll see shortly we created handbooks and project deep dive videos and then project team assignments and these were primarily to just ensure that people had an easy onboarding to the projects. And also you know as a way of rather than us repeating the answers to the same questions over and over again kind of provide a central place for people to get answers to questions. So that was the pre-work and then during the actual cohort itself again this is one of the courses that we've done essentially we had this timeline where we had kickoffs a kickoff which was just more orientation to the project letting people meet each other deep dives about the projects we also had some recommended courses for people to take and I'll talk a little bit about those because those are also resources that you can utilize they're free and open for anyone to utilize and you know talking about how they can deploy the solution and then we had like a cadence of events where I think it's very important to have a cadence of things that regularly occur during the course of the cohort. So we had office hours every two weeks and then we had playback sessions on the alternating weeks. So office hours were on I think on Webex or Zoom and maybe also on Slack where people can come and just ask questions and we definitely had a lot surprisingly I think Morgan Stanley just shout out to Morgan Stanley they're very engaged so we definitely had lots of people coming to our office hours throughout the entire course of the cohort asking questions consistently. And then we also had playbacks for ours we kind of kept it a little loose as far as the structure just kind of gave them the time slot and just roughly what they should cover. Going forward we might do maybe a bit more structure there but we still got some pretty good feedback or we're able to capture what they were working on during the projects pretty well as well. And then we also had because the nature of our projects there's a lot of we're trying to design and upload or advance the some features as well so we had some designing design thinking around this as well as some planning sessions to really try to figure out exactly what we should be working on. And we kept this going and then we had a final playback and retro for everyone and in part of ours we also invited some key stakeholders which I think is important to be able to get more people to be able to repeat the project essentially or repeat the cohort going forward so we had more people who took part in the final playbacks just so they can see the value of their employees being a part of this event as well. And then a little bit more about our resources as I mentioned we created these handbooks which sat in GitHub where they could very their interactive handbooks where they could learn about the program our contribution contribution guidelines about the handbook about the projects that they were doing you know the very steps to get involved of course we had to reiterate things both in the handbook and also when we had our playbacks and our office hours but it was good for them to have a resource to refer to as well as knowing how to onboard to Slack register for IBM Cloud and just even logging their volunteer hours through Morgan Stanley in this example. We also had some as I mentioned deep dive videos so we created some videos that walk through the actual issues and the repositories to provide more detail again just trying to automate certain things so that we can just have a more centralized way and kind of reuse some of these materials going forward so it's not always starting from zero when you're starting a new cohort as well. As I mentioned we had some playback and demo days so this is actually from Hacktoberfest where we you know just to encourage people to see what progress is being made to see what your your fellow teammates or your fellow employees are doing your fellow cohort members are doing it's really good and also a good way it's for people to be able to showcase and show off the work that they've done together. So we had playbacks and demo days as I mentioned as part of this and then a little bit more about the resources so this was good because it helped people to better onboard right so for us within IBM we have IBM this course introduction to open source so if anyone's new to open source they can participate they can take this four-hour course that allows them to learn about open source they get some exposure to get as well at the end they receive some certificates or a certificate we also have a design thinking course so we encourage people who wanted to take part in our cohort to take advantage of these resources and again you you can also take advantage of these resources and include it as part of your core just by going to these websites here. All right so a little bit about the results of what we found you know putting all this effort in just a bit more about casual contributions a few papers and publications have found that like with casual contributions people were just you know coming to your open source product and contributing a lot of times they're providing updates on typos and grammar bugs you know sometimes new features sometimes some code refactoring right so we definitely want to see whether or not there's something that's going to be valuable valuable to the maintainers right whether or not these kind of contributions are useful for the maintainers in terms of the work that they put in so this is why I think skill assessment is very important so as I mentioned before before starting the the entire cohort it's kind of good to know where people's skills are so you can be able to better gauge the kind of contributions you expect to see and also the type of issues that you should be highlighting for them to work on whether that's bugs or just more documentation or some new features also so for our Hacktoberfest cohort essentially we saw again kind of similar to that paper that I just put on the screen that we had similar distribution as far as the type of things so we had some documentation people fixing grammar errors but also like finding things that just didn't work or links that were broken in our documentation and working on that we also had people doing some improving our just our CICD GitHub actions just making things more automated and depending on the maturity of your project you'll probably skew more to one side or another as far as where your contributions the type of contributions we're getting from your cohort as well. For younger projects you're probably going to see more documentation as well as some just you know basic CICD or GitHub actions things that are implemented there but for us we also had saw a good bit of UI updates or UI suggestions for things to be done with our projects and then now for our Enterprise engagement so we had with our cohort specifically we had a few different types of contributions that were had we didn't really focus on documentation per se as like issues to work on but we did say that if people found issues with the documentation they should feel free to open a new issue update the documentation make a pull request and work on it so the things that we found were you know UI updates which is in the top right the community legislation at your fingertips people there were also some bug fixes that happened closer to documentation in the bottom left we have we had an opportunity for people to create a sandbox environment so a lab that people can utilize to learn more about the project right so basically being able to install the project but in a sandbox environment where nothing's going to break right your dependencies are not out of date like everything's going to work you just have to follow the directions so this is a good way we found for people to on board to the project so we wanted to improve our documentation by adding this to the products as well we also had some data model fixes which is the bottom middle picture there's where we had people actually providing great feedback as to how we might want to update our data model and add more data to our models to be able to better document that information and then the bottom right is some of the CICD work that was done as part of our projects as well so now we'll talk a little bit about the tips and trade-offs of adopting a cohort model so first of all it's potentially very demanding for maintainers right it definitely requires a lot of upfront investment but the benefit is that it can be repeatable over cycles so we have to figure out like what parts of your projects or the contributions you're looking for are things that maybe you can just invest the time in to create evergreen documentation or onboarding or videos etc that can then be utilized by different cohorts coming through to work on over time so you know another thing to think about is how can you actually make the effort worth it so one that's needed to be done is to determine whether or not this model works well for your team makeup so for us like we had some I guess informal project managers such as myself who could work on this so whether or not you have people on the team who are able to kind of plan things organize things and you know not be frustrated with that also whether you have maintainers available to help whether that's you know being a part of office hours playbacks helping you with choosing issues and things of that nature so really determining whether or not this model works for your team it's going to be the major first step to determining whether or not you should look into a cohort model the other thing is I think that's very important is to create a healthy pipeline of cohorts right so you know it's not wouldn't be great to just have one cohort and you never do this again because that's a lot of investment in the project or in this model I think it's good to also have a group of people who might participate who found interests within with working on cohorts as well so finding mission aligned groups as well as skill aligned groups so finding groups that have the skills and will be necessary to be able for them to onboard with course with some help but not something where it's going to be a lot of time spent even with all the resources for them to get engaged effectively and then just a little bit more on some tips lots of tips here so as I mentioned before and kind of this is like a summary we have pre-work before launch you want to provide training and onboarding as I mentioned before you want to know what your cohort skills are beforehand potentially I mean maybe it depends on you know the audience that you're looking at you might just be able to gauge what that is knowing what your cohorts time commitment is is also pretty critical and being able to choose an ideal time length actually what we found in our cohort is that our most recent cohort is that people wanted to do this for longer actually so it was for eight weeks and the feedback that we got repeatedly was like they would actually would have liked it if it maybe even went on for 12 weeks which is very surprising for us or to us rather but I think it was because again they were very dedicated to the mission and they just wanted to have enough time to work on it and also you know because of the length of the projects and just in general it's really good to plan for team building activities and culture so again with the play backs if you have like a slack channel what we did is something called thankful Thursdays where people can you know recognize people who've helped them with their projects during the course of the week having happy hours or anything like that or games nights or games times for people to participate in it's just very good to create like this kind of other worldly experience within the corporate environment where they're able to you know get a lot of low stress hopefully experience with their fellow employees building something so something just again that just garners goodwill amongst the participants the other thing that we found that's very helpful is to encourage pair programming so we found a lot of people made a lot more advances where they were able to schedule ad hoc times to talk to other people getting creating surveys to get feedback such as what we did of course getting buying from maintainers you need that upfront otherwise this will not work at all but getting that buying explains them the level of effort and knowing how that effort will reduce over time is something that's going to be critical and also a drive to incentives so this might be for pitching this to stakeholders so what are the benefits to the organization or to their employees from this cohort so things like certifications as well as maybe any recognition on blog posts so for instance here as an example I'm using myself just because I don't want to you know put anyone else's stuff out there you know having the finishing or taking part of the open source course is something we get a certificate as part of that and again just a plug for the open source course as well as with an IBM we're able to also highlight people who took part in this initiative and just a little bit now changing gears a little bit before we get into the Q&A just wanted to highlight again just IBM's participation in open SSF so we're working a lot on this issue of supply chain security and I encourage you to check out these materials to get a little bit more information there so we have a few minutes left so I'm going to leave some time for my colleague Joanne to talk about call for code our global challenge overall and then after that I'll be able to take any questions that we might have from the audience oh no you can go first hello thank you yes so I am the ecosystem development leader for our call for code team so thanks Demi for that you just want to share a little bit about how to get involved there you go so for this year our 2022 global challenge theme is sustainability and how technology can improve sustainable production production consumption management reduce pollution protect biodiversity so those are some of the questions that you can answer as part of participating in the challenge for this year and the challenge kicked off on April 26th of this year and it runs through October 31st we have gone through we got a slide with the actual timeline so we have it broken up into accelerators so we just finished the first accelerator and we'll be kicking off the second one in a few weeks and so there these are some themes some topics that you can actually work on that will be provided as part of the platform for working on some solutions and it kind of varies they all fall within the areas of sustainability and we picked sustainability because as you see there are a number of companies 86% that actually have a sustainability strategy but only a few have acted on it so we felt that that would be a great area to focus on and then also global consumers you know the pandemic has affected them so that's an area in which we're looking for solutions more in the supply chain and those specific areas and this is the timeline so this is the key thing and all of this information is available on the platform but we just like to show the timeline that I mentioned that was kicked off in April and then we had the first accelerator in June and then we have July 13th through the 27th is coming up and the accelerators is a two-week just a prescriptive set of time that you can work on solutions so we hope you get we get participation in those various areas and it goes all the way through October 31st and there are prizes that are available for participants and just some of the ways that organizations can participate so of course participating in the challenge but also we look for organizations who have APIs they have technologies they have some datasets that they can contribute to some of those solutions such as Demi had mentioned earlier we also look for mentors to participate and as she had already talked about you know it's a great way to engage employees and developers within the company I actually was one of the participants in the challenge within IBM a few years ago and this this is just a slide that we can make available we're here to actually provide some input as well or provide some feedback and more information but we basically just say answer the call and then at the bottom there is a click through where you can register to get started on the platform on how to participate and start expanding your network and creating some solutions and building some solutions so that's all I have all right so thank you everyone happy to take any questions looks like we have about a minute anyone have any questions all right thank you everyone for joining