So, this is my talk called how the NPM CLI team manages almost 100 open source projects. And I think what I've submitted to the CFP, we had about 94.  So we're now in like the 80s, I think, which is really exciting. I love to give stuff away. Give projects away. But a little bit about myself first. My name's Luke. Luke Carries. I live in Arizona on the NPM team. Not sure if you can see it on the projector. That's a place I like to go ride my bike from my house. So I live in the desert. It's the opposite of here. There's no green. But you can contact me at any of those places. And the reason I needed so much help getting HDMI connected was this is the last, this would be preparing for my last talk. And then this is me preparing for this talk. So Sandsbeard, you know, only one kid. Now there's multiples. They don't number us. And so I think it's about eight years since my last talk. So feels good to be back up here doing talking about JavaScript. What? I did not talk yesterday about sports betting. I did not. All right. So like I mentioned, I'm on the NPM team. I've primarily spent the last two years as part of this NPM CLI team. So we are responsible for currently, these are all numbers as of this morning, 78 packages that are across 78 repos, about 19,000 stars across those, which is not enough in my opinion. I think there's 70, 70 repos of everyone in here stars all 70 repos. I think we can add a few thousand before the end of the day. Be nice. I have a script you can all run after just a GH star all of NPM. And then all together that is about 4.3 billion monthly registry downloads across our full open source portfolio. So that includes Semver, which hosted get info and a few others, which are the top downloads. And a lot of our download metrics don't even account for registry downloads because the CLI itself bundles all of our dependencies. So there's there's a lot of downloads. And that means we have a lot of users. So these are our responsibilities as engineering team. There's currently between two and four ICs working on the NPM CLI at any given time over the last two years. So between two and four ICs, we have weekly and bi-weekly NPM CLI releases. We're currently in a bi-weekly cadence due to me, you know, being here for a few weeks and a few other staffing changes. All the NPM CLI dependencies and all the releases for those, those happen on an ad hoc basis as needed. But I actually forgot to run the numbers for those, but across all 78 packages, we definitely average at least a few releases a week as part of the CLI releases. And so over the last year, I can't do the math, but it's a lot, a lot of CLI running because of us. And we also are first level support, so we do issue triage and pull request review for community pull requests across all of our repos, as well as community engagement with like the RFC call that we have and open office hours. Those are currently on hold as well due to some staffing changes, but we're switching between office hours and the RFC call. So the RFC call is more structured where we discuss specific RFCs pertaining to NPM and then open office hours is like kind of come and ask us questions, which some of you in the crowd I have recognized, take full advantage of. And then we also do, we have bug bounties that we don't triage ourselves. That's part of the GitHub security team does that, but they get escalated to us and those become priority. We fix those as well. And then this all, we also ensure this all is supported across, works across all supported versions of nodes. So we run integration tests across all supported versions of node, nightly node, as well as top packages in the NPM ecosystem. So we run tests like for, what are some that recently bubbled up with actual bugs, create rewired, I forget what the actual name of the package is, but the create react app has a plugin called rewired, which like rewires your create react app config. And we found a bug in NPM when we were publishing version nine RCs.  And then we also do backports, which is something new. We just started, we figured we did not have enough to do. So now we, we wanted to develop a system so that we could backport any and all of our features to old release lines. Most recently we, I think we backported a security dependency fix to NPM eight. And it's possible there could be more backports, you know, to NPM six as well. I know there's a few people here as well, which would have been asking for those, but we at least have a system now to do backports. Used to be very difficult, if not impossible. So then our other, you know, those all fit under the umbrella of open source, the MPL. I see our main responsibility as open source, like what does that even mean? It's a, it's a big umbrella, but hopefully I plan to go through like how our approach to open source and what we consider kind of our responsibility within open source as well as the node, the node ecosystem in general. So the first thing I want to say is that everything we do is open. This is a, the new GitHub code search, I'm not sure if you can see the query, probably not, but searching for in the GitHub org or in the MPM org is private. And this is me logged in, obviously authenticated to see private repos and nothing comes up for the MPM CLI topic. So we have a big GitHub org that is the registry and the CLI combined. And we put a topic on all of our repos and all of those are currently open source. We have one repo in a different org, which we use to triage, security, private security vulnerabilities. And that is our, our currently our only private repo. So that, that includes our status board is public. Our future roadmap is public. All of that is open source and everything is open. You can sing that to the, the Lego theme song that my kids sing all the time. I couldn't write that without singing it in my head. Everything is open. So the other thing we want to do is open source that scales. I already mentioned the 4.3 billion download a month mark. But that's not really the kind of scale I'm talking about. Like that kind of scale is separate from open source. Like our approach to, we want our approach to open source to scale. Like we don't, we also want our, you know, the end product, the code to scale as well. And, you know, the registry to scale and all of that to scale. But we also want our, what we can do to support open source to scale. So when I joined the team about two years ago, we had a lot of issues around that.  But the repo wasn't archived, stuff like that. A lot of mismatched expectations as far as like what was supported within our open source portfolio. And so we also want to really quickly be able to open source new things that we find helpful and valuable and be able to do stuff like that, publish new packages. We see ourselves as solving a lot of novel problems in the JavaScript ecosystem. So if we have a solution, we want to make sure we can open source it, we want to not just throw it over the wall, style open source. We want to make sure people can use it, we can support it. They can ask questions. We can take people's, we can collaborate on it. Like when we open source something, we absolutely always want to be able to collaborate on it with within the ecosystem because our style of open source is like we're not going to do everything perfectly, but we want to basically not have years long pull requests that are open. We went through Sember, INI, and I believe one other one and got them down to just a core set of pull requests that are still open, meaning like those open pull requests are things we are considering. Everything else has been closed or merged after like years long period of time that they were open. And so like I said, everything is open source. This is our status board, which is also open source. You can see the link in the corner to see the status board that also has on the status board. There's a link to the GitHub repo for it, but you shouldn't be able to read all this, but it's essentially just to show that everything that is open source we want to be able to measure and look at and support. So if something is not on this list, it means we're not necessarily tracking it. If you do find something that's not on this list that you use that is published by us or in our GitHub org, let me know, open an issue on it, tag me in it, and I add the NPM CLI topic to the repo and then that adds it to the status board. It runs once a day, pulls in all sorts of data so that we can see how green we are. I think currently, yes, some people here helped build it and helped have ideas for what we could use it for, because it used to be a lot more red than this. Actually, this amount of green is shockingly good, and this was also taken this morning. I did a bunch of extra screenshots this morning just to make sure all my data was up to date. So the other thing we want to do is, as I mentioned, share this open source. So open source is, by definition, open. We can share it with people, but I really mean collaborate and share it with people. So when we open source a solution, we want other people to use it. So the newest member of the NPM CLI family is NPM agent. I believe we did 1.0.0 in December, and then 1.1 is open right now with a bunch of new features. And this is a new HTTP agent that will be in the CLI that will allow for much more configurable timeouts, and stuff like that that the NPM CLI currently doesn't allow for. There's only one very not granular way to configure timeouts in the CLI currently. So this will help that, but this can also be used by anyone that needs an HTTP agent with configurable timeouts and stuff like that. So we are not just open sourcing stuff just for ourselves. We are the primary user of all of our stuff, but if we use it, we want to make sure that other people can use it, because that means it's easier for us to use it as well across that many repos that we have. Like there's still ones I think that I've probably not committed to yet in two years, and that just means that just goes to show how much stuff we do support. So there's repos of ours that I approach as a new contributor, sometimes even being on the team for two years. So as I mentioned, we want to be able to support all this open source. So it's a big area of responsibility that we have. And as I mentioned, there's a lot of things that can happen when you have a portfolio that big. My probably worst bug was when I published the CLI and manually published the dependencies that are part of it, the workspaces, and just missed the very last one. And since we bundle our dependencies, I didn't see it as a bug like in running my system, but then probably like overnight, we just got a flood of bug reports that you couldn't use Yarn anymore to install that version of NPM because they handle stuff slightly differently, as you might have noticed in Darcy's talk yesterday. And so that was a fun one to figure out why it was breaking in one system and not another. And this was kind of a time when we were like in a transition between automating some of this stuff and not. So I was like, you know, I know exactly how to publish the CLI. Like, let me just publish all these workspaces. And I'm pretty sure I just left one letter off like the very last command that I ran. And it didn't, I didn't look at that all the generated output at the end, just saw that most of them, you know, saw that there was green and that the CLI was working and all of our tests pass. But that was an interesting one. And that approach to open source, I think, doesn't scale. And we can't support that if like we're not running all of our code across a bunch of different systems. And so I consider that like open, if stuff like that is happening, we don't feel confident in, you know, supporting that much open source. So, or we want to deprecate it. We want to support it or we want to deprecate it.   Darcy, what was the other one? Yeah. What? Yeah, yeah, it all got passed by by legal. So this was a case where, you know, I, if you're not familiar with the, you know, the details of the MPM CLI, that's okay. It's not super important, but you know, it makes heavy use of tar balls and tarring and untarring stuff and streaming tar and stuff like that. And we are not the Isaac, the original maintainer. He's the expert in tar. And so we make heavy use of it, but we weren't supporting it to our, the level that we wanted to like people were coming to us with bug reports. And I remember looking at the repo and saying like, you know, someone had a one line fix to make it work and like node 18 and node 18 was just released. And our whole test suite pass, but I wasn't 100% confident that that one line of code, you know, it was just making something wait slightly longer in an async setting. And so I wasn't as a not the subject matter expert in tar. I wasn't super confident in merging that so that bug, that PR set open for a long time and that's not the level of open source support we want. We want people to be able to, you know, have confidence in giving us pull requests that we are going to merge them or close them with good reason, not just let them sit open and say like, I don't feel confident merging this. So we want to give stuff away. You know, we want to make that status board smaller, eventually fit on one one slide. Hopefully, I could not get it to fit on one slide, even like shrinking everything as much as possible as I could in my browser. So this happened again recently with our CI detect module. That package I'm not sure if anyone's familiar with that but it's essentially just looks at a bunch of environment variables and tells you whether or not you're in a CI environment. And so someone opened this and said, hey, can you document like what the maintenance status of this is. And we had actually switched in the CLI to a different better in my opinion, and all of our opinions package do CI detection. Developed by it's in the Watson GitHub or so I'm not sure exactly what company is responsible for it, or what maintainers are responsible for it, but it was just a lot better to us and was keeping track of. By definition, I think CI detection is like something that's constantly moving and constantly changing you have to stay up on pull requests. If you want to be, you know, have the best possible package there and so ours had a bunch of open pull requests. There's had been merging stuff like that. So we just switched to it in the CLI. But what we forgot to do was archive this report deprecate this package. So this person came by the repo and asked the question I responded and said like, you know, yep, this completely fell through the cracks. Sorry about that. We didn't. That's not this is this wasn't part of our process at the time of like if we stopped using something what happens to it is now where it will actually bubble up on status board. If you either deprecate the package or archive the repo and just remind you to do the other one as well, but it's not a. I consider it like really lucky when when people come by and ask us questions like this because the alternative for every one person that asks this question there's I don't know 100 1000 that are looking at the repo and just saying like this is really frustrating. I can't tell if this is used or not if this is maintained I don't want to use this you know how can I figure this out so we want that to be like a binary question of looking at our open source portfolio is like is it maintained. Yes, if it's not you get the big archived GitHub bar at the top of the repo and if you go to the npm package you get the big deprecated up at the top with hopefully a good error message for what to do in this case it tells you to go install the version of CI detect, I believe no ours was called CI detect the new one is called CI info which just tells you to go install CI info instead so I see that as a really positive outcome for our how we support open source giving either giving stuff away or deprecating it. I want I love deprecating I love deleting code getting rid of code so that kind of leads into the next thing of like we want to do open source that inspires confidence across our users. So, yeah, you should immediately be able to tell from our repos whether it's supported or not and the answer should always be yes unless it's very very obvious that it's not. And that also means, I think confidence goes a lot to, we were able to build confidence by making everything look the same if it is supported. So, there's no, there's currently no levels of support it like I mentioned it's a binder we had discussed internally whether we wanted to have like some other level of support which indicated like we aren't accepting pull requests for this we but we are maintaining it we will publish new versions. And we found that was probably just going to be more work for us to like maintain a whole different level of support. As far as like with a small team. So, we just have decided to either deprecate or give something away or like fully support it meaning we're committed to keeping it up to date. Kind of with that whole list I showed at the beginning we're committed to releasing it, fixing security vulnerabilities, keeping it up to date with any latest versions of node. There was a current change in node 20 that changed how the exit code was basically whether it was undefined or I can't remember all the details someone else on the team ended up triaging it but we fixed a bunch of our repo so the test would pass. Once we started testing in node nightly at that point so that was another really positive outcome of like since we support everything and test everything across our full matrix we were able to be like okay this change needs to be made and then let's make it across all of our repos. And so with a large open source portfolio it is inevitable that things will fall through the cracks. It's not possible. It's not probable like it will happen all the things I've described so far like those are just the times I've personally been responsible for things falling through the cracks.   Flaky releases in a row that like have some simple bugs that we're not catching because like we're not fully running CI or we're not confident in our CI. And so that's how do we do that.  Difficult to do in practice. And so I've always wanted to come up with an acronym really badly and have it like become a thing so hopefully next year someone gives a talk about P PAP is what I'm calling it. Feel free to like you know rearrange those letters or come up with better synonyms and tap the taps already a thing. Tap tap. So like I said, I've always wanted to come up with one which is why I probably never have and never will because I'm like really bad at naming things but for the purpose of this talk and the purpose of coming up with terms that I could put on slides. Last minute patterns process automation and tooling are the four umbrellas that I came up with of how we accomplish what we do so far. So, but yeah, just feel free to tweet at me or to that me with with better acronyms. So the first pattern is make everything the same or MPX at the same. We use make for a long time in the CLI. Now we just kind of dog food the CLI with itself and with npm itself to run a lot of our commands to keep everything the same but there was like a lot of as I mentioned before there's still repos that I haven't committed to so there's a lot of power in it's really powerful to like clone a repo you've never been in before and have it feel familiar.  And we don't allow files anywhere else in our repos, unless they've, you know, there's ability to whitelist or have an allow list of stuff. But in general, like there's just one place you're going to look for the entry point to a package or just any any of the source code for a package for that matter. And just the same linting the same formatting, same CI workflows, all the CI workflows in every repo are named the same thing. So if you are running, you know, the same if you want to check the action for something across two different repos, you can use a well known URL, you know, well known GH CLI command if you want to to get the output of those logs for two different repos because everything's named the same. And same with, we've had a lot of success with our change logs these days, which used to be non existent and a lot of repos. Someone gave a talk yesterday about an annoying trend of projects having no change log. And we did that. But now, now we have change logs everywhere and they're named the same thing in the same spot in the repo have the same headers.  And that was easy to do. I didn't need a markdown parse or anything because I know like, you know, we have one hash for the title to for the date, you know, three for the, the number of the release.  So the next time I go clone something like I've been in Sember a lot recently, but they were probably like the first year I didn't do anything in Sember. And then when I first pulled it down for the first time, it was wildly different than any of our other repos. Sember is kind of like the behemoth. It gets around 1 billion of those 4 billion downloads a month. So like a quarter of our downloads are just from Sember. So we take a lot of care with changes we make in that repo. Jordan has dissuaded me from some changes I wanted to make because I didn't realize like that they were breaking changes. And when something is used, downloaded a billion times a month, like everything is a breaking change by the strictest definition we found. And again, we've been lucky enough that users told us that when I accidentally dropped node, an odd number, maybe like node 13 support accidentally out of the engines field and like the next day there were issues open saying this started throwing in CI because it doesn't support node 13 anymore. And I was like, that's an odd version well past end of life anyways, but like, you know, we did a patch that day to, you know, fix it so those users wouldn't have failing CI anymore. So, but that was just another example of when things were different, it made it much more difficult to make those changes. And obviously not everything can be the same because, you know, we need different source code in our libraries we need a bunch of different stuff. And so when we do have differences we try to reduce them or abstract them to the smallest possible surface area so we have configs and a bunch of our packages and repos that will do things like switch it between CGS and ESM. So we, you know, always, we still publish common JS for everything, but we have a few like internal tools or like leaf packages that are just that we can use ESM with because, you know, I think there were some dependencies I wanted to pull in. And it's nice for like CLI tools if you're not expecting someone else to consume it like things that we just publish as like other separate tools. And so we have a config in our packages that can just switch between those two modes and make sure that like your linting files get named correctly your that we lint that your file extensions are correct like that we use MJS for ESM and stuff like that things that are going to be different across projects but you don't have to remember you only have to remember to change that in one place in this project. And if you forget to like you're just going to, you know, all linting and all tests are going to blow up until you just switch that so it's very discoverable that you need to change that config you won't be able to get very far without it. And we are currently have an internal plan to adopt formatting across all repos. One thing that we found difficult is during in reviewing community pull requests, there's like a lot of back and forth about formatting. We don't want anyone to have to worry about that especially when contributing.  It is VS code in the browser, but like maybe they don't have VS code, they're not going to go through a bunch of time to set up extension sync and have like a really robust dev environment there. And so we found people do that and then we'll have to pull down their pull request and update it for them which is work that we're happy to do because we're enabling contributors but there's tooling that can help with that including like prettier and adopting that so like if someone has a line that's too long it just see I will just fix that for them. And we're experimenting with ways that like the pull request can detect whether the red you know if the pull request is in a red state it can detect if it's a linting problem and then you know the GitHub action the robot can fix it for us and push to that pull request without manual and with all with also without dissuading contributors because we've definitely been very guilty of that in the past of leaving contributors on red, I believe as the kids say, where, you know, someone will have a really good change and we're just not able to get to it and it doesn't filter up as high in our notifications because it's a red, you know, CI is red and we're just, you know, you know it's going to be a bunch of work to go in and manually fix someone's pull request, which is, you know, we don't want to close because we do, you know, value that contribution but so far it's been difficult to do those without like these patterns I've been mentioning. So here's an example of Semver where it has different engines and CI versions. So currently we support the late all the LTS versions for 141618 and then anything above 18 so like including 1819 and 20 but Semver supports everything above 10 and that means we want to test in all in a bunch of new stuff as well so this is just a config setting that changes Semver to test and more stuff and provide more node support for more versions because we didn't want to do a breaking change when something's downloaded a billion times a month. Breaking changes are are much more expensive as far as adoption goes like we can look at the download counts for old patch versions and old majors and see that like, you know, there's still hundreds of millions of downloads a month on old majors because you know projects that are being updated so we don't want to do majors for like really expensive majors when when we don't have to. So another thing we wanted to do is make adopting new patterns automatic like I mentioned prettier if we want that to be something across all our repos. That's just a robot wrote like a, you know, prettier itself is just writing all of our files since they're all in the same place. And we're confident of like the standardization across all our repos, we can make that automatic like we don't even have to have any manual step to adopt prettier across all of our repos. So we recently did that with auto publish. So using granular access tokens. We're now auto publishing a bunch of CLI dependencies not the CLI itself yet we consider that one still like, you know, we it's it's good that it's manual. We don't want to accidentally publish the CLI but all of our dependencies. Now, as we update them they get auto publish for free because that was just a GitHub workflow that has like this was the default basically to get added to our template or templating repo. And then it's across all repos that want it and like I mentioned before we abstracted that down to publish true as the config so if you have published true to our templating config the repo gets that because there are still some like Sember also actually no we did do Sember once we felt confident with the approach across a bunch of other repos Sembers now auto publish as well so that was a big deal. And then there are always going to be new patterns that are time intensive to do so we want to make those visible and measurable for our team. So, an example of this is coming up with the standardization approach was like a very time intensive task we had to do it across all of our repos one by one essentially manually because that was work that I don't know chat GBT wasn't up to it at the time. I haven't asked chat GBT for yet to do it for me but I'm still you know I'm still skeptical that it could that could do this if it can then you know maybe I can take a break. Another one we want to do is we haven't had time to support types for all of our packages so we've been steering people towards definitely typed and as great of a community resource as that is we still find that we get bug reports and unhappy users when we we follow Sember so like even if we're publishing something that only we primarily use if we're removing an API or doing something like that we are updating a major version and then types are slow to follow. And then if a users happens to be using that in a project they will you know get the wrong types and and have a poor experience because you know I use VS code daily especially within VS code because it's just giving me a tell intelligence based on those types so we want to start publishing our own types but we are again like a lot of manual work that needs to be validated first so we are approach to that is kind of to add it to our status board as a new column. And so this is a poor crust from last year where I removed the templating column from our status board could we actually finally templated everything which meant we were confident in the node version it was at and a few other things so I got to remove all those columns from our status board because we no longer needed needed to track those things so kind of like as our status board gets more green we're able to drop columns and then add new red columns to force us to do more work. But it's good work and you know it's it's easy to make sure that we're doing it the right way because we'll validate the approach in one project and then make sure it scales and then we'll be able to track it here so it was a really nice approach and you know it's a nice at the end of the stick for like going to this and seeing like one by one year you're making stuff green for a while I would go to it every morning because it's a CI it's a CI job that runs overnight so like I'd go to it in the morning, make sure that there wasn't any new. We also run a bunch of CI overnight to like check for new security vulnerabilities or even that like our tests aren't breaking due to transitive depths. See Darcy's talk for what a transitive depth is. But you know to check to check all those CI runs but then also see like you know teammates were going and doing repos one by one so we get to see you can sort the status board by color so you can say like show me you know sort by red at the top and just see that number go down was like a really good feeling and then dropping those columns was the best feeling because it's like we don't this is not something we need to track anymore we we did it let's you know track something else. And also we want to make make our process. Rotatable. So we have everyone go see our you know everyone takes turns doing all these processes. So you'll never be like blindsided by a brand new process that you've never seen before it's all incremental and you're free to like update the process while you're responsible for it and so you know it's kind of like a fun surprise. But you know it's all documented so the next time for a while like our release process was being overhauled like pretty much every person that worked on it so you'd get a new. A new like new documentation or what to do every time you ran the release but it was all clear because we standardized it so we also want to make all these process changes transparent so we use. GitHub wiki to kind of store playbooks for this stuff and the one thing I want to highlight here is our release process is 222 revisions. And so we keep we keep them in that we like the GitHub wiki for this because like we don't want to force us to review these pull requests they're just things that are. Someone can do but it's it's nice to have this audit log for it essentially. And we also want these processes to be discoverable so as I mentioned this is the our current release process and it opens a pull request for you and gives you checkboxes and each command that you should copy and paste in your to your terminal and run. And this and it auto it replaces anything that's really specific and so you really just copy and paste and as for the question is like why can't a machine do this and like for the ones we auto publish a machine now can do it but we consider the CLI. To big of a target where like we don't want to mess up or like have a process bug that we haven't thought about before like run amok and have you know. Our release process become sentient or something in the CLI releases itself a billion times and eats all of our. CI I don't know it's been a while since I saw Terminator. So the next is automation we want to have automation that we can kind of tweak and configure over time so this is the current list of all of our config automations and hopefully this is. These tools are not prescriptive kind of everything in the first half of the talk like those are the general my general thoughts about open source and like kind of the themes of this and all this is is I mean it's open source I don't know if I mentioned that yet. You can go look at this adopt you know decide to adopt this for your team or not. It's currently very like fork friendly open source which means like you could fork it and use it and we can collaborate on it if you want like there's a thing in the bottom of the repo for our tooling that says like this works for us. If it works for you if it doesn't work for you let us know. I believe I'm pretty much at time but we have one more tool I wanted to show off is our templating tool. And so this is kind of like the path to profit with our templating tool which just means that it updates itself so we use template OSS to tell depend about to watch for updates to template OSS so depend about can apply template OSS updates. That I tried to make a graph for that and I just yeah yeah no it's it's it's a it's a snake eating its tail but in a good way. So this screenshot is our post depend about workflow that template OSS writes to repos and then depend about runs and then the very last line of it you can see it runs template OSS apply so we're in a constant state of getting all of our own updates. So here's one just for a single repo that updated it from 14 to 15 and then here's the rest that need to be merged. So like this is how many pull requested opened again hopefully one day I can fit this on one slide like it keeps going down but I couldn't. And so the last thing I wanted to mention is just a quick plug for making your own tools and having a common set of tools. So we currently have you need node and the GH CLI and that's it to run stuff no one installs them like this but this was like the easiest copy and paste way to install them without being with being as prescriptive as non prescriptive as possible. So every you're free to have your own opinions on how to install these things but as long as you have them you can run our tools. And so we also have staff tools again open source fork friendly feel free to go through the repo see anything you find if interesting. Wes in case there's like people that want to do Holly repo plus monorepo configuration solutions this will be the the place to look. And so this is just a bunch of screenshots of everything you can do with our staff tools that we wrote just as as needed. So this was just kind of ad hoc as needed stuff and these are all the places you can contact me if you have a blue sky invite. Let me know. Thank you so much. No. No time for questions but feel free to grab me in the hall about anything. Oh yeah Darcy had we had two thousand two hundred and three releases over one hundred thirty main maintained project and dependencies for average of twelve point five releases a week. So this was at December. I believe that was for all of twenty twenty two we average twelve twelve and a half releases a week for a year. Yeah we ship so let's collaborate on all this open source. As I said it's either it's all supported if it looks unsupported yell at me like tag me by name in repose please and let's collaborate and open source and we also have we need more people to help us do this now. So if this sounds interesting to you that URL will have some open job postings next week or feel free to come come at me as well. Come at me.


Hello and welcome to the session. This is Professor Farhad in which we would look at the monetary unit sampling specifically the tolerable and the upper statement bound. This topic is covered on the CPA auditing exam and I'm going to show this in a form of a simulation and an auditing course, whether it's a graduate or undergraduate courses. This topic is challenging for many students because they don't like statistics and when you combine statistics with accounting, it turns people off and often students don't learn this in college. And when they get to the CPA exam, they struggle on this topic. So hopefully through this example, I can make it easier for you. But if you want to learn more about this topic, visit my auditing course, auditing and attestation course where you would learn the basics because this is an exercise where you would learn the basics, the explanation of what I will be doing today. Although today I will explain what I'm doing, but if you want more knowledge, please visit my website. As always, please connect with me on LinkedIn. If you haven't done so, YouTube is where you would need to subscribe. I have 1,700 plus accounting, auditing, tax, finance, as well as Excel tutorial. If you like my lectures, please like them, share them, subscribe to the channel, connect with me on Instagram. If they help you, it means they might help other people share the wealth. On my website, farhatlectures.com, this is where you find additional material about my auditing course as well as many accounting finance courses as well as CPA exam preparation. If you're planning to add 10 to 15 points to your CPA exam, check out my website. It's a great supplemental tool. So in the prior session, what we did is, and I'm going to put the prior session in the description because it's very important, we were asked to calculate the sample size for a company that had, there was auditing inventory with a population of 3,140 inventory items. The dollar value was 19,325. The tolerable misstatement was 575,000. The acceptable risk of incorrect acceptance was 10% and no misstatement was expected. So in the prior session, we computed the sample size happens to be 77. Also in the prior session, they said, assume your starting point is 123,608, compute the cumulative dollar amount associated with the first five sample items. And that's what we did in the prior session. How will the auditor determine the physical inventory item associated with each dollar amount? So it's very important that you look at the prior session or you don't have to look at the prior session. As long as you know how to compute the sample size, as long as you know how to know how to select the five items, you're good to go. But if you feel you want more confidence, please look at the prior session. Also, what's important is the 10% acceptance of an incorrect acceptance and no misstatement was expected in the population, as well as the tolerable misstatement because we're going to be using this information now, which is now, is what? Now is assumed that a sample of 100 units was obtained and assume that the following three misstatements were found. So we selected rather than 77, we selected 100, it doesn't matter. So we selected more than what the sample suggested, but the point is we found three misstatements and those are the three misstatements. We had an inventory recorded value of $897.16. When we audited, we find out when we selected this item, we find out the value is 609.16. We had $47 and two pennies of some inventory, but when we find out it doesn't exist, the audited value is zero or the value of it is zero. It might exist, but it really has no value because it's obsolescence. We had another item for 1621.68 and the true value is 1521.68, the audited value. So now what they want us to do is calculate the overstatement bound and draw the conclusion whether the population is acceptable. Basically, we need to know is the population is acceptable as stated. So we need to figure out what's called the upper misstatement bound because we know the tolerable misstatement. We can tolerate 575 and we're going to add to this something called allowance risk. And if that allowance risk, that risk, that additional risk because we're sampling is above a certain number, if above the 575, then we're just, we're not going to go ahead. We're going to say that the population is not fairly stated. So to work this example, it's best to work it in an Excel sheet because we're going to be doing quite a few of computation. So let's go ahead and look at the Excel sheet. Let's take a look at this Excel sheet. And basically we are starting with the information that we have, which is the misstatement as well as the recorded value, those misstatements right here, the recorded value. So the first thing is you want to find the difference between each item and dollar amount as well as percentage. Let's take a look at misstatement number one, the item number one. So let's take a look at it. The first misstatement, we had the recorded value of 897. The orated value was 609. The factual misstatement, the difference was 288. Therefore we overstated the value by 288. Now we find the percentage. The percentage is 0.32, which is we overstated this amount by 32%. Then we have misstatement two, which was $47. The orated value was zero. Simply put, we overstated by 47 and the error is 100% or one. And we have the third misstatement. You guys get the point. So first we find the dollar difference, which is the factual misstatement. Then we express this in a percentage. So this is the tainting percentage. Now what's going to happen is we're going to take those tainting percentage and we have to project them. Because remember, what we did is sampling. Sampling means we did not look at everything. We did not look at everything. Now, before we even start the sampling process, we know that the confidence factor. Now if you don't know what the confidence factor is, please look at the prior session. The confidence factor for this exercise is 2.31. Now how did we come up with this confidence factor? I'm going to tell you how we came up with it. We assumed 10% the risk of incorrect acceptance and we assumed to expect zero misstatement. So this is how we came up with 2.31. Let me show you here. So we said the risk of incorrect acceptance is 10% and we expected no misstatement. Therefore, the confidence factor was 2.31. So this was computed in the prior session. Therefore, what we say is even if we don't find any misstatement, we expect to have issues with projected misstatement of 446,407. So even if we did not find any misstatement, we take the sampling interval, which we computed earlier, 193,250. This was called the sampling interval and we multiply this by 2.31. So let's assume we did not find any of this. Let's assume this did not exist. We would still say we could be wrong up to 446,407 because we sampled, but that's not true. We found 3 errors, 1, 2, 3. Now we're going to take those errors and project them and add a sampling factor, then add the 446,407. So how do we compute this tainting misstatement? Here's what's going to happen. The first thing is we're going to take those 3 tainting misstatement and we're going to organize them from the highest to the lowest. Simply put, from the highest to the lowest would look something like this. Basically what we do is we say 1, 2, 3. The first, the largest one obviously is number 2. Now it becomes number 1. The second one is 32%. The third one is 0.06. Now we already computed the sampling interval. We put the sampling interval in 133,250. Now we have to project. Project means take the sampling interval and project this tainting percentage because we find a problem and the problem is 100%. So simply put here's what's going to happen. We're going to take the sampling interval times 1 to project it to the population 100. The projected error is 193,250 and we'll do the same thing for the other 2 errors. We have to project it. Simply put, taken the sampling interval multiplied by a tainting percentage. But we don't stop there. If we added those 3, it means we have 267 and $63.25. But when we started our problem and the problem we said that we expect to find zero misstatement and the original problem says we expect to find zero misstatement. We find 1, 2, 3 because when we started our confidence interval, we expect zero misstatement right here. But that's not true. We have 1, 2, 3 misstatement. Now here's what's going to happen. We're going to take our errors, our projected misstatement and even add an incremental change in the confidence factor because our confidence factor simply was incorrect. We thought it's 2.31 when initially we thought 2.31 because we assumed zero misstatement. We were pretty confident that their inventory is good. Now we find out 3 mistakes. We have to change our computation. And for each error, we have to find the incremental change. Incremental changes. What's the difference between 2.31 and the next level of finding one mistake 3.89? So let's look at this. Let me pull a calculator. It's better if I pull a calculator so you can see the computation. Now I'm going to take 3.89 minus 2.31 and the increase 1.58. Now I'll do the same thing between the first and the second error because remember I found 3 errors. Therefore I have to keep on going. Now I find the difference between 2 and 1 which is 5.33 confidence factor minus 3.89. I have to increase, I have to multiply my projection by 1.44. And I'll do the same thing for the third error 6.69 minus 5.33. So simply put overall my confidence is 6.6 should have been 6.69. So I needed to increase my sample but I am adjusted for that. So I'm adjusting for that 6.69 minus 5.33 and that's 1.36. So I'm going to take those incremental increases in my confidence factor and multiply them by my projected misstatement. So there we go. So you know where these numbers are coming from now. 1.58, 1.44, 1.36. Those are the incremental, the increases because I found more than one mistake. Now what I do is I project, I compute my projected misstatement plus the allowance that I'm sampling. There's a risk. If you're sampling, there's a risk. If you found one mistake, it doesn't mean that's the only mistake. It's an indication that you might have more mistakes. So you have to find the incremental allowance risk. Therefore I'm going to take my projected misstatement times the incremental factor and that's going to be 3.05, 3.35 and I'll do the same thing for the other two mistakes. I take the projected misstatement, which is I take the projected misstatement times the incremental factor. Now I can add them all up. Then I have to add to them, I have to add to them my precision, which was my original estimation is, even if I don't find anything, I'm going to assume I have 446,407 because I'm sampling, but now I find out there's a problem. I have to add my projected misstatement plus the incremental. Therefore I add those two and when I add those two, I come up with 857,000. This is the upper misstatement bound. So this is the upper misstatement bound. Based on the upper misstatement bound, I can make a decision. What is my decision? Remember in my original problem, I said I can tolerate up to 575,000 of misstatement. Well what I find out is this. After I did all my computation, my upper misstatement bound is something in the 857,000, which is above 575. What do I do? I reject. I don't accept that the balance is fairly stated. Simply put, based on this calculation, the population is not acceptable. Why? Because the upper misstatement bound exceed the tolerable misstatement. So 857,118 is greater than 575, which is my tolerable misstatement. I don't accept this population. I need to do more work. I don't accept their balance. Otherwise I could have lived if this amount was lower than 575. So this is basically how this works. You could see this in a form of a simulation. You could see this in a form of multiple choice or many form of multiple choice. You just, I mean, if I'm testing you about this, I can ask you 15 to 20 different multiple choice questions on the data like this, or I can, this is an actual simulation, or this could be an actual simulation where you have to select things and input things in an Excel sheet. If you have any questions, by all means, let me know. As always, I would like to invite you to visit my website where I do what? I teach you the material. I don't, I don't review it with you. My job, when I teach, I teach to, to college students and college students, they need to learn the material. So I suggest you check out my website, farhatlectures.com, and for one law subscription, you can subscribe to all my courses, whether it's accounting, finance, or CPA supplementary material. Study hard. CPA is a long-term investment in your career. Good luck and stay safe, especially if you are still living through this coronavirus. Good luck.