minus one without the colon, putting that in the outer column. This equals 205 minus one. Let's do some fancy indentations for the subcalculation. Select in these three, home tab, alignment, indent, and then I double indent in here. Home tab, alignment, and indent again. So that's our standard subcalculation colon. Representing there's going to be a subcalculation. We pull that into the center column and then we indented. And then when we finished the calculation to get to what we had with the subtitle, we put it on the outside. So now we have the numerator and the denominator and the outer column, which is a standard tax return kind of format, which may kind of turn you off with the tax return format. But it's actually a good strategy or format when you're trying to work through practice problems, even though taxes are not enjoyable for most people. So this is going to be the R or correlation. Maybe I should have put the R up first here. R correlation. And so we just divide that out because we got the numerator and the denominator, home tab, font group, underline. And let's just divide it out. Obviously, 204 divided by the 204 is one, but now it's negative one, which means now it's perfectly negatively correlated. And so that's what we would have, that's what we expect. So I was like, OK, perfect negative correlation, that makes sense. Now let's do the same thing with Excel just telling us it's negatively correlated. So to do that, I can go to the data, to the analysis. Now, if you don't have that analysis tool, remember you just go to the file tab. You go to the options. You go to the add-ins. You have the Excel add-ins. Go to that and then add the analysis tool pack, the super cool pack of tool. So then here we are. And if you don't have the tool pack, you are a tool. I don't even know. Anyways, correlation. Here's the correlation. We're going to say OK. And we'll find this one. And let's put this down. And we'll say, we're just going to take these two. I'm going to take the headers in, control shift down in our data. We have to have them side by this side. You can see I'm going to say backspace. I think I've got the right data, so it's still summing that up. Yes. All right. And then I'm going to say OK. And then labels checked off because I had the labels in there. So you have to have that if you included the labels when you summed it up or drew the location of where the thing is. That wasn't very well said, but I will leave it in. OK. And then where the thing is when you did the other thing, let's put it here and say OK. And then OK. So there we have it. So then it tells us it's perfectly negative correlated. I'll format this. Let's make some black and white, home tab, font group, black, white. Let's center it and wrap the text. OK, so that looks good. And then, of course, I'm just going to do that last analysis to let's put let's pull this underneath now. So we have room for our charts. Can nice go there nice and cozy like underneath. So they're not too far away from everything else and they feel like they're part of everything that's going on. They're not out in the distance in the cold. Let's also then do the other data analysis data analysis and do that descriptive statistics just to practice with that because it's a cool tool. It's a cool tool. Let's go same thing, same set of data, selecting the data. And then I'm going to say, where do we want to put it? I'll tell you where to put it. Excel, you put it right there. That's where you put it. That's where it goes. That's why you put it there. Summary statistics and then I'll do the confidence intervals, although we're not going to focus in on them now. OK, so then and then let's make this a little wider. Boom. And it gives you the mean, the standard error, the median, the mode, standard deviation. And that, of course, can give you some indications about the relationships between the data sets. But remember that this is kind of static data, so it's not dynamic. So if you can't change it as easily. So it's any case. Let's do it. Let's just format our stuff now like we normally do. I'm going to go all the way back to the beginning, control shift down. I'm going to make this blue, home tab, font group, make it border blue. If you don't have that blue, by the way, it's in the more color. You don't have to do this blue, by the way. It's that blue right there. You can color it whatever color you think is fine. Home tab, font group. I like the blue. I've grown up with the blue. The blue has, I find it has endeared my heart. And so I stick with it. Home tab, border blue. But that's just me. You can do whatever you want. I do enjoy other colors as well. Home tab, font group, blue, borders. And then let's do this one. I tend to like to use the other colors for other standardized areas, see? And so I have it all worked out in my logic system in my mind, which isn't always that logical. It has this plan of which colors are supposed to be where. And that's just so I just, that's why. But you don't have to follow that. And here we go. And then this one, home tab, font group, and black and white. Color coding is not my strong suit. It's not my strong suit. That's why I use the same colors, because then I don't have to think about it. Let's put some borders around that. Let's do a spell check on it, if we would. Check the spelling. Correlation, I can't spell that word. I can't spell it. It's a hard word to spell. That's why you have spell check, though. So that's cool, no worries. All right.


Hi Josh. Populating the agenda things. Do you have anything? Hey. Hey, there's a work. This work much better when I turn them on. Oh, okay. I was like, hi. I was like, okay, no, hi. Yeah. So yeah. Okay. You injured your voice. Yeah. It really hurts to talk. Wow. I'm not going to ask what happened. I mean, you're going to tell us next week when you're fine again. Yeah, tell us in chat. Or chat. Yeah. Yes. I don't know what it says. Oh, hopefully. It goes away. Just sometimes there are like weird things that happen. I'd like that.  So I don't think it's, I think it's, um, my vocal cords, like the muscles. Um, yeah, I, I don't think it's a upper respiratory infection or anything. Not that I go anywhere. And never leave the house. Yeah, I think we're all in the same boat. It's like day in, day out. Home sweet home. Yeah, I don't know. I somehow did manage to get a cold within the last three months.  It was really bad. Oh, wow. And the worst part about it is they expect you to do something about it. Right. It's like monkey fix this, make it go away. It's like our cat all the time expects us to fix the weather for him. Yeah. Like I'll open up the back door and he'll look at it raining. And he'll yell at me. Fix this. Really? That's funny. My nails all the time. Yeah. The, um, So it's our fault. We talk to him all the time. So he tries to talk back. Did we want to walk through the framework? Or, um, I wasn't quite sure what people wanted to work on. Honestly, I'm not working out much. I'm a little overwhelmed at work. Yeah. I'm, I'm. Hearing that story in general, including me. Um, so I, I did put a, um, Pull request because there were like some links missing and some spacing. And then there was like a sentence that shouldn't have made it in that was like the copy and paste kind of stuff that not only that one that we fixed, but another one that was not. So, um, So that's still in right now. Do you want me to, to share screen or like, if you, or just what did you mean with going through it? I wasn't sure if I just looked at the future agenda. Yeah. My question is, uh, for instance, there are like. Sections where. I would love to have more input. Uh, for instance, um, In the tools that help minimize, uh, you know, PR submission process, like that streamline the process. Like I mentioned, I mentioned something about tilt and I put something in there, but it's like it needs a proper description because it's like sometimes I. Because I'm not that technical, like if a look at the website, it doesn't really tell me what the value is in here. And I'm sure there are like maybe some other things and they're like, um, that could go in here. have a look and see specifically with the technical parts to be honest, it was in the PR process, it was really like okay I'm just typing what people are telling me, because I don't really understand the process which is like for me. But I think like Scott looked over it so I think that's probably fine but with the tools maybe there is like something that we want to add here it's like I don't know. So when I read the tool section. It's intended to be examples of how you can help people with tools, not recommendations for tools I would say or a thorough explanation of the value prop. So I think what you had was fine I'll definitely recheck it though. I think only one of them I commented on because it was a little confusing Docker. Yeah, I mean, but I wouldn't worry about trying to capture like selling tilt or why like it only makes sense if it makes sense for your project and they're just examples of like here things we can do in our projects to help people beyond just a build script. Right. So I wouldn't worry about it too much because the point of the framework right it's not to technically tell anyone how to do things it's about the people level and kind of the tools. Yeah and it says example of tools right, but then there is like this, what is ID, an ID that they are comfortable with I don't know what that was, I don't know where it came from integrated development editor. It's just like VS code or IntelliJ or pie charm. Okay, so that doesn't really need what it well, like, maybe like what it. I mean, we could replace the word with editor to be honest and it would work just fine. If we want to remove the acronym. We're just saying wherever you type your code in if it understands your programming language. It's easier. Okay, that was like mostly the thing and it's like if if you feel, look, I mean it's not as you said it's nothing like super prescriptive is like very high level so I, I don't know if anything is missing or, and the other one so the next section is actually should be become a PR very soon, hopefully tomorrow. I'm sorry I'm behind on the PRs. I'm looking over the updates to the framework right now and should be able to merge it. As soon as I'm not talking to people. I don't like talking and merging always miss something. It's difficult to be in a meeting and not talk. Yeah, I prefer to do all my mergers at 130 am. I don't want to be sleeping. I merge at like the post lunch slump, when I don't want to do anything. That's when I read reviews and do stuff. Oh, the problem. No problem is actually I always find something I want to tweak. And then it stops being the slump right suddenly you're working. Yeah.  So I can't promise to be able to put in with you and, and input on this. Yeah, well there are a lot of things so why don't like we like we have the problem is it is kind of a beast right so they're like five. Well this is the biggest section and it becomes smaller each one. Yeah, probably as well because it was the interviews and people were getting tired word. But also like these are kind of the main sections to. So I don't know if, yeah, if. So I don't know what what we're going to do with this anyways like one, like once it is all there and we got feedback or didn't get feedback, it's now in the draft folder what what are like what are. Of course at some point we wanted to be on a website where everyone can access it but the website isn't live yet right so that's also like a long process. And I don't know why it looks so nice. I don't know either, and wait, so who needs, who needs to approve what for the website. You are. Oh. Oh, well, that has more to do with your being over committed. I know I know it's nothing personal but you know, yeah, that's all it's we're waiting for for the website is that and then, um, you know, we can flip the domain when we're ready, but we could at least have a resolvable display of a website. Yeah, well, my suggestion is to ping him via, you know, slack dm. Good morning. Sure. That's that's been my, my way on your house. Yeah he's in Europe but he stays up late so. And that's that's how I've gotten the fastest turnaround from things is by DMing him at like 830am my time. I can do that. I was pinging him on GitHub but that's probably not helping. No, I don't think I don't think he even reads his GitHub notification. Okay. Well, I'll leave a tab open and then I'll remember tomorrow. So with the content. To move something out of draft and into a regular proposal. Don't we need the RTSC liaison to prove it, or is that only for governance related things. We need to have a review of anything that might be providing specific guidance to projects but a lot of our things have already been reviewed. Specifically, would this framework need to be reviewed. Before. Yeah, we'd want sad or. We have a new, we haven't new second liaison and who it is. I mean one of the things I actually wanted to talk about was actually having a meeting with Saad and. Elena volunteered. So we need to bug Elena, and maybe have a meeting with her inside. And maybe we should add a tag to things that specifically are waiting on just their approval. Do we have anything right now that's waiting on their approval. No, we don't, but we want the future right like when we're ready for the contributor frameworks and that that'll be in that situation. And that would make it easier for them, right if they know that they just look at the liaison approval label. Yeah, sounds good. And should we just because it has several sections. Should we kind of do them one by one like this one like I just want to have those questions, like, still answered right but like once we feel this is like ready for that. Should we just put the sections. I'm just thinking about user friendliness, because it's like if it's like five at once it may be overwhelming or do we want to have it like ready and then put it all in there. So it's them until basically we're ready to put it on the site, I think. Because otherwise you're going to be edited after they've looked at it and, you know, okay. I mean, correct me if people have different opinions on that, but a man that label for liaison review. Making it red fire engine read done already we're very productive. When is the leather getting into approval process I've been hearing about it since I joined. That should be. It looks pretty complete. Is it also ready to the working with it so I've been using this. I feel awful about the ladder. I haven't I haven't done anything at a time I need to it. I haven't done anything on the last week but I know that Karen's put in a bunch of work on it. Yeah, but what's missing. I'm on the ball. Yeah. I think that Josh and I talked about splitting it so kind of like the main version is like the most generic version, I guess you can say, and then I think what we talked about, they kind of can't remember just leaving going back and forth body was kind of having like a Well, I'm not into the expansion. It's like an expansion of the maintainer section because based on some of the bigger projects. There are more categories under maintainer. So let me drop the link. I know. So I haven't deleted. So basically I made a duplicate version of the original one that we had. And I need to clean up the maintainer expansion pack but essentially that would be like a. I'm going to put my Cougar clock is off. But basically we were going to have this expansion pack be more, more specific to like the different maintainer roles that we talked about. So, I think as of right now what would fall under that would be like the community maintainer project manager, which Stephen and Gus has gave us. I think I have it saved. Just like a PR that Lori Alphel wrote. Yeah. So I think that's project and program manager I think will probably be the same and then like release manager docs manager and then like sub project lead. So I think that we don't like overwhelm a reader with everything that would be more than necessary for their project. So I think that was kind of the last update we had but care of everyone here so if you have any thoughts there. I had a question. So looking at the expansion pack. And it still seems to have stuff about community participant. Okay, let me clean it up. It was basically a duplicate of the light version. Okay, let me clean it up real quick. I just was making sure I understood the deal. Okay. So I think we said. Hey Josh, the sub project lead go under maintainer. Yeah, that would be a type of maintainer. Okay, yeah. I really like the suggestion to split it. I think it makes a lot easier to think about. Yeah, there you go. Ignore the like table contents at the beginning but yeah. Project lead like should we do a project lead section or would it just because that also kind of comes down and governance right. I feel like that's more governance. Yeah, I mean the difference between project lead and maintainer is governance. I mean, whether or not we want to. I mean the case for adding that to the template thing is we already have a governance template for maintainer led organizations. Right. So I kind of feel like we should just direct people to that rather than supplying alternative I realized some projects do have combined governance and contributor letter documents, but there's a limit to the permutations we can represent. So I just like just linking to it and being like hey beware of this. It's a governing governance issue. Go read here. Yeah. Yeah. Because I mean like the maintainer. Well once we have this I'm going to make some changes to the maintain to the maintainer council governance template to take some things out and simply direct people to the contributor letter template. So the, because better than having sort of duplicate stuff. For one thing. I'm already dealing with some projects that have two different definitions of a maintainer in two different documents. It doesn't help anybody. So then for maintainer. Under responsibilities include some of it is. Governance handling CNCF relations speaking on behalf of the product. Those would those would probably go away right because those are more projects lead. Um, so, like given maintainers like the umbrella category for all the breakdowns of the other categories, like what are, yeah what are like more general responsibilities. I mean general just for if you're a maintainer. Yeah, because like we were originally wrote this right like as like kind of like, um, yeah but like the project lead position in mind and I guess it's like now how do we just make this like as generic as possible for the maintainer category. Wait so we have the maintainer category in the basic fun. Yeah. And then we have sort of sub types of maintainer. Yeah. So we're going to include all of these are going to put in any project lead I would say the difference between a maintainer and a project usually governance responsibilities so see the maintainer council governance template here. So then should I create a section that's just project lead as well and then might point it elsewhere. Well I would put that in the, in the separate types of maintainers file. Yeah. So, do you mind Karen if I just make a little edits as I'm so go for it. And seeing like places we can expand a little bit. Yeah, um, yeah, because we pulled it off from GitHub and now we're back on that. Also, um, I don't know if we should call it the maintainer expansion. I like that. I like maintainer expansion track but we should probably name the file something else. Yeah, does the people get a one of a kind unique card in there. Yeah, it's holographic. The. I mean, honestly, I think for our target audience calling it the maintainer expansion pack would actually be a lot of fun. I think the TOC would find it frivolous unfortunately. Like extended letter contributor letter because it's an extent like once you grow you extended. What was it extended ladder. I think the one would be like the basic right like that's what you need the core any project needs those and then the extended slather is like once you grow you start needing you start to need additional roles, not necessarily all at once but. Yeah, I mean, some of it has to often do with project structure, right because like we have a brand new project that we're launching and it already has some project leads, because of how the project is organized. Right, because the project is actually kind of a collection of drivers and so each driver has an individual for others like community manager release manager and stuff. Those often only show up once have like production adoption. I have a question regarding the community manager, because we were kind of brainstorming about creating that role as well for linker D, but not so much for the social media part but more like helping like really foster and engaging community being like help answering questions I feel like that really is part of it right like someone who helping people identify people who have a story to tell and then encourage them to tell that story right like. The, these all need to be filled out so we could really use your help with that. Because if you look at the earlier roles and sort of the core set, like, like, you know the basic maintainer role, for example, we have this criteria and responsibilities and privileges with each one. And we really need to have that with all of these roles we just have not filled that out yet.  So, I'm kind of going back to what we're saying with the like umbrella category being maintainer then do we. So right now under maintainer there is the criteria responsibilities and additional privileges sections. So we want to just take it out under the like under the maintainer section and then create, you know, a set for each subset. Or do we want one that is like a general maintainer list that would apply to the community manager the project manager release manager and like so on and so on. Yeah, well this, I feel like we need some other things right because, for example, for some of these roles, particularly the ones that are not traditional code review roles. Yeah, we need to add some stuff about the kinds of contributions that qualify you for that because we'll say okay. So there's a maintainer role and therefore this person has to have had experience with authoring and reviewing and that sort of thing. Yeah. But they're going to be offering and reviewing different stuff than a release manager what so it's not necessarily how much we need to put in there but what kind if you follow me. Yeah, wait so then. So should we leave the current criteria responsibilities and privileges as is under maintainer and then everything under, you know, subcategory like community manager would just be like additional responsibilities. Yeah, or clarifications, right. Okay, like for example we already have this right is that general maintainer needs experiences a contributor and reviewer and approver. And the community manager needs specifically experience of reviewer and approver of the projects, media and contributor guides and that sort of thing. Right. Yeah, is that they should have a track record of contributing to those things. Specifically, the docs manager should have a track record of contributing to the docs. Right. I think there may be a little bit of a, not a problem, but I don't often see a community manager or some of these other managers always move up from contributor and approver. They may have been contributing, but in a different way, like for example, they may be showing up to meetings and helping to design and lay out like your plans for doing a whole bunch of things and being extremely engaged. They may have never actually worked on a PR with you though. And I'd be concerned that the criteria would make people who are coming from a different method of engaging with the project. Yeah, feel like they can't be this unless they've been doing PRs. A lot of these things don't happen in PRs. A lot of project management, release management, community management are happening in other channels. And I want to want to make sure that like we can somehow clearly say, you don't have to be a pull request person to do these roles. Yeah, so I think that was kind of like what I'm getting at we can either structure it where we put the initial set of criteria responsibilities and privileges at the beginning for all maintainers and just make it like really, really generic. Like do like the, you know, additional points under each category of like the different kinds of maintainers, or we scrape the generic criteria responsibility privileges, and then just do each section with those points. So I don't think it's generic, but I think instead of thinking about specific activities. Yeah, looking for a general level of responsibility towards the project and people demonstrated it already. So they are coming to meetings they are engaging with new users and helping them. They are aware of and helping to make decisions for the project, like, I'm maybe not saying these great because I probably want to like think about it before I write them down. It has nothing to do potentially with conference speaking obligations or pull requests or anything like that. It may just be someone's acting like a maintainer.  It's it's not always number of PRs or so let's be under criteria, right. Yeah, so for general criteria but like, I think those like what we have right now is perfect for code maintainer. Yeah, and we can just start over and make just more general things like do they have the right attitude are they demonstrating that they will be a responsible maintainer already. You know, yeah, they're doing certain actions. The actions are going to be different for each one of these roles, but in general there's a there's a different attitude to someone who's trustworthy, I guess we know that they'll be able to handle the responsibility of that role. I know that sounds really qualitative, but that's okay. quantitative part comes in for each individual role. Yeah. Yeah, it's a good way to do it.  That's like the broad overarching characteristics. And it gets like if you go specific it has to be completely different because these are, and that's why I think sometimes the word letter is a little misleading because it's not one it's like you have like these parallel tracks right. If you're a community manager. I mean yes you need to understand the technology to help and so on but it's like it's.  So it's like, you want someone who has like really good skills at writing and explaining technologies. That's their strongest, you know, characteristic not necessarily like triaging and things like that. So looking up on Porter. We have a docs manager, and she didn't get the role by submitting a ton of PR as a doc so it was all through giving us on advice on how to do our docs, and then maybe she helped all the meetings and then was able to give us feedback on like where we're missing how we should organize the stuff that none of it gets captured. You know, even though the docs are in GitHub, a lot of that higher level planning and design and everything happens through other interactions. So I'm just agreeing with you and giving an example that's all. One thing I think would be great to mention is we have some project lead right. And I know we have like approvers to a lot of times people don't become a maintainer for the whole project all at once. They usually end up being able to review in a certain area of the code, or the like your projects, not project lead, but some project lead I guess, or like the area where they've worked the most and they have the most domain expertise. I guess this is like a common thing I see.  So right now our prover is on the other one. Yeah, the other one because like, I guess like, regardless of how, or that seems like something that's more of a generic role than like, or that like most projects will have regardless. So that was sitting there. Do you think that's where I'll edit it then I just want to maybe add a quick mention that someone can become an approver over just a sub area. Yeah, they don't have to be a prover for everything. The whole project. Yeah. There was one section that I did. I'm not really familiar with that I think Josh had originally built out but if you could take a look under organization member on like the main ladder as well. Yeah, I guess, because do all projects have organization members or is that just not all projects do that now. Okay. Um, the reason why some do is because of how GitHub works.  Okay, or added to the repository, you know that kind of stuff. There's a importer for example, people like to be able to assign issues to themselves and pick them up and you know we have like a lot of stuff in the backlog and we don't want to be like, ask a Navy will let you. So as soon as someone's done their first PR they become a, an org member, just so that they can assign an issue to themselves and claim it. So I think I'm going to drop but I think I would like to help with the community manager thing just because I was like thinking it through and if you need more, you know, areas, but you are working now. So this is, so it's not you're not working. This is not merged yet so like where is like the best way to kind of add ideas or should I just, you know, you can just add to this directly I don't know if you have a HACMZ account. If you don't you should still be able to. Okay right in here. Yeah, like, um, there's a pencil at the top left.  Okay, so cool. I'll do that because, again, like, that's exactly something that we've been discussing now so, and that's probably the only role where I have something more of a clear idea. I'm happy to help on that front. Yeah, just add as much as you want and then like, you know, whatever, like, if necessary. Awesome. Okay, cool. Thanks. I will do that probably tomorrow or so, or by the end of the week for sure. Karen was there a specific change you want me to help make an organization number and always kind of discussed it and I'm trying to figure out. Not necessarily more so just I guess like it over because I'm not like, I don't fully know what that like membership level is. Yeah, yeah, and it looks like Josh added elections to. Yeah. I guess, I think in, because we all most for the most part work in GitHub, I think all the scene CF does get up. It's easy to conflate the GitHub organization member with this. Maybe if we call it project member. It would not be like there wouldn't be like, we wouldn't have to like have a caveat and we're like, this doesn't actually mean GitHub organization member. I actually don't know the difference so I will defer to you. Oh, okay. Yeah. Um, like for example, in the GitHub there's like a days labs org or Kubernetes org or how has an org to. And it's called in GitHub organization member. Okay, right. But the way this is worded right now in the document where they're talking about like elections and things like that. Those two aren't actually tied together at all it has more to do with are you a member of this CNCF project. So I think if we change it to project member. People won't be confused and think we're talking about GitHub privileges, like being a member of the GitHub org. So what do you think is like the most generic version of this because I think for Kubernetes specifically, I think you have to actually be an org member to like vote for stuff right. I'm saying it's that's like a technical mechanism for doing voting. Yeah. So this role right here that we're describing. That's nothing to do with GitHub. It has to do with just categorizing your relationship to the project. And so we're saying, like, when we say the word organization, what does that refer to when you're talking about the CNCF project. So what I mean for me is GitHub organization, which is like a very specific detail that some projects may or may not do. I thought Josh was going for that. Was he. Because like, well, so what would be the difference between a contributor and like your version of organization number. I'm saying project member isn't your member of the Kubernetes project or the helm project or linker D. I don't think we want to conflate, like make like a one to one thing between GitHub organization membership, which may not be a thing for all projects, and they could implement membership differently. That's all I was suggesting.  Or maybe the problem is that there's stuff about elections, which is governance in here at all. That's a good point. Maybe that's the thing that is bothering me. I think they're both bothering me one, because it really. It's not even a term that maybe isn't the right term for the role, but to that we're talking about governance outside of the governance doc. Well, so okay if you didn't see that term just based on the description that's there, what would you put there. If I just see the word organization member the only thing I'm aware of that like I could map to is GitHub organization membership which seems really specific to be on the ladder. Sorry, wait, let me ask you a question. Okay, so, um, what do you think of when I say someone who is an established contributor who regularly participates in the project and has the privilege and who has privileges in both project repositories and elections. I don't know, because elections is very specific to everyone's governance doc. If we just took off the elections part. Um, I would, I don't even know I think I call them a good contributor. I don't know. Yeah, that's why I just like just member. I don't know. Yeah, I mean, I'm trying to like see this from Josh's angle, which would I'm guessing be like the Kubernetes org membership. Example. Yeah, it's just that not everyone does what Kubernetes does. Right. So like, it's just a way to put people on a list, basically. So it's the most generic abstraction from the Kubernetes like org member. Like conversation. Because I almost think like Kubernetes is hyper specialized. Yeah, with a lot of roles. Some of their roles may not be on our ladder, and that's okay. Right. So then, because they're like the unicorn. Right. Everyone else is much smaller and usually isn't as organized. Yeah, because now that I'm thinking back about it right it's like if you look at the requirements it says like the like number of PRs and all that, like I think this was put in there to describe someone who is an org member, like on GitHub. Yeah. Maybe I'll just put suggestions on it and point Josh to it. Yeah, and be like, I think this is maybe a bit more of project member, and let's take the election stuff out of it because we should be covering that in the government stock, not duplicating it here. Yeah, not in the government stock we should move it there. Because that's why there's so many metrics is used for elections. But like, you know, a couple of the projects I've been on like anyone can be a member if they stick around. Right. And it has nothing to do with being able to elect people. So they're not nearly as picky about making someone a member. Okay, so. Okay, so we're going to consider possibly taking it out right. Yeah, or just, um, it's just, yeah, it's just conflating too much stuff in here. So then going back to what you were saying we're like, you know, you were wondering if this was like organization member versus project member. If we were to build out a section that was project member, what would that look like. I don't know if it needs to be a role. Right. No. Okay. Maybe that's the thing. Maybe this organization member just needs to move into governance. Okay. Okay, let's see if I can make a comment. It's my clock. And now I think it's 630. Okay, I said a comment there. We chat about that in Slack later. I don't think the content there is is wrong at all. It's just, I think maybe it belongs in the other doc. Okay, yeah. And I added something to approve her just to say like it may just be over a sub area, not an entire, you know, thing. For the maintainer section on the main ladder. How much of it should I abstract in relation to the expansion pack. Like what is the generic maintainer description then just a maintainer as a contributor with mid access.  What do you all like, do you all different kinds of maintainers have commit access. It's a, it's a, because you have commit access and it's hard for me to speak about it because I don't do the Kubernetes model and a lot of people don't either. Because they have that approver thing, which is different. But because you get to decide what code ultimately gets into a release and it goes, you're making decisions about the project either from a technical perspective, a roadmap perspective, and priorities. Because you ultimately get to decide if this contribution is accepted or not. And if we're by doing that you're deciding the entire direction of the project. So it's commit access right but really it's a decision making pro role at the technical level. Okay. If you need me to like somehow write that instead of trying to translate what I just said, I can take a stab at it. Sure.  No, no, no, no, not at all. I'm just, sometimes it's not nice to babble at someone for five minutes and then expect them to turn it into two sentences. Do you want me to comment so you remember to go back to it. Yeah, let's just do that. Oh hack MD, the comment like clean up the section. That's not for me. Oh, there it is. Okay. Yeah, I'll update the description and just explain it's a technical decision. Yeah, role that's usually not usually it's because they can decide if things go in the project or not. Okay, you know, are we going to do this issue. Are we going to merge this PR approvers. I think also get to kind of say if stuff should merge. But I think usually they're not making decisions about if doing that issue in general is the right thing to do. And like an approver and a reviewer, or maybe kind of the same thing, right. It's, yeah, it's this is a very, and that's why I was kind of like picking on it a bit is, it's very specific to Kubernetes. So in Kubernetes, no one has commit access to be clear. Everything goes through prow, which is like this GitHub automation that they have.  And if you're a prover, then you can, you can do slash LG TM, but you can also do slash approve. Approver can just, you know, merge the thing all by themselves pretty much. Yeah. And then if you're a reviewer, you're able to do the work of the code review and then maybe make it a little easier for the approver to just go yes this looks good in general and trust that the review was done well. So a lot of projects has different rules about that but a prover has more responsibility because their comment is what merges the code. A lot of projects just have maintainers though. Yeah, and they do all of this. So if you only have like, if you had one person would get something before our maintainer, are they more likely to be a reviewer or an approver. A reviewer. Okay. So then, it's like, it's mostly helpful in projects where they require multiple reviews. Like, we need to reviews to merge. Yeah, so there's people who, who don't have as much trust. So like they can help review and they, they can be like, Oh, this style is wrong or whatever like help fix the code and get it up to speed. But that second person could be a maintainer could be the approver has to make a decision on like, is the whole thing actually implemented the way we wanted it to be. Is it ready are there gaps, you know, is this safe to bring in. So then, are all reviewers. Sorry. No, all approvers are reviewers, but not all reviewers are approvers. Yes. Okay, maybe. Okay. And include that one way or another. Are you writing that I can write it down. Yeah, I'm going to change the section to reviewer then. Okay. Oh, where'd that go. What happened to her. I changed it. Wait, what did they used to be two sections under. I thought there was a section called a reviewer and a section called a prover. Oh, yeah, there used to be. Yeah. So, I think, Josh, so I mean, it's it's like, like, I think that version is what I have in the draft folder so we still have it. Oh, okay. Yeah, but I think maybe we went, I think we took out. Yeah, I guess we took out reviewer, or we at least changed the name. But now I think let me reread this son approves pull request before they emerge by maintainers. Oh, yeah, you're right that should be reviewer. Definitely. Yeah, I agree with you. Sorry, in my head I just kind of thought that it said something different because I was thinking of the draft. A reviewer approves. Okay, that looks good. Where should I add like, I think they want to explicitly say this in Kubernetes. I think the tanner may be a prover.  Should we address it. I think approver is very specific to Kubernetes. And we just don't need to say it. They will have their own special section. Okay. Yeah. In general, I don't want to worry too much about making the template. Handle everything that a specialized project may be doing right. Okay, so I understand the change now. You're right. Change it to reviewer. So I'm going to change experience as an approver to an experience as a reviewer for somebody. I think we say approver elsewhere in the stock basically. Okay, I'm going to control us. I mean, there's the talk, right? Huh? There's the table of contents. Yeah. You were, and then. I don't know how to search in this very well. I think I got them all. I think you did. I just do control us. Okay, great. Great. I'm going to update the expansion back just to remove that word too. Oh yeah, because we have to look at. Oh, we took it out. Yeah. Yeah. Really good. It's just so hard because it. Ever changing documents work on. Huh. So this is a tough document to work on because everyone does it differently. Yeah. No. Okay. Yeah. So I guess I want to be able to clean up the maintainer section in a way where it will. Seamlessly. Flow into the expansion pack of someone needs it. Yeah. Okay. So we would get rid of. All the stuff right now that says community maintainer. Okay. So just leave that whole section. Yeah, I think so. Okay. And then. Maybe as a sub. Section under maintainer. We send people to the expansion pack to discuss. Different. The different roles to find there. Like there's lots of different ways to be a maintainer on a project. Yeah. Not, it's not always a code. Roll. So all right. So with those, with the expansion pack, be the non-code roles or. Will the code maintainer role. Like, are we just discussing a code maintainer role here then? Or will the code code maintainer role be. A category of the expansion pack. I think we want to be careful about how we frame it because I don't want it to be like, well, the. Default best first class, whatever one is the code one. I just more meant that the description right now for maintainer includes a lot of. Technical. Like code contributions because the contributor reviewer. I'm not going to do that. If you're trying to become a computer. Community manager, for example, you're not going to do those. Right. And there should still be a way to do it. I have an idea, a suggestion. What if we take. I'm just going to type on this real quick. But imagine it's going to go in the other documents. Whatever. I don't want to use the word technical. Okay. And then we would have this stuff and this would move. To the expansion pack. Right. And then up here, we would do. General criteria. That was that attitude stuff. Yeah, your responsibility. Yeah. And then because we did that. Maintainer doesn't mean just code maintainer. Yeah. Someone with decision making capabilities on the project. And then. There are different types of maintainers and code maintainer is. One of them will to these other ones. So then. Okay. So. Like originally, I thought when we were splitting it, that we were just kind of splitting like. I originally had this one is like the light version. And then the other one was like the, you know, the expanded version. Right. Oh yeah. Yeah. And then when we're on our call last Thursday, Josh mentioned like the other, the newer. Or the additional ladder being more like a breakout of the maintainer section. And so now I'm wondering like the way you're phrasing the code, maintainer role. You know, if we're trying to not necessarily. Give any weight to any one kind of maintainer than another. Throw the ones that are in the, in the expansion pack pack in. Oh no. Oh, okay. I don't, I don't think so. I mean, I want to make sure that my suggestion makes sense. Okay. I think it's trying to address what you're talking about here. Where it says maintainer. Right. We're going to change it so that none of the criteria or tasks are about code, committing code, reviewing code, all that stuff that we think of. Yeah. And then code maintainer goes into the expansion pack and the expansion pack is. We stop calling expansion pack maybe we just call it types of maintainers. Yeah. And then we see. So does that kind of. We don't need to move things back into this document because they all. The, the, the maintainer description in the general doc will be. Vague enough to have vague, but you know what I mean? None of it will be specific to code. Yeah. Well, so I get what you're saying. I guess I'm asking, do we need to break this out into a separate document? I guess. Maybe like, as in like, you know, do we do that? Other like, well. The maintainer. Doc. I think it's, I guess. I think it's big enough. Okay. And the idea is that maintainer is the, the top. Yeah. So you've made it to the top of the ladder and it's just a question of like, are you on the left side of the ladder or the middle side? The way. Yeah. You know, like who are you standing next to on the ladder? And they're all different people. So I think. I can see making it a separate document, just what's not so giant. Yeah. It's a way to say the other one could be like, just like, I'm like a maintainer. I guess it's a template now. Or it would be, yeah. So just like.  I've decision making capabilities on the project. Yeah. Right. But. What area of the project depends on the type of maintainer I am. So would it just be a maintainer template then? I'm just wondering if you want to use the template word again. Oh. Oh, I see your question. But we call it. Yeah. It's still a template. Yeah. I would just need to be caught. If I got to just pick and I wrote down whatever I felt like, I'd probably call it. Contributor ladder. Maintainer types. Template. And I know it's wordy, but. Yeah. Yeah, like that. And then. It'd be clear. It's kind of like a sub document. It's just so it's not ginormous. And it's easy to see that they're all equal at that point. Okay. Wait, I'm going to change the talk right now because they're not all equal. Fixing it. Maybe cause not the right word, but I just hope I really don't want to use the word technical. So that's the best word I have. And then. I have one question for you. You just saw some of them are called maintainers and some of them are called managers. Yeah. Yeah, I noticed that. It would be great if they could be consistent. But I don't know if that's just like me wanting to. Make stuff like tidy, but more just, I want to make sure they are all perceived as maintainer roles. Well, I mean, there's three categories or there's maintainer, there's manager and then there's the lead. Yeah, isn't that weird? I'm not as familiar with some project lead to be honest. I don't quite know, like, do we have an example of a project that has it? Yeah, I think just like the Kubernetes SIGs. Oh, yeah. So like if you're the lead for SIG networking. Yeah. But isn't that a governance role? No, I don't. Do you have to be a lead for one of the SIGs? Or we not talking about SIGs. We talking about something else. I think it's SIGs, but I don't think you have to be elected. Per se. I'm thinking of like one specific. Can you say it? We're recorded. So I don't know. Yeah. Which one of this? I can't remember specifically and also like, I can't say, but more so that like, they're like. Just that like. The role that someone took up. Wasn't necessarily dictated by like a voting system. Cause sometimes like, if you have like, um, like, I think some of the newer SIGs, like, cause you started as like a working group, right? And then sometimes you become a SIG. So I think like, sometimes you like, naturally.  Yeah. Yeah. I still feel like that's a government governance, not all governance models use elections. I'm going to leave a comment on that and we'll, we'll talk to Josh about it. How's that sounds? Yeah. I want to be like, isn't this like governance role? Wait. So what about when, um, like, you're like a, you're an owner for a, like a, I don't know the terminology for this, like, for like a sub repo.  So like Kubernetes has lots of repos, right? And there's the Kubernetes, Kubernetes repo. And then there's other ones inside of that.  Yeah. Is that what we're saying with lead though? Yeah. I mean, I wouldn't even call that a separate thing. What would you call that when we did reviewer? We said, this was a change we just made in this meeting. I said, a reviewer may only have responsibility over a sub area of the project. You may be a maintainer just for a single repository. Yeah. In a, cause like Porter does that we have, um, Like lots of repos. And some people are just a maintainer for one of those repos, but they're a maintainer. They're not called. They're not less than other people. It's just the scope of their decision making capabilities is restricted to that repository. Wait, but okay. So does that mean that you're interpreting some project lead to be above? I'm saying that some project lead. I'm not sure it should be a thing. I think it just means a maintainer with. A different scope. Like maintainer doesn't have to be. Oh, we want it because like there's a project maintainer. And they're like a maintainer for. The whole project. And then there may be a reviewer. And they're just responsible for a smaller scope of the project. Okay, but they're not necessarily a different type of maintainer. Exactly. Okay. Like I could be the docs. Maintainer for just one repo. I could be the release manager for just one repo versus a larger one. It really depends on how projects do their own thing. Okay. But I don't think it's a separate thing that's. This. When we're talking about types of maintainers. Yeah. Doesn't fit. Okay. Right. Cause you're saying that's just more around governance. Like. Yeah. I want to say that maintainers can have. Different scopes. Of responsibility. They're scopes of responsibility. Maybe the entire project, like all of Kubernetes. I don't care where it's happening. And people may have responsibility just for. One or two refos. Okay. So maybe it's more of like thinking it from thinking about it. Not from the, not so much the angle of like. How much they're overseeing, but more so like kind of like. Discipline. That's probably not the best word, but just kind of like the kind of stuff that they would do. Right. Like. Cause it's like the nature of like being a community manager. Like the nature of the work that you do will be very different from a docs manager. And that's why we're. Like. We're split. Yeah. Discipline is a good way to put it, I think. Okay. You want to change it to discipline. Or just, I don't know type works too, but I, I like thinking about that way. Cause it makes it clear that sub project lead and project lead. Don't go in this doc. Yeah. This is a template contributor. There's so many works. Okay. This is a template contributor. Water. Yeah. I'm moving it down since I guess the top part was. Oh wait. I think we want to explain maintainer and then do the table of contents. Right now. Oh my gosh. Okay. Right. Okay. I think that's. What we're going for. I have a question for you. Sure. The main. The main. The main. Like the heading one maintainer. Is that just repeating what. Is on the contributor ladder. Basic. Okay. Do you want to repeat it? Cause I think people will mess up editing both. Maybe we should just have a short one line that says. What it is and just link to the section and the other one. Okay. Okay. So we're going to end up with two documents. Well, we would only have to copy it. Well, I guess we'd have to copy and paste it. If it went up or we update it. Cause. Cause it's not just us. Right. Anyone who's using this template. We'll also be trying to keep these in sync. Cause they may have. If they do. To follow a template. The way it is. They'll end up with two documents as well. Yeah. Okay. So that's why I was thinking the link may work better for people. Yeah. I'm not suggesting you put it. Let me. I'm going to edit this and you can yell at me if you don't like it. Okay. Let me update the maintainer description. Okay. This is what I'm going to suggest. Oh wait, I'm going to, that's why I was going to, I was going to delete maintainer. And then up here. I was going to. Do you see the second paragraph now? Yeah. Yeah. Yeah. Okay. I'm trying to make it a link, but, um, and then we'll go back. To do. Me and ladder. Yeah. Does it make sense? And then. So I got rid of what I want to get rid of. I'm going to delete it real quick and then don't cry. I want to do this. Does that make sense? Yeah. I don't want to lose the changes you've made, but I'm just saying like that should. I don't want to lose the changes we've made to that. Should just go in the other document and we can get rid of this section. Okay. What do you think? You don't have to like it. Yeah. No, I think that makes sense. Do we want to include that word discipline in the part you just added? Yeah, totally. But. Often have. Larger, more complex projects often have. Maintainers in various disciplines. I don't know. Yeah. Often separate. Responsibilities. Discipline. Oh my God. I don't know how to spell that word. Yes. Yeah. Separate. Maintainer responsibilities by discipline. There you go. All of these maintainer. Disciplines. Yeah. I have no idea if that's well, right? Are variations of the maintainer role. From the contributor. Oops. I love whoever's watching this video in the future. By the way, if they've stuck through it to the end. Like if you're still watching, come to our meetings. What do you think? Oh my gosh, it's going to go seven times. Sorry. Yeah. Yeah. I don't really like, so if we just need to like stop in the middle of what we're doing and give up, that's cool. Yeah. I think it looks good. We should copy the coat. The maintainer section over. Does the, do you think the table of contents should go before the second paragraph or where it is now? Like where it is. Okay. Cool. Explain why those. Bullets are happening. Yeah. I don't think there's any more. Five 30 my time. The last sentence of the second paragraph. Yep. What does that mean? I think that people are trying to give guidance on somehow consolidating these two documents and making a single document out of it. But what's a contributors file? Like that's just where you list the names, right? Okay. All right. Do we still want to do that? Do we want to encourage people to. Not edit this template, but just copy and paste and put it in the other file. So in the end, they have one single. Contributor ladder. I guess I was confused about. What the intent was when the file got split. If in the. If people who are following the template and end up with two files or one. I think they should end up with one. I think they should end up splitting it so that when they're reading it, like they might not need this. But if they would just have extra. Yes. Do this. I want to like make it read. I'm going to be really clear. Copy and edit. Any. Maintainer. Disciplines that apply to your. Contributor. Later. How does that sound? A little more clear. Yeah. Which should be contributor ladder file. Sorry. I just want to make people clear, like. Yeah. Any of these are you put them in that file. Yeah. Okay. Yeah. And then, oh, I didn't edit the other thing. In case. I think we don't need to say that twice. I don't remember what it says. I think we're fine. Maintainer. Section. We can just make this one sentence. That's all I was trying to do because we were kind of saying the five same thing a couple different ways. How does that look? Yeah. Would you know what to do if you ran into this? We're reading this template. Now that I'm reading it. Yeah. Yeah. They should put like, they should by default, at least put in code maintainer, right? It's not like, Oh, if you need, like, it's not like, these are additional. These are things you should do. Yeah. I'm fine with saying that in order to make it clear that they're all the same. Yeah. I still want code maintainer in here and you're always going to copy at least code maintainer. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. So that's the thing where it's like, if someone were to use the templates, they are going to have to use both. Right. You mean they're going to have to have two files by the time they're done. No, not that they'll create two files, but they're going to have to have to have to have two files. And then they're going to have to have to have two files. Which is all of these disciplines are equal. You just include code by default. I think you're implicitly saying which one's the most important. I mean, I think because like, they're going to have to view both docs anyway. I kind of still keep revisiting the idea of making. One doc instead of two. Sure. Yeah. And then when we submit the draft, once we've decided, we'll just put this in the right place in the document. Okay. Yeah.  Cause I know one file just fine. I'm not going to throw a monkey in the works about this, like whatever people want to do. I can see what you're saying, but it's easier just to delete stuff that you don't need than copy and paste over. Yeah. Yeah. I mean, especially if they're already going to have to reference the second doc or the second template, no matter what. If we want, we could just do that right now, or we can just kind of keep in our heads. Maybe put a thing like. Note. This. Instructions. Yeah. So we remember what we're talking about. Well, we don't have to stay here for 20 more minutes. Yeah. Sounds good. Okay. We feel better about this. Yeah. A lot better. Okay. I feel like this is really moving in the right direction. It's so much of what we've been doing is categorization. Yes. And that's hard. So it's fine. Yeah. Other templates didn't have to do this task of categorization. So. Yeah. Yeah. Yeah. I'm glad you're able to look over it because they feel like Josh and I were just kind of running in circles for a little bit. That's fine. That's fine. I think. I think we're getting a lot closer. I'm sorry. This is so iterative, but like, I think that's just the name of the game. Yeah. Okay. Cool. I'll clean it up a bit. But otherwise I think it's just a matter of like building out the different maintainer. Categories a bit more. Yeah. Yeah. All right. All right. Love it. Thanks so much. Yeah. Bye.


Hi everyone, this is Dr. Laura Portales and I'm here today to talk a little bit about Managing People Unit 4 with you. We'll be going over the learning objectives, the topics, and we'll be pulling out some of the key points from the study guide and from this unit to talk a little bit more about. So let's get started. Now let's take a look at our course unit structure as our course managing people is divided into eight units. And in this video we will be addressing unit 4, Managing Human Capital. On this slide we'll talk about our learning objectives and learning objectives are very important because all of the test questions both in the practice and the final exam and all of the content actually in the unit is ultimately tied to these learning objectives. So let's take a look at them together. Explain how viewing people as part of the human capital of the firm adds value to the organization in terms of talent management and competitive advantage. The second learning objective is explain the forces such as technology, business processes, workflow, skills gaps, generational changes, and talent development that affect enterprise decision making in managing human resources. And our third learning objective is use ethical principles and employee rights such as trustworthiness and equal pay to fairly manage people and effectively execute corporate social responsibility. Let's now take a look at the list of topics that we'll be addressing. This slide here lists the vocabulary that we will be discussing throughout this video and also words that you should know and be comfortable with to get yourself ready for the practice exam. Our topics for this unit include some reasons why we should invest in human capital and we'll also define what human capital is. We'll talk a bit about talent acquisition. So in other words, how do you get people that are talented? How do you hire them? We'll also talk about how you develop the talent or the human resources that that you've hired. We'll talk a little bit about succession planning and some of the forces that affect human capital and then we'll also address ethics. So let's take a look at our first topic which is human capital. Human capital is critical in just about every organization if not every organization. That's because even though we have a lot of technology available to us, it requires people ultimately to manage that technology and manage other aspects of our business. So we spend a lot of time in this unit talking about human capital and how to manage human capital because they're really a key cornerstone to the success of just about any organization. So when we talk about human capital, we talk about how do we acquire talented people, so how do we attract and retain people that are valuable and can add value to our organization and how do we develop those individuals once we've hired them, and then how can we do some things to plan for turnover and how can we limit the turnover within our organizations by developing people and hiring the right people to begin with. So that's ultimately what human capital is and what we're focused on in terms of this unit. The information presented on this slide focuses on some of the reasons why companies should and do invest in human capital. So let's take a look at some of those together. So when we invest in human capital as an organization, we do tend to see an increase in productivity and that results in more profit and more output. So increasing in productivity, of course, saves a lot of money on costs when people are more productive. So we want to ensure that we make those investments in human capital so that we can get that additional productivity, which eventually results in profitability. Also, we see that we have better attitudes by the people that work for us and that of course contributes to the bottom line as well. We see a decrease of costs related to absenteeism and turnover. Absenteeism refers to an unplanned absence of someone, whereas turnover refers to the loss of an employee, which is very costly when you have a high turnover in an organization or in other words when employees leave frequently. This is a very big cost because now you have to go back to the drawing board and hire someone else. Once you've hired them and spent all of the time and money doing that, then you have to spend time and money training them and developing them and getting them ready to be productive. So when we invest in human capital, we see a decrease in both absenteeism and the turnover that we were just talking about and that can save a lot of money in the long run. We also look at reducing the time necessary for introduction of new technologies. So when we invest in human capital, which could be training of a new technology, for example, we're then better able and better prepared for them to be up and running and more productive more quickly. And of course, that's an advantage to the organization. Also, when we invest in human capital, we're ensuring that the people that work for us, we're using and leveraging their skills and their abilities to the highest potential. So oftentimes if someone is in a job that doesn't make sense for them, for example, or we haven't invested in training them properly, then we're not taking advantage of their full potential and their full range of skills that they can use to contribute to our organization. As we talked about already, there's also a decrease in absenteeism, which of course when an employee has an unplanned absence that costs the company money in terms of productivity. So we see that as a big advantage. We also see more creativity in our organization, which means that we see greater creativity and the ability to solve problems that the organization may face. We also see people use equipment, systems, work processes a lot better, which saves money in the long run. We see our employees become much higher performing. And then also we see an increase in the quality of production and services. So that could mean, for example, we see if we're working in a manufacturing firm, we see that the actual product that is produced is of higher quality. But also if we're in service businesses, we see that our customers are better taken care of when we've invested in human capital. So those are the reasons why we should consider doing that. And in the next few slides, we'll address some of the ways that we can do that. There are several things that we want to consider when we look at how we can measure our investment in human capital. So when we look at indicators of efficiency of investment in human capital, we can look at the investments that we've made and the rate of development and investment that we've made in education. So that might be how much we've spent on training programs per employee, for example. So when we really want to measure that type of investment, we want to look at the actual expenditure that we've undergone in order to invest in that type of human capital and specifically as it relates to the employee development aspect. If we want to measure the loss of human capital, we can look at people that have retired and maybe they retired early. We can look at the turnover numbers that we have. And that can be a really good indicator of whether we're investing enough in human capital or not. Next, we can look at the effectiveness of our human capital. There are a number of metrics we can use here. The cost of staff, the sales per employee, the profit per employee are all ways that we can look at how well we're investing in our human capital. And then we can also look at the value that our human capital brings to the organization. And we can do that also similar to the last one, profit per employee. We can look at the rewards that we give to our top managers and to our first line supervisors. So when we're thinking about developing human capital, we definitely want to provide metrics as it relates to that human capital so that we know exactly how in financial or number terms, how our investments are paying off. That's really important. A lot of companies will just all of a sudden start developing training programs, for example, that really doesn't help with the production or efficiency or really development of human capital. So we want to put those measures into place before we put human capital development programs in place so that we can better measure and understand if we're meeting our goals around the development of human capital. As we consider developing programs around human capital, there are a few things and a few forces that we want to consider as part of this process, as we look at development and the types of development of human capital that we want to do. Of course, virtual workplaces, remote work definitely impacts how they work. So that would definitely be a consideration. The fact that organizations change rapidly in part due to technology, that can be a force that impacts our human capital or our employees that work for us. Generational gaps or generations in general can also impact human capital in that we have people from a large variety of age ranges in the workforce right now. They all have a different set of needs and wants based on events that happened in their formative years. So we want to consider how generational our workforce is and make sure that we're providing human capital development opportunities to really meet the desires and the needs of each generation, which of course are very different. There's a lot more focus on work-life balance, so we want to consider that. Many people feel like they need to check email, for example, seven days a week in case their boss has emailed them. So this is a big force and there are a lot of things that we can do to encourage a work-life balance so people don't feel like they have to be checking email when really they should be off work. And then also another force is the fact that businesses are more focused on succession planning as part of development. So succession planning is when an organization has plans in place that are set to when someone leaves an upper-level management position, they have people trained and ready to eventually take on that position. So of course there are two benefits to that. One of the big benefits to succession planning is that it can provide a clear path to promotion, which is very advantageous to individual, but it's also advantageous to the organization because you've identified these individuals that could take on these management positions and as a result of that you have people that are prepared and ready to go, so there's not a lot of time in between an upper-level manager leaving and before you can replace them. So succession planning is definitely something that impacts human capital as well and can impact it in a positive way as long as we're ensuring that we're developing people to take on those roles as people leave. We are now going to turn our attention to the idea of ethics and we talked about ethics in this unit because most people want to work for an ethical and socially responsible company. So because of that we invest in human capital simply by being ethical and making sure that our organization does the right thing. So we first start with that topic in terms of making sure that we have ethical leaders. We want leaders and managers in the organization that really model the behavior, the ethical behavior that we expect from our employees and we also want to make sure in order to be ethical and legal in some cases is that we ensure that the work environment and the working conditions for individuals are safe. So in the United States we have OSHA which focuses on rules for workplace safety and I'm sure if you don't live in the United States your country probably has something similar that really enforces and sets the standards for creation of a safe work environment for everybody and this may involve how chemicals should be handled within the organization and how accidents should be reported and that type of thing. So in order to be ethical we want to make sure that we have a safe workplace, not just physical safety as we've already discussed but also emotional safety too where people from diverse backgrounds feel like have a say and that they're hired fairly. So in the United States we have a lot of laws around that and in your country there are probably a lot of laws that revolve around being ethical in terms of hiring and promoting people and paying people within our organization. So we may in the United States we do have laws that focus race, gender and religion and makes it illegal for harassment to occur based on any of those elements. We also here in the United States have ADA which is the Americans with Disabilities Act and this act essentially focuses on offering equal access whether or not someone has a disability so if someone for example can't hear well it's up to us as an organization to be legal and ethical and ultimately make sure that we're providing the tools necessary for that person with a disability to be able to work for us. Also the United States had a DEA which stands for Age Discrimination and Employment Act and this of course means that you can't discriminate based on age and it encourages organizations to hire older workers and retain those older workers. Finally when we look at an ethical and legal work environment we look at sexual harassment and really any type of harassment as we discussed just a minute or so ago. So avoiding any type of harassment creates a work environment that makes people be able to work at their best and show their best productivity. So these are all really important when you look at an ethical and a socially responsible work environment. In the last slide we talked a little bit about ethics and social responsibility and I think it's important here to mention the difference between the three terms that we have listed here just to ensure that as a manager and as a work environment that you're being fair to everyone and offering everyone chances to be successful at your organization. So these three terms can be detrimental to that role. Let's first talk about stereotypes. Stereotypes are general cognitive thoughts that we have about a specific group of people with certain characteristics and the challenge with this is that it's overgyzed. So when we have a stereotype about someone and their particular group and we meet them in our mind we have this preconceived notion of who they are and how they are which of course isn't going to be correct because everybody's different whether or not they are of the same race or of the same gender. So we want to make sure that we try to limit the amount of stereotypes that we have although it is natural to have stereotypes we definitely don't want that to turn into prejudice which is our next term. Prejudiced is the negative feelings about people from a group but it can also be positives. So these feelings then can result in how we treat others who we decide we want to hire and who we decide we want to. So our stereotypes can sometimes turn into prejudice which of course again are detrimental to an organization. Now when we look at those two stereotypes and prejudice and nation discrimination is our actual behavior acting on the stereotypes and the prejudice that we all have. So when we act on these like for example not hiring someone of a certain gender that is potentially illegal depending on where you live but also of course it's unethical and doesn't create the environment that you want to create within your organization because then it creates an organization and a culture that is that is negative and where everyone is essentially the same and we know that and this comes from research we know that individuals that companies that have diverse individuals are generally more successful because they have a great idea is a pool of ideas and creativity that they could ultimately pull from. So what I'd like you to take away from this slide is the idea people have stereotypes prejudice and a lot of times those will turn into discrimination which again is illegal and most place but also definitely negative for organizations. Now to go ahead and conclude unit four let's tie back what you learned to our learning objectives. The first thing you learned is how viewing people as part of the human capital of the firm can add value to the organization and this adds value in terms of talent management and it does create a competitive advantage for organizations. We also talked about the different forces that affect decision-making when we manage human resources within our organizations and finally we discuss the use of ethical principles such as being trustworthy having equal pay and being fair as mayors to show our responsibility within organizations. Let's take a look now at what's next to prepare you for the practice exam. I definitely recommend that you do another review of the material maybe especially some of the material that you had some challenges with. Once you review that material you should be all set to take the practice exam and I wish you the best of luck on that.