Greetings everyone! Premier John Horgan here and graduation ceremonies are normally a time of great pomp and circumstance and is a rite of passage for students around the world. It is an enormous milestone and I want you to be proud of what you've been able to accomplish this extraordinary year. Congratulations BC students, you did it! All 600,000 students from kindergarten to grade 12. Under the most challenging public health emergency in BC history, where things have just been so different, despite it all, you've finished the school year. Congratulations! And to BC's teachers, educational assistance, school leadership and administration, our school custodians and maintenance workers and our bus drivers, we can't thank you enough for making the social and emotional wellness of students our collective priority this school year. And to parents and families, your support makes our education system strong and this year you've played an even more vital role. Thank you so much. I'd like to send a special shout out to all the graduates, those students moving from elementary to middle school, from middle school to high school and of course our high school graduates. Some of your peers have some thoughts on this extraordinary year. It's not the usual school year, it's not how we really thought our grad year was going to be or to start any year is going to be. So I think that we should all just be proud of ourselves for accomplishing it. It's crazy, I think it's just really we should all just really be proud of ourselves. I know it's been challenging and difficult at this point but just keep on keep on going and don't give up. The future is bright and we're all here with you supporting you each and every way. And we've persevered through this and we will be the subject of history textbooks in 50 years which is something I think is really great. I think the pandemic is just another obstacle and we are so strong to be able to overcome it. I would have liked the graduation in the big building with all my friends and all my family. Given the circumstances, this graduation is still honestly really great. We know the celebrations. We're not necessarily what you've been hoping for but I've been so heartened to see how families and schools and our communities are doing their best to honor your accomplishments in safe ways during this pandemic. Every graduation is a celebration and please know that all of us at Public Health have been cheering you on and marveling at your resilience and strength during this most challenging year. Have a wonderful and relaxing summer. The class of 2021 will be memorable for so many reasons. To all graduates, congratulations. From all of us in the provincial government, we are very proud of you and your accomplishments. And to all students, have a terrific well-earned break this summer and we'll see you in September. I'm proud of you.  Your community is proud of you.


Hi everyone, welcome to my talk today. I'd like to talk to you about how to unleash your features Let me dive right into the implementation So what is a feature toggle feature toggle is essentially a branch in your code asking if this feature is enabled Then do this otherwise do that That is essentially what a feature toggle is but what's the use cases of using the feature toggles? so I want to start with a example I Work on a project called OpenShift cluster manager where we install a lot of OpenShift clusters and sometimes these clusters may break They may get into some weird state and they end up in an error state and what we wanted to do was we wanted the system to collect any piece of information it can and then Report it as a Gira ticket so we can track it. We will have all the information available on Gira for investigation and and have that Automated process running But when I started working on this feature, I thought to myself well There's kind of a risk we've introduced in this feature for once this Gathering of these pieces of information it may cause some performance issue We're talking about the service that is now supposed to communicate with another system Whether it's the cluster itself to get information from the cluster whether it's Talking to Gira and communicate with that system add all these information Pieces as attachments it might break it might fail So I was kind of concerned with How much risk am I going to introduce to the system just with having this background process running around? in my service, so I thought well, how can I reduce the risk of introducing this and One of the things that I thought was let's see. Let's try to think of introducing this With some activation strategy I want first I want the developers and the QE team or the QA team to be able to test that feature We've just a small amount of clusters just to see how it behaves to see that tickets are opened on a timely manner that the system is able to collect all these pieces of information from the cluster and have it attached to that Gira ticket and Once I have enough confident that the flow is working. I want to see some feedback I want to see some customers actually Going through that flow and see did I actually Increased the response time. Do I catch issues earlier than it? I could have caught them Without the solution and once I gain enough confident that everything is working and there's no performance penalty With this solution I can open it up for everyone and eventually remove that feature toggling from the code itself So there's many use cases for using feature tokens and this is just one of them So testing with just a small amount of users is one use case Of course, I'll need to collect some feedback from customers or use users And it doesn't matter if these are external customers or QA team internal developers So that's one use case one use case would be to test with a small amount of capacity So sometimes I don't really care who are the users that this feature will be enabled for them I care more about how much of the users will get exposed to that feature Because I want to monitor the system I want to see that it can handle the load and I can gradually open it up more and more for more users and more capacity and Once I make sure that the system can handle it or not and do the right tweaking I can Remove the toggle itself There's also a be testing of course I can test different paths and collect analytics information and decide which path is the best one to proceed with and A kill switch is is a great example. So I Can test my feature. I can have the QA team Assure me that it's working as expected I can have some customers using it or every everyone can use it But at some point there might be a surge Or like a huge amount of requests coming me coming in and then it may break the system I should have a way of hitting some switch to kill that feature and protect the system from Any incident and sometimes it's not the system itself. It may affect our system that the system is talking with So having a kill switch is a very powerful tool there Of course, it's also can be useful as an alternative for canary deployment with canary deployment You take your code you deploy it in a very controlled and safe environment. You test it and Once you're sure it's working as expected you deploy it to more parts But we feature toggles. It's kind of an alternative way of doing it You just deploy the functionality to the entire system, but it's disabled you can enable it at runtime on your own Time window when you're available when you have everyone on board that you need them to be and then You can test the feature and then you can switch switch it off when you need to at any point I Like to talk to you about unleash So unleash is a management system for feature toggles or feature flags It's open source project. It's available on github We're using it for a while now and the way it works is that the user is using your software Whether they are using the CLI or making an API call to your service They may have been using the UI itself somewhere in your code there's going to be that feature toggling asking is this feature is enabled and We've using unleash the flow will actually making an API call to the unleash system asking is this feature is enabled and providing some context like some user information any kind of context that is Important to make that decision and then unleash will respond with a yes or no And then your code will be performing that branching according to their response Now there's several activation strategies with unleash The basic one would be the one that you will probably expect it to have which is either on or off The feature can be disabled or enable. There's some user identification activation strategy so you can pick Activating something per user. It can be per session ID or IP address There's also the gradual rollout options, so I can say please open it up just for 30% of the request or 40% of the request it doesn't matter to who and then open it up gradually as I see as needed and Interesting part is that you can also extend it by writing your own custom strategy, so we are using that feature and we are actually Implementing a custom strategy, which is organization based So we pick an organization like a specific customer that they are very interested in Trying out this new feature this new functionality We've opened it up just for them just to play with get their feedback And then once we've made all the adjustment we can proceed and open it up for more and more customers So how do you start with unleash? You can install and run the binary itself. You can download it. There's also a hosted option Once you run it you log into the system you create a toggle and You pick an activation strategy for it now The other part you need to do is integrate with your code So you can use one of the available SDKs that unleash has it has several SDKs in different languages If you're using a different language and then you can just make an API call to the unleash system And that will essentially be asking unleash is this feature is enabled or not? So how does it look like? This is how the admin console of unleash looks like when you log into it You see a list of available feature toggles. These are features toggle feature toggles that we've created there's also the new feature toggle button that I've mentioned and If I'm gonna dive into one of the feature toggles, I will see something like this So on the upper part upper part, there's the feature name I Can see the features active I see a description of that feature over here and I see if it's Enabled or disabled And on that main part I see the activation strategy This specific feature is enabled just for a couple of organizations. One of them is the development Organization the other one is the QA organization. So we are testing How will the system behave if we are? Bypassing the limitation of number of compute nodes. We want to make sure that the system can handle it We want to make sure everything works as expected and then once we have gain confident Then we can open it up for everyone if I'll go into the metrics tab of Unleash feature. I'll see more data about the exposure rate So I see I can see how much request got into unleash asking it is this feature is enabled or not I can see how many requests got rejected or Accepted I can see it over different period of times 48 hours 24 hours and Etc. There's also event log. So it's kind of Important if I want to see for example, my morning tells me that there's some performance issue If I'll go into unleash I might see Someone enable some feature like in the last hour I can maybe correlate issues with that So that's also important for auditing I'll just summarize this presentation. So using feature toggles is a great way to test your product and Have its table as a service, of course unleashes a great system to manage your feature toggles and You can also implement your own strategies according to your own product needs and your own business needs And I'll take any questions now No, it's an open source project. Oh, sorry. The question was is unleash An open source project maintained by me or the team. No, it's not Open source completely not owned by red. Any other questions? Yeah so You need to consider that Sorry repeating the question. The question was how much overhead is there with using a leash? So you need to consider that every time your code would be asking if this feature is enabled It's going to do another API call now. Of course, there's some penalty for that You may catch the results you can introduce that into unleash client itself and then there's also You need to be aware that when you hit the switch on unleash it takes roughly I think three to five seconds until it syncs with all the clients. So Yeah, there's a performance penalty there that you need to be aware of any other questions Great question. So every time you pick Question was what happens if unleash is not available. So first of all, obviously you you should probably pick In a good as a la for the unleash system But if it's not available, then you're gonna need to set up a default for every feature. So Whether it's on or off, it's your decision, but yeah, you need to pick one One option. Yeah There's no other questions and I'm done. Thank you


Konnichiwa, Watashi no namaewa, Borek san Jeff Desu, and I've just exhausted my knowledge of Japanese language. Thank you very much for coming. How many are here? A quick show of hands. How many are here for the deep dive on the Linux kernel, the technical deep dive on the Linux kernel? Raise your hand. You're in the wrong room. We're here to talk to you today about containers and the OpenStack Magnum project and the involving ecosystem. Let's do a real show of hands. Now, how many have heard of the containers? You'd have to be living under a rock if you haven't heard about containers by now. It's the hottest topic in the IT industry and kind of has been for the last 18, 24 months now. We're very pleased to be here to chat with you about it. I want to quickly go over the agenda. We're going to go a little bit into the history and kind of help frame the argument for some of you who it may be a bit new to. We're going to talk how containers fit into OpenStack and in particular the Magnum project. We're going to go into a little bit of what's happening in the area of standards around containers and a lot of activity. You've heard of probably the OCI or the CNCF. We'll talk a bit about that. We'll also talk about where this is going to go in the future a bit and then hopefully we'll have some time for a little Q&A at the end. I'd like to start though by introducing a couple of my colleagues who are here with me, Megan Kostak and Dan Crook. They're both part of IBM's Open Technologies Team that I also am a part of. We roll up to IBM Vice President named Angel Diaz and what they focus on is specifically engagements with clients, helping them form their strategy around emerging open technologies and the area I focus on is working with our partnerships and business development, my background is engineering and I've done some coding in the past but it's been quite a while. I do work with the OCI and the CNCF as well as I am the chair currently of the Docker Governance Advisory Board. With that I want to turn it over to my colleague Dan who's going to kick things off. Thank you. Thanks for the introduction, Jeff. For the few of you in the room that are not familiar with containers we're just going to take a quick look at the technology and why it's so exciting. As you've been watching probably OpenStack for the last few years as we've gone from Cloud 1.0 to Cloud 2.0 where the original basis of virtualization was virtual machines. Traditional applications in these cloud environments they basically required a lot of duplicate resource usage on the hosts. They relied a lot on copying entire applications many times and they required emulation of the hardware. So on the left side of this diagram in the traditional virtual machine virtualization model there's an entire guest OS that's copied multiple times for each virtual machine that you're putting on a host's Nova compute node. There's a whole hypervisor that's emulating and translating the calls to the hardware for you and it leads to large size images as well to transfer the entire guest operating system. So with containers you're looking at basically a magnitude of much better density as well as faster startup of the applications, faster scaling, scale down and much easier deployment of applications because they're much smaller and therefore easier to transfer. So you're getting a lot of benefits with this shared kernel usage of the containers but there are some drawbacks there that expose some security vector the attack service becomes a little bit larger and that's where OpenStack Magnum comes in to help ideally host containers for you. So containers aren't new even if they're the hottest thing in the last couple of years. If you're new to them you may think that Docker is synonymous with containers but there's a long history of this virtualization that goes back even to the start of Unix. But about 15 years ago they really inert us started basically building on the old Unix CA Trute concept where the file system was segmented between processes into something where the actual processes themselves were isolated. So this concept came from FreeBSD and was translated over to Linux around 2000 but it required patching the Linux kernel. It was pretty deep into the lower level aspects of Linux so it didn't really have much uptake back then. At the same time in System 5 Unix Solaris was also innovating with operating system virtualization. So they introduced this idea of snapshots, cloning of individual virtualized instances and building upon this in 2006 Google put together a paper on process containers which were a way to group together processes to have them share resources independently on that operating system from other processes there. Red Hat introduced user namespaces with namespaces and this allowed the virtualization of users. So within a container you could now allow root privileges that never could escape that container. And IBM introduced a bit of tooling around that bringing these concepts together but there were still some questions about security and user friendliness of actually working with those tools. So that brings us to Docker which really brought the mainstream both by making the tooling a lot easier but also coming up with the concept of images and images that can be built on with deltas so you can iterate and basically take an application, package with the dependencies, build on it and deploy it out to your production systems without as many dependencies. So with all those benefits of containers naturally you'd see them go into a lot of the brand new innovation that's been going into open stack over the past five years. One of the first places that containers showed up as they were seen as smaller individual units of compute was the Nova Docker driver. So basically within horizon from the Nova CLI tools you could work with them, images could be stored in glance. So it's basically an IaaS light individual containers just managed like virtual machines. A little later we saw heat enhanced to orchestrate the deployment of containers on top of Nova instances and more recently we've seen the COLA project emerge to containerize the open stack control plane itself. So if you're familiar with starting with open stack where you had one monolithic controller node that had all the services on it, you had maybe a network node that was separate and you had n number of compute nodes. What COLA is letting you do is take all those services, spread them out over smaller resources and enable you to treat them as microservices, scale them independently, aggregate them, deploy them with zero downtime, things like that. And newest is Murano. If you're at the Vancouver Summit it basically showed the marketplace, the app catalog and how users can consume containerized applications. But the most important focus of this talk right now is open stack Magnum. And what Magnum is doing is taking a lot of innovation in containers and exposing them through the traditional open stack projects.  Thank you Dan. All right, I'm going to walk you guys through a timeline of containers in open stack over the past few years. So back in May 2014 the open stack container team was formed and their main goal was how do we standardize the container environment in open stack. They wanted to provide consistent deployment of containers and have that familiar open stack project feel. As well as remove the risk of choosing a single container strategy just because it was just getting hot and we're not sure where it's all going. If you fast forward a year the container networking team formed to specifically focus on consistent networking strategy for containers and this is still something that's evolving. And just this last August at the open stack Silicon Valley conference the main focus was on containers and where it's all going and how it fits into open stack. And as you all know the open stack Liberty release just happened this October and the first production ready release of Magnum was included in that. So what is Magnum? It's open stacks container as a service solution and it just provides your complete management for containers in open stack. It uses heat for the orchestration of the host machines. It implements multi-tenancy using Keystone and it provides multi-host networking using Neutron. Right now it supports some container orchestration engines that include Docker swarm, Google Kubernetes and Apache Mesos. The cool thing about Magnum is that along with its own APIs it also exposes the native APIs of these container management solutions. This would include like your Docker CLI commands as well as your Kubernetes client commands. Right here up on the screen is kind of a high level view of the architecture of Magnum. As Dan stated earlier it's very integrated with a lot of the mature open stack projects you've heard of and this morning as Jonathan Brice flashed up on the screen the adoption versus maturity of projects, it's continually changing. So Magnum was, you know, on the lower aspect there being new and all but some of the most common projects that it's integrated with are Heat, Nova and Neutron and it has that consistent open stack feel or layout having the Magnum APIs client and conductor. So now that you've got a brief history of containers and what Magnum is from a high level perspective we're going to switch gears and Jeff's going to come up and talk about the foundations and the work going on there. Thanks, Megan. And if you're wondering why we're switching back, we have a philosophy it's harder to hit a moving target so we're going to keep doing that. So I want to make sure I meet expectations though. How many have heard of the open container initiative before? So about half. So I will spend a little bit of time and I think we're doing good on time so I will spend a little bit of time talking a little bit about that. I've got a small pun, I don't know if it will transition but it's the good old saying, you know, I love standards in IT industry. There's so many to choose from. And if you think about that it's like, well, wait a minute, is it standard or is there so many to choose from, you know, it represents a challenge, right? So why the open container initiative? So another quick show of hands. How many have been to a Linux conference? Linux foundation conference, let me be specific. Okay, not as much crossover as I thought there might have been. So this is a great point to stop a bit and talk a little bit about that. The whole idea behind containers is that it's really revolutionized something that was fairly deep down in the Linux kernel, fairly gory, difficult to use. And yet it's so important and IBM and other companies feel that it's so critical to the evolution of how this infrastructure is going to evolve going forward that it really can't be left to any one single company to have control over and or struggle with trying to manage. And so a number of companies have come together under the umbrella of the Linux foundation. And it's not to try and create a whole heavy bureaucracy of overhead in helping to define containers and standardize them. The real goal about doing it as a collaboration project of the Linux foundation is to provide the leverage of that existing body but only a small efficient lightweight group that are really dedicated to try and standardizing what it is to define a container format and runtime. Next slide, please. So this is really about trying to meld these emerging technology areas and how many got a chance to experience or saw news about DockerCon North America that happened in the June timeframe in North America. So at that you heard Solomon Hicks from the main stage make a big announcement about the formation of the open container initiative and that was great because up until that point IBM and other companies have been working with Docker and talking to them about what are our options, how are we going to evolve what's been this great viral uptake in the open source code behind Docker containers and begin to mature it towards an open governance model entity. And at that conference they announced that not only were they going to participate in the open container initiative but they were also going to contribute code to that initiative in the form of what's called Run C or their implementation of the container standards back. But it wasn't all altruistic. In that last year in the fall there was a competitive project announced by a company called CoreOS. They'd been working actively with Docker and yet they were struggling a bit because they had been trying to collaborate and Docker's a small company totally overwhelmed by a huge potential opportunity and so there was sort of a lack of effective forum for which everyone to come together and have dialogues about how this should evolve. So CoreOS launched a competitive alternative to Docker called Rocket and that also helped to kind of get the attention and get people in the industry thinking about this important concept of who should get to define a container and how should that evolve going forward. And you can see from the slide in front of you that there's some concepts that you can read and we could talk about them in the Q&A afterwards but the most important element of this is that it's really no longer a situation where it's intended to be Docker versus Rocket and CoreOS, etc. The press likes that. It sells news feeds and that type of thing but the real key element of that is that with this OCI coming together it sets the stage to resolve these conflicts and the other last point I want to make on this slide is that again it's not just those two companies it's IBM, it's CoreOS, it's Google, it's SUSE, it's Red Hat it's all sorts of important companies coming together to help solve this problem or this challenge associated with the OCI. Next slide. So three things that I think are most important about this concept is that the open container format specification is the document that is going to be shared in open governance as part of this collaboration project under the Linux Foundation but yes, dockers donated the Run C code and that code and the implementation spec are going to iterate back and forth as they evolve going forward under this shared governance model and CoreOS is actually going to be a key participant they've offered up AppC as their reference implementation for their spec we want to see those come together and resolve to a single group but as the slide shows it's also being driven by a lot of additional input into this process by other members of the community and that's another key element of this because at the end of the day, if you think about it how effective would Linux be if way back when there was a split and there were these two factions thumb wrestling over the control of how that would evolve so it's not going to be easy but we think it's got great potential and so far every group is really committed to making this happen and making it a reality and the last thing I'll say is this is all happening in real time in that the charter documents and the membership agreements are still getting defined through this community process and if you're interested in getting involved in it as it's coming together or going forward see me after the presentation today I'd be happy to talk to you about it a bit more next slide so I thought about putting an interim slide before with this one that just said IT, heart, buzzwords because who's heard of the CNCF? Anyone? A few? That's one of the newest elements of all of this but if you think about it it would be not exactly finishing the project if you came together and defined a container spec but what about everything else that comes into play when you look to try and effectively manage container technologies? So I talked about Docker and the group announcing the OCI that happened in June of this year one month later at the OSCON conference in North America a group of companies including Google and IBM and others all came together and announced this CNCF and the idea is containers are great and they're so impactful how are we going to share a common vision towards container automation and orchestration and so the goals as you can see here on the slide is to start with this common container packaging approach but to make sure it's dynamically managed in a way that's a open framework that's very microservices oriented and those three key elements are going to be part of what drives the vision of the CNCF it also will be a relatively lightweight meaning that it's taking advantage of the infrastructure behind the Linux Foundation it'll be a collaborative project of the Linux Foundation and you can sort of see the synergies between the OCI and the CNCF they're going to resolve their charter and membership agreements about the same time so that there's a clear end-to-end goal to start this initiative right but this isn't going to happen overnight it's going to take some time and if we can take a look at my last slide you can see that there's a pretty impressive list of companies not quite as broad and expansive as the OCI but companies like AT&T, Box, Cisco Cloud Foundry, Twitter, and others if you think about what's happening in this space how many are aware of Kubernetes? it was talked about during the morning keynote that's a very impactful project from Google based upon their Borg internal infrastructure but it's not the only type of cloud-native infrastructure project out there you've also got the Mesos project from the Apache Foundation how many have heard of Mesos? pretty good pickup on Mesos in addition to Kubernetes and Mesos you've got Docker Swarm, right? I mean that's part of what caused some of the tension in the community is that 24 months ago when Docker was brand new everybody loved Docker because it was the thing that made something that was really challenging in the past very accessible to the typical admin or developer who wanted to do a very DevOps cloud-native type of application development but when mid-last year became apparent that Docker's vision was beyond just container technology but looking at it as a platform to do end-to-end application development other competitors in that space people from the Cloud Foundry ecosystem or other ecosystems kind of got concerned and so that's another thing that in the industry we think both the OCI and the CNCF will help come together to resolve and as you can see the high-level conceptual architectural diagram here and my thanks to my friend and colleague Craig Mclucky from Google who contributed elements of this as a document as we're working together again real-time and coming up with the CNCF charter and membership agreement it gives you a high-level representation of what the architecture could be as we all try and work together on this so my last thought for this slide to leave you with is that just as the OCI targets container image portability the CNCF targets cloud application portability so it's all about freedom and it's all about choice for the individuals and users and with that I'm going to take it back over to Megan to pick up on the rest of our session Thank you, Jeff Alright, so I'm going to try to tie the foundation efforts into how it's going to affect Magnum and so let's start with what Magnum brings to the table so Magnum kind of set itself up from the beginning to incorporate, I guess, any uncertainty that the industry was going to bring in terms of containers so some of the things it brings to the table are their main goal of providing a standard container environment not having any container strategy lock-in for its users as well as an adaptable infrastructure for change so in terms of a standard container environment right now it supports Swarm, Kubernetes, Mesos and these all run Docker container or manage Docker containers which are based on Run-C which is the basis for the OCI so we're in good shape there and then with the CNCF Kubernetes donated their code as kind of the starting point and so there are some possible changes that Docker Swarm will want to align with as we see things progress and a big thing as I talked about earlier was they didn't force anyone into a strategy so users can see what's going to happen with these foundations what standards are going to come out of it and then they can choose what works best for them and just being adaptable Magnum itself supports these container orchestration engines so a lot of the changes it's going to inherit because it supports those and they're going to change and turn so that'll be good for it to sync up quick with the standards so kind of in short term what Magnum is doing now and especially throughout this week you're going to see a lot of sessions and design sessions that are focusing on providing consistent networking so right now the container networking team is trying to leverage Docker's Lib Network that way users of OpenStack will have a consistent container networking strategy in and out of OpenStack but this of course is continually evolving we could see some results this week even on it and right following this presentation is going to be another session on Courier which actually links Neutron to Lib Network which could definitely be something positive for Magnum and here is kind of a projection slide so none of this is set in stone so some things that we think Magnum is going to need to focus on in the future is of course adapt to any results of the foundations as well as contribute back that's what these foundations are all about so as Jeff stated earlier the OCINCNCF are continuing to work on their charter and member agreements so we're going to see changes there but as I said Magnum kind of is agnostic from these specific container technologies so they should be able to pick up these changes rather easily and just Magnum having a growing user base they're going to get requests for different user stories which they could then give some good insight to these foundations from a production level CAS perspective so with that I'm going to hand it back over to Dan who's going to wrap things up for us okay thanks Megan so the key takeaways here the key summary basically containers aren't new they've evolved since the early days of UNIX from CH route through all that standardization through all those features going into Linux kernel for the last 15 years and we see them going forward also collaboratively with different organizations through the OCI and through the CNCF so and containerization itself is used all over OpenStack through many different projects but probably the biggest impact is going to be on Kubernetes because I'm on OpenStack Magnum because that's the one that's directly tied to the cloud orchestration engines like Kubernetes, like Mezos and Docker Swarm and because those expose APIs directly to the end users giving the full power of the CLI and the client libraries any sort of changes that go to the format container formats or the runtimes you'll need to be aware of and finally our view really is we're excited about OpenStandards, OpenTechnology that's what we do at IBM so it's great to see that just as OpenStack has standardized infrastructure as a service as a cloud computing model providing APIs around the compute, the network and storage as you're looking at a container solution for your organization for the longer term there's of course so much rapid change in this area but looking at these standards looking for the interoperability that's provided through OpenStack and through the OCI and the cloud native computing foundation it's really something that you should be doing if you're trying to develop that containerization strategy and as we said these are very active user groups right now very active foundations with a lot of customers helping to find these standards driving in the innovation and of course we want to see people drive their requirements in their use cases basically make sure that those standards and foundations represent the end users of both OpenStack and containers in general as I mentioned there's a couple other sessions if you're really interested in Magnum a Magnum deep dive Adrian Otto the PTL of the Magnum project he's going to be doing a session tomorrow right after this one in this room is the connection from Neutron to Lib Network and there's a few other interesting talks out in the container track most of them I think are happening in this room over the next couple of days there's ones there and some other orchestration techniques scaling techniques and of course there's quite a few great resources out there in fact one of the best ones to look at right now for the state of the art in OpenStack is a white paper called Exploring Opportunities containers and OpenStack that white paper search for that you can find it there and finally before we take some questions we're going to post these slides right away after the talk so if you follow any of us on twitter or the OpenStack hashtag you can find those dig in there and find us at the conference we'll be here for the next couple of days questions okay the question was OpenStack Magnum Design Summit schedule I believe those would be happening on Friday I don't know for sure but if you look at the schedule instead of the general OpenStack Summit schedule look for the design summit sessions alright great thank you


Is that anything else here is, Dr. Shea? Thank you very much. Good afternoon, everybody. Welcome to New York. Welcome to John Jay College. My research area primarily is focused on police policy and practice issues, largely from the strategy level. And prior to becoming an academic, I had a full police career in Newark, New Jersey. And I retired as a police captain. And I was literally at a fork in the road. It was either become a deputy chief, get promoted, stay, and have more of the same. Or it was finish my PhD and go on to a new career. And I decided that I wanted to try something different. And that's what I did. And I took what I learned from the police department between 1985 and 2005. And I'm now trying to bring that to the academic side of things, looking at police problems and issues with data. And I am a quantitative researcher. I don't do a lot of qualitative stuff, which is why I like the data realm. And I'm going to introduce a couple things to you today, some of which dovetail on what you heard earlier by our folks from the BJS and the FBI. And I hope to add to that a little bit. I'm going to talk a little bit about how I see police use of force translating into policy issues that can create a constructive dialogue with the community and bring some sort of crime theory to bear on that. And you'll see how that works in just a moment. First, I think if we open up by talking about that use of force data and information improves knowledge and awareness, it leads me to this opening statement. This is attributed to a businessman in the United States. And it goes that if measurement is the first step that leads to control and eventually to improvement, if you can't measure something, you cannot understand it. If you can't understand it, you can't control it. And if you can't control it, you cannot improve it. One of the only ways to do that is to get yourselves into the data, no matter what it happens to be. Data reveals a lot of different things to us. It tells us about strong points. It tells us about weak points. It talks about budget issues. It tells us about human interaction issues. But the reality is it brings to bear knowledge and awareness that we do not have at this point in time. It facilitates control. We're talking about controlling police use of force through training, supervision, and policy development. All of these really big high level issues that inform strategy, they inform practices, they enable us to look at something and say, we need to refine this, we need to do away with this, we need to come up with a different approach. If we are able to control police use of force, we can understand the incidents and we can understand the prevalence of it just as the CDC does with disease spread and things like that. Right now, we don't have a good handle on that. We have at best some sporadic research from single cities or maybe a couple of cities, some of which is sponsored by the federal government, some is through the research initiatives of single researchers. We really don't have a good handle on the national picture of what this looks like. We are often enamored by the anecdotal evidence and the case studies that seem to have these generalizable qualities. Well, if it happened here, it must be happening everywhere and that seems to be a large theme that is running through police use of force today. I don't happen to believe that that's true. So I ask, what's the problem? It's led, this lack of data has led to a fundamental misunderstanding about police use of force. I think in a number of different ways. We don't have this good national understanding because none of the data is really being collected at its lowest level. We have some understanding of deadly use of force, but we don't have anything really good to compare that to. We don't know how often police officers around the country are employing different kinds of force like canines or mechanical force. We have some understanding through some research on taser deployment and what the implications are for that, but we don't know how widely those things are being done. I understand the limitations though of trying to capture all of this, but we're talking about capturing every time a police officer puts their hands on someone, that is a massive undertaking compared to what we're trying to do with deadly force alone. So then we start to scale that back and say, well, all right, if we're not gonna do every time a police officer puts their hands on someone, how about when they deploy the taser, when they deploy the dog, when they deploy the baton, or is it the level of injury that somebody sustains? And right now we don't have good measures on non-fatal injuries versus fatal injuries either. So when we talk about wrapping our arms around this monster, we haven't even conceptualized what we are talking about when we say police use of force. Is it deadly force? Is it mechanical force? Is it all force? What do we wanna do? Because we don't have that data, what tends to happen is that emotional arguments backfill the logic. We do get a lot of anecdotal case stories, dare I say some of the things that have been recent in the press like Ferguson, Eric Garner, Akai Gurley, some of the more prominent ones are not necessarily representative of the entire picture about what's going on in use of force around the country. They are celebrated cases. They all have to be looked upon for their accountability features and some of the important aspects of use of force. But whether or not they represent police use of force throughout the country is a completely different story. And I don't think that these handful of incidents are going to bring us to a conclusion that the police use of force is either out of control or it's a crisis or it's an epidemic or the other words that have been attached to it recently. Much to my dismay by the way, this is a fault of the police themselves. They have yet to capture the data. They have yet to advocate for capturing the data to get a good handle on these things. If that's the case, we don't have the data. We don't have a good outlook on things. We can't compare deadly force to non-deadly force or accidents to intentional shootings. We have none of this data. How do we propose to solve this issue? Well, we need a more flexible, in-depth, robust data system. We need something like Nibers. The national incident-based reporting system is just what it sounds like. National, incident-based reporting system. National means it's national in scope. It covers the entire country. I would like to see that for the police departments in the country that it be mandatory, not necessarily voluntary. Voluntary means limited participation and limited participation means limited coverage. Changing the 10th Amendment to have that happen is gonna be a really big undertaking. The question is whether or not the 10th Amendment should be sacrosanct in such an area that is politically and socially important to us. If it's this important that it occasions these kinds of conferences, that it occasions the presidential task force to look at, then 10th Amendment to have police departments capture the data doesn't seem like that big an issue to me. It's incident-based. One of the things that we have talked about in policing for a long time, and from the academic side as well, is that incident-based data captures the fine details and the contextual differences of an incident. Something that aggregate data does not. Aggregate data will mask the features of an incident that we need to tap. You've heard of something called death by 1,000 qualifications, if you will. Someone said earlier that the Washington Post data set, which is sort of trying to fill this gap on incident-based data, said that black and male and unarmed were more likely to be shot than white, male, and unarmed. If that is true, and I haven't looked at the data myself, but if that is true, that is incident-level data that we need to talk about. We need to figure out why that is happening. But there are severe limitations in the Washington Post data set that haven't talked about. Things like offender variables are very, very, very, very limited. There's almost no information on officer-level variables, and there is no information on environmental-level variables that I will talk about in a little while. Aggregate data masks all of those things. Incident-level data breaks them apart and enables us to test theories, test different hypotheses, examine relationships between things like officer and offender, offender and circumstance, when controlling for other levels of officer involvement or organizational composition, all these things that we don't have right now that contextualize a given shooting. This model that I'm proposing should, at some point, become available to the public. It should not be captured exclusively by the government, left of the government, and then no one ever does anything with it. I think that local police departments should have access to this data, to begin a constructive dialogue, so that local policies can be informed by regional and national trends that are going on. No one police department in the country is going to capture enough data on use of force because it is such a low-frequency event that it's going to explain what's going on in a particular area. You may have to have several police departments from several counties or regions to explain how these trends are playing out on larger levels. Nibers is superior to FBI UCR data. We know how well it's been done in the past. It is used to look at patterns and relationships on these kinds of crimes. These are the very sorts of things that we can use, incident-level data for, to unmask relationships on when we're talking about police use of force. As things I've just mentioned, contextual variables in the environment, the officer, the setting, the circumstances, essentially understanding the who, what, where, when, how, and why of a use of force transaction, most of which we know nothing about today. So if we had a system like this, what do we want it to do for us? How do we sell this to people? Why is it important to everybody? Well, staving off a DOJ consent decree is probably one of the big things. Reducing and or eliminating lawsuits is another one. But as I thought to myself, when I was putting this together, I said, well, those things are external to the police department. And sometimes police department in their insular, provincial ways may save themselves, but we're not really interested in what's going on outside. And if we get sued, we're insured, and if the DOJ wants to come in, they have, that's fine, we'll fight them and we'll, you know, we'll do whatever it takes to appease them. But, and then I said, well, if they didn't care about what was happening outside, wouldn't they at least care what's happening on the inside with their officers? Wouldn't they at least want to keep their officers safe? And there's a lot of discussion about training and policy, but it's not wrapped around anything empirical. So we don't know what police departments feel about keeping their officers safe and using data. I happen to think that it's not, it's not on their radar from that perspective. And just like body cameras and dashboard cameras were first sold as this is all external and very quickly as they became to be adopted in police departments, police departments realized that there was a lot of internal value and that they brought capacity and value and support to the organization. And they are getting more and more acceptance as the adoption goes on. In the Newark Police Department, I recall when I was doing one of the early evaluations of dashboard cameras, I had gotten a complaint from someone who said, I was a woman who said that a police officer propositioned her in so many words. And when the investigation began and we began to look at the video, nothing could have been further from the truth. And it was one early example of how the data could be used internally to support the police in the things that they do. Because I also happen to believe that police officers are doing the right thing in most of the circumstances. And that this data that I'm talking about can only help them through policy training and these other internal mechanisms. A steady flow of information is the root to performance. If the police department doesn't have a steady flow of data coming in from all different metrics, if you don't have a business plan that you're following, if you don't know what it is you're trying to capture, what goals you're trying to achieve and you're not measuring your performance, you're not gonna get anywhere. That plays on the theory of rational technical organizations compared to what are known as institutional organizations. So rational technical theory would suggest that police departments would put in place a performance framework and then collect data to achieve their goals. Whereas an institutional framework suggests, well, we don't really need that per se and even if we did have that, we're more driven by political influences and cultural goals and the informalities of the organization regardless of the technical goals. And there is a lot of that present in police departments. They are politically driven machines. However, this notion of institutionality should not take over the rational goals. And that's a lot of where my research is focused, making police departments more rational, collecting data, creating performance management frameworks surrounded by a business plan that a police department can return to to say, this is what we said we were gonna do in January, 365 days later, these are the things that we've actually achieved. That's a rational performance framework. Use of force is an aspect of that kind of performance. And I don't think anybody could say that deadly force or use of force is not a performance measure. One of the most important components of collecting data and using that data proactively is to discuss things with the community, acknowledge shortcomings on use of force, acknowledge the baseline level of use of force in a given city. Right now, most police departments can't do that. They can't undertake a conversation about use of force. They're afraid to talk about it. This ethos of solidarity and secrecy surrounded by bravery is kept quiet. It's not talked about very frequently. And so what happens is the community invariably fills in the gaps with anecdotal evidence or rumors or variables that are easy to fulfill, things like my own personal experience with the police leads me to believe that that's true. Or vicarious experience. My husband, my wife, my cousin was treated poorly. Therefore everybody must have been treated poorly. And the police themselves can never pull out the data and say, this is where we were in January. This is where we are in June. This is where we are in December. To defend themselves and have an open rational discussion. I think those things are some serious shortcomings that the police just haven't entered into by getting the data. Even at the most local level, if you come to the biggest police departments in the country, most of them don't have really robust incident-based data on offenders, victims, excuse me, offenders, police officers and environmental variables. To tie this all together, we have to have a factual understanding of the depth of use of force before we can apply terms like crisis and epidemic and widespread and discrimination and disparate treatment. Right now, a few celebrated cases around the country have given rise to almost a moral panic of sorts where police departments around the country are hunkering down in this bunker mentality, circling the wagons afraid to talk about use of force. They are being defined by these incidents around the country. They are being defined by things like the police do these things. The police is everyone. If you don't have the data to suggest that it's not everyone, then it is everyone. You are defined by those circumstances. Collect the data. Let's find out what the baseline measures are. Let's have something to compare against. They, I think there's been a lot of media circus around these things that have allowed people to hijack the discussion on police use of force. The last police public contact survey, I think it was done in 2008, suggests 40 million contacts with the police. 40 million contacts with the police, the Washington Post has captured in about a year and three months or a year and four months, 1,254 fatal encounters. That translates to roughly, if my math is correct and I'm thinking off the top of my head, something like 1,000th of a percent of the encounters end in some sort of fatal encounter. I don't think that that is cause for alarm. That maybe it could be lower. We'd have to find out. The reason we don't know how that baseline plays itself out is because we don't know how many people are actually at risk for being subjected to police use of force. Another difficult measure to wrap your arms around. The reality is that we need more data, we need better data, and the Washington Post is set out to do that. It's incomplete, it's not a great data set, but some of the preliminary research that I have done on it sort of dispels a lot of myths around age, sex and race and the relationship to whether or not people are more or less likely to be shot and killed by the police. Thank you very much. I'll leave this for you. There's a paper that accompanies my presentation that I suspect that NACO will make available to everybody. And let me turn it over to my colleague for her presentation.


Ladies and gentlemen, it gives me great pleasure to welcome you today to the 28 IAEA Fusion Energy Conference. The conference this year has attracted more than 3,000 participants from all over the world and is for the first time open to the public. The first Fusion Energy Conference was held in 1961 and since then it has helped the field of nuclear fusion becoming the main platform for discussing key physics and technology issues as well as innovative concepts directly relevant to the use of nuclear fusion as a future energy source. Let me of course start by congratulating the ITER organization lead by Monsieur Bernard Bigot on the progress with ITER construction. We are very impressed. One year ago, the fusion community celebrated a historical moment. It was the start of ITER assembly after more than 10 years of complex construction phases which involved the site preparation, the design and the manufacturing of the key systems and components. ITER is proceeding at a steady pace and is a critical step forward towards this goal of harnessing fusion energy I mentioned just now. Significant strides forward will be taken in the next 5 years and continuing on to 2035 when ITER will achieve its ultimate goal to demonstrate the feasibility of fusion energy. Another success was the construction and assembly of the JT-60SA Tokamak in Japan which was completed in March 2020. This project started in 2007 as a collaboration between Japan and Europe and presently is the largest built Tokamak in the world. It will soon begin addressing key physics and engineering issues for ITER and the demonstration fusion power plant known as DEMO. I would like to congratulate Eurofusion and the United Kingdom Atomic Energy Authority for the progress made in the new experimental campaigns with the European Tokamak Chet. Starting in a few months, the Chet Experimental Campaign with the Turium and Tritium will be a crucial source of experimental data which will provide a unique physics and technology basis for ITER's operation. Ladies and gentlemen, 5 decades ago, an international panel of leading scientists recommended the establishment of the International Fusion Research Council within the framework of the IAA with a primary purpose to promote international cooperation in controlled fusion research and its applications. Since its creation, back in 1971, the International Fusion Research Council has been acting as an advisory body on all these matters. The International Fusion Research Council, as well as the Standing Advisory Group on Nuclear Energy in the IAEA, provide advice for the range of key activities that the IAEA conducts to strengthen international cooperation and fusion research and to contribute to enhancing the present state of the art. These activities include the development of science and technologies around ITER, facilitating the coordination of the global effort for the development of future fusion power plants and in recent years working on the production of guidelines and reference documents being used by the fusion community. Addressing matters on technology and infrastructure development and deployment including the qualification of structures, systems and components their supply chains, regulatory framework, licensing, nuclear safety, nuclear waste management, material controls, as well as human resources development and management, nuclear liability issues and economic aspects associated with the future deployment of nuclear fusion facilities cut across all of these areas, all IAEA's technical departments. So we are all invested in this. Requirements, standards and good practices relevant to the establishment of the necessary infrastructure for future nuclear fusion are developed and there are strong interdepartmental collaboration and coordination here at the agency. We all know that the concepts and designs of innovative technologies including fusion reactors are technologically diverse. Therefore, the IAEA is working on the establishment of a technology neutral framework for safety to help harmonize these different international approaches on the basis of the existing IAEA safety standards. Although fusion reactors are inherently safe, the ultimate goal when it comes to regulation remains the same. Ensuring the protection of people and the environment by minimizing the risk of radioactive releases under normal operation and accident conditions. Ladies and gentlemen, after decades of intensive research, scientists and engineers have contributed and witnessed significant steps towards making fusion energy a reality. Nowadays, while publicly funded experiments continue to progress, research, infusion science and technology is also being conducted in the private sector. The increased publicly and privately funded research and development including emerging examples of public-private partnerships demonstrate this growing trust in fusion as a promising option to provide a sustainable worldwide supply of energy for centuries to come. International collaboration is vital in developing and deploying technologies and the IAEA will continue to facilitate and work together with our member states in emerging fusion industry and the increasing number of private partners, as I'm saying, for the steps to come. With several countries and the private sector currently engaged in their individual preliminary designs of fusion energy pilot plants, the IAEA stands ready, is ready to offer a feasibility study that encompasses the full scope of fusion pilot plant criteria and produce a set of technology-neutral requirements for the safe, secure and economically sound deployment of future fusion reactors. I therefore today invite member states, sponsoring fusion programs, the emerging fusion industry and the increasing number of private partners to support and jointly participate in this international endeavor coordinated by the IAEA, leading to the best future options for fusion energy. We are going to be actively consulting with all stakeholders in the near future. Ladies and gentlemen, over the last 10 years we have seen fusion advancing quicker than ever before, opening new job opportunities and inspiring career horizons. Fusion could offer an exciting career path for young professionals and give them the chance to be a part of achieving significant milestones and breakthroughs in this field. Ensuring a talent pipeline is critically important. The IAEA is committed to achieving gender equality in nuclear sciences and applications through ongoing efforts to increase the representation of women also in this field. A virtual side event on women in fusion will feature female fusion experts on Wednesday. The IAEA fusion portal and the fusion device information system developed and maintained by the IAEA are valuable tools for you to have information on the world's fusion devices at your fingertips. The upgraded system which has been launched today includes now 119 experimental fusion facilities and devices operating under construction or being planned in no less than 27 member states as well as technical data of these facilities and country statistics. Let me assure you that the IAEA will continue fostering international collaboration and coordination to help close the existing gaps in physics, technology and regulation and move forward in developing the peaceful use of fusion energy working together with all sectors of the fusion community. As you probably know, I strongly believe that climate change mitigation remains a key potential driver for the use of nuclear power. Now that the stage has been set and we all know the common challenge is to decarbonize and to do it fast. We need all viable technologies and fusion power holds the promise of providing us with infinite clean and safe energy. So let's continue to work together towards this grand engineering challenge of the 21st century, achieving energy production from nuclear fusion. This is possible. Thank you for your attention.


Hi babies, Mama Dukes here with alldayshares.com. In honor of Entrepreneurs Day, I'm going to give you my origin story. When I first started out, I was trying to look for a side hustle away to make extra money, but I didn't have money to buy big, huge machines. There was no such thing as a Cricut machine yet. I invested in some stencil. These are the actual stencil that I used from back in the day. I'm going to show you a way that you can make a shirt, sweatshirt, hoodie, whatever using stencil and spray paint. The items that you're going to need for this tutorial are very simple. We're using a G180 today, Gilden spray paint, and our 25 year old stencil. Let's do it. The paint that we're using today is Rustoleum spray paint. I got this at Walmart. You can use any type of spray paint you like, whatever color, the stencil. They are also from Walmart.  Now we are ready to heat press our design to complete this look. I'm going to go with a two-tone. Do not mock my hands, my fingers. It's a hot mess I've been spray painting.  You're not allowed to laugh. I want to crop this. Fold it in half and just take my scissors and go straight across. Let's try it on. It looks good. Please be sure to wear some gloves. You don't want to end up looking like this, honey. Wear your gloves. With spray painting, the options are endless. You can spray paint in reverse. You can do it freehand. You can use stencil. You can use cardboard, whatever. The world is your oyster. You can do it however you want. Do not worry if it feels a little hard. That's fine. As you wash it, it'll get softer and softer every single time. Do not despise humble beginnings. We all have to start somewhere. If I can do it, you can too. Be sure to like, share, subscribe, and ring the notification bell so you can be kept up to date with everything that we do here at alldayshares.com. I will see you guys next video. Bye. Use gloves.


Good morning. Good morning. So yeah, I'm excited to talk to you about the next generation of contribution It's a little tongue-in-cheek title Hopefully to get your attention and wake you up this morning on a on a bright Sunday after some lovely lambic beers all weekend For those of you who would prefer to follow along if it's easier for you to read on a local tablet or device I've uploaded these slides on speaker deck slash MB bro bird I also tweeted it out, so I'll give you a second to find that if you need to But yeah, while I give that introduction. Hi, I'm Matt I'm a full-time technical editor for open source comm were really small team that produce a lot of content I'd love for all of you to consider being authors if you are at this event You you absolutely have an open source story to share. I can tell you more about that I also want to give a plug to Brandeis University in collaboration with the open source Institute is running a really interesting Master's course on the business of open source I'm taking it right now and learning a ton about all the things I don't know about open source that a lot of this community. I believe does So just a level set with you how I'm walking into this I'm assuming you are a seasoned open source participant while I am of the github generation of open source So you more of what that means you could possibly maybe not recite the SFF for freedoms off the top of your head anyone willing to do that right now, okay never mind While I recently learned that OSI and FSF are different. I kind of definitely conflated them more than I'd like to admit You think you've had a contribute before get I think that get is basically Latin in in technology It's the only thing it's a lingua franca. So anything before that didn't exist. We're all just oral tradition You're probably active on IRC. I'm active everywhere, but IRC And lastly you care about your community as do I I think if we can all create communities Where we care about each other and people feel welcome will be on the same page But I just figured I'd level set with you also and you knew where I was coming from Because I'm gonna just jump right in and say I don't get IRC when I was Every time I try to log into it. I end up getting into a bit of a tit for tat with name serve I'm not quite sure who I'm talking to I'm not logged into the right place I feel a little like a wizard which is kind of cool because I'm a little behind on my sys admin skills these days But ultimately I end up seeing a stream of offensive spam and I'm confused as to what channel I'm in and what's going on and That has led in the communities that participated in where IRC is a default channel I'm always told that you know go check the manual the friendly manual that will explain in great detail How to use the the tooling more appropriately? But I'm always left this with with the sense that I don't get it and I feel kind of ashamed about it I mean, I've got a degree in computer science been in the tech industry for ten years after four years of IT work beforehand, and I don't say that to To brag it's actually out of embarrassment that like oh how can this technology continue to elude me on a day-to-day basis When I have this foundation behind me But I think it comes from where what my point of origin was that like for me open source started the day I made a github user and a user account and logged in to do something and I wanted to participate for the first time I was very excited pretty nervous about it And I was using homebrew on Mac for those that know the package manager and I opened my very first issue only eight years ago with a Bunch of junk about why the package wasn't working for me and me being confused about it and to my absolute surprise and delight immediately I hear from these people who are Really big names in that community in my sense, and they actually told me I didn't install get correctly on Mac It was a totally trivial issue No one made me feel stupid at all though They immediately pointed me towards helpful documentation and I felt like I had done something like somebody else has definitely felt That silly going into the homebrew community and when they look through issues They will find that path ideally get to the same positive conclusion and see the welcoming people along the way And I love that experience and it really set me up for the success towards as I Slowly iterated towards an open-source community and an open-source career focus Because my pathways all through proprietary. I started with a proprietary hardware vendor I found communities that are surrounding proprietary technology that live on a proprietary platform of Twitter and I eventually joined a proprietary code sharing site and found that to be really open-source and fun to me and I got into open-core startups. That is a different conversation We can talk about what whether that works or doesn't and the many ways in which it doesn't and so on and so forth now I'm very much centered around open-source communities as a focus of my career I've got the joy of working at open source comm to get those stories out further and coach people through that experience and I continue to learn about why we obsess about licenses by coming to Fossum and by taking courses like am But my pathway is not the same as I know many others have gone through That started with IRC just being a logical simple thing But for me, it's still it's still this even though I understand where it comes from and I understand that had its place in time I feel as if it's not as inviting as that incredible github issue that didn't shame me or make me feel stupid Ultimately, whether that's a sign of my posture syndrome or or not is between me and my therapist but as somebody who's as I like to say on the easy setting of contribution in in this world a Concept taken from straight white male the lowest difficulty setting there is By John here. I understand I have already a bunch of easy ways in which I can be involved and not feel too Ashamed of things when they don't go well that said if I can feel that awkward I can definitely imagine other people who have a more difficult path towards open source who don't want to be is out there will have more of a challenge and Also, I want to talk about this is because I'm doing as they continue to read a lot more about the inclusivity and diversity challenges in the technology space and Try to inform myself while I don't feel ever informed enough to give a full lecture on it I do know I need to start making changes in my own behavior in order to improve this for those that are Going to be coming forward now that are in their their teens and their 20s in their 30s Or are people that are pivoting from other parts and other industries and want to participate? I do a lot of mentoring on the side for people who are confused as to how they can get involved in technology I'm consistently asked the same question of where do I get involved? What do I do? How do I do this open source thing that all these companies are looking to hire for and I can't in good conscience say jump on IRC and see how to get involved. It's confusing it and it ultimately could make some people feel Like they they shouldn't be pivoting into technology that they shouldn't be there and quite honestly It's not where their community is the one that they're going to pursue that they're going to feel welcome in So I think about how we can start to change that and one of the talks that really influenced me recently is by creator of Jenkins he had an incredible talk at Monktoberfest about The that underrepresented people are underestimated, but he also brought up this amazing concept Thank you for Margaret for for tweeting it so I could quote it About the curb cutting principle that if you think about cutting the curb so that people in wheelchairs can go up it It actually helps a number of other people along the way It helps people with strollers or with heavy luggage bags or anyone with any form of walking disability People who have sight difficulties by creating an easier on-ramp for a specific target people You have a halo effect you end up positively impacting all these other people and I think about what? What we're doing as community leaders to do that for our early onboarding for people who? Maybe don't it can't just quite get up that Ledge right away. How do we make it easy from the beginning? We may have a greater impact than we even realize So to put it in some context I understand when IRC Came out and became the de facto standard. It's because there's a lot of empty space around it was IRC or nothing to communicate I guess telnetting and reading each other's things is something that I've read about as well, but I'll just put that aside I don't know it very well, but if we fast forward to today The the stats I've been able to find is that IRC is hovering around 400,000 active users in the last year or so and we look at some of the other Synchronous communication channels that people are talking about we've got Microsoft teams as much as people have to use that for work and don't necessarily Love it. There's 13 million people on that slack people love it open-source communities hate it 12 million users Riot that I am very impressive that they've grown to well over 11 million users Google chat It's like slowly waning in the background, but at 4 million And that's just synchronous communication channels And that's just recently we zoom out even further and think about like the ways in which we interact with communities in the technology space That's an interesting noise I'm going to keep talking while somebody figures that out. So if we think about where communities are talking across the industry You've got Twitter, which is my default place to Conversate with community members at 126 million users Telegram is way more massive than I ever realized at 200 million and a lot more open-source communities are talking there Discord is humongous reddit is a complete beast when we think about it Is that getting pretty distracting? True All right jazz hands for a moment and I'll just leave this for your curiosity Not that one That's the cables That's exciting Electricity is strange everybody. It's probably some sort of a noise from the audio channel of the HDMI. Yeah Yeah, I know I definitely At Fossum that does feel appropriate changes lie very gently. Oh, I'm watching you. Yeah. Yeah I Thank you, it's a video guy. That was amazing Cool, okay, so there is a lot more competition There's a lot more places people are conversing about open source than ever before and that that can be quite It's quite exciting, but it's also it starts to make that little dot of IRC in the middle look Maybe less to be centric even though it's center of the picture. It's definitely not the dominant place people are talking now Man, I'm gonna like say So just a quick side-by-side by no means Inclusive of everything that's important to setting up a healthy community a healthy place for people to converse We think about just the sign-up experience the mobile access the inboard on The in-app onboarding of users accessibility options. Just comparing IRC to yes The hated but often used slack it starts to look like okay I can understand why people aren't jumping on the platform that's existed for the longest There are other options that are definitely maturing But the default option is shifting and I'd like us all to shift with it In quite honestly one of the more important parts is why are we using synchronous communication? I am not always on and I doubt you want to be too. It's rarely the right place to start So I want to take a take a moment and talk about why I mean just to list five I think we can go through a hundred each one of us has at least one That it requires it always on participation. There's this expectation that it sets a default of immediacy There's no continuity of knowledge when you use synchronous communication If I answer a question today three days later. Yes, the same one you get the same question It's it's often not a place that is building the type of community that we're trying to foster or or maybe it is But it's it's not alone. There are other pieces to the puzzle So I'm gonna pivot to you talking about community channels and my theory of operation It's a model that's worked for me. All models are wrong. Some are more helpful than others. This one is mine Well, this one actually isn't to start. This is somebody else's So in the great good place, there's this wonderful concept of Your third place where like traditionally your first place being home We have a certain sense of identity and purpose and meaning your second place being your work Which is in our culture is is just as dominant if not the dominant place that you live in and there is this magical third place That we're all searching for it's a place where we feel comfortable and feel connected It's where you relax in public encounter familiar faces and make new acquaintances Take a moment it think of some community you participate in and doesn't it check all those boxes right away That sense of feeling comfortable and connected to other people.  It's a great theory of operation And I think we're all building third places as we build open source communities and places where our communities interact So to take that in mind, I kind of break it into this quadrant that works for me Where I think about the synchronous communication, which I don't think is the greatest default But it is fantastic for casual and high throughput conversations It's the place of banter where you start to build some sort of connection while asynchronous is really the Definitive record of what is the right answer and what is the wrong answer? We all end up making these static webpages for things like this There are a bunch of other tools that are useful There's also the power and importance of face-to-face connection Many of us flew drive took a train to be here to make face-to-face connections with each other Because no matter how much we work fully remotely no matter how much we connect with each other as much as I love that Over the internet experience. We still need this. There's something special about this this space Lastly, I think it's important to think intentionally about your news channel Like how are you feeding information and distributing that context to people that care about what you're doing? It's cathedral in the bizarre like that you need someplace where I'm being regularly updated with information so that I know I'm making an impact on what I'm doing So what are some default ones synchronous? We've talked about asynchronous, you know Google groups That's the logo for it that no one knows about There's github is actually pretty decent at asynchronous communication people kind of bend the way you use issues to be more about collaboration Discourse is absolutely fantastic. Whether you like the creator or not. It's a really powerful Conversation and threading platform. That's open source and you can deploy yourself or use their service Stack overflows another form of it and they have their ability to branch off and use your own face-to-face We all go to them. We're at a conference right now user groups and local meetups are important News for better or worse Twitter is where a lot of us hang out It's certainly what been my my choice and this where I know a lot of you from But then there are infinite number of newsletters and other places where we get our news So to see this in practice, I just want to give a couple examples So Mozilla recently did a huge renovation of how they communicate internally and externally with their community They landed on riot, which I think is really telling that it's a maturing technology it's it's a There's great research if you look up Mozilla's Synchronous communication conversation why they chose riot they also went to discourse for their asynchronous So if you join the Mozilla Community, they have a whole platform you can jump on they have incredible Moz Fest And then their Mozilla blog is really really detailed They are always pushing information out and I think it's so interesting They do a great job of having syndicated channels, so they push it out to Twitter They push it out to their newsletter subscribers It's like a really tight way of staying connected to this broad and diverse open-source community If we look at go the go programming language, for instance, they've defaulted to slack There are many many thousands of people talking about go on slack on a regular basis They use Google groups quite a bit as well as github github issues to communicate with each other for asynchronous There's a ton. There's go for con which is the unofficial official place to be It's where people go year-round and go meet-ups are all over the world and then they have the go blog But what's interesting about them they have more of an unofficial presence on Twitter and email and newsletters They have great podcasts and and newsletters to distribute it out go times one from changelog That's not an official part of the go language, but it is an unofficial place that the community circles Last but not least let's talk about kubernetes because everybody else is they are also on slack And it's really interesting default channel is more github It's a lot github centric while then the newsletter or excuse me the discussion Lists are a little bit of a back Back channel while the face-to-face is really interesting. They do so many videos online So they're using zoom and they're using YouTube to extend that face-to-face It doesn't quite substitute the in-person because that community is getting so big they've added this virtual element as well I think video chats can be really powerful in that way in these distributed communities In their news is just as deep just as distributed people filling in the gaps that they don't but the official channel is always their blog So if you're looking for some sane defaults if you're building a community and you you find this framework kind of useful I'd say if you're starting from scratch. I'd really recommend not going with synchronous from the start and trying to Build a place where you answer questions for people and you can create some dialogue amongst the frequent visitors Start to get that sense of belonging Building and then once people really start to know each other you and you need that side channel. You need that conversation You can do that through synchronous But wait until the time zones aren't a factor and that you have a sense of culture already Discourse is a great asynchronous communication channel. I'm really enjoying using it. It's highly customizable. It's really easy Relatively easy to run on your own or to they have a very reasonable cost structure if you want to pay for it If you're looking to do face-to-face from the start Look at Kubernetes way in which they do the community meetups They're really interesting ways to get people connected was on one recently with 40 people from around the world We're all talking about the bugs that they had squashed that week and ways in which they've made contributor experience a little easier I can't talk about many communities that have that level of scale and that number of people that during the day are jumping in and Talking to each other and not all of them were paid to do it There's a lot of volunteers a lot of people who are trying to grow their career And the news whether you love it or not the centralization of Twitter is really effective I look forward to understanding mastodon a little bit more to see if that is a Collaborative place, but I think it's going to be an and not an or and then newsletters are really powerful It's a great place to be if you're interested in running your own website having a blog that then syndicates to those is really effective So that all matters because contribution matters So just to pivot back into the conversation of what are we all trying to do? We're trying to build communications of practice Because the actual footage of people trying to recruit contributors is like a hungry hungry hippo's game No idea if that reference works internationally, but I love it anyway. It's a great game Just to look at one of the hundreds of sites that try to say good first contributors First contributors that github.io. These are just some of the amazing organizations who are desperate for new contribution To give a shout out exorcism is one of the best place to learn a programming language and it's run by brilliant people All of these others are great too, but everyone is very interested in getting new contributions So clearly there's a lot of demand which means we need to meet people where their expectations are and not ask them to meet Meet us where we already are Because if we think about the contributor Experience early on back in the IRC only days like almost everyone who is contributing or who is talking about what they're doing We're was also contributing to something because it was one in the same you had to have that level of skill But now it's kind of shifted that the contributors is a very small peak and the potential contributor field And if we think about it, there's like a little dot that's ready to roll off in either direction of the actual maintainers of the software Thank you So I I just want to reinforce that communication channel channels are exceptionally important And they said an expectation and we want that expectation to be something where people feel incredibly welcome and don't feel like they're being told to Try harder and maybe one day they'll be worthy of being an open-source contributor It's going to be multi-channel It's just that's the new standard that everybody is using multiple channels if you try to break it into this grid I think it gets a little bit more sane So you don't have a half a dozen synchronous communication channels and no place for the right and wrong answers like a discourse But lastly I just want to make a shout out to the idea that any place that is contributing to open source is an open source community So whether they're using slack or otherwise you may not like that choice But it is not necessarily the wrong choice We can try to grow people towards an all open source community and understand the nuances of it But it's taken me eight years to get there and I'm finally starting to get it and I'd like to grow that way But I don't want to shame or make anyone else feel unwelcome because they're not where I am today So I hope we can all meet people where they are today and help them grow into being open-source advocates and understand the nuance of it I really thank you for your time and I look forward to hearing more of your talks as well. Thanks That was super easy. Yeah So the distinction between async and synchronized What I have experienced is that most time when a community have an asynchronous community is that they Demand that people installed the app on the phone and use partial notification We then become synchronized Communication method anyway, and if you don't want to install the app you more let's get frozen out Okay, so I'm hearing that the question is like is Notifications in that sense that asynchronous converts into synchronous in most cases I completely understand what you're saying there I think there is a level that all technology these days is trying to steal our attention all the time And trying to get us to turn notifications on and be as real-time as possible. I think it's not a requirement I'm part of about a dozen different discourse services right now And I just kind of schedule out time well I turned off notifications and I log into the web apps and and go in there on my own time So I think it does take more Mental effort than it it should I don't think it's a necessity to think of it that way And if you think about the experience like let's say the same strategy where like I just logged in three days later And looked for updates if I do that in a synchronous communication channel I've got to scroll back infinitely and try to thread in my head the conversations that happened While in like a discourse or stack overflow experience. They're all spread out with Q&A's in their own separate categories So more advocating for that structure as opposed to the unstructured if your goal is to get to a simple like yes No definitive answer if your goal is to get people to banter with each other like choose a synchronous channel That is definitely the place to do it Leslie how am I doing on time? Oh cool. Well, he's got the mic go for it. You didn't mention mailing lists. I did not mention mailing lists I would highly recommend so I did mention Google lists, but I didn't give mailman the respect that deserves I'm on an infinite number. I'd prefer not to be quite honestly with all due respect Discourse has a great built-in feature where you can use it like a multi-threaded mailing list It will so I think it's a one-to-one replacement with a better user experience for those less familiar with it While also providing a mailman like experience mailing lists So I'd love for you a disagreement that is where we could learn a lot from it But yeah, that's that's my current stance on it Especially for the expectations that there are today of just a full-fledged Friendly experience. I'd say discourse is a better choice to start Hi, it's just in regards to dealing with actually setting up all these channels and form of communication as Community manager for example, how would you install perhaps unique code of conduct for each of these channels? Or would it be a blanket all channels how you interact with each other? So like for example, if it was the Synchronous you would have to perhaps say no spamming no doing x y and z great that kind of aspect Yeah, absolutely. So I'm hearing the the question is that like do you have a per channel code of conduct and per channel channel? Documentation or is it centralized firm believer you have to have one URL to rule them all That's kind of a different Conversation but like by default like your documentation should lead to one place and Give as brief and overview as possible and then link to other things So I think a default code of conduct for across the spectrum because that's you're all still participating in one Community across the channels is really important and then yes There may be some specific nuance like how to what's our reticent versus how we use discourse and those instructions can be in those different channels