Well, thank you very much for coming. This talk is going to be about comparing the communities of OpenStack and the kernel. I'm CTO of server virtualization at Parallels, which is actually my day job. So it means I'm in charge of a lot of technology at Parallels and OpenStack is a very important project at Parallels. But my hobby job is that I'm actually a kernel developer. So effectively I'm coming to I'm representing the kernel point of view to an OpenStack audience. One of the key things about the kernel is that the skill it tends to value most is C programming. Everything in the purity of the C language and obviously OpenStack is Python. And as an actual kernel maintainer, especially a device driver maintainer, it would be expected that I would be a C purist as well, C purist to people who don't really like any language other than C. But I thought I'd give you at least a little resume from me. Not only am I a kernel programmer, I'm also a sort of serial drive-by programmer and a lot of open source projects. I actually have a lot of Java and Python experience. I did actually write a whole graphical user interface in Java once, but my most recent Java experience was actually coding for Android, the Android platform. If any of you run Sanogen mod on your Android phones, you'll notice it has open VPN support. I actually wrote that. And the reason I wrote it is because I had an open VPN server that I wanted to connect to, like all open source projects. There's also another Android application called CitDroid that I actually wrote fairly extensive set of patches for, one of which was to do the multiple codec support. Again, for me, because talking at conferences where the wireless network is as bad as this one, if you can use a very low bandwidth codec like the spx codec, you can actually get to your home asterisk server reasonably as opposed to everybody else using GSM who has a lot of stutter on their calls. This presentation, as you probably noticed with some of the CSS3 trickery is actually written in JavaScript, HTML and CSS. Being a kernel developer, I can just about get away with programming a fourth generation language like Java. It's much more difficult for me to get away with being an actual web developer. So if this were a kernel audience, I'd apologize for the presentation and say I'm a recovering web developer. Since you're actually a completely different audience, I can confess to the fact that I have actually written several websites. I count PHP and Ruby and other website programming languages among my proficiencies. But this talk of this actually never has to get out to people in the kernel, so I'm trusting you. I'm only coming out to this audience, not globally. And I suppose the final thing I should say is my marketing department insisted that I put a Twitter handle on this and told you to use the right hashtag. And of course, I'm not really very social media friendly. I actually, social media for me is right mostly. I tend not to read it just because the fire hose is too big. But with that, let's get into the community comparisons. One of the most difficult things is actually how do you compare communities that are so disparate like OpenStack and the kernel? Well, one of the things that I've actually seen a lot of the community comparisons that have been done before this do is compare the headline commit rate. How many commits went into each project in the last month, year, whatever. OLO actually tracks them. If you actually look at the commits on OLO, OpenStack already passed the kernel on active contributions. These are the active contributions. OpenStack, blue line at the bottom, kernel, red line at the top. In February 2014, you actually crossed. So OpenStack in that month had more commits per month than the Linux kernel did. So on that metric, you already beat the kernel. Well done, by the way. You can congratulate yourselves. However, what I'm really more interested in is other than the headline commit rate, which is useful for competition, getting grants, convincing your management, is that actually anything more interesting we could say about the comparison between the two communities. One of the really interesting things is what could we actually learn from each other? What does OpenStack do well? The kernel doesn't do very well at all. And what does the kernel do well that OpenStack doesn't do very well? The first thing you obviously like to consider is process. I mean, we all have it, right? Both OpenStack and the kernel have an extensive process for getting commits upstream. The kernel process, it might surprise you to know, actually exists. It is formally documented. We have a big documentation directory. It has files like submitting patches that tell you in excruciating detail exactly how to do it. But the key point is that nothing in the kernel process for commits enforces this. A maintainer, if they choose, and for the kernel, maintainers are people who actually accept patches on behalf of Linux, build a Git tree, and then pass that Git tree up to Linus. Our process is much more informal in the OpenStack one. We have no concept of Garrett reviews or anything like that. Reviews are all done on the mailing list of patches. So the maintainers choose exactly how much of that process they follow. If they don't want to follow any of it, they can actually legally do that. OpenStack has this extensive process. I think I saw someone document the 27 steps you need to do to get a patch into OpenStack. But the key difference between us is that your process is enforced and ours is not. Ours is mostly enforced. If you look at some of the flame wars on the mailing list, you see active enforcement going on all the time. But it's not a requirement of the submit process that it be enforced. And one of the interesting things here is that process enforcement does actually create barriers to contribution. Sometimes some people trying to submit a patch go away just because you make them jump through too many hoops. And we can have arguments over how many hoops is too many. But I've got to say that 27 hoops is actually rather a lot for an OpenStack commit. Deciding where you draw the line in terms of process is really key to actually what goes on. And sometimes that line is not a hard line. It should be a variable line. For some people doing something really simple, it's obviously correct. Perhaps you can short circuit, you know, 20 of the 27 steps of the process. Perhaps you just don't need it. For somebody who's trying to get a full-fledged feature into a system of OpenStack that's already moving fast, perhaps you really do need it. Deciding where to draw the line is key. One of the things, the kernel values in this that you don't have the freedom for an OpenStack is flexibility. Once a process is set in stone and enforced by all the mechanisms as it is an OpenStack, you can't really waive it for anybody. OK, so testing. For those of you keeping score, this is the real killer one. This would be kernel zero, OpenStack one. Because one of the things I actually do as a kernel maintainer is I'm on a lot of sort of our informal committees that actually represent the kernel to bodies like the Linux Foundation and even to a lot of our funders. And a lot of my conversations in the last six months have been going, why isn't your testing process more like OpenStack? So, one of the things I can tell you today is that the kernel is now developing more of an extensive testing infrastructure. The guys who are beating me up about it six months ago are now giving us money to do it. So it will be actually an official project funded by the Linux Foundation. It can't quite be modeled on the OpenStack one using Jenkins because that has to be tied to the commit process. And as I told you, our commit process is pretty informal. So our model will be a forgiveness based one. We actually already have a guy called Feng Wang Wu who looks at all of the git trees that are sitting waiting for Linux to pull them and runs all these tests over the commits to see what's going on. We're actually going to add a more formal testing structure to that. So the tests won't happen at commit time as they do in OpenStack, but they'll happen in between the commit goes into my tree to push on to Linux and Linux actually getting it. And usually that time period is pretty long. It's usually the order of a month. So we actually have time to do the testing and for me to throw these patches out if they fail. But this I'm proud to say is one of the things that we sort of learned from OpenStack. I mean, learned is I learned it with lots of people beating me up with crowbars, but we still got it from OpenStack. Reviews. This is a mixed bag. In theory, you have a much more formal review process than we do because our review process is just over the mailing list. But we both have the same fundamental problem at the base, which is neither of us can find sufficient good people to actually do the reviews. And in that case, it doesn't matter whether your process is completely informal or fully formal. If you can't find the people to do it, commit stack up behind reviews, which is what's happening in both OpenStack and in the kernel. And encouraging more people to actually do reviews is a problem for both of our projects. And if I'm lucky, it's a problem we'll be discussing at the Kernel Summit. But I gather it's a problem that lots of people in OpenStack are already thinking about how do they fix. One of the particular problems that both of us have is this thing called bike shedding in reviews. That's why when a reviewer actually looks at something and says, oh, but what if you implemented this feature in a completely different way? And you go away three months later, you come back with it in a completely different way. And the reviewer looks it again and says, no, I didn't like that anymore. What about if you did it this way? And unfortunately, that is a feature of both of our projects as well. We do get a lot of people who participate in the review process, who don't seem to add a lot of value. Part of my job as a maintainer in the kernel is actually recognizing these people and either shutting them down on the mailing list or ignoring the reviews or telling the committer privately to pay attention to these five reviews, but not this one. Part of the actual law in the kernel is trying to learn whose reviews you should listen to and whose you shouldn't. The social system that Garrett actually has does have the ability to do this, but I don't think you make use of it. So an open stack, getting more people, some people's reviews to count more than others is done, but it's not actually apparently done in the open. It's done behind the scenes. But the base problem is neither of us has enough reviewers and neither of us has a process which actually encourages people to become reviewers. Regression analysis is a sort of mixed bag. It's inconclusive. Both projects have regressions. I could give you graphs up the wazoo that say what the regressions are. A regression, by the way, is a fault in a feature that was in a previous release, but didn't have the fault and is now in the next release. So it's something that was a feature that now has a bug in it that wasn't in the previous release. For the kernel, we actually used to have a formal process that tracked and concentrated on regressions. But if you look at the number of regressions we have with and without that process, they're exactly the same. So the formal process did actually nothing to help us prevent regressions. As far as I can tell, open stack doesn't even track regressions formally. So like I said, the data is pretty inconclusive. The release process question is actually much more interesting. The kernel, as you probably know, has two to three month release cycles. We have a two week merge window right at the beginning of the release cycle and a six to ten week stabilization period right at the end. Open stack does almost the same thing, except you have six month release cycles. You have about a four week planning cycle, which the design summits apart. You have what we could call roughly a 14 week merge window, because you could say it starts when the planning cycle ends and it goes up to the feature freeze. And then you have a six week stabilization period where you start releasing release candidates. The kernel, when you compare these processes, we don't have a designated design period. We concentrate on the code only. We don't really concentrate on the design. That means that code at the merge window has to appear fully formed. If it's not ready by the merge window, it moves over to the next merge window. So we do actually do design stuff. It all goes on on all of our different mailing lists, but it's not done effectively formally. That means if you look at the open stack release processes, they look something like this. There's your, well actually, the color bars are slightly wrong. The purple, which would be the merge window is slightly bigger. This would be your design merge window release stabilization. You go on like that. The kernel, if you look at it, actually does this. Effectively, if you add in the actual design period, which is what we're doing between one merge window and the next is all our design time. Our release cycles are almost the same length as yours. Theoretically, they vary somewhere between four months and six months. But for the sake of argument, we could say they're six months. So we do have this formal design period. We have this tiny merge window and we have this long stabilization. But the key takeaway from this graph is that if you look at what you do and what we do, we have an overlapping release process. Effectively, this means that we do the same as you, but we release twice as fast. And if you also look at it, we do spend more time on stabilization than OpenStack does. Now, the question you could ask yourself is, who benefits from this? It is hard to actually get any conclusive data on this. Regressions, we could say are the conclusive data, but I've just told you they don't really say very much. So I present this as a difference between the projects that you might like to consider. But I'm not actually going to draw any formal conclusions from it. I mean, the obvious conclusion is the kernel does go twice as fast because we release twice as often. We're a code base of equivalent size and we have the same cycle length that you do. So overlapping releases definitely work for us. I would have to say that most open source projects do not have this really tight merge window followed by a long stabilization. The kernel is fairly unique in open source projects doing this. And because most open source projects don't do it, what I can tell you is it works very well for us. I'm not entirely sure from the data if it would work very well for you, but it's something you could actually consider. OK, so other comparison methods. What are the other ways that we could say different things about the projects? One interesting metric is prolificness, which means that you take any project and you use get statistics to tell you who are the top five committers to this project and you look over a period of a year and say how many commits do each of these top committers make over the period of the year. That's a very good way of actually measuring the prolificness of the project, how much change is actually physically going into this project. So that's basically what I did for these statistics and this is what they actually come out at. OpenStack is actually an interesting project to try and do this for, because I can take what would be considered core, and I know what's considered core is a bit controversial, so I took an arbitrary cut. But most actual open stack committers are project monogamous. That means they usually have commits that peak in one project and not very many in another. So the statistics look virtually the same, whether I take a single project or whether I take the entirety of OpenStack. So I actually did both. This is roughly what it looks like. That's the kernel. This is OpenStack as a whole for all of what you consider core projects. This is quantum and this is neutron. As you can see, the top committers for the kernel peak over the last year at around 1250 patches for the top committer. For OpenStack it was somewhere around 350. Now one of the things I could tell you as a kernel developer is this means that we're about four times more prolific than you are. But there's a dirty secret hiding in all of these figures. You probably don't know it, but a lot of commits to the kernel are actually done mechanically by people who run source code checker over the sea that says, you know, you have spaces instead of tabs here. You have duplicate semicolons here. This include is done twice. And in fact, the top three committers here all make those type of changes. They're all people who basically have the Linux kernel mailing list feeding into a checker for the commits. They put it on a work queue. Then they produce patches that correct all of the mistakes and have them put upstream later, which basically means that the statistics I've showed you here are completely worthless because our top committers are done mechanically, not actually by substantive useful commits. So how could I give you statistics that are actually substantive useful commits? What it means is I actually have to go through our top committers. So I went through our top 15 committers and it helps being a developer. I know personally which ones are actually doing decent work and which ones are doing trivial work. So when I take out all of the people doing trivial work, this is actually what the statistics look like. So this is our top committer who actually does real work. And as you can see, OpenStack is still sitting at just shy of 350, but the top committer in the kernel is only around 650. So the prolificness of the kernel over OpenStack on this measure alone is only a factor of two. But then you get into process problems. In the kernel, because we have a mailing list process, we're very good at forcing people to break changes up into easily reviewable components. In OpenStack, in theory, you are supposed to do this. It's actually written down that you should do this because it makes reviews easier. But in practice, getting commits through Garrett is a time consuming process. And so most people would rather do one review up to Garrett than actually try and work out how to divide it into two. So some of these commits here are multiple patch sets that wouldn't actually be present in OpenStack. But in theory, the figures show that our prolific committers are about twice as prolific as yours. In practice, if you actually analyze the patch series and work out how many they do, you might get a 50 percent, well, sort of 25 percent reduction in the kernel. It might come down to somewhere like 400 instead. Perhaps we're not that much more prolific at the top end than you are. But again, I can give you the figures that Garrett says, and I can explain why it's hard to compare them. I think, I mean, being a kernel guy, I'd obviously say that we go faster than you just because we have a release cycle that's half as long. We do the same type of process, so we release twice as fast. These figures seem to say that our top committers are twice as prolific. The data does seem to match in some form. The other thing you can look at is called the long tail. That's how easy it is for someone like me when I did Android OpenVPN or CitDroid or some of my other websites. How easy it is for someone who's an outsider in the community to actually make a contribution to it. So it's basically look at the total number of committers who submitted n or fewer patches and ask how many are there in each project. And it looks like this. That's the kernel in dark blue and open stack in light blue. In theory, the long tail of the kernel is a lot bigger than the long tail of open stack. That means that the kernel is, in theory, a much more accepting process of patches from drive by committers than open stack is. Now, in practice, this statistic is absolute and therefore not correct because it's showing the absolute number of committers. If you think that the kernel has about 60,000 committers and open stack, I think in the last release cycle has about 25,000 to 30,000. Obviously, since it's a bigger project, the kernel would actually expect to have more long tail committers than open stack would. How do you actually account for that? One of the things I can do is actually scale this down to a percentage. So here, open stack actually beats the kernel on long tail because I have divided the statistics by the total number of committers over the year. So in theory, that says open stack has a bigger long tail in the kernel. The problem with doing it this way is that what I've actually done is I've overcompensated for the prolificness because we have many more contributors right at the top end who do more patches than open stack does. And I've just divided by all of those contributors. So again, I've given you a metric that isn't actually properly accurate. So if I do it in a way where I scale the prolificness figure so that it's the same for both open stack and the kernel and then do the division again, this is what it looks like. And this time it says that the long tail and open stack in the kernel for each of the patch things is about the same. Perhaps there's a slight advantage to the kernel, but that advantages of the order of 5%. Perhaps it's not even significant. But if you want to look like the kernel does in its incarnation over here, you obviously have an interest in making open stack more accepting to drive by committers. So like I said, the anecdotal signs are that the kernel's long tail might be longer, but there's nothing really conclusive in this because I can slice statistics either way. In fact, what I think I've just proved with all of this is Disraeli's contention that there are lies, damned lies and statistics. However, one of the things you can do to actually increase your long tail and actually even make your prolific committers be much more prolific is to reduce the barriers to contribution. If the hops they have to go to to get a patch in are much lower, they'll tend to get more patches in and people who would have been put off by it and not submitted the patch will be more actually eager to do it. One of the barriers to contribution you definitely have an open stack that we don't have in the kernel is contribution agreements. Everybody who makes a commit to any accepted core project of open stack is supposed to have signed your CLA. Now Mark McLaughlin actually has a session on this immediately after me in BO through to in the design summit. So I'm not going to give you the long version of this talk that I was going to do. I'll give you the short version. Which is Legally in the US your employer owns your contributions if you're making contributions to any project open stack the kernel I don't know dive dive stuff that Linus does gnom any of them your employer owns that contribution under the US law For most of you who work for companies that are used to dealing with open stack This isn't a product used to dealing with any form of open source including open stack This isn't the problem none of you has probably run across this as an issue Principally because it's all been sorted out at your companies long before you started committing to the kernel or open stack or any other project But if you're trying to attract drive-by contributors They're people who work mostly in companies that are not used to putting code upstream and open source Anything you put in their way, but it's a barrier that looks like a legal document Actually has to go through a legal counsel at that company. So if Potential contributor to the kernel comes from a weird company. Oh, let's say Microsoft The only thing to make a contribution to an open source project that commit has to do for the kernel In Microsoft is get their managers permission. That's fairly easy if They have to sign the CLA they have to sign that legal document on behalf of their company the CLA actually says this at open stack and One of the things that no manager can do is give an engineer permission to sign a legal document All legal documents have to go through the corporate counsel in the company So this is already a barrier difference between the Linux kernel and open stack. It's actually a barrier I'm not just between the Linux kernel. There are lots of other projects that have this informal commit thing and The problem is that the actual corporate counsel is the guy who actually has to sign the contribution agreement Most of you who work for companies that are used to doing this with open stack I've already got a process for this your corporate counsel is already doing it. You never ever see this problem But let me show you what the corporate counsel for most companies who are not used to open source actually looks like This is the corporate counsel. This is the corporate counsel's job The intellectual property of a software company is the treasure pile And the job of the corporate counsel is to sit like a dragon guarding the treasure hoard If you want to go to the corporate counsel who is not used to dealing with open source what you're basically saying is Excuse me, mr. Dragon. Can I have a lump of this treasure? I'd like to take away and give to the open source community For a lot of people it won't just get you burned. It can sometimes get you fired The corporate counsel is not a person who wants to give away any of that treasure It is literally like trying to steal treasure from a dragon's hoard So for all of you in the room, this process has already been gone through by your predecessors But think about how it would look if you had to go and actually bait that dragon Try and force them to give up the treasure and to actually sign this agreement Because to the intellectual property dragon to the corporate counsel signing the CLA Looks like an agreement to give away the gold pile that they're sitting on hoarding This is why it is so difficult for people who don't actually work within your ecosystem to sign that CLA This is why the CLA is such a barrier to contributions in open stack So the one thing I'd actually ask you from this session is please go and support mark in his bid to remove the Contributor license or agreement and replace it with something else that gives you equal legal force But means that the poor old developer and say a dev ops or who doesn't contribute or some other organization Only has to get their managers permission to contribute. They don't have to go and be at the dragon of the corporate counsel okay, so Another thing we can look at is how would you actually go about increasing the prolificness in projects? And this is a problem not just for you an open stack It's also an interesting question for us in the kernel as well. We might look on paper like we're doing well, but we could always do better so The easy thing you can do is just increase the chances of acceptance getting rid of the CLA would be one way of doing that but there are obviously others and Obviously you have to do this without compromising quality There are spectrums if we had a project which was a free-for-all and we just accepted any patch that was presented to us We'd have commit statistics that overhauled the kernel by God knows what just because there was no quality control in the project Conversely if you have too much quality control, you're actually pinching the amount of contributions So you're artificially reducing the amount of contributions So either end of the spectrum is obviously wrong What we actually have to try and do is find the medium point in the middle and that again is why the prolificness Statistics I showed you are not things that you should take with too much Seriousness because it could be that the kernel is actually Accepting too many patches and therefore giving itself a quality problem looking at the regression statistics for our releases I don't believe this is true So I think we still sit on the quality control side of that bell curve, but I don't know how far we sit on there I think we could perhaps stand to loosen our process a bit and perhaps accept a few more patches But I'm not sure we'd actually do that I think you also since you sit to slightly the left of the bell curve of us could also do with loosening up your Quality control process, but again I don't know how much and there's always a danger to loosening the quality control process because you're it's not just Quality control on the back end. It's stabilization on the front end The more you loosen quality control on the back end the worst stabilization on the front end becomes your Stabilization period is a lot shorter than as well as 50% shorter than ours That means we have time to catch quality control problems that you might not catch with the shorter stabilization period So the perfect point on the bell curve for us is probably not the perfect point on the bell curve for you And so I'm not giving you any advice about doing this I'm just pointing out the comparison the comparison says the kernel is doing slightly better in terms of quality control and commits than you are because we're accepting more patches But they're still not giving us a huge stabilization problem, but whether you could do the same I don't really know because it would involve tampering with your release cycle to do that But one of the things that you and us all both need to do is to accept patches easily from non-core contributors in one way or another Harvesting your prolific contributors Nurturing them giving them free goodies in the dev lounge is a very good thing to do because they're the people who make most of the patches But remember Everybody who actually grows up to become a core contributor to either project had to start somewhere trying to encourage people who are starting out is also a vital part of this process and Like I said, I don't really have much advice to give you the biggest piece of advice I give you that I see happening on your reviews and our reviews is Basically, if you are a leader in your community like I'm a maintainer That makes me a leader in my field in the kernel community. Lots of you are leaders in the open-stack community Preventing bike shedding and reviews things which give people a negative impression of the community because they're basically wrong It's actually a very good service to the community If you see somebody give a bad review and a bad review means you've told you've given this person a list of ten Things to do seven of them are wrong. It's your duty to say so because if you don't say so What's going to happen is that person will do all ten things on that list. They'll come back The reviewer will be happy, but it'll get up to the commit of the maintainer like me And I'll look at it and go what the hell did you do those seven things for I'm not accepting this patch And that is very very dispiriting to the person who did that Trying to police the review community and make sure reviews happen is actually a very very core way of actually Encouraging people to come into your community and making them feel welcomed giving people bad reviews as a way of making people feel terrible Okay, so I think I'm going to leave five minutes for questions. Let's come to the conclusions So both projects actually have a lot of the same problems. There's a lot We could actually tackle cooperatively in the open-source world Bike shedding and lack of review is something we both have in spades If we did something about it, perhaps we could do something about it together Both projects actually have things they can learn from each other I think it's no secret now the colonel has learned testing from OpenStack Perhaps there's things about stabilization release you could learn from us But the testing thing was very simple. We didn't do it now. We're planning to do it the Altering the release process to try and get more prolificness that I presented in the graphs is not a simple thing to do It's not a yes. No, we do it. We don't do it thing. It's not the cable. Honestly. It's tight end It's something to do with the other end it's Sorry lost the train of thought. Oh, yeah It's it's something that you would actually have to debate and consider where they actually suited you or not because You sit at a different place on the whole set of curves that I was measuring from us And the reason you sit at a different place is because your release process is different from ours What works for us might not work for you So I can say the colonel learned from OpenStack. I can give you something You might be interested in learning from us, but I cannot say it's it's not a yes No thing like testing was it's something you have to go away and consider for yourselves So the good news is that both communities are already talking at many levels The current level that we're talking on which is the crowbar. I got beaten over the head It with is that the companies who fund the colonel are also a lot of the same companies who fund OpenStack So it's our funders who are actually discussing this and so things are actually being pushed down from the top towards us So ultimately you lot will hear about this as well as I heard about it in testing But that's actually a good thing and sort of me coming here and perhaps you coming to our events Would also be good things because there are a lot of common things in terms of building a community that neither of us get Right that we could actually look at doing common mechanisms for trying to sort out So with that if you enjoyed this presentation, it's actually done by using impress.js by Bartek Sopa I've got to say that this presentation is not the vanilla impressed.js That's in Bartek's account on GitHub I actually forked it and did lots of things that do some of the special effects that he can't do Which obviously goes to prove that I am a web developer in spite of everything My fork of impress.js is on git.colonel.org under my account, which is JJB if you want to look at it I'll probably put this presentation up online and I might even send a social media tweet about it So I'll tell you the URL so you can just download the source and look at it from yourself But with that thank you for listening to me and did you have any questions? Okay, so I think I saw one question there. You can either come up to the mic or I'll repeat it When I look at statistics for Contributions it seems that activity.org doesn't provide more granular stats Well, you're asking the wrong person since I'm a kernel developer But I can tell you that none of our kernel stuff provides the stats that I showed today I did a git pull on all of your repositories and actually ran a set of git scripts over them I looked at OLO stack-alytic and a few of the other activity things But none of them gave me the statistics I the only statistics I could get out was the initial graph I showed with the headline commits everything else I used my own analytic tools running over the git repositories for so and Obviously being a kernel developer. I can't really answer why open stack.org does something or doesn't do something But I know that neither project gave me the statistics I wanted to actually do the analysis I presented here today Why they don't do it? I suspect is partly in the reason that I gave you which is that trying to match these up by Statistics is fraught with danger. I can spin those statistics either way if I did the scaling one I can show with those statistics that open stack does miles better than the kernel if I show the raw ones I can show the kernel doing much better than open stack at the end of the day without the Explanation of the comparison base the statistics don't really mean anything, which is probably why they're not tracked Okay, so this is a question about the politics of open stack the question was what actual core projects did I count for that analysis? The answer is I knew I was going to get this question because what is core and what is not core is a really significant political problem With an open stack at the moment So I punted on the problem and I went to Olo anything Olo counted as core is what I eat So that commit graph was basically straight from Olo Olo seems to take non incubator projects that are actually sitting in open stack Which is where it gets most of its statistics from but I knew I was going to get the question So I basically sidestepped it. I have no real good answer for you There are people who are working in the open stack board to try and define what your core projects are But right at the moment I haven't really seen an answer come out of them And I wouldn't presume to give you one as a kernel developer from this podium Okay, any other questions? If not I'll say thank you very much for listening and please do turn up and support mark in the design summit. Thank you


I was diagnosed quite unexpectedly with stage 3 cancer. As I was nearing the end of my operations, I wanted to document my scars. I remember asking a friend of mine, I said to her, can you take some pictures? And we just sort of had a laugh of it and we took these pictures and I was like, alright, you know, let me know when they're ready. She brought them in, I was in tears. They were so powerful and they came out so strong and I said, imagine if we could get a group of women to take these pictures and we could showcase them to raise awareness of cancer in our community. So that was my buying for the women was that if you're going to do this, we need you to tell your story and it's going to be difficult and it's going to be hard. With Black Memorising, it's more than just the charity. You build friendships with everyone who you meet. I don't know what I'd do without these girls, I'm really done. So yeah, it's been brilliant. I was treading water, now I feel like I'm swimming, you know, and I'm not doing it alone. In our community, we don't see young black women getting breast cancer. Cultural myths and taboos are stopping people from talking, reaching out. Sorry, I always get emotional when I talk to them about this. I remember my oncologist, she said to me, I need you to go back into your community and I need you to tell people that chemo isn't bad and that this could save their life. When we opened our charity, the lottery was the first money we applied for the exhibition and we got it. We were able to print the pictures and we were able to do an amazing exhibition and the project went viral. People just had goosebumps, it was electrifying. Once they started and they started to see the love and support from the audience, they couldn't stop. Some people cried, some people laughed and that's why we've called it the untold cancer stories because people don't hear them enough. The poem says, phenomenal woman, that's the woman right there, she's amazing. So we've got the title now for the first black cancer scar exhibition. In the world I think, I think in the world.


I'm Steve Nunn, President and CEO of the Open Group. Welcome to Toolkit Tuesday, where we highlight the various components and leading experts of the Architects Toolkit, a collated portfolio of the most pertinent technology standards for enterprise architects. During the series, I'll be calling on a number of recognized experts who will bring their particular insights on how to most effectively use the various tools in the Architects Toolkit. We'll have a mix of interviews, panel sessions, and pre-recorded presentations along the way. While all standards of the Open Group are designed so they can be adopted independently of one another, the greatest value for an organization can be derived when they're used in unison, that some of the parts should be greater than the whole. In the Architects Toolkit, we have collated a portfolio of the most pertinent ones for architects, together, all in one place. For most of these tools, certification from the Open Group is also available, so practitioners can demonstrate that they have the skills required, and recruiters can take the guesswork out of the recruitment process all backed up by our Open Badges program. Chat, AI, and Energy. I've posted before about chatbots and sustainability, separately from an architect's point of view. I learned recently about the energy consumption involved in developing and operating these chat AIs, like Chat GPT, for example. I can't do it justice here, but I urge you, go take a look. I was horrified. I expected it to be quite excessive, partly as the whole setup doesn't work on the basis of ruthless fragility, and of course the promulgation of many siloed bots, as I've said before, simply replicates the energy cost. So ignoring the debate between the trustworthiness and the threat of these AI models or the opportunities that they present, as responsible architects, we need to make their sustainability footprints a key concern and an architectural risk for us. I can easily see technical debt not being measured in dollars, but in energy footprint as a result of this explosion in AI chat models. Welcome everyone to Toolkit Tuesday. And a great thank you, as usual, to Paul Holman, very on topic there, Paul Holman Distinguished Engineer at IBM and member of the Open Group Governing Board. Paul Holman's always seems to have some good thoughts here and teeing us up to think about the carbon impact of the latest AI developments and chat GBT. It's a perfect topic for today, where we are going to be talking about some of the work that the Open Group has been doing in the Open Footprint Forum around that very topic. But before we do, just a quick bit of housekeeping. As I say, welcome to you wherever you are. Thank you for joining us. Great to have you with us. And we're delighted to have people join us from all over the world. Those of you who are regulars will hear me say this not all the time, but nearly all the time. It's great to know that we are a global community and that the work that we all do together has an impact globally. And none more so than... No topic is more important than today's topic for that having a global impact. But just a quick item. If you'd like to ask a question of today's speaker, then please do that through the Q&A channel in the WebEx tool. And if you can't see the Q&A channel, please click on the three little dots in the bottom right-hand corner of your screen. And that will give you the opportunity to click on Q&A. So please ask any questions through there. And please encourage you to use the chat channel. As I said, we're spread all over the world. So let us know where you're joining us from. Let your other fellow attendees know where you're joining us from. I kicked it off. Welcome from Sonoma County, California, where we have normal service resumed on the weather, which hasn't been the case so far this year. But we needed the rain. So without further ado, our topic today is the work, as I say, the work that we're doing inside the open group on carbon emissions measurement. And as you know, climate change and the impacts of carbon are becoming more material every day. And the world is recognizing the impacts. There isn't a day goes by where we don't see something about the impacts risks or opportunities around this topic. And over the past several years, the open group's been working collaboratively across multiple industries, technology consulting, academia and other groups to establish a standardized data model to enable the accurate and timely reporting and sharing of carbon data. As you'll hear, that's a challenge without some work being done. Companies need to have a level of trust to influence and improve their sustainability impact, and that trust is increased by having a well-aligned data model. So today our focus is on that data model, and we are delighted to have with us Mr. Ajay Vandervoort. So Ajay, welcome. Ajay is a customer-focused, results-oriented global executive with more than 28 years of experience with Fortune 500 companies in oil and gas, oil-filled services, consumer goods, automotive and government in most continents of the world. He's currently been 10 years with InterTech. Before that, he was with SAP for 15 years, and he started his career working on Unix Systems, which is a topic dear to the hearts of folk at the open group, still an important part of our world. So warm welcome to Toolkit Tuesday for Ajay Vandervoort. Over to you, sir. Thank you, Steve, for the warm introduction and greetings from sunny Florida. In the next 20 minutes, I'll be discussing our comprehensive standardized data model for carbon emissions. On the right, you can see the well-known image of the greenhouse gas protocol standard. It differentiates between direct and indirect emissions and scopes 1, 2 and 3, providing clarity in order to avoid double counting. Now, OFP, which stands for Open Footprint Forum, has taken this concept and developed a versatile data standard focused on third-party verification by auditors as regulators are mandating this on a global basis. That means companies need to have a level of trust in data in order to influence and improve their sustainability impacts, and that trust is increased by having a well-aligned data model. More on that later. First, let's delve a bit deeper into the topic of standards. As you can see here at the bottom, there are various reporting standards and I only have put up a few. There are frameworks and as well-aligned, for example, the WBCSD, which stands for the World Business Council of Sustainable Development. They outline the requirements for ESG and carbon reporting, yet often they overlook the technical details and currently there is no established technical standard. OFP provides this. This enables companies and technology providers like hyperscalers, ERP software companies and other ESG tools to use the OFP standard and implement their own way for tracking, managing and exchanging the data, providing maximum flexibility and extensibility. As you can understand, there are many players in OFP's ecosystem, from policy makers, standard setters, auditors to technology companies. Many impactful partners are already engaged in the forum and the following organisations have already committed to OFP and total 288 members. They are organised in six working groups. Each working group meets once a week. Some groups are more technical, others are functionally around sustainability and regulators, or more marketing related. I mentioned before, there is a reason why this is urgent. As regulators, like the SEC, which stands for the Security and Exchange Commission, are mandating climate-related disclosure next to financials. The timeline here on the slide shows when the proposed law is expected to be final. As you can see at the bottom, the UK is already active and the SEC's final rule is expected this month, followed by Canada and Europe in the middle in the summer of this year. Based on this ruling, the blue arrow shows when carbon data collection should start. For example, in the UK, they require five years of historic data, once you file in Q3 2024. The SEC, however, requires two years of data. This means when the first filing is due in Q1 2025, you're required to report on data from Q1 2023, which started a couple of months ago. Notice well when limited and reasonable assurance is required. This means data quality is not optional. Today, most companies use thousands of spreadsheets as reporting is voluntary. In OFP, we've identified over 30 disclosure requirements that are consistent amongst the global sustainability regs that impact the data model. Here, a list of the first eight. For example, periods covered. As I mentioned in the previous slide, that the UK requires five years of data, including energy usage performance. I've highlighted that here in the bottom. Now, what does the data model look like? Here is a high-level overview. Note the various entities and their relationships. I hope you can zoom in to look at that in more detail. At the bottom, you find the carbon emissions per product value chain entities, as defined by the WBCSD scope three requirements for carbon data exchange. This is important because our alliance with WBCSD is quite critical. We even included product lifecycle analysis, or LCA, as the industry calls it. That means we are ready for the circular economy. A complete data model for all your sustainability needs. The next three slides show the basic concepts. The heart of the data model are the emission activities, either source or sync, and its calculations. You can build hierarchies like what you do in accounting, with the output being a statement, like with your financials, of your greenhouse gas inventory. Ready for the regulators. Here is an example of those activities and how they are calculated for an organization structure, with its unique organizational, operational, or financial boundaries, based on equity share or emission allocations. Each reg or regulation has different requirements. Last but not least, as I mentioned before, emissions per product. Remember that on each product that you buy from the supermarket, you'll find how much calories there are in this product. It is envisaged that it will be a time where each product will have as well what is its carbon intensity. As per WBCSD requirements for data exchange in your supply chain, including lifecycle analysis. And this diagram shows the depth and breadth of the data model. So what else makes OFP unique? And that's its architecture. As the model is built on a 21st century architecture with microservices and containerization for AI, IoT, backdata, or blockchain, with an API-first approach, including the latest cybersecurity and DevOps environments from the world's latest hyperscalers with most microservices from Google Open Edition, that you can run on either AWS, Azure, or GCP. That means maximum flexibility for independent software vendors or companies that want to use it as either a platform as a service called PAS, a software as a service called SAS, or a business process as a service, and build cool apps and data insights on top of an open source OFP. So what about integration and interoperability? Well, there is something unique about common data. Most data is already there, either sitting in an API system in some form or thousands of spreadsheets. All you need to do is ingest it and rich with calculations and then consume and deliver to support a full lifecycle of data. That's called sustainability build-in. Meet for analytics, climate risk mitigation, lifecycle analysis, carbon offsets, or just simply regulatory reporting. You don't need a monolith rigged ERP system with limited integration and interoperability. Even better, the Open Group has delivered this successfully with standardization of subsurface data called OSDU. OFP is using the same architecture with a different data model for all the data above surface. This is the last slide. We need your help. The data model is already developed. Of course, it can still be extended and it will evolve. We need your help with validating, extending and documentation. Please join us and you will see here the website link or you can contact Alison, who is as well on this call. I'll pause here and hand it back to Steve for Q&A. Thank you. AJ, thank you very much. It was a whistle-stop tour that represents an awful lot of work that's been going on. Thank you very much for that and for setting it into a context that we can all understand because after all, it's one of the major topics we hear about every day about the carbon emissions. If I can just play you back before I get to the questions, if I can just play you back how I've always understood this and what we're doing and that's that right now, believe it or not, there is no common way for organizations, for companies to record and report their emissions data. Some of them are making great claims zero by whatever date, but it's based on the set of standards and the models that they choose to use rather than anything that's consistent so you can't really compare apples with apples. Is that about fair? That's about fair and that is one of the principles of what we focused on at OFB is as well the verifiability of the data. Where do you get that number from? Like every order to would ask when you, particularly at this time of year when taxes are due, that receipt that you gave me or that number that you have here where did it come from? Can I trust that data? Because it's now mandated by the regulator there are liabilities. So boards of directors worldwide particularly of public companies all are concerned about what's going to happen in the next couple of years and they don't want to be held liability for data that is not somewhat accurate or reasonable accurate. Yeah, no, of course. Of course. So as I said, different organizations are using what they can use at the moment or what they choose to use. So what makes the work that's going on here different from other data models for greenhouse gas emissions? And that's a great question, Steve, because, you know, as you've said in the introduction, I have a long ERP background and monolithic systems costing quite a lot of dollars to implement, right? I think the first thing that's exciting about OFB that it's built on 21st century architecture as I mentioned in one of the slides, right? Because in the previous century proliferation of spreadsheets proprietary systems with their own databases have created a hodgepodge of non-integrated data systems that we're all still suffering from and pulsated correctly technical debt, right? Secondly, the data model is backed by an industry that has done this for all data that is subsurface as I mentioned, right? OFB benefits from five years of data standardization, right? And we're not yet finished, right? There's still a lot of ways to go. We just have to do it above ground for all industry. And do not forget that 70, I think it's about 73% of all emissions globally is actually caused by those energy companies that I mentioned before, right? So they have a vast experience with managing that data not only for subservice as well above ground. And lastly, the open group they have proven they can deliver standardization in IT. They did it with Unix and all major OSes like Android, Mac OS and Unix are a core. Even Windows I hear is turning a corner but I'll leave that up to you, Steve. Yes, let's not go there right now. But it's a great point you make that we're building on something we know works both the approaches that we're taking but also actually building on the OSTU for which ironically, I say ironically, maybe these things aren't just thrown together. That is the subject of next week's Toolkit Tuesday. But I'll save that for then. But we're building on something right but delivered by the energy companies but what you guys are doing in the Open Footprint Forum is really relevant across all industries as far as I can see. Every industry is going to need to do this reporting. Is that not the case? Absolutely correct. And that's why it's all about particularly because of scope three where you have to look into your supply chain, right? Then based on let's say a recipe or a bill of material you somehow have to figure out what is the carbon footprint of the product that I'm making, right? And then you have to sell that product, right? That's the downstream part, right? So it has an impact on all industries, right? And as Paul mentioned in the beginning session, right? There is as well a look into what does it mean for software, right? We is well involved with the Green Software Foundation who've actually developed a software carbon intensity model. So you could calculate based on AI or blockchain or whatever what would be the carbon intensity per, let me call it serving, whatever that serving is, right? Is it per hour? Is it per PC? Is it per blade? Is it per process or per transaction, right? That's possible to do. Great, great. And so far, how would you describe the adoption of industries around this data model? I mean, it's still work in progress, I think is an important point. But how would you describe the adoption levels? Yeah, I think the exciting thing is that first of all the big three hyperscalers are committed. I've mentioned them already. That is AWS, that's Microsoft with Azure and it is Google with Google Cloud Platform, right? And secondly, the big four audit, financial audit companies. I myself, I'm from a non-financial audit company called InterTech. We're heavily involved in ESG assurance. We are collaborating. So last but not least, the largest emitters. I mentioned them before on the planet, right? Responsible for 73% of emissions have committed. So I think that is a great statement for what we've already achieved. And next target is to get independent software developers to develop cool apps on OFP. Right, absolutely. I mean, there are lots of other things to leverage from inside the open group there on the architecture side, on the data model side, there are various things. And so I think I would predict some cooperation and collaboration between individuals in different forums in the open group too on this. But also a point you made early on your slide and I realized until people get these and have the chance to look at them again, they may not have been able to see clearly some of the organizations involved. But we always at the open group are very open to cooperating with other organizations working in the same space. There's enough work to be done without redoing stuff. So you've mentioned a couple of specific alliances and I think that's a key part of moving forward with this group. That's correct, Steve. Great stuff. So one question that I'm sure people you've called to action was we need your help. What could people expect in terms of a time commitment? Because obviously we all have day jobs. You all have day jobs. How much of a commitment is this to participate and make a difference in this way? I think it really depends how much you like to be involved. I'd say a minimum of one hour per week to attend a set of workshops or whatever you want to be close to. I must admit that in between teams and Zoom meetings these days, I look forward to get my hands dirty on some carbon data because there is so much to learn, right? And I'll leave it at that. Back to you, Steve. Yeah, I appreciate it. AJ, we'll leave it there in the interest of time. Thank you very much for your summary. And I will see you. It gives me a chance to give a shameless plug for the Open Group Summit event in London, April 17th to the 20th at the QE2 Centre in Westminster. And the Open Footprint Forum will be meeting there along with many of the other forums of the Open Group. So I look forward to seeing you there, AJ. And thank you for all you do. Thank you. OK. So that's it for today's topic. But we have another one next week. Some of you will know we're on a weekly cadence right now leading up to that, the summit I just mentioned in London. And next week's topic will be on the OSDU, the Open Group OSDU Forum data platform. AJ mentioned that that's been, a lot of that work has been leveraged by the Open Footprint Forum. But the OSDU Forum has really been an incredibly successful, highly active and participatory group that's been going in the Open Group for some time. And they are really changing the way things are happening in the, currently in the subsurface world of the oil and gas industry. But now looking to how that can be used, all their work can be used and repurposed towards new energy as well. So I'm looking forward to hearing about that. I'll be joined by my colleague Dennis Stevens, who's the Program Director for the OSDU Forum. So that's same time, same place next week. And I do hope you can join us for that. It's a great story we have there. And in the meantime, thank you for joining us today and keep safe and well wherever you are in the world. I'm Steve Nunn. Thank you for watching Toolkit Tuesday.


Hello and welcome to this session. In this session we will discuss a question which says that 8 pounds of butter cost 1.92 dollars. Peter got 9.60 dollars worth of butter. How many pounds did Peter buy? Now before starting the solution of this question, we should know our result. And that is, a unit rate compares a quantity to one unit of the other quantity for example times odd beat. Now we divide both numerator and denominator by 3 and we search this equal to 75 beats per minute. Now this result will work out as a key idea for solving out the given question. Now let us start with the solution of the given question. Now it is given in the question that 8 pounds of butter 1.92 dollars is the cost of butter per pound. Now as cost of 8 pounds of butter is 1.92 dollars upon 8 pounds. Now let us start into the key idea which we had discussed earlier which is equal to 2 can be written as 1.92 upon 100. This butter equal to 1.92 upon 8 into 100. Now we know that 8 into 24 is 1.92 so this is equal to 24 upon 100 which is equal to 0.24 butter to 4 dollars. Now suppose Peter purchased x pounds of butter now we know that cost of 1 pound of butter is 0.24 dollars so the cost of butter 0.24 dollars into also given that 9.60 dollars of butter which means the total cost of x pounds of butter is equal to 9.60 dollars therefore 0.23 dollars equal to 9.60 dollars. 9.60 upon 0.960 upon 100 now 0.24 upon now 100 is cancelled with 100 so this implies x is equal to 960 upon 24 is equal to hope you all have enjoyed the session.


Ie ddweud o'i gyddon am fawr, cynyddiol yn cyd-dweud i'r ffagliau ar y cyfryd y ffiliadau ar y gyfan y ffiliadau ar gyfer rydych yn ei wrth. Gweld y byd erbyn... ...awtodd o'r Llywodraeth i'r gyffredinol ei gael, ac yna'r Llywodraeth ei gael ar y mynd... ...gweld bwyd i'n amser tydd yn ychydig yn du olyg mewn ychydig yma. Mae'r brydau'r cyffredinol yn gallu yw broadcast, mae'r ymarfer yn cynnig yr ymarfer ar agor, mae'r dweud yn gyda'r cyfrifiad o yn dweud o bydderu yn gynllenio. Dysgrifon Gwylwedd, yn gweithio ar y yrhyw, plau'r cyfrifiad yn ddod o'r cyfrifiad yn y cyfrifiad o'r cyfrifiad yn gweithio ar yr hyn, mawn i'n frefgfaeth y cwrs pan mae'r cyfrifiad yn cael ei gwyfod trafnol. Bydd yn defnyddio allan i gyfrifiad, a fofyn iawn o'u cyfrifiad o'r cyfrifiad, dweud o地 o flynyddiad ar eich chiarfeydd. please switch off or silent any other devices. Please use a headset when speaking and hold a microphone close to your mouth and when you are invited to address the meeting, please make sure your microphone is switched on. When you've finished addressing the meeting, please turn your microphone off immediately Speak slowly and clearly and do not talk over or interrupt anyone. Thank you for attending this extraordinary meeting of the Committee to review the Ie, ymethai'r gwahanol y llinig yn ymwneud. Y gweithio dros southwyr rydyn ni o'r gweithio ar gyfer y cangwyd, os ymarfer cyffredin. Mae'n mynd i ni weld yn y cyffredin, Cymru? Mae'n mynd i wedi'u gyrthwyniad ar gyfer y cyffredin, fel ar gyfer y nursefodol yma o'r cyfru sy'n sicrhau hynny. Mae'n ei gyrddio i fynd i'i gyrddwniad ar dyfodol. Mae'n yn ymwneud. Thank you. The minutes of the previous meeting we will defer until the next full schedule meeting on 23 March unless anyone strenuously objects. So item four, the substantive item for this meeting is completion of accounts for 2019-20. Could I please ask Mr Maddick, chief public officer, to please present this report which was provided in a supplementary pack and the accounts. Thank you. Thank you, chair. So the audit has been progressing and we think we've now finally got to the end of everything. It was going right to the 11th hour so I have to apologise that we have a further change to the accounts that we've published with the agenda. But what I'll do is I'll go through the change that was published, i.e. the change between the original draft set that was approved back in September, I think, and the set that was presented. And then I'll go on to the further change that I have to report and we've agreed this final change with the auditors yesterday. So you'll see Appendix B, there's a balance sheet comparison and that there, the major change there relates to property, plant and equipment and that change has the effect of, well, that change has the effect of a 570,000 reduction in the values shown compared to the original draft accounts back in September. So it's quite difficult to flip from one document to the other, but if you look at the accounts at Appendix A, you'll see that the figure is shown on the balance sheet. Apologies for interruption. Peter, would you be able to guide us by way of the page number in the... So page, yes, so the balance sheet is page 18. Is that the little numbers or the big numbers? So the number I'm referring to is the top line on page 18. We're showing a figure now of 549195 and that's changed by 570,000 since the draft accounts were published back in September. And that was as a result of the work that the auditors carried out. So we made that change as a result of the work that carried out on the accounts. Is there any questions on that particular point? So... Sorry, can you... Is it possible just to give any further detail? I'll just remind the committee what the nature of that adjustment is. I may have to turn to one of my colleagues because I can't... I mean, I appreciate this. I mean, it's less than, you know, it's 0.1% of the value of the fixed app at the PPE, so it's not a major issue. I think it was to do with a couple of beacon properties that weren't valued when the value did his report. I don't know whether one of my colleagues online can provide a bit more detail. James or Sunjif? It's James here. I think Sunjif would be better able to assist with that one since he went through the adjustment with Tracy Flagg. Hello. Hello, it's Sunjif here. The adjustment relates to some beacon properties which were transferred from assets under construction, and they were missed in the final valuation when they were done. So the adjustment was to do with the valuation of those beacons. So there was a drop in value when they were transferred from the assets under construction into the final council dwellings account. Continue with any other changes you want to highlight? So that's the only substantive change. There are a number of disclosure changes when the change things dramatically, so I wasn't proposing to go through that. So if we now go on to the further change, so there's an additional paper here. So there's additional paper here, and this is the core statements to the accounts when we updated figures. So within the draft accounts, there was an item showing as a provision in relation to the Nall Stoke project. The provision was shown within the CIS as part of the cost of services, and that was in relation to the Housing General Fund. So what in discussions with the auditors we've reached the conclusion that it doesn't actually meet the full definition of a provision. So in agreement with the auditors, we've changed the classification of that. So the effect of that, and the amount we're talking about is 2.386 million. So the effect of that is to increase the surplus on the comprehensive income and expenditure statement to 48.577 million, and that's on the original version that would have been 2.386 million. Thank you. I wonder perhaps that Mr Russell from Ernst and Young, do you have a comment? I'll come to you in a moment, Councillor Williams. Are you now satisfied that this item is being treated appropriately? I'm aware it's been under discussion for some time, so perhaps a quick update from you just on this final change. Yes, thank you, Chair. So yes, we've agreed with Peter that that should be adjusted to remove it as a provision from the financial statements. So the reason why it was, I guess, raised in the first place was because the 2.3 million was the council's funding gap between the amount they'd have to spend for Section 106 related responsibilities versus the funding that we're going to receive. So that doesn't constitute a provision. That's obviously a funding gap. So quite rightly, the council have now moved that out of provisions and created an earmarked reserve to reflect the difference in funding that they're going to get. So obviously, when that becomes realised and the expenditure is made, then the gap will be funded out of the earmarked reserve that Peter and his team have now created. So we're happy with the position of the accounts. Thank you. Councillor Williams, you wanted to come in. Thank you. So what's just been discussed to be clear to the public is absolutely no cash consequence at all. It's simply where it appears. I think it can be argued both ways. I think it's a pedantic citing of where one person says, I think equally it could be the other way around as well. So I do hope we've not been charged too much for this. But on a procedural basis, Chair, this paper that's in front of us that we've got this three sheet isn't as a supplement on the website. Can we have your assurances that if we were to proceed and go ahead and go, this will be put as a supplement on there for transparency purposes. So people know what we're discussing. I think it's very important we make that very clear. And then if we can please sign these off, I'd be happy to move that chair. Thank you, Councillor Williams. Yes, I'm sure we'll have the supplementary and then perhaps also the final status accounts. I've just checked for my own sanity that indeed the overall effect on the general fund balance is at full zero as you'd expect because it's, as you say, can move to an earmark reserve instead. So page 16 of the published agenda shows the surplus being 46191 and it's now 48577. But then when you get to the movement in reserve statement, it reverses out that difference because you're transferring the amount into the earmark reserve. So the effect on the general fund balance is nil. And then when you go to the balance sheet itself, which is page 18 on the agenda and the third page on the additional piece, you'll see that the balance sheet total has changed both at the top and the bottom half of the balance sheet by that 2.386 million. So the overall effect of the changes are to remove it from the line provisions, which relates to note 19, and to put it into usable reserves on the bottom half of the balance sheet and you see those totals have moved by 2.386 million. So we're basically moving the item from the top half of the balance sheet into the bottom half. Thank you. Are there any further questions from members of the committee, either on this final change or indeed on the rest of the papers that were provided for this meeting? Thank you. Councillor Williams has suggested we move to approve these statements and I'm happy to second that. Are there any objections to me approving these as the final audited accounts for 1920? Fantastic. I will sign all the bits of paper after the meeting as required and we'll make sure that everything is put online for the public in as clear a manner as possible. I think we don't even have a final item for this meeting is the date of the next meeting, which is our regularly scheduled meeting on Thursday, the 23rd of March at 10 o'clock in the morning.


The Tokyo Olympics officials' organizers have reported 12 coronavirus cases linked to the event. The organizing committee said in their Thursday update that two athletes staying in the Olympics village were among those who tested positive. Neither are however Japanese. Organizers said two more people from the Olympic village affected, but they are not athletes. And all four must now go into quarantine. The latest numbers bring the total positive test since July to 87.


Hey everyone, welcome back to the cubes on the ground coverage of pager duty summit 22. I'm your host Lisa Martin I'm very excited to be joined by a manjula tolerasia the SVP and chief customer officer at pager duty Welcome to the program. Thank you. Lisa. It's great to have chatted with you this morning as well Isn't it I have had the great fortune of watching her fireside chat that manjula did With is it log logic monitor? Yes. That was your of logic. Yes, and I thought she's got great energy We're gonna have a great conversation. Thank you. Let's talk about the customer experience these days One of the things I think that's been in very very short supply in the pandemic is patience I know it's been in short supply with me and of course in our consumer lives in our business lives The customer experience though has been something that every company Needs to really pin their businesses on because if it's not a good customer experience That customer goes right to social media. They churn They they leave but they they take others down with them talk to me about how the customer experience fits into This year's summit, especially for this we have to be ready for everything in a digital world environment I love this question and a reason I love this question is I even look at my own behavior. But before we get into that, let's talk about data I'm just reading an article Mackenzie did a survey. Did you know that from pre-covid to today Customer interactions that have moved to digital are from 41 percent to 65 percent. That's exponential. It is that's huge And guess what we've all got impatient. We become like our kids And I think about myself as an individual If I need Tied right now to do my laundry. I need it right now So if I go to a Costco website to order it so that it can get delivered in the next hour And if even if there's a second glitch on it, I'll swap over to amazon or I'll swap over to target That's what's happening in real world. Whether it's b2c or it's b2b And why is it important to the points we are making in terms of ready for anything in the world of digital everything It's important because customers are impatient It's a digital world. I don't walk into the store to do any interactions anymore and The reality of all of this is it's grounded on trust Customers have to trust you And the wind of choice Not only in the b2b, but a lot in the enterprise and the b2b world It's about trust right and what does pager duty do Pager duty is at the heart of this Pager duty is at the heart of making every second matter and Every second is equal to money Absolutely, and it's about customer experience and it isn't about Just the experience for of an employee Who may not sleep at night because they got a disruption due to an incident Which is also super important during the mass resignation, right? But it is also about the ceo agenda and the boardroom because how are ceos driving customer trust in order to keep customers And drive this new era of digital everything as digital transformation is occurring Well, I know pager duty is doing that. I had the chance to watch ceo jennifer tahara's uh As fireside chat her keynote and then her fireside chat with the ceo of docu sign and and you the story was very bi-directional very symbiotic in terms of the trust that pager duty has in docu sign and docu sign has in pager duty But talk to me as the chief customer officer What is it that's unique about how pager duty works with its customers 21 000 plus now to build and maintain that trust Especially in such volatile times You know what is really cool? I joined pager duty a little less than two years ago in the next few days It'll be two years And what do I find exciting as a chief customer officer and the go-to-market teams? Differentiation versus other customers We are a born sass company And what do we have access to form our customers? We have access to their operations data And that combination Of our core values that is championing the customer and the data science that we have About how customers are using our data Is our differentiation? That's the magic So if you think about why pager duty is bringing this level of trust to the customers It's because we know How many and let's take an example Employee retention mass resignation We know which employee was called how many times at night during an outage Can we give that guidance to managers and leaders? In order to drive that trust Absolutely And on the other hand we are driving amazing return on investment at the executive levels For the customer experience that they are driving So pager duty is becoming the trusted advisor all the way from practitioners Where we are improving their work-life balance to the executive levels Improving work-life balance is so critical There was a stat that Sean Scott shared this morning that that was looking at The amount of work volume from 2020 compared to 2021 and 42 of people said I am working more hours I don't think I've ever heard anyone say can I work more? Please No, that work-life balance is critical, but the also the ability to Deliver that seamless digital customer experience that we all expect And and to get it right the first time is critical But using that customer data as you're saying Empowering the organizations not just the customer support folks or the sres or the devops folks But all the way up to the c-suite to ensure that their brand reputation is Valuable it's maintained and that trust is really bi-directional. That's the secret sauce You're absolutely right You know, there's a different dimension to this as well. We think about how are we using customer data? In order to achieve the results we want Three vectors here number one is we'll use customer data To really understand what is best in class on uptime? What is the best in class to reduce noise during alerts? What is best in best in class for customer service operations? And because we have customer data we can benchmark we can benchmark What industry what's happening in the financial services industry? What's happening in the technology industry? What's happening in the retail industry? Our customers love that so we will share with them The customer success organization Especially the customer success managers will go in and meet with the customers and say This is where you stand in reference to your peers And customers love hearing that. Yeah, this is the differentiated value proposition, right? The second thing that our customer success managers do is share with the customers This is where you are in reference to your peers in your vertical other vertical But let me tell you how you can improve your deployment the performance of our technology And your role operating model as a result of the data we've got There's the proactiveness That's another differentiator of what I was hearing today from pager duty that you're enabling those csm's to be proactive when so Often many are reactive and it's the customer that's found the problem first. Yes I'll even talk more about the reactive to proactive We build a methodology and i'm sure sean scott covered it as well Which is our maturity curve? Moving from reactive to proactive because so many of our customers are saying We are reacting when we have a disruption on our digital platform but 30 of the times we are hearing from customers before we are hearing from ourselves So how do we become proactive and how does our data science? Actually start showing the signs when a potential disruption could occur And that is about moving reactive to overall proactive I'd also like to add one more dimension to this You know when customers are doing really well They're optimized on our platform they don't want to hear from our Post-sales organization all the time They want a human touch when they need it They want a digital touch when they need it By using our data and our data science. We are becoming one of the best world-class customer success organizations in the world and you ask why The reason is Because we are using data science in order to build and we have built the early warning system The early warning system tells us how every single of our customers Is doing in terms of both Their growth as well as the risk that they may leave us So if a customer is very healthy on a scale of 1 200 if we have a healthy customer We will engage with them potentially just digitally And engage with them with our services our customer success team and our entire post sales organization When there is an optimization and when they really need us So data science is being used not only in terms of Giving customer the right information to grow them, but how we interact with them as well That's brilliant. And there's so many organizations that I talked to across industries that cannot get that right And so customers are being contacted too frequently They may have said I opted out. I don't want and then suddenly that that the first responders the incident responders is marketing But that happens so frequently. You think but there's an opportunity there It's not rocket science, but it's about leveraging that data in an optimal smart way But you guys are light years ahead of a lot of other companies that haven't figured that out No, we are leading edge And we're leading edge because we are a born sass company And we've got effective operations data of the customer And we have some of the best data scientists and the analysts within my organization Looking at this engaging with the customer and only optimizing The magic is data science and humans coming together to engage with customers and drive customer success for the customer And ultimately building their customer experience for their customers Let's talk about some of the numbers manually because they're really impressive I was looking at some stats your pager duties renewal rates are over 95 percent. Your growth is incredible Just coming off the biggest quarter ever But also the gross annual benefit from customers talk to me about that alone. That can be up to 10 million us dollars these We these tangible business outcomes that pager duty is delivering to customers are significant And again, it's based on data science. This is not making you know, what traditional companies do Traditional companies will go to the customer and say tell me your business imperatives Tell me your um, what are the business problems you're solving Are because we have the data science. We have ROI ranging from 300 to 900 percent Very impressive within a couple of months We think about it if we are able to drive incidents that are Very very significant. And I know you've got the numbers in terms of growing our reducing the workload on very expensive engineering Individuals within the organization From I believe 30 to 125,000 and I know you have those numbers Think about If 30 percent of your organization focuses just on innovation and product development Versus on an incident And they work life balance their quality of life Increases the retention of the employees and yet the company is only driving their growth. That is why Our customers love us. That is why our renewal rates are greater than 95 percent That's why our net retention scores are greater than 120 20 percent over five quarters And that is why we have More than 30 growth year over year quarter over quarter when I saw that stat manjul about, you know, the number of incidents reduced That translates to employee productivity and and looking at it in terms of fte from a quantity perspective That's the first time I've seen a company and I interview a lot of companies Actually put it in that perspective and I thought that is Huge that's how organizations should be talking about that rather than reducing fte's or going we were victims of the great resignation It's look at the impact that can be made here by using data science By using the right mix of human and automation together It's that's the first time so congratulations to you and pager duty. That's the first time I've seen that And I think everybody needs to be working to be able to explain it that way especially The fact that we're still in a volatile environment. Absolutely. It's about customer experience But it is just as much employee experience. There is so much That the industry is talking about that's top of mind for board levels. That's top of mind from CEOs How do I retain my employees and drive greater operational efficiency? And now with the macroeconomic challenges that are occurring in terms of inflation And in and the cost to serve and increasing the profits Our customers are making operational efficiency is becoming even more important so that the employees are focusing more on innovation rather than downtime or disruptions and It's actually about growing the business rather than just running the business And if we can optimize running the business Growth is what our customers are looking for right? I always think and we're almost out of time here But I always think the employee experience and the customer experience are like this And they should be but it's critical to optimize both How do you when you talk to some of those big enterprise customers? We had docusign on the main stage this morning But I was looking at the website and three that jumped out to me that I used peloton sales force and slack How do you advise them you have this wealth this gold of information on customers? This is how you need to leverage it In the right way to grow your business. What are some of the the top three things you recommend those customers do for example That so let me talk about a couple of customers as an example There are some customers of ours in the retail business Or it is a telecommunication company that is trying to increase their Uptime from 98.7 percent to three nines as an example Or a tech company that doesn't even know that they were down for six hours in one small part of their business And we're trying to figure out how do we solve for that as customers are overall complaining So for us as a organization the magic is again bringing data together Employee engagement And what we do is we use the data to engage with the customers to ultimately understand. What is their business value proposition? It's you don't do it in isolation You do it in what is the customer trying to achieve? Are they trying to achieve? The best in class Website are they trying to achieve increase operational efficiency? What are their metrics? What are their numbers and we take our data? Our people to marry all of that together and that's the magic I love it. I wish we had more time Angela. We are out of time But talking about the the value of the customer experience The impact that is possible to be made leveraging technologies like page or duty It's it's revolutionizing operations. It's revolutionizing customers 21 000 plus 1 million plus users at a time It's awesome. You have to come back so we can talk more because I can know we're just scratching the surface here Yes, we are this is a very very exciting area right now And it is a great opportunities for chief customer officers on really rallying the whole company on championing the customers Because whether it's our products our capabilities It's really a major transformation happening in the in the industry and we need to stay very close to it Absolutely. Thank you so much. Manjula for joining me today. It's been such a pleasure talking to you. I look forward to seeing you again Real pleasure Lisa to get to know you and the conversation was awesome. Good. Thank you for Manjula. Teller Asia I'm Lisa Martin. You're watching the cubes on the ground coverage of pager duty summit 22 from san francisco Thanks for watching and bye for now


Yeah, well the fans are filing in as they come alone as the day goes on some of them though Would have missed a great performance from the under 17 Jaffron girls champion a Dorae Smith Scott rather 52.53 the new mark new record Dorae Congratulations to you. Thank you so much. You're able to snatch back the metal that you lost just a year ago at home How do you feel about achieving that feat? I feel fantastic, and I want to thank God for allowing me to Achieve in one of my biggest goals. We didn't know coming into this event that you were one who could potentially break the record But you went way beyond that Were you achieving to go past the 50 meter mark? Yes, sir. I actually wanted to do 55, but you know I came a little short, but I'm still grateful Yeah, and yeah, this is a teammate that you played that you you you compete against Regularity you were cheering for her every step of the way come out strong. We're talking about Just tell me what it's like competing against her. Is she your biggest push?  What is a one-two mean for Bahamas? I'm sure it means a lot because You know, yeah, it means a lot.  Thank you back to you Ricardo and Terry


Oh my lordy lord. I've just done the absolute worst thing you could ever imagine as far as being a youtuber. I have just clicked stream. I've just clicked stream as opposed to record on my OBS video streaming slash recording software. What I've done is I've just streamed the last half an hour of my antics to youtube. That means I've gotten through 2 or 3 different videos having... jeez I could have done anything. I really don't know what I've done. I've changed the video to private thank god. Hopefully I can download it and I can cut it up and use it as these videos. For those of you who have been watching, well done. You've seen me behind the scenes and that was certainly not the way I wanted to do things. But it's the way we've got to this point. We've got 2 more videos left. There are just 2 players to go. I am thrown off by that event I must admit. I'm very thrown off actually. What do you do? What do you do when people have scenes behind the scenes? It's almost as if someone's had a camera in my bathroom. That's how I feel right now.  You've got to make the video private and just crack on. So here we go guys. Number 52 on the list. Matthew Judeon. Linebacker for the Patriots. The first inkling of how he's played this year will come from his quarterback on the offensive side of the ball. I must admit. But, cool, calm and collected. Decent hairstyle. Decent rookie season. Mac Jones. Respect. Let's see what he has to say. What do you think made him great? His red sleeves. Judeon just goes right around that right tackle. Disjoys him. Well, when you can't have a hairstyle to stand out, there's only one way to do it, right? With your sleeves. He really is. I ain't seen someone wear red sleeves. I'm not going to lie. He can cover running backs out of the backfield. There's only a couple of teams that he probably could get away with that with, right? We pass Rush. He could defend the run. Being with a guy like Bill Belichick. They run a versatile system. Jude. And it allows guys like him to really show who they are. Judeon catching him. Judeon sucking him. Let's be honest. Speaking of linebacker, he's going to be what? 110, 115 kg. He's going to be what? 6 foot to 6 foot 3. He's going to have a 40 yard dash of under 4.6 seconds from what we've seen thus far.  And that's what linebackers are. Good job on a pass, Rush. Jude, good job on a pass, Rush, man. Good pass, Rush. That's it. That's the way to rock him. You know what I'd love to see? If he could just rock Bill Belichick just once. Just once. Just once. Just rock him. Rock him and sock him. Versatile. We joke around that he wants to play tight end, but we have good tight ends already, so I think we'll pass on that. Man, that was all Judeon. I'll take that one. You look like a... Tell you what, Mac Jones sounds as if he's been smoking cigars all year. I'm not going to lie. It's got to be Matthew Judeon. It has to be him. It has to be. I don't mind the first pick, the second pick. Guess who? Matt Judeon. He just ran both guys over. Guys at least. There's only one thing Patriots Nation might love more than Tom Brady. Matthew Judeon's sock celebration. What is it, Mac? I remember our first couple of practices. He was back there making plays, you know, just having fun with it. So I think that's something that I've taken from him is just enjoy the game and do what you're supposed to do, but also have fun. Tell you what, tell you what, Mac Jones coming into the league has only been in there one year.  Look at him. He really, I mean... What, you're going to try and say anything against him? You can't! You can't! Everyone's getting in on him. But a sock celebration is only cool if you get to do it a lot. I don't think they had a guy like that since Chandler Jones, maybe. They definitely got a gym to him. What is the celebration? What is it about?  It's like just, just, just... Is that what we're talking about here? One of the best background soundtracks of the series thus far, I must admit. What is that, though? We're going to have to look into that. In fact, we're going to look into that right now. We've got 20 seconds left to go. Matthew Judon celebration. All right, what do we got? I'm going to have to take this off.  We've got some light in the house. Matthew Judon is 30 years of age, August 15, 1992. Six foot three, 280. Mate, that's 60. 261 pounds. Grand Valley State from 2010 to 2014. That means he was there for five years. He must have sat out the first year. Got picked up in the fifth round of the 2016 draft with pick number 146 to the Baltimore Ravens. Stayed there for five years. He's been at the Patriots since 2021. He's a three-time pro bowler, 19, 20, and 21. Run to 4, 7, 3, 40-yard dash at six foot three and 125 kilograms. That's scary. 35 inches on the vertical jump, nine foot one on the broad jump, 30 reps on the bench. Here's a strong mofo. What do we got? Six seasons in the league, 93 total games. 296 combined tackles. 47 sacks including 12 and a half last year. That's not on the top five, but I would say that's going to be pretty damn close for the top 10. And look, the list goes on. 11 passes deflected for 95 yards total.  He's been in the league for six years. He lands himself at number 52 on the list of the top 100 players of 2022. His fellow players are finally giving him the time of day. And so am I. Worth all the money you paid him. This guy's been great since day one. Damn, man. Drilling me. I thought you got me right there early.  And what are you doing? Shit, sir. I've got that all game. Way to go, man. Thank you. Great play. Keep it up. You too, man. Go. Keep it up. Oh, bro. I tell you what. Every time I see Tom Brady on this list, it gives me goosebumps. I've had goosebumps six times, and five of them have been because I've seen Tom Brady. Anyways, guys, thanks for watching, and I'll see you in the next one. No time to lose. We've got one video to go. Fuckin' A. Let's do it. Alvin Kamara running back for the Saints. Don't mind a running back. Alvin Kamara, I think, was like top five in 2017. He's just slowly but surely made his way down the list. He's in the top 100 still. And with that in mind, let's get into it. See you in the next video, guys. Peace.


Here he comes, here he comes, here he comes, here he comes, here he comes, here he comes, here he comes. Big crappy. I missed him, I missed him, I missed him, he had it. He's coming back. Got him, got him, got him, got him. Oh, what an awesome hit. Dude, another staving crappy. Oh ho ho, yes! Another giant crappy. Yeah. Look at these things. Bigger than my hand, bigger than the fry pan. Golly, they're pretty too. Wow, wow, golden, perfect yellow and little blue tint to them.