As you can see, this is my dog, by the way, he says hello. I deploy on Fridays, maybe you should too. We'll get down to that. If you want to reach out to me at any point in time, that there is my Twitter handle. Feel free to post any criticism, any suggestions, any things you like or dislike. I will not respond during the talk, but after. OK, let's get going. As I was running through slightly foggy London this morning alongside the canal, which is beautiful, by the way, I was thinking, as I do often, people that know me know that I like to talk about this. I was talking or thinking about deploying. And I was not just thinking about deploying, I was thinking about deploying on a Friday. And funny thing, it's Friday today. So it got a little meta. I was thinking on a Friday about deploying on a Friday. When I say deploying on a Friday, what's your reaction? Can we do that? Yeah? OK, can the people that say no please raise their hand? Awesome. I hope that that would be the case. Of the people that raise their hands, who is forbidden to deploy on a Friday by company policy or team policy? OK. And the rest, are you doing it off your own volition or? Yes? OK. So you're not alone. Because whenever I talk about deploying on a Friday, typically the reaction is this, are you crazy? And once again, you're not alone. You just have to Google for deploying on a Friday, and you get this, the internet is a wash with memes about it. I don't know who you are, but I will find you. And yeah, there's only going to go one way, right? 5 PM deployment on a Friday. So this is an actual t-shirt you can buy, and there are mugs you can buy as well. I may just get one for kicks. Should I deploy on a Friday at 5 PM? No, what if I just need to know? So basically, stop. Don't. Don't deploy on a Friday. And OK, let's not then. Well, that would make my keynote very short. And that's not why I'm here, right? So I want to get down into why people say this. There are a couple of reasons. There are a couple of reasons that I've identified over the years. And one of them is it's simply tradition. We've never deployed on a Friday at this company, so please don't start now. And if you then ask why, well, because the previous person didn't do it. And they told me not to when I got into the company. And so I don't do it either. It's tradition. It's written in the company culture. It may be unwritten, but it's tradition nonetheless. Risk is a thing that is always associated negatively, or not always, but it's regularly negatively associated with deployments, with releases. Why? Because they fail. And then the irrevocable but and also understandable reaction is to reduce your deployment frequency. Things go bad. Things fail. So what we do as humans is do less of it, because it hurts. And ironically, the less you do it, the more risky it becomes. And we'll get back to that in a little bit. So risk. And it's interesting that you see this happen at large companies, for example. Financials are notorious that they deploy once or twice a year because they associated all this risk with that release. And the only thing is it keeps confirming their bias, because every half-yearly release basically goes wrong. Control, if I ask you, as a developer, as a tester, as a team member, as an ops person maybe, are you allowed to decide when you deploy to production? Who says no? OK, I see a fair number of hands. There are companies that actually do not allow technical team members to make that call. They want certain features to go live, only when some other people, in some cases, even the CEO, says it's OK to do that. And that's a control mechanism. It's basically somebody without any of the technical knowledge or background saying you cannot do that on Friday at 5 PM because I have this idea associated with that thing that it's dangerous. So please don't do that. I've seen somewhere in the newspaper that it breaks on Friday, so don't control. Confidence and trust, the legacy application that you really don't know what is happening or what will happen when you touch it here and then all of a sudden over there something falls apart. We don't have confidence in the changes that we make to our system that when we deploy them to production that they generally will work. Maybe we don't trust ourselves with our code. I'm changing something here and I don't really know what I'm doing because the system is not architected and designed in such a way that it helps me to understand me what I'm doing. So I really don't trust what I'm doing, so I tried to limit my exposure to, well, at least not on a Friday. Time to repair and recover. A lot of companies optimize for the time between failures. They want to have that as large as possible, which is insane because things fail. But the reason they do that is because their systems are so difficult and so complicated that when they break, it takes a long time to fix it, to restore that system. So if your time to repair is 24 hours or more, then, yes, I can understand why you would not want to deploy a change on Friday because it will possibly, if it breaks, push you into the weekend. It will actually force you to deal with that system going into the weekend. And worse, if it's more than 24 hours, it will actually blank your entire weekend. So the time it requires you to repair a system or recover a system definitely plays into the don't deploy on Friday. And that also goes directly into on call stress. The person that goes into on call Friday afternoon, well, if it's not you doing the deployment, I'm doing the deployment and somebody else is on call. And if I know that my system tends to break after deployment, then I'm, well, maybe if I don't like that person that is on call, then I may actually want to do it, screw their weekend. But let's assume we're all reasonable individuals and we're all team players. So we don't because we know we've seen it before, right? We've hit our nose. We've bloodied our nose on that wall. And so let's not do that because the person that is on call is going to, they're going to be hurt by this. Their weekend is going to go into the toilet. So that's not something we want to do either. So all these things combined, it's pretty reasonable to say, don't deploy on the Friday, right? And funny thing is, I used to say the exact same thing, not that long ago, at least not when you compared to cosmic timescale. So six, seven years ago, I used to say something like that as well. Probably without context, maybe because it was tradition, maybe because I heard people in the industry saying it as well, maybe because I saw the shirt online. I don't know, I can't remember, but I used to say it. And I just as much as everybody else, like my weekends, I like my evenings, try as I might. But what about bugs that you find in your system? A critical issue that you find on a Thursday night or a Friday morning? I've seen companies that actually have two streams of flowing software to production. The one is the stream that they advertise, that is the feature stream. And the other is the, huh, it broke. Let's fix it. And they actually bypass everything that is in the feature stream just to get something to production really quick. There is an organization which I shall not name in the Netherlands that used to advertise that they did two releases a year. And they actually did four. So two that they advertised. And then a week after the release, they did the real release that fixed everything that the release broke. So what about bugs? What about 3 p.m.? Is that okay?  What about Thursday though? If your system takes 24 hours plus to fix after a broken deploy or after a change, if you do it on Thursday night, maybe or Thursday in the afternoon, then maybe the system is still broken on Saturday. So maybe we should not deploy on Thursday either. And we should say, okay, maybe let's just only deploy on Monday, Tuesday and Wednesday. Friday is 20% of the working week. And if you block pushing value to production, value to your user for 20% of the week and your competitor isn't, then you're going to lose that battle. Friday is 20% of the week and that is an important thing. So I'd say, let's improve. Maybe we must improve even. Let's do it more often. This is not what your doctor would recommend. Doctor, I broke my knee. Okay, do it again. It will hurt less the second time. I promise you. But in this context, it's definitely a thing that is the case. Because some people associate negativity with failure. And that's not really the case. Failure is not the opposite of success. Failure is encouragement to learn. It's an opportunity. Failure is an opportunity. And as Winston Churchill once said, and he was a wise man, success consists of going from failure to failure without losing your enthusiasm. So we basically, we keep tripping and yet we're still smiling and we're continuing happily along. And this is what improves us. If we take those failures, not as negative data points, but as opportunities to improve. And the thing is, if you do things in big steps, then they will fail big. So if we do one release a year, then what can go wrong will go wrong and it will go spectacularly wrong because there's a lot of changes in that release, right? So conversely, small steps, if they fail, they will fail small and fail they will, or some of them at least. But that's fine because they fail small. So we can recover quickly and it's cheaper. And the object of this whole thing is making things effortless. So instead of worrying about the next deployment, will it work? Will it screw up my weekend, my evening? Will I have to fix things again? No, we're going towards a situation where we actually don't think about that anymore. We just make our change, we test it and we have sufficient confidence, sufficient trust in our system and ourselves and our team that we can deploy that to production that it won't break, effortless. So all this is to reduce risk, not eliminate it, because that's not possible, but reduce it and reduce it to such a level that it is manageable. And I came across an interesting tweet the other day. On the left side of this picture is the risk and cost diagram with infrequent releases. So what you see is basically, this is inventory. If you don't release things to production and you keep building things, then you build up inventory, right? And once you release that, then you actually realize value towards the customer or that's what we hope. While you are building up inventory, you are also building up risk because you actually don't know whether the thing you're building is the thing that people need because you haven't tested that. It's still lying in your company, nobody's actually used it yet. So it's risk. Whereas on the right side of the picture, you see a deployment frequency that is far greater. And so what you see is that the amount of inventory and therefore risk that you build up is significantly smaller because we release in small batches and we can learn quickly from those small batches and if there is risk involved, if there is a failure, whether that's a technical failure or a business failure, we can easily compensate for it. This rolls right into the continuous everything mantra. Rather than thinking about start dates and end dates and projects, we're thinking about products, products that have a life cycle that we improve day by day by day and we improve them through a feedback loop that goes on and on and on. We plan, we code, we build, we test, we release, we deploy, we operate, we monitor and along goes the cycle and we never stop and we do this in very small steps. Continuous everything. That's the basis of realizing value quickly to our customers. And one thing, if you haven't read this book yet then I absolutely suggested to you to Continuous Delivery Bible, if you will, by Jazz Humple and Dave Farley. Continuous delivery is all about delivering value to users safely and quickly in a sustainable way and this is a key point. It's about a tempo that you can achieve and that you can sustain indefinitely. So it's not about crunch time, this needs to go into production right now. No, it's about a tempo that you can maintain indefinitely as a team. Continuous delivery basically looks at things in sort of a sequential way in deploying or delivering value to production through a number of stages. Stages that do testing or building or variants of those things and in an abstract simplified way, Continuous Delivery starts on the left side of the picture with a developer checking in code to GitHub, GitLab. Then a build and test system starts running, it compiles the code if you have a compiled language or it builds assets or whatever and then you run the tests. When all is okay, all the tests are green, we deploy automatically to a staging, a testing and acceptance environment. The name doesn't really matter and then at some point, after testing on acceptance, we decide as a team, this is okay, this is good enough to go to production and then it's deployed into production. The red arrow then or indicates that there is human involvement, there is a human decision that actually says, okay, now we are good to go, we can promote this change, this build to production. Continuous Delivery says, specifies that your code should always be in a releasable state. Regardless of the moment of time, you should always be able to deploy the thing that you are working on to production. And if that is true and we've done the thing with the manual intervention often enough and we learn about that, then we can go to this situation. Continuous Deployment, where we actually, after we deploy into acceptance, we don't have any manual checks, all our checks are automated and we verify on an acceptance environment whether the deployment there is okay, is successful and then we immediately and automatically progress into production. So there's no human involvement in this pipeline anymore. Everything flows from the left to the right of the picture in an automated fashion. All the checks that we do are automated checks. Why would we do this, you might ask? Well, research, for example, the research presented in Accelerate, another very interesting book that you definitely should read if you haven't yet. Their research says, for high-performing teams compared to low-performing teams, their deployment frequency is 46 times higher than the low-performing teams. Their mean time to recover, they recover about 100 times faster, so that's the difference between days and minutes. Their change failure rate is one-fifth as likely, which means that the low-performing teams will have this and they will have a fifth of that in terms of change failures. And what's especially interesting, the lead time for changes, which is basically how long does it take for a change to be developed by you, a developer, and actually be delivered into production and be used by a user. High-performing teams do that 440 times faster than low-performing teams, and they all do that by incorporating all, well, some of the suggestions that I'm about to give you. So, the effort then, or the idea then, is that if you can deploy on a Friday at 5 p.m., you can do it always. The idea is, the goal should be, if you ask me, to go for the most difficult period that you can imagine, which in this case would then be Friday, 5 p.m., and go for that. And if you can do that, then you can do it any day of the week. You can do an emergency fix on a Sunday, and it will be the exact same effortless thing as it is on a Tuesday morning, right? Just look at Netflix. They don't have windows that they can't deploy in because everybody's looking at videos all the time, worldwide, they don't have off hours. So, if they cannot deploy during the release of their most incredible series, their most popular series a few years ago was House of Cards, now I'm not sure, but if they cannot do it, then when can they? So, that must be our main effort, I think. So, people say, okay, but our code is old. We cannot do all the things that you're saying. It's impossible. Please go away. Our code is not on the test, so we cannot have any confidence in our system. We can never say whether the thing we are changing is actually going to work, and we have an impossible-to-change system, and I don't like my job. And please go away. So, dealing with legacy. Now, legacy is quoted because legacy is also associated with negativity, and that is understandable, and in some cases even justified, but please do remember that legacy systems earn money. I've consulted on many legacy systems that actually were reaping in money, and yet people are like, this doesn't... So, yes, there are problems with legacy, and I'll give you a few patterns to deal with that. The first one is the strangler pattern, much like this type of vine, which is a strangler vine, and forgive me that I don't know the exact Latin name of the thing, but you can look it up on Google. It grows on trees, and it basically grows on the outside of the tree until it has enveloped the entire tree, and the host tree can no longer survive and dies. Which is something we want to do potentially with a legacy system as well. Imagine we have a monolithic application that is very difficult, very much not under test, and it's connected to the Internet, and it's connected to a database, so far so good. What we do is we insert a proxy between the monolith and the Internet, and initially it doesn't do anything, it just forwards the traffic from the Internet to the application of vice versa, but then we start adding a service, and this is not a microservice or a microservice or a monoservice, it's a service, or it may be a module, if you have a system like that, and it may have its own database, may not, but it's going to implement a small piece of functionality, and when that is done, we add a rule in the proxy that actually forwards the traffic for that particular piece of functionality, not to the monolith, but to the service, right? And then we add more services and more services, and we carve out pieces of the monolith, and we make everything nice and loosely coupled, and the proxy gets more rules, and at some point, our monolithic application is either not doing anything anymore, or it's reduced to the size of all the other services, and it's become a service of its own. That's the ideal end state. The strangler pattern, which is uniquely, well, not uniquely, but very much applicable to web systems, for example, because you can insert a proxy into the web traffic and then forward that, but it's also, if you do messaging, for example, you have a message bus that gets messages based on the message contents or key in the message, you can distribute it to module X or the monolith, very applicable in both cases. Another pattern is branching by abstraction. Now, this doesn't have anything to do with branches in your Git and your Subversion, but rather a functional branch, a logical branch, and let's assume we have a module of some sort in our legacy system, and there's a bunch of client code connected to it, and they all rely on the old module and its specification, and it's not well tested, and we don't really know its specification, and there are bugs, but all the clients, all those clients are completely linked to it, so if we change the old module, then those clients start falling apart, and that's not something we want, and we don't want to do it in a big bang, we don't want to change all the clients and the module together because that's risky. So what we do instead is this, we add an abstraction layer next to the old module, and the abstraction layer is think of it as an interface that is well defined, or if you have an ugly building, think of it as a facade that you had in front of the building, right? All of a sudden you don't see the original building anymore, you only see this beautiful, shiny facade, and what we then do is start transporting those clients to the abstraction layer. The abstraction layer is going to call the old module, so it's going to abstract that away, and the clients are going to talk to the facade, one by one by one, until they are all talking to the abstraction layer, and now you have a stable interface which can be tested, can be specified, all the nice things associated with modern code, and the old module is hidden away. And what we can then do is, hey, add a new module with the same abstraction layer or which implements the abstraction layer, and then we can, preferably by configuration change, switch those clients to the new module without the clients knowing that they're actually talking to something different, right? And that new module is, of course, your TDD and everything, it's beautiful, it's well-designed, and all of a sudden you've carved out a piece of the code that was impossible to maintain, and it's now replaced by something that is well-maintained. And we do that, and then we can get rid of the old module. Great. This is a very powerful pattern that unfortunately is not used enough. And this allows us to do things in small steps, which is great, which we can test and deploy to our heart's content instead of going to a big bank change. So, on branches, while we're talking about branches, and now I'm talking about the Git branches or version control branches. Who here has ever had a merge conflict? Please don't lie. Okay, who's here had ever had a merge conflict that took more than a day to fix? Thank you for your honesty. This is something I caught at a client last year, and this was relatively benign. This occurred more than I wanted. This can happen, but what is really at play here? Continuous integration. That is a term coined by, amongst others, Martin Fowler, way back in the day. And continuous integration, there's one incredibly important line in the idea behind continuous integration. Integrate to master or to mainline or to baseline, at least daily, not from. There's an important distinction. The idea of continuous integration, as it's stated, is as a team member, it is important that you integrate your work with others so that it can be tested and verified and also that any potential merge conflicts are as rare and as small as possible, which requires you to integrate your work with others, at least daily, to mainline, not from. So pulling from or rebasing from master is not the same as integrating your work to. So what you essentially do, or essentially saw in the picture, is delaying integration, delaying integration of code to others, to other code. And okay, I know that there are people that say, let's use branches to decide when we want to merge a feature and when we want to put a feature live, like a timer, like a schedule. But there are better ways to do that because if we endeavor to couple the deployment from the release, then the deployment becomes a purely technical exercise. We deploy to production and that is a technical thing and the release, which is actually allowing customers to use a feature, that could become a business decision or rather a joint decision within the team and other stakeholders. How can you do that? Well, a thing called feature toggles or feature switches, feature flags, all different names for the same thing. And what they basically mean is we put sort of like an if statement around a piece of functionality and depending on a condition, the functionality is either dormant or active. And we can add a dashboard for that, for example. And basically you would have a feature that is based on a flag or a toggle, switched on or off and available or not available to groups of consumers. And this can go, this can get very complicated. You can activate feature flags based on region, based on preferences, based on other things. But what it boils down to is basically, this is one of my client projects a few years ago, an old version of a search page on the left and a new version on the right. What you see happening there is a complete re-architecting of the entire search functionality. So going from solar to elastic search, a new design and a whole bunch of other things, which is not, you know, this is not done in a day. So this took about a month and a half and if we didn't do that with a feature toggle, it would have meant building that on a feature branch for a month and a half with all the associated merge conflicts and issues with that. Or we would have blocked the deployment for a month and a half, both very suboptimal. So what we did instead was in a number of small commits behind a feature flag, develop the new site, develop the new page. And then once we thought it was okay enough to release to the company, we enabled the feature flag for people inside the company network. So based on IP address. Then we got some feedback and then we enabled to feature flag for 10% of life traffic. And we saw that the metrics were actually getting better. So we increased it to 50% and then to 100%. That's what feature toggles allow you to do. There is a real thing though, feature toggle debt, is that if you have too many feature toggles, long lift feature toggles in your system, they could lead to a combinatorial explosion of possible paths through your code. So if something reaches 100% and doesn't require you to have the feature toggle anymore, then please go ahead and remove the feature toggle. So let's get back to branching. And I've stolen the next few slides from somebody who's talking about this more often as well. Successful branching strategies, don't. And the second is please also don't. And third, don't branch. When I say it is, you're laughing a little bit, but I've also seen this happen, the pitchfork reaction. So what I mean with this is trunk-based development or master or mainline or whatever it's called in your version control system of choice. This is not new. For those that are old enough to remember extreme programming, which by now is 18 or 19 years old, I think, this was introduced as part of XP, trunk-based development. So what it basically means is you have a mainline of development, you have master or trunk, if you're still on subversion. And that is where everything goes. We don't use feature branches. We may, depending on the context, we may use a release branch, but we don't use feature branches. Two, get into the continuous integration mantra of integrating with each other at least daily. The question then becomes, okay, what about short-lived feature branches? My question then would be, what is short-lived? What is short-lived to you? Who thinks short-lived is three hours, four hours? Okay, a day?  Okay, you're violating continuous integration, sorry. And a friend of mine, this is not something I thought of myself, I wish I would, he called it discontinuous integration or continuous disintegration. So short-lived feature branches, if you don't wanna violate continuous integration means a feature branch can only be alive for less than a day and probably a lot less than a day because you also need to factor in time for the merge and et cetera, et cetera. So three, four hours maybe, I don't know, but if you are at three or four hours, why would you use a feature branch anyway? Because it's probably not that, it doesn't exist for that long even. So short-lived feature branches then. However, pull requests are in essence branches. Who here uses pull requests? Okay, that's almost the entire audience. Using it for code reviews, I assume, right? Code reviews are not un-useful. They are very useful. If you don't have a code review system in place and you go to pull requests to do code reviews, that is way better than not having code reviews. But there is an even better way of doing code reviews because code reviews in the pull request fashion introduce flow delay. And what I mean with that is it's asynchronous in its nature, right? I develop some code, I create a pull request and then another person, another developer has to look at that and they have to verify may change and they may see some issues with that. They need to get back to me. And all the while this is happening, I have a bunch of context which is going on. I'm working on a thing, I'm finishing the thing, submitting the pull request. I pull somebody else out of their context to look at my pull request. Then their intended changes come back to me. I need to go to another context. So there's a lot of delay involved. And the only time this really, really works is if you have a sort of SLA agreed on between your team, like if a pull request comes in, it needs to be looked at by somebody in 15 minutes. I don't know, something like that. Also it's been looked at that pull requests that are large and large depends on the language, but typically 50 to 100 lines sort of seems to switch over point. People start scanning and stop actually reading. So yeah, it looks good. Merge it. Do it. Whereas if it's 10 lines, people will actually start looking line by line and will actually find things. So there's a better way I think. And that is pair programming. Okay, maybe not like this, but pair programming is a very useful way of collaborating on code, well not just on code, but on software development. Because it allows you to do a continuous and inline code review. You're working together. You're talking about code. You're talking about your system. You're talking about everything and you're doing it continuously and inline. There's no asynchronous, there's no context switching because you're both in the same context. There's knowledge sharing, all those beautiful things. It does tire out people. Not everybody is comfortable with pair programming, but it can be taught. Maybe not for eight hours straight, but it is a very useful tool in the box. Mop programming is another thing that's starting to gain popularity where basically we have a whole team and one system, one computer. And somebody's doing the typing and the rest of the team is yelling at them. No. Now that's not what happens or that's not what you want happen, I would say. But the entire team collaborates on a feature, on a thing, on a fix. And sometimes they break away to a whiteboard and collaborate on that and there's all this energy and people rotate in and out because they have a meeting or they need to bring their kids to school or something. But the entire team is focused and involved and the quality is markedly better than doing things on your own for pair programming and mop programming. Now, let's take a little bit of a look at pipelines. This is what continuous delivery is all about. A pipeline to deliver value from the left to the right and the right meaning the user and the left meaning us. Pipelines should be automated as much as possible. If it's dirty, dull or dangerous, you need to automate it. Luckily, we're typically not in the dirty or dangerous business, but the dull business, well, I've been there, I don't know about you, but I've been. So I tend to automate whatever I can to allow time for things that actually matter, for things that really require human insight and decisions. Taking a look at a sample pipeline which starts from the left by checking out code, compiling the code, testing, making a package of it, you know, something of an artifact and then deploying that to acceptance, verifying it automatically, deploying it to production and again, automatically verifying it over there. An important part of a pipeline, any pipeline, is testing. And like everything in the continuous delivery, SWIR, we do it continuously. We continuously test our things. And we can do that, for example, in this way. If you look at the testing pyramid, we have a number of potential testing layers here. Depending on your product, you may not use all of them, but I sincerely hope you have unit tests. Unit tests are cheap and fast. That's why they're at the bottom of the pyramid. Integration tests, which actually link to get our components and test components, they are slower and more costly to maintain, so they're less of them. Then we have acceptance tests, your B-hat or PHP spec, for example, which, again, are slower and more costly to maintain. And at the top of the pyramid are end-to-end tests, selenium, click things, stuff like that, which are often brittle, expensive to run because you require a browser and the whole stack to be deployed. So we have only a few of them, not too much. Some companies have the pyramid turned upside down. So we have a whole bunch of end-to-end tests and maybe one or two unit tests. But the unit tests are the cheapest and the fastest to run. So it's important, if you can get away with it, to push as much of your testing down in the pyramid where it is cheaper to maintain and faster to run. But also, don't forget, exploratory testing and user feedback, essential parts of any system. Those can function as your early warning, your tripwire. There is, depending on the project or product you're working on, there may be a group of people that are very interested in the beta program, for example, you know, getting to see features that are half finished and getting some feedback on that.  And on the right is monitoring and alerting. No testing system is complete. You cannot test for everything, ever. So use your monitoring and alerting to alert you to conditions that are abnormal. So if your error rate starts to go up an hour after your deployment, then you should alert on that. And that is part of your testing pyramid as well. But if tests are good enough, then they are good enough because, again, we cannot test everything. Nothing is ever watertight. And no test issue detects, or no test suite, I should say, detects every issue. So this is why pipeline speed is key, essentially, right? We're looking at something that delivers our value into production fast enough and that we get feedback from it fast enough. So if we have a testing suite that takes three hours to run and we made a commit and after three hours it breaks, then the only human response to that is we're going to bypass the testing suite because it doesn't work. It's too slow. And I now have five commits lined up that may or may not have fixed the test that I just saw break. So, and maybe another test may fail. So keep it as fast as possible, preferably within minutes. My personal goal is to have a pipeline that deploys into production from the check-in to GitHub to the last deploy to production, not more than 15 minutes.  Let's take a little bit of a look at deployments before I send you all away. The deployment strategy I use a lot is the rolling update. I was looking at interesting pictures to associate with the rolling update. I think this is the Gloucester cheese roll or something like that, where people actually start running after a rolling block of cheese, which is thrown down a hill. And yes, there are injuries, I read. You brits are crazy. Anyway, the rolling update. So let's assume we have the internet and there's a load balancer between the internet and our system. And connected to the load balancer is our application or one of our services. And we have multiple instances of them because we wanna be highly available. Let's assume that we do. So we have three of those. Now what we do with the rolling update is we spin up version 1.1 of our service and it's not added into the load balancer yet, but we spin it up and we wait for it to check out and do some automated checks on it, et cetera. And once that is all okay, we add it into the load balancer by swapping it out with one of the existing services. So it's now in a position to actually take traffic and it starts working. Now none of the users connected to your load balancer are, if this all goes well, aware that this is happening. They only see the system which is still live, which is still processing requests and still available. And we start doing that for the next instance of the 1.0 service and then we do it for the third, at which point we've replaced all our instances of the existing service with the new version and we can throw the last one away. Nobody ever noticed this was happening. Maybe some feature got added, but everything worked as expected. So zero downtime deployments, which is a key thing if you do a number of deployments per day, for example, you cannot go down for every deployment that would be a waste. So taking all those things together, we come into the pipeline and then ideally, we write that down as code as well, just as much as the testing code and the production code that we have, we write that as code as well. And you have your Jenkins, you have your GitLab, which was presented earlier today. Both do roughly the same thing, even though there are nuances and people like the one more than the other maybe, but our pipeline is written as code, written as stages that do something and that if the stage passes, we proceed to the next stage. And if the stage fails, we get feedback. A simple pipeline, this is in Jenkins, this is off of a client project last year, could look like this, where we have a flow from left to right, actually delivering things into production. And this pipeline took 20 minutes and I think by now they've improved that to 10, 12 minutes from the check-in or the start of the pipeline to the deploy into production. Now if the pipeline breaks, if something fails, then you want immediate feedback. And there's a whole bunch of systems to do that feedback. I've tried the USB-powered rocket launcher once, which is cool, that shoots Nerf darts. We've also tried the LED siren once, which basically honks at you and starts flashing lights whenever the build breaks. Whatever works for your team, whether it's a slack update or a lava lamp that starts or a big monitor that shows you as long as you are aware or alerted as a team to deal with the situation, because the pipeline is what deploys your software to production, so if it fails, well, then you obviously need to deal with that and fix that. So this was a talk about deploying on a Friday, on a Friday, and by now I think you can do it too. Thank you so much.


Welcome folks, we have the Dow Industries trading up $1,077, Nasdaq up $6.56, S&Ps, check it out man, up 181 points, gold, gold contract up $43, trading $17.57, you got silver up $0.43, $21.76, platinum up $60, $1,056, light sweet crude, flat, $86.36 a barrel, notes and bonds, here you go, 10-year note, up 2 points plus 5 ticks at $1,1216, the 30-year up a full 4 points and a half at $1,2403 a king dollar, smoke them if you have them baby, down $2,333 ticks at $108,219, the euros at $101, the yen is at $141, the British pound is at $116 to $1 US dollar, now check this out folks, okay the bottom line, you know the CPI time and price, I mean volume and price came in in spades here, bottom line, S&P you got an ABC up, all of you, we're at 92 million shares right now, you're going to need 100 million I think it is, yeah 100 million, we're going to do 100 million, so you got an ABC structure up, you're up $18 right now in the spy, this projection goes right to the swing point, the actual number is 41107, that swing point is 41179, that's exactly where we're going to be going, we take a look at the Q's, the NDX100 now the Q's are up, I think we're up like 6.5%, let me look at this for a second, the NDX, I mean the, yeah the NASEx up 6.3%, so we're not at the swing point yet in the Q's, you get the volume coming in, the volume out here is 73 million, your swing here is 59, so you're going to have that volume out here, we go to the gold contract, you take a look at gold, bottom line, gold's moving, also with conviction mind you, okay the bottom line, in the gold market we've got that $277,000 contract, so that baby's on its way, up to this 1824, we talked about this yesterday, it already broke the hold down trend, I mean you're talking $19,900, now the dollar now, bottom line, we'll be talking about this 104 right, well guess what, now you broke the total trend, okay so now you're dealing with 101, and you broke it with conviction, when you break with conviction it's a whole different animal folks, and we broke with conviction, so you know we were talking about yesterday the day before the 104, well guess what, 101, 297's game, stay right there folks, you're coming right back.


Well, after submitting a letter of need, the Crowing County Board voted to support an All Men's Substance Abuse Treatment Center that will soon be opening in the county. The center is now hoping to gain the support of their neighbors. Our Logan Gaye has more. Through a letter of need, an All Men's Substance Abuse Center in Crowing County called You Are Not Alone has asked the Crowing County Board for their support as they apply for their license with the state of Minnesota. The letter of need is something that the state requests for licensure, although it's not mandatory. And we go and explain to the county why it's needed out here, what we have to offer, the shortages of facilities around. The facility is able to accommodate 14 men in-house and 16 outpatient men per counselor and will be used as a transitional home that will put men back on the right track after various missteps. Our mission is to bring them in and help them get jobs, help them find housing in the communities because that's so hard for them to find, and then help them reach out to their resources, counseling, medical, dental. And even though the staff of the treatment center may believe in their mission, some of their neighbors do not. They're concerned about what could happen if there's going to be people that maybe have had some drug addictions. But with all the criticism, they are still determined to open their doors and help their community. These kind of people are brothers, sisters, family members that have had a problem or made some bad choices, as Shanda has said, and that need the support systems move on. And Brainerd, Logan Gay, Lakeland News. The You Are Not Alone treatment facility is currently planning an open house in the next few months. If you've enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland Public Television.


So we're going to jump right into it and leave time for questions at the end. Mary Newfort, the director of the consortium, and we'll be going over the agenda. So today we're going to talk about the activities that we had from 2014 for those that missed the presentation at our conference just to give you some of the highlights of our activities. We have Susan Huggins, who is here today from Open College at Kaplan University, and she's going to talk about the Open portfolio that they've developed. We'll have a report out on the Open MOOC pilot that we've been doing this year, an update on the Open Education Information Center. We'll also talk about the Global Implementation Strategy for OER that's happening. I'll give you some highlights from the conference this year and where you can find more information in case you missed some of the presentations, and then leave time for your questions and comments. If at any time you have any questions or comments that you'd like to make, we invite you to please ask questions, jump in, type in the chat window, raise your hand, and we'll be happy to stop and talk a little bit about whatever questions you have. So to start off, we wanted to go over the highlights of some of our activities from 2014. One of the big activities we had at the beginning of last year was an exchange program with the U.S. State Department in cooperation with the Arab League and Alexa. And we had 15 professionals from across the Middle East and North Africa region come to the U.S. for three weeks to learn about OER and Open Education and to visit various universities in Boston, San Francisco area, Washington, D.C., and then have internships and placements at various universities for a full immersive experience. This program was really successful. We had generated incredible interest. Every single person who was in this program has gone home and done something in their home country, one of which is another project we've been deeply involved with. This is the National e-learning center in Saudi Arabia. And they have started a big project on open education, one component of which is to train their female faculty members on e-learning and open pedagogies. And so we've been involved in designing and delivering this program since February and it will continue through December. We also launched the Open Education Professional Directory last year. Hopefully you're all listed in it and have been able to use it for your various needs. The Open Education Professional Directory has almost 300 entries right now. And we will be continuing to refine and to work on this to make it useful for everyone this year. We also had a great program with the Organization of American States and Virtual Education and combining together to help support a portal where educators in Latin America can come together and find Spanish language resources to support their learning. And we've been taking up the open component of that. And Marcelo Morales has been working quite hard on it this year and is pretty excited about the launch of the portal that will take place very soon. We also had a really successful Open Education Week thanks to many of you who participated. We found that the level of engagement this year in Open Education Week was very high. That we were successfully able to reach over into communities that haven't participated in the past. That we had well over 100 different universities participating online. And then other universities participating through local events that some of which we didn't even know about until after the fact. But we found that this is now an event that people are planning calendars around and that has been fully incorporated into outreach efforts. So we want to thank you all for that. As one indicator, we found some really interesting Twitter activity which reached nearly 2 million people through the networks in just the four days of the first four days of Open Education. We also moved our search function over to Merlot so that we could combine efforts and make exposure to OER even greater. So Merlot is now working with us on the search which allows people to find materials more readily and to find more extensive materials. And then one of the other activities we wanted to highlight was a special collection we've been working on. We've taken Marshall McLuhan's digital materials and working with his daughter to make the transcript of his digital resources open and to make sure that they're available to everyone. So the Marshall McLuhan Speak Special Collection is just about ready to be launched. It will be launched in another week or so. And educators can take words right from him and incorporate it into their education. So we hope to be able to continue to work on different special collections this year. One of the slides that I realized did not get included in this but I did want to mention is the outcome of our elections this year. We have a new board member, Stavros, from FGV in Brazil who has joined the board. Marie Lille from UNISL also in Brazil. Unfortunately, his term was up and so he left the board. So we have a new board president, James Lapagross-Clive is the president of the board and Larry Cooperman is remaining on as the past president of the board. So we have the benefit of both of their support. Next I wanted to invite Susan to talk about the open portfolio at Open College at Kaplan. Susan, do you want to take the microphone? You need to click on the talk button in order for us to hear you. All righty. Now can you hear me? Yes, we can. Fabulous. Thank you. I really appreciate this opportunity. We are really excited to launch this open portfolio product. Can I-yes, thank you so much. And you can go ahead and go to the next slide as well. The open portfolio is a concept that we came up with, I guess maybe about 24 months ago. It is a product that we developed actually in-house that helps learners track and manage their open courses, which we think this is a great tool in the open world. You can access it at the link that's provided in the slide right here. Off to the left you'll see Maximize Your OEC Experience with Open Portfolio. You just simply click on the link and you are directed directly to the portfolio. What is very unique about the portfolio, not only is it free and open to anyone, but you can also, as a learner, create multiple learning plans. You can create it by topic. You can self-organize it. You can create professional topics, topics of interest, or maybe even topics that are discipline-related, such as topics in higher ed to help you prepare or strengthen your academic skills. We also have a series of what is called Suggested Learning Plans, and these are learning plans that are pre-populated. We have faculty that will go through here and make some recommendations about various courses that together will make up a particular learning plan, such as business management is one that's huge that has the most users in those particular topics. We also have health management, entrepreneurship, humanities, and information systems. If anyone would like to see a particular learning plan with particular courses, you're welcome to send them directly to me and I'll get them created for you if there's a certain grouping that you use the most. Right now, this is made up of the collaboration between us and Open Education Consortium. So right now, the courses contained in the Open Portfolio come from courses that are listed on OEC website. This slide, I just wanted to show you right quickly, is really the robust of the word search here in the Open Learning Portfolio. If you just simply enter a keyword in the keyword area, click search, it will search by title, keywords in the description, et cetera. We also have an advanced search where you can isolate it by institution, by language, or even by category. And again, if there's categories that we can help you with that you would see a little bit more defined, please reach out to me and we'll work and see if we can get it added for you. And the last slide, another aspect of the Open Portfolio that we thought was very useful to the learners is to see who else was in the particular courses. We have the ability on the little drop down inside of each course, you'll see a little drop down that says learners. And you can select the little drop down to see who else may be studying that particular course. You can message back and forth within the community, within the Open Portfolio, without having to go outside and fill out other mailboxes, so to speak. But you can see who else is in the courses. We have many other features in the Open Portfolio. Oh, I'm sorry, there's actually one more slide. Under the About Us tab in the Open Portfolio, we are soliciting feedback. And we would love your honest feedback and we would love users to get in here and share with us how they're using it, where they're using it, and if they find it beneficial. This is a product that we are testing with the Open Education Consortium. And we would love your feedback. So complete the survey. It's only about six questions. And give us your honest feedback. We'd love to make this a tool that we all can use and help us manage our open learning. If you have any questions, my email is on the last slide, as well as our Twitter handle at Open College at KU. And thank you for the opportunity. And I really, really look forward to everyone's comments. Great. Thanks, Susan. Do you have any questions for Susan right now? You'll also have an opportunity at the end of the meeting. And if I can follow up, we'll be sponsoring a webinar on July 15th. So stand by for an announcement and more information on the webinar. We'll be actually giving a detailed demo inside the open portfolio so you can see more in depth of how it works. I do see a question. Do we want to address these now, or shall we just say at the very end? I'm going to go ahead and address the ones right now. And then if they're more at the end, we can take them then. But I think if people have questions specifically to your presentation, best to do that now. Yeah, absolutely. There is one for Amy. She was just asking about course content. That's something you would work out with OEC by loading your courses to the OEC website because we're just pulling directly from there. We're not dealing with content in the open portfolio per se. We're using the content that's already on OEC. And yes, there are ways for faculty to contribute. And James, I couldn't agree more. I think in this world right now, let me read the question. James just made a comment. He said that this portfolio tool is very timely and will fulfill a need for learners. And we were thinking along the same pathway is that in the open world per se, there is no way to really track and manage all the open learning. And if you're like me, I've got lists here and lists there, but no collective way to bring it all together. So we think this is step one of particularly a project that could be very beneficial to open learners. So again, I'm very interested in your feedback. You are welcome, Amy. And if that's all the question, do you have my email, please feel free to reach out to me. I really look forward to your feedback. Great. Thanks, Susan. I'm interested also to see what people do with this and how we can improve it and make it easier for people to collect and eventually assess their learning. Yes. Great. So we'll move on then to a report out on the open MOOC pilot that we've been doing. And I wanted to throw up a slide that we put up here last year in our first quarterly membership meeting almost exactly a year ago on why we were doing this. Why did we think that open MOOCs was a good idea? One of the things we thought at the time was that our members were really interested in doing MOOCs but didn't have the opportunity to participate in the current offerings or wanted to perhaps cast it out before committing fully. We also thought there was a real need to leverage existing OER and to put it in a way that it could benefit from the interactions and the opportunities that presented in a MOOC platform and to make them really fully open MOOCs. So we decided to do open enrollment as well as open content. We decided to go with edX because they were using open source software and they were also aligned with the ideals that we have as a community. So to update you on what we've done then in the past year, we ran the pilot with eight courses from universities around the world. So we were able to do this in multiple languages. So we worked with the National Chatsen University in Taiwan, Hokkaido University in Japan, and a Rundle Community College in the U.S., Tufts University in the U.S., the Test India Teacher Education Program in India, which is a collaboration between Indian universities and the Open University of the U.K., and the Polytechnic University of Madrid. You can see from the screenshot that several of those courses are either starting really soon or are actually going on right now. The pilot phase actually took longer to develop the MOOCs than we had initially anticipated. So many of those MOOCs have started since March of this year and going on through early fall. We decided to survey those who had participated in the pilot and to figure out what it took for them to actually make MOOCs out of their OER. One of the criteria that we had for doing an open MOOC was that it be based on existing open educational materials. And so we asked them first about the time commitment and we found that the time commitment is quite significant. They reported that it took a lot of time for instructional designers, for faculty, and for course facilitators. For those that didn't redo the video parts of their OER courses for the MOOCs, it only took about 10 to 20 hours of editing their videos to get them ready. But for those who decided to go with new videos, they spent well over $100 shooting and editing new videos for the MOOCs. And the MOOCs are generally fairly short. They average length is probably four to five weeks long. So this is not a full 15 week semester course. Project managers who just oversaw the process and kept things moving on the campuses averaged about 10 hours of work as did the higher level administrators. We asked about their re-use of OER and it really varied from institution to institution. The reported use of OER was between 25 and 100% new content that had to be made. And when we look at the 100% new content that had to be made, what that really meant is that they took the existing OER materials and basically remade the videos to make them more MOOC friendly because the videos that they had were primarily classroom shops and other things that weren't as useful in the MOOC setting. What we found was that lower cost of making the new MOOCs was correlated to reusing OER. And that's one of the things we have thought at the beginning. We'll see costs in just a second. That the new content again was primarily new video made specifically for edX's requirements and the MOOC platform. And that everybody had to create at least some new content. It wasn't possible to just use what was existing because edX has particular requirements that had to be made and that was primarily new content specific to the edX platform. We asked them about the cost in dollars and it depended on the extent of the modification of the materials that they had. The range was about $6,500 US dollars for universities that re-used much of their OER content to well over $100,000 for university that re-shot all of their video and created most of the material based on their OER but re-did it entirely for the edX platform. This is inclusive of staff time and other resources but obviously the extensive video work was the most expensive. And one of the things that we have found is that as the edX MOOC platform evolves and the requirements change, that the increase in requirements is directly related to an increase in time and cost for the university making the MOOC. There's also of course impact on the consortium itself. And one of the things that we have found is that the format of the existing OER has a big impact on how well it incorporates into edX. So different formats sometimes are harder to incorporate into edX and we have to work a lot more with the university to get it correctly rendered for them in the platform. That the overall process is quite involved and because it's evolving it requires a lot of communication and a lot of time back and forth. We were a bit surprised by the amount of time it actually required for the OEC staff. Just for the basic level communications didn't include reviewing the courses or any course design or even troubleshooting the platform itself. That we spent at least 40 hours per MOOC just discussing with edX and with the university on how this would evolve. One of the things that we have concluded from our pilot is that we do think that the open MOOCs are a really valuable contribution. But then in terms of our organization we won't be able to continue to offer them for no cost to our members because we have to at least cover our staff time. So one of the things that we are grappling with right now is the right way to do this. If we want to have a membership that would include MOOC support which would be at a different membership level and a different membership due structure or if we would want to have some type of a fee that would be associated with offering a MOOC through OECX. And we would really love to hear your comments on this and how we can support the open MOOC movement but also make sure that it has a positive impact on the organization. So if anyone has comments on that now we'd be really happy to hear that again and we can discuss at the end. Hi Mary, this is Steve Crescent. I would think you might be able to do both is to offer a membership level that includes the MOOCs and also maybe offer a null card option. I also had a question that you might see in the chat window there which is how much of the format adjustments that had to be made were related to policies from the edX group side and how much are related to technical requirements of the platform. Thanks Steve. Yeah, I should have mentioned earlier that I have a very strange thing happening with collaborate platform and the chat window gets so tiny I can't actually see it. So if you do type something in the chat window that you want me to respond to please signal me so that I can figure out how to read it. So yeah, so getting to your question Steve, a lot of the modifications were actually based on the changing requirements of edX. Certainly we found that some of the video for example that was shot in the classroom was harder to chop up into the small segments that the platform works best with. But it really was about the requirements of edX to have captioning and to have transcripts that go along with the videos that required quite a bit of additional work and editing and reshooting on the part of our members. Okay, that's helpful. I mean we're working with EdCast so we have an install of open edX set up for ourselves. But if anybody is looking for captioning service we use a service called FreePlay which is actually relatively affordable if anybody wants any more information that I'm happy to provide. Great, thanks. Any other comments or questions on the open booth pilot? All right, we'll continue along with the rest of the agenda. So the next thing we wanted to talk about was the open education information center that we've talked about in previous meetings. And Nina was going to give us an update on that. Can you guys hear me okay? Yes, we can hear you. So the open education information center is now live on the constitutional website. On the top menu bar you can go to resources and you'll see the menu for the information center. Now the purpose of the information center is to offer a place where people can come and find all sorts of information on open education. And there are three things that the information center offers. It offers information on open education, a calendar of events related to open education, and the discussion forum. Let me show you what it looks like. So the open education information center has information on open education organized for five different stakeholder groups. There are faculty, students, administrator, policy maker, and researchers. And you can see the submit information, submit info button where anybody from the community can submit the kind of information that they have. Now I'm going to choose a topic from the faculty section which is technological concerns. When you go into that page, there you go, when you go into the page for technological concerns, you'll see that information is organized in the format of questions and answers. And at the bottom of each page you will see a button that says join discussion or start a discussion. So after reading questions and answers on a certain topic, you can either start a discussion with other people or you can join the conversation that's already there. Now unfortunately we found a bit of glitch in the function earlier today so we hit it for now. But in a couple of days it'll be live again. So this initiative is still a work in progress. We'll be inviting the community to contribute content and more content are being uploaded as we speak. Now so that's all for me as it's probably much better for you to browse through the pages rather than to hear somebody talk about it. Please go to the consortium website, visit the information center, let us know what you think, and we'll have the form function up there very soon so that we can all talk about stuff. Thank you. Great. Thanks, Mina. Mina said one of the motivations that we had for doing this was that we found that the interest in open education has become much more nuanced and sophisticated over the past several years. And for one thing there's not much room for people who are rather experienced with open education to really collaborate, ask questions of each other and find out more information about what people are doing. So we tried to organize this open education information center by role rather than by topic so that you can go in and find the information you need for the purpose that you're looking for. And we do appreciate any comments and feedback so this is the beta version. It's being launched now for feedback and comments and we'll be consistently improving this over the next few months so that we can have a full hard launch by the time the new school year starts in Europe and the U.S. So the other thing we wanted to talk about today was the global open education implementation strategy. We're not going to have time to get too far into the document but it's also inviting your comments and your feedback. This document will be sent out to the wide open education community this week. We're planning to send it out on Thursday. What happened was there was a group of OER professionals who got together in Washington, D.C. from around the world earlier this year to discuss the state of OER globally and how we could advance it as a coordinated group. And so they got together and thought that there were several opportunities that we had. Those included demands for OER, the supply of OER, and the capacity of the movement as it stands. And we put together a document based on discussions that we had over a couple of days that talked about the areas where we commonly agree in general in the OER movement. This includes our values and the importance that we attach to OER for the future of education. And areas where we have divergent views and that includes things like what's the next big priority and is it more important to do this in higher education or K-12. We looked at overall strengths and challenges that the movement faced and we summarized all of these up to form a snapshot of where we are in the global movement. So looking at where we are now, the opportunities that we have moving forward, we thought that it was a great opportunity to figure out where the opportunities are for collaboration to be able to implement OER worldwide. And that's the document that we have that we want your feedback on. It's about a four or five page document right now. There are a few of us that have been working on drafting the document based on live conversations that we had both at that meeting and then a number of follow-up meetings held at various conferences around the world including one in BAMF. We want this document to be useful like the Cape Town Declaration or the Paris Declaration and really both stating what the movement is doing right now but also in figuring out what we need to move forward. And we really want your feedback on that. This will be sent widely Thursday, but if you'd like a pre-look at the document, I'd like to get your comments in first. I've included the link to it there. It's tinyurl.com slash OER implementation. Please take a look. Include your comments. If you have extensive comments or edits that you'd like to make, you can send to any of us on that drafting committee and we'll be happy to incorporate that in. We're also happy to talk to you individually by Skype or by email if you have particular comments or concerns. So please do take a look at this and let's make this useful as possible for the moment. All right. So we also wanted to take just a few minutes and summarize the Open Education Global Conference that we had in BAMF this year and to give you an opportunity to see where you can find out more information about the presentations you missed. So our conference was held in BAMF just about a month and a half ago. It was a glorious location, very well coordinated, and everyone seems quite pleased with being in Canada. We had fantastic international representation this year. We had 37 countries represented. These are the top 10 number of people, which included Canada and the United States, which makes sense from a geography standpoint. But then the next number you see is from Saudi Arabia. And this we attribute to that project that we did with the U.S. State Department that we talked about earlier. But also the Netherlands, United Kingdom, South Africa, Slovenia, Taiwan, France, Indonesia, and Mexico rounded up the top 10. So you can see it was a really interesting mix from around the world who all came to Canada. We had wonderful presentations, very good, very professional. We had a lot of comments about the level and the quality of the presentations this year. We were able to capture almost every presentation and we have put them up on the website. So if you'd like to visit the ones you weren't able to attend or if you missed BAMF entirely, you can get a feel for what the conference was like. If you go to the conference website, you'll see it under presentations and the links are right there, highlighted in blue. You can also find selected presentations done with Openpraxis, our partner again this year. We were very thankful to have them do a special edition on selected conference presentations and papers. And they are available online at the Openpraxis site.  So the floor is open. Mary Lou, this is Una. I wanted to answer a question that Buddy asked earlier. He asked what the average enrollment was for the OECX MOOCs. And it's interesting. The average, I would say the average enrollment was about 3,000 for the MOOCs that we've run thus far. We've run about five or six now. There was one exception to that, which was the business MOOC from Anna Rundle. And that one actually, the enrollment was 13,000. So there's a couple of things to be aware of. Number one, enrollment is not the same as retention. And only one of our developers at this point has actually looked at retention. And that's Tufts University, which offered the biology of water. And they actually had a very high retention rate for their course. And they'll be offering that one again in July. And they'll be offering it part two in September. The thing with the business course that was offered from Anna Rundle was actually a very good intro course. But we know from some of the statistics that Edex has shared with us is that learners who come to the platform are looking for courses such as business and engineering. Those tend to be the top ones. So courses like that do attract more attention. So that's why the 13,000 I think is a little bit of an outlier. And we don't have the retention numbers yet from Anna Rundle, but hopefully we'll be getting those. So on average, with that exception, they were running about 3,000 in enrollment. So I hope that answers your question. Hi, everyone. This is Susan. I wanted to just jump in for a second and let everyone know we have a Twitter event coming up in July. It's specifically on July 27th. This is a follow-on to our original Twitter event that we did during Open Education Week where we attracted well over 400 individual Twitter's focused on the subject of Open. It was called All About Open. In July, we'll be focusing on alternative course providers, which is us. So we are actually sending out invitations. You can reach out to our Twitter handle and find more information. But we're soliciting participation. It'll only be a four-hour event that day, 1 to 4 p.m. Eastern or New York time. And we invite anyone and everyone to participate and become involved in discussing the Open Alternative Content Providers. Great. Thanks, Susan. I know that people have participated in Twitch apps before, but they're really self-paced and interesting. And I found some really inspirational stuff coming from that. So thanks, Susan. We'll look forward to that. Susan, do you want to share the hashtag handle? I would love to. It's hashtag All About Open. Very simple. Okay, great. We'll put that in the chat window. Fabulous. Thank you. Yeah, and Mary Lou, I'll add on to that. Our first event was 24 hours. And it was very difficult to break away, even to take a nap. The invitees, the participants were so engaging. The discussion was just beyond what I ever imagined it would be. And it was just very enlightening to have that discussion in the virtual world. And I'm sure this will be the same, but I agree with you. It was very inspirational. Great. And since you brought up Open Educational Week, you reminded me that we have a survey going on. We've heard from several people that the timing of Open Educational Week can be difficult. And while we probably won't be able to change the date that much for 2016, we do want to look at dates that would be better for the overall community. So I just put up in the chat window a link to a survey. And if you would take a couple of minutes to let us know what would be the ideal timeframe, the ideal month to hold Open Educational Week from your perspective, you can put that on a global scale and come up with something that might work for everyone in the future. Any other comments, questions, activities that you'd like to highlight? Mary Lou. Yeah, Larry, we can hear you. Great. I just want to make an announcement that we've been working on our own Open Education platform for our UCI's website to manage open courses, download in common cartridge format, various things like that that in the past were fulfilled for smaller organizations by, what's the name of it again? It's now sort of orphaned software. Edu Commons. And so we're going to release it as open source. And we're putting in some last feature sets to it right now. But one of the questions that's being raised in the Open Education Information Center is how to choose the right platform. How can I make this easy on myself? Looking at the possibility that we both release it as open source software so people can do whatever they want with it, but also that we could host for as tiny a fee as possible an instance of it that would let people get going. So there could be a free level and then also some kind of premium support if people were interested in that. And I would actually like to find out what the state is for open education management software and whether people, particularly with new members, whether they're looking for something like this so that it would actually fill a need or whether we just, you know, as people lose Edu Commons or that they just go on to Moodle or something that's cheap and easy for them. Great. Thanks, Larry. Does anyone have any responses for Larry? Well, Larry, maybe we'll also invite you to speak at the next membership meeting and you can present more fully what you are working on and people can ask more questions then. Okay. I think there was a question from Sylvia about sharing the lessons learned from OECX and the next steps. Yes, Sylvia, we are going to prepare a report that will post on the website and let you know when that's ready so that you can look at the lessons learned from running the open MOOC pilot based on OER. Anyone else have comments or activities that they'd like to share? Okay. We want to remind you that next year our conference will be in Poland in Krakow in April and the website will be ready by July 1st. The call for presentations will go out at the beginning of September and that will need to be in by the middle of November so that we can get those a program ready and shared with you by the start of the new year. So we want to thank you all for participating. We are, of course, happy to receive your feedback and your questions at any time. Feel free to contact us, any of the staff members, or you can write to feedback at OEConsortium.org and we will get back to you as soon as we can. We appreciate your support of open education. We look forward to working with you in the future and we thank you again for your participation. Mary Lou, Buddy asked if you could repeat the information about the conference next year. Yes, absolutely. The conference next year will be in Krakow, Poland in the middle of April. The dates are the 14th through the 16th of April and we will be putting out the call for proposals at the beginning of September. They'll be due by the middle of November and the website will be up and available on July 1st. I also noticed that Ines, who is the editor of Open Praxis, has joined us. So I wanted to acknowledge her and thank her for her support and participation in the special edition. We really appreciate having Open Praxis as a partner for the consortium and as an opportunity for people to have their papers peer reviewed and published. So thank you, Ines.


Cobra Commander 788 here, you're a so great cop here, love G.I. Jones, but arise it! Sorry, sorry! Wait a minute. Ready? Ready. Ready. Silence, kill. Everybody hooded Cobra Commander 788 here, it's time for another Vincen- Where did you go? Are you done with the video? The hedges in the backyard still need to be trimmed. Mrs. Hoody! I hear that guy from Suburban Commando. Well, never mind that now, never mind that. We have a crisis on our hands. Your husband hooded Cobra Commander 788 has been reviewer naped. Reviewer naped? You mean he's been kidnapped? Yes, but I'm not kidding. He's in serious danger. I've come from the future to help you rescue him. This means I have to trim the hedges myself, doesn't it? Take this. It's Hoody's communicator watch. You will need it to summon help. The force is trying to interfere with Cobra Month. You can't let that happen. If you think I'm going to do the reviews, you're crazy. I've tried and it did not go off. Of course not. Just use the communicator watch to get help. In the meantime, I will try to find a way to rescue HCC. But I have to keep moving. The villain who reviewer napped him has been chasing me through time and space. He's right on my heels. If I don't stay a step ahead of him, he will capture me and I will never see your husband again. This is bad. This means I'm going to have to mow the lawn myself. And I'm not going to let that happen. I will hide clues in Cobra Month's reviews. Use this to decode the secret messages. I've got to get out of here before he finds me. Form BXU-57 reporting in. Hooded Copper Commander, you've regenerated again. No, it's me. Hooded Copper Commander has been reviewer napped. Reviewer napped? You mean he's been kidnapped? Problem. Tejas have to be trained in embarrassment of the neighborhood and I probably have to do all the gardening work myself again. I'm fortunate that I found you both here at the same time. I am the Toy Master. The Toy Master? That's right. The Toy Master. I've taken your cohort hooded Cobra Commander 788 and I've added him to my collection and he'll remain there forever. No. That's right. With him in my custody, it means no Cobra Month. No Cobra Month? For too long, reviewers have shared their collections online. It fills me with rage. I hate it. A collection is not something to be shared. It's something to be controlled by me. But you don't understand. Cancel and Cobra Month could throw the entire showverse out of balance. The consequences could be disastrous. I certainly hope so. Let this be a warning to all Toy Reviewers. The sharing stops or you may face the same fate as hooded Cobra Commander and end up in my collection. Once something goes into my collection, it never comes out. No Cobra Month. This could cause the biggest inter-dimensional crossword since the Tunguska Blast of 1909. We have to do something. We can do something. Before I called you, a crazy old guy told me that he was going to leave clues in review videos to tell us how to rescue HCC 788. He said we could decode the clues with this. That looks like... a Sergeant Savage Decoder ring? Oh. Is that what this is? We're not dealing with CIA level cryptography here. I have a plan. We'll keep Cobra Month going to prevent the Joverse from collapsing. I'll call in some help. In the meantime, keep an eye out for clues that will help us rescue hooded Cobra Commander. Good plan. One more thing. Can you recommend a good gardening service? I'm serious. My lawn looks like the Amazon and jungle. I have to take a machete with me just to walk to the mailbox. Um, no. Great. Just great. Should have married a Transformers reviewer. Yeah, I just don't know what to do, man. I mean, I want to get more popular, but I have no idea how. Uh-huh? Uh-huh. Well, I don't really want to do that.  Timber! I gotta go, dude. I think the drugs are kicking in. What are you doing? Oh, Kevin. It's you. Oh, thank God. We have an emergency. Hooded Cobra Commander 788 has been reviewed. I mean, kidnapped. Who? You know, the YouTube guy. He has kind of a... Oh, you mean Steve? Sure, whatever. A villain calling himself the Toy Master has captured him in order to stop Cobra Month. No Cobra Month? Is he nuts? That's one of the signs of the Joe Pocalypse. Well, we have to keep Cobra Month going. But we need some help. Last year, we worked together on Cobra Convergence. But this time, we have to call in all the agents for... Ooh, I want to say it! Okay, you say it. Cobra Convergence 2! Assemble the team. Yeah! Five, seven, half the battle. G.I. Jober, Strident, Sanitarium Productions. Be true. Joe Payne 82, reporting in. Sanitarium Productions, checking in. Strident, reporting in. Knuckle up. And I for orders, I'll explain the situation later. For now, I will do the first review of 2017 Cobra Convergence. Is everyone ready? Ready. Ready. Ready.