 Hey Erin. Hey, hey, hey, how is going? How is going on? Oh, it's going. How are you? Yeah, I feel like maybe we didn't fill this out the last time we talked. Oh, no. Because this doesn't look right, does it? No. Well, has it been two weeks? Wait. When was the last one? It was the night, but you were here. Yeah. Oh, I just didn't put my name down. That is the thing. Oh, man. Oh, you're almost there. Yeah, you got it. You got it in my dyslexia. We'll catch up. Oh, where do I find this link? It's on the GitHub somewhere, right? Yeah, let me put it in the chat too. I can find it. Yeah. I'm at least going to put this into my invite. If I get all the letters in the word, doesn't that count? Yeah. I feel about it. 100%. Okay. This time we're going to get out one's name. Yeah. Oh, wait. I'm going to do one better. Cool. Okay. Let me put this in my calendar invite too. Contributor strategy. Cool. Cool. Cool. Okay. This and following events. I feel bad that we didn't get all the people's names listed down. Karen was here. Josh Berkes was here. My spelling is the same, right? Yeah, you got it. I feel like is there someone else? Blah. I don't remember. Repos. Cool. Yeah. Yeah. Your question about a repo template, how does asking all sorts of questions this morning? Because that repository that had been suggested to me is where we could put the contributing template, the contributing guide. Sounds like maybe that's not the right place. So we're now looking at making a new repository that can be a template repository. Oh, cool. Yeah. So I know I said I was going to make a PR and take everything we had worked on and put it up there so that we could all a little bit easier to collaborate. You know, we can do like the normal suggest changes and kind of thing like that. Yeah. And other people could add commits and it'd be a little bit easier to collaborate on, I think, and you're not doing markdown. Oh, I see what you're saying. But it sounds like that's actually not the right repo for it. So I'm working right now to get us a repo created that'll be a repository template. Nice. And then someone wants to you know, make a new repo that either they're hoping eventually to contribute to the CNC F or it's already kind of a new repo for CNC F project, or they're an existing project. And they just want to take one thing like, oh, we're going to, you know, get an issue template, they can just obviously copy it. Just be things that are meant to be copied. Sweet. That's the idea. That's awesome. Yeah. Of course, we're still working it all out. But cool. Okay. Let me write that in my notes. Yeah. This is, this is the plan. So this is, let me show you the issue. Term strategy. The issue where we're chatting about, we're chatting about it in here. Because this is where we initially decided, oh, we would use CNC F contribute. Okay. That's where I had gotten that idea. Okay, first place. And now we're thinking of making another repo. So hopefully this week, I should have a repo for us to, to work on. And then we won't have to be doing all this inside of this. Okay. Instead, we could eventually turn. Oh, nice. Okay. So you can put some of the stuff in a website, the website be kind of like how to get started with your new project or something. Yeah. Like, you know what you did with Athens, where contributing almost had its own website. It wasn't just like readme's that you kind of had to plow through. It could be, because a lot of our guides and things like that, I think they're going to be interlinked. And I think we could, if we wanted to make it a standard website, eventually we were interested. Obviously it will start as just marked down. But our templates, I loved your idea. Like it should just be a repo that someone can use the GitHub template functionality. Yeah. Be able to just, you know, use this template, be able to click that green button and just have everything they need to get started with a recommended structure, you know, inclusive documents and practices, and they can just start customizing. Nice. That's super cool. Yeah. Yeah. So otherwise it's onwards and upwards with our contributing. Onwards. I worked this morning on taking more of our optionals. And what I started with on, yeah, here we go. Yeah. This stuff. So let's jump into that. This is just kind of hard to track what I've done. And I'm sorry, this is what we're still doing. That's cool. All right. So first was for ways to contribute. I think a great way to contribute would be attending meetings, actually. So I wanted to add that. Like it's your ideas, your designs, your presence, your interactions is helpful, I think. Yeah. So attending meetings, does that mean lurking or like lurking and then working towards something else? Or lurking and then working? Yeah. I mean, let's think about it. I mean, that's how I got started in every single SIG I've ever been in. I showed up to the SIG's meetings first. And I got a feel for things. I occasionally shared an opinion. I got to know people. And then I would do, when I was in a meeting, I would then try to fill in and do work. But part of contributing and eventually becoming a regular contributor and working your way up the ladder and feeling a part of a project is that interaction. So it's figuring out where people are and being there, too. Mm-hmm. So one of our items was communication, how to contact us, who to ask for help. Yeah. Right? And so I was thinking about that. Right? So if there is a Slack channel or a dev list, subscribe to the dev list and get in that Slack channel, get into the discuss forum or whatever it is. Yeah. The other piece of it is, is if there's a regular open dev meeting, you know, Athens had that for quite a while. You know, SIGs usually have something like that, too. Yeah. Go up. Probably, it'd probably be good to say explicitly, basically, what you just said about kind of the progression from just showing up to the meeting to sharing a few opinions to giving like substantive feedback to maybe coming up with your own ideas or opinions or a design doc or something more kind of meaty. So maybe just kind of describing that progression from your first meeting to your 10th or something like that. I mean, I do think it's perfectly fine and I've welcomed it when someone has shown up and this is their first time and they share an experience report or things like that. And people have shared like design ideas, too. It's just that if you want, I was just sharing one way to do it, which is a vague, I want to contribute, I want to just generally be involved and they didn't have a specific agenda, you know, that you don't have to limit yourself to just engaging with our issue queue. You can just show up and slowly get to know people and you don't have to wait to be invited. Oh, I see. The scenes, yeah, it isn't like that. You don't have to be asked to join our meetings. All of our projects meetings are open. Oh, so maybe it sounds like our Slack channels are open. Our dev lists are open. And we encourage people to passively engage and then if they're if they're interested, speak up, say something, say hi, you know. So is this more like, we don't expect you to come to the meeting, but we really would like you to come to the meeting and just have that that different kind of interaction? Is that what you're doing? Yeah, yeah, because I think that a lot of a lot of people I have talked to didn't know they were welcome. I felt like they had to be asked. Yeah. And I think it makes a difference to extend an invitation to people who have made it this far into the contributing guide to say you are welcome. Even if you have nothing to say, show up. Okay. And it's fine to talk if you have something to say or just introduce yourself. Do you mind if I read? We always have that usually at most of these meetings or in the Slack channels or in a dev list, just, you know, any healthy community that SIG contributor strategy would be saying is a healthy community would welcome this type of interaction with new members. Yeah. Do you mind if I write? Please do, because I'm saying it a lot, but I'm not quite sure how to maybe make this not be a long rambly paragraph. Yeah. So should I put it under like right here? Yeah. Yeah. I'll put like a sub bullet point. I just want to encourage projects to tell people to come. So like absolutely everyone is welcome to come. Any of our weekly meetings, you never need an invite to join us. In fact, we want you to join us even if you don't have anything you feel like you need, how you want to contribute. Just being there is enough. Few more notes. You can find out more about our meetings here. Link. Yeah. It's gonna be the read me is where I think we want to encourage people to put that. Okay. Is if they hold meetings, they should link to it on their read me. Okay. I'll put link to me info in the read me. Is that right? Yeah. Okay. You don't have to show your face. Oh, introduce yourself. Yeah. The first time you come introducing yourself is more than enough. Over time, we hope that you feel comfortable contributing, let's just say voicing your opinions, giving feedback on others' ideas, and even sharing your own ideas, experiences, and so on. Yeah. I'm like that. Yeah. Yeah. I don't think this is its own thing, not even like us, the whole thing. Let me change this. Yeah, please do. I want to pop this out. Oh, wait. I'm not very good at cool. Technology is terrible. How do I get this out of the bullet point? Oh, you got it. Yeah. Come on. What about shift tab? Yeah, that's what I was trying to do. Is it a thing? I have no idea. It was kind of a thing, but it wasn't really giving me the all the way there. I have an idea. Oh, wait for this. Yeah. Three of them. Is that a thing? Yeah, yeah, it is. I'm super proud of myself for three, H3 or whatever. I'm going to move this ahead of that real quick so that we don't lose that. That needs to go above that. Yeah. Because I just feel like it's important to just say that explicitly. Yeah, for sure. You know, the only thing I think is, I mean, this, I think this is a good thing for the record, but it's just getting people to put in their time synchronously. And I think really the big barrier is getting people to feel comfortable. The only way people feel comfortable is, and this is something that we can do, let me add this as I get to do, is, I'm sharing what you can do in typing. I really like, and this may be written up somewhere in Kubernetes before, is how to moderate meeting. So things like recognizing someone's hands up. Oh, yeah. Making sure that quiet people are given. Sorry, I'm trying to type with one of my fingers being in a jump. Oh, no. To speak, you know, all those just various things that someone's running the agenda. Yeah, it would be also really, I think it'd be really good to help people feel comfortable if either like, there was a link in here to the new thing you're writing here, and have the link just be like, if you come to the meetings, the moderator will be there to help you along. It's not going to be a shit show for lack of a better term. And you'll have a chance to, we'll make it a welcoming and comfortable environment. You'll have a chance to speak if you want to. Yeah, blah, blah, blah. Yeah, this would be a great piece of content that we could write for that repo we're talking about. Then maybe let's turn it into website content about how to actually moderate and run a meeting. And then someone could see like, this is how we moderate and run our meetings. Yes, nice. Yeah. Because this is what made it possible for me to show up to meetings because I have real hard time getting worded end-wise when I feel really new. So I love this. I would love to encourage more people to think about doing that, especially in groups where they feel really comfortable, so they're not sure if they need it still. The answer is you always still need it because someone's new. Yeah, yeah. Even if everyone is veteran in the meeting, I feel like it still can really quickly become a free for all. And then the next time, a lot of times, at least for me, the next time, there's just no motivation. Like moderators don't want to moderate. People don't want to risk talking and then getting totally overwhelmed with responses or even interrupted or whatever. Yeah, and as we talk about having inclusive meetings, having a moderator who's being conscious about these things really helps so that you don't have the same people and the same personalities dominate the meeting. Are you up for writing this how to moderate? Do you want to write that now or do you want to let it? I was going to make a separate issue and then see who was interested in writing it. I feel like I personally have not moderated many meetings and everything I do know. I've actually just done from what I've seen you do. Bad idea. So I know some things. Having someone who's usually not the main talker is the person who should be moderating and someone who has the right power or authority who can get other people to be quiet when they ask them to, who can move the conversation around. So you don't want to just give it to the person who can't say no. So there's certainly good rules to follow. We have the hand thing and things like that and then giving new people a chance to speak and then paying attention to people who may be unmuted and then muted again and we're obviously trying to jump into the conversation. There's things that I am aware of but I feel like there's more to it and there's things we could look out for because I bet some of this has been written already and then we could look for it and incorporate it. One thing that I hope would be written somewhere that I don't know the answer to is if you're a moderator what do you do if you want to contribute something? Raise your own hand. Get in the queue yourself. Oh yeah, yeah. Yeah but that's why when I often don't serve as moderator in groups where I or in meetings where I know that I want to talk a lot and I will step back and try to get someone else who won't be as active to be the moderator because it's hard to moderate yourself. That's the same thing why I won't often be note taker as well because it's hard to participate when you're trying to type at the same time. No taker. These are hard things to juggle because oftentimes it's the same two or three people who are willing to step up and do this so these are things though that if we can help provide guidance and think through about how to rotate gentle ways to nudge people to do things. By gentle ways to nudge I mean how to stand up and not be the person to do it every time. I mean you know that'd be good. That brings up that chop wood carry water thing in my mind. Is there a way to give out some kind of recognition for people who do that? I have no idea. Yeah so this brings me back to the contribution ladder. Hmm these are activities that should be accounted for on the contribution ladder and should matter enough to contribute to real roles on the project. Is there okay that right there what you just said really I have feels stronger than that. Yeah for a contribution ladder at least what I've seen is like a lot of people rightly I think rightly believe that when you rise up higher on the ladder you're expected to do really a lot more advanced technical work and technical leadership. So what I think is personally what I think is important for people to know is for this project you're expected to do the the non-technical stuff more and more and not necessarily the like writing the fancy new algorithm or whatever and that would be things like yeah taking notes or moderating or writing stuff like writing agendas or whatever it might be. Yeah yeah so so what we're looking at with a contribution ladder is it's a mix of some of it is project governance and that incorporates things like what it takes to get the project done right and includes like project management and triage and who makes decisions and bus ties and things like that but it's also the chopwood carry water of note taking running agenda chairs and all of the be the chairs not a glamorous role you know yeah it is every all the chopwood carry water yeah right it is just all the extra ministrivia that needs to be done to make the SIG work or the project work um and then it's the technical contribution side which is how do I get commit bit right yeah um and we have we want to combine it and have roles that acknowledge both um because we have roles where some people want to be able to contribute to the project purely from a project management standpoint yeah for example and they actually don't want commit but they just want to be able to help in different ways and I think we need to be able to have roles that work with that um I have worked with a number of people who make projects work who will never make a technical decision on the project ever but who offload 80 of my work and our contribution ladder needs to carve out recognizing respect their role on the project so kind of like a project or program manager type of type of role or yeah or maybe you know release manager I mean you know it depends how many people you have how many what hats you need to like spell out right how many when you have four people the hats you you don't have a lot right you have 600 or 4000 you get to have many hats and let people have very well-defined ones right um um so maybe that means for the template for the template site or the template read means or whatever it is yeah maybe that means suggesting some roles but also at the same time saying hey these roles might not be a separate person if your project is 50 people but we think these are really important to consider for any project yeah and this is also why when we laid these out here that we were trying to give people a wider variety of not all like feature code specific things as well to again just try to plant the seed this idea that there's a lot of things that falls on the shoulders of people who are running a project and there's many ways that people can contribute to to help shoulder that burden right and if you want them to help with it you need to recognize it yeah you need to call out for it you need to ask for help for it and you need to recognize it when they do it yeah so yeah this is gonna get themed that we need to like put breadcrumbs through and pepper throughout all of our our documents that we value it and um yeah we value it boom yeah and that you get rewarded slash recognized for it yeah you'll get you'll get recognized you'll get the title you'll get standing in the project yeah you know i mean another thing is oh yeah you put communication social media blog posts i was gonna say marketing but that's pretty much the same so never mind i call out marketing but then i felt that that was a really difficult term to understand the tasks behind so we tried to we tried to take that and split it into the tasks instead of the role does that make sense oh yeah the role in maybe marketing but what are the tasks behind it that they would be contributing yeah definitely um so that's why this originally was the word marketing cool uh so you have more there's nothing wrong with having more uh ways to contribute by the way um these were just what we've thought of so far i can maybe say like c i c health or gosh yes yeah i don't know how to say that the best way in it yeah no it's all the underlying processes to make the project yeah that's such a builds yeah oh sorry that oh you're suggesting you can edit that's fine if you want to i'm on my g-suite account so i can't edit sorry no that's fine maybe i can switch this will blow everything up maybe will this okay that's fine you can be the anonymous beaver yeah i'm just gonna stay it's like it wants me to sign in now i don't know it's a whole thing it's good no that's a great suggestion i love it that's definitely um another way to contribute yeah i mean yeah i i think there's tons more probably but it might be project specific or i don't know maybe these things it's like what you said if it's 50 people someone probably can do builds and x whatever other x thing or they can do new features and builds or whatever it is so maybe maybe these are good suggestions but not necessarily required i i don't know and i add one more i guess they are required they're just not required to have one different person for each thing yeah yeah and some of this is um you know we're making the template first but next this is going to be a guide that talks a lot more about this and gives people some new ways to think about how would you go about uh figuring out what rules make sense for your project uh i gotcha you know like porter's really small maybe we have five people we don't really have you know 12 roles right but as we grow we should have in our mind we may get a new contributor who could do just one of these roles for us and it would it would help us immensely so we shouldn't rule it out right yeah um but at the moment i may be wearing you know four of the five roles all at once you know okay sorry i kind of like got stuck on this um i mean this is an important thing for sure yeah yeah so that's dad's okay and then we want to link to come to our meetings again because other ways not everything happens through github right so we want to tell them just come to our meetings or contact us if they have other ways that they think they could help us right okay we have come to our meetings and then one second i'm gonna um um unbullet point that through the magic the magic of something go yeah there we go cool and then i added this i stole from Athens um about how to claim it yeah i don't know a better way than than that i want to keep it as low key as possible but i just everyone always asks me that yeah i want to work on it i can't assign it to myself how do i just say i want to work on it and really like let's not overthink it yeah i want to work on it because yeah yeah um so i added this how to ask for help i figured putting it right next to finding an issue um and i just want to give them like please just replace this which i would ever want you do um and uh whatever some people do everything through github but if you have other ways to ask for help then just tell people how to ask for help does this include if you don't know if you want to work on a thing but you don't know what good question i know it right now it doesn't but like i feel like that's almost a separate thing um let's just call that out separately because it always is a yeah it's like the number one thing yes i don't know if that should go here or should i think it probably goes to finding an issue actually uh find an issue yeah sorry it's my finger that's right over the uh the explanation point it's so hard to hit um i almost cut off my finger this weekend oh no but it grosses me out so i'm not talking about it okay never mind yeah it's fine it doesn't hurt anymore good can't be too serious then it's icky probably yeah and now that's recorded for the record her finger is fine it is not icky good um if you can't find an issue um um oh i have an idea go out one time it's done um sure yeah but you can't but you don't know where to start or can't find a suitable issue yeah say how you want books to reach out uh say how people can reach out to you for help finding something to work on happens all the time just gosh yeah i'll delete my part and i can delete this i think yeah it's just inevitable yeah especially i think in the kubernetes world um because a lot of people do it for work and their boss tells them to and they might just not be familiar with the project or tech or whatever well i mean because like the the flip side of this um so i just open the issue i'm gonna take the good first issue guidance that i wrote for kubernetes which is how to as a maintainer label issues what what makes a good first issue what makes a good help wanted but i want to update it with the how to make it not a huge burden to make those issues and find them and label them and like oh i see backfill all this info that usually they need that you don't have when you come up with the issue to begin with um that jennifer and i have been coming up with um so i want to take this and add it um but you know as a process you don't always stay on top of that right so people come to your project and you may not have any at the moment when they come to your project and so they're just going to come to you and be like there aren't any help which one should i work on you know i mean sometimes it's just as simple as that you didn't have time maybe we should call that out here like sometimes there won't be any issues with these labels yeah there is likely still something for you to work on something like that maybe i think that's good yeah we can probably make that more succinct but yeah maybe a start probably i think um for now let's just focus on getting the content and not worry about tone or verbosity or anything like that we can we need to sound serious later yeah very serious we're serious business people all right we do business we do business all the time oh my goodness very good this is recorded oh yeah to everyone watching we are serious business people um okay i'm gonna skip over the next one because i didn't write any content for yet i did write content for some other things here okay uh we had a section we wanted to do about signing your commits okay so i gave them options because i would say everything in the cncf with the exception of kubernetes does dco okay so i put that first and did something really generic that just explains how to do dco okay and then otherwise i have a really short one that just says we require you to have signed our cl a and then ask them to either explain it or link to the explanation for the cl a here okay um but otherwise i expect most people will just customize it and keep the dco part so is the dco do you just have to do one of these yeah okay and customize okay i think i have to sign out and sign back in to this meeting because my screen is flickering crazy i'll be right back you better we'll see i think so okay um there isn't anything to customize on the dco section um it's just the cl a that i mean i don't i'm not familiar with all of the the projects i just know that kubernetes is a little bit of the different one using a cl a and that everyone is encouraged to use dco's in the cncf um so i just kept it brief because i don't really know what other than we just want them to to say what the process is cool and the process is going to be different depending on the cl a yeah um and then i wrote a poll request checklist these are all the checks of poll requests must pass before it can be merged we recommend that you validate these locally before you submit your poll request so that your poll request is more likely to be merged quickly okay can i make a few yeah yeah so when you submit your poll request or you push your commits to it um our cicd systems will run some automated checks is that right is that the expectation that there will be some of these are going to be manual and some of these will be automated okay it's a combination of both so for example we want people to just know what is what their pr is going to be evaluated against okay so okay so their pr might pass the cicd stuff but there's still some stuff that might yeah so if you look down um micelle steering like did you write tests yeah that's something that will kick your pr back for but it won't have failed yeah the the poll request build um did you write documentation because maybe you added a new feature will kick your poll request back yeah so ideally you should write it up front so that your pr goes more smoothly okay so let me adjust this okay um when you let's see we would like or we require that your pr passes these checks but we have more criteria than just that before we can accept and merge it these are all the the so um we recommend that you run these so that you check the following things locally before you submit your code something like this i want to change cicd because i don't think that's a term that everyone knows okay so how about our automated systems will run yeah automated it's great we require that your pr i was right poll request now we're filling poll request out just to be friendly but we also have more criteria than just that before we can accept and merge it we recommend that you check for the following things locally before you submit your code um pass this test run the following command to run all of the tests locally yeah and the the comment above is for them to customize what's below oh okay because this is just an example gotcha okay i'll leave that alone yeah uh below and i i let me change that below is an example does that make sense though like yeah yeah for sure um so like one is the automated thing what can you run locally yeah just to know like so you don't have to hunt down what's their Travis file is going to run right yeah help them out but then also know what is the approval going to look for as well do you think that people are always surprised like what i need to i need to test i didn't know that people are always surprised um so do you think that those two lists should be split i think they have to be but i think like that could be up to the the person customizing it i guess okay how they wanted to do it yeah um one thing that would be really helpful that you did in Athens was explain how to set up see if you run the task set up what how you because like sometimes running the test isn't easy oh yeah and trying to find developer environment setup so you have our we have here how to test the source code unit integration test and and so that should be enough we just kind of hand wave and hope people know how to do that i think we're really useful linked to good examples from other contributing i think we should give them examples because yeah i feel like i'm often not given enough information on this oh yeah that's a huge turnoff you're like i have to dig through the code now to figure out what i need before this thing will run i mean i just had this experience where i went to contribute to a open source project and i got to the pull requests and they said well we want you to run the end-end test because we don't have it automated in our pr we want you to run it locally and tell us that it passed i'm like no thank you i wasn't able to get it to work um with pr never went anywhere it was kind of sad oh actually here's another one though um to run the thing locally oh my gosh the project yeah something yeah i knew there was a better word than thing yeah there you go it kind of goes yeah that's like really important it kind of goes hand in hand with testing to it doesn't it doesn't because usually when you do the tasks you're running like a test framework not the final service or command line tool or whatever maybe yeah another one i don't know how important the naming war is but it might it might be useful to say this is what we define our or this is where you'll find our integration tests this is where you'll find our end-to-end tests like this is our this is the difference between the two in our project and that is just because different people expect different things when they hear integration or end-to-end do you think that goes in contributing or do you think that goes in like a development.md yeah probably the latter yeah you're right let's just add a comment so we remember that though i guess probably like unit integration and and and i guess everyone uses different names and like i picked integration some people call them functional some people call it system whatever you write yeah i've just seen i've just seen so much like so much confusion or debate over what are these things how do they fit into our project yeah so it'd be cool to have like the go-fumps version of this like these are what our names are yeah it doesn't matter what you think is right it's just what this is what we've defined for this project totally and we're not we're not saying what terms to use we're just trying to say whatever the project uses yeah this is how you run our tests yeah cool um yeah so the one part is skipped over just for a comment here um this is optional section we encourage you to think about your pull request process and set expectations for contributors and reviewers um so let's back up go back up to the goal for this section how do you how does the project stand top of pull requests pr timeline sets expectations for maintainers and authors on what you would ping etc um so like porter has won i'm not contributing um and so we have we have a couple things one we have how to get your pull request reviewed fast and we tell people a couple different tips like use draft prs uh limit your pr a single path task don't refactor and do the thing at the same time uh grouping commits uh make your changes in new commits because you know if you just keep amending the same commit it's really hard to review we talk about follow on prs and then we also have this which is like the pr timeline and we tell people like you make it you submit it up somebody assigns themselves so that you know that they're on it we tell people three days if you know one assigns themselves after three days ping and we tell people how to ping um so that that last sentence right after ping i think that should be surfaced at the top to just build a little empathy like that's really and you know how it is it's this is asynchronous there's no faces or voices involved yeah so just have people just to have people have the expectation that hey we're humans you know we're trying but we have day jobs we have lives yeah we get busy we have to go and you know we have to rest that just all of that just to put a human element into this whole section yeah maybe even the previous section as well or instead i don't know yeah agreed um and then we kind of explain like the types of feedback you can get and how to put some context on it like it's okay to ask do i have to make the change um and again saying it's okay to bump and ask if you don't hear about and then letting you know that if you want to rebase and deal with your own commits you can let people otherwise they'll squash it for you and then how to get your code when it's done cool that last part is awesome so something like this um that obviously the project customizes to what their thing is you know we say three business days because carol's paid to do that um you know like people can do whatever they want but like something like this to get people thinking about it i think you should link to this or copy this yeah either link to it or copy it in because it's hard to know how to say these things without sounding crappy i guess you think there's anything that we can put in the template or do you just want to link to it and maybe another example or i don't know many examples like this to be honest this is like this is what i personally wanted so i wrote it yeah i don't know any of the other examples either um let's see i think the key things for me as a maintainer i see it from the maintainer and from the contributor viewpoint so for me as the maintainer being able to figure out if they're ready for a review is big um definitely the single task thing is big um and then setting that expectation of when i'll be able to get to it definitely setting expectation that i'm a human being uh and i i guess those are the top things there's there's other obviously but if i had to choose just a few that would be the ones can we okay wait wait wait wait oh i'm scrolling i'm scrolling to try to maybe decide right i think i can write it in somewhere yeah here it is the polar price timeline let me go up up up where are you okay so i want to put this because what you said is what i love use this to set expectations for both reviewers and contributors yeah yeah and but then you had a lot more yeah let me try to write this here okay so for reviewers when the yard is ready for a review when um the contributor should expect initial review and or actually when to expect follow up reviews when how can you pull up the porter one again yeah i think that was it oh yeah and then telling contributors that you are a human and things happen these aren't i'm set in stone it's on best effort something like that tribute tours i think that's how you spell it so for contributors um so this one is like kind of the same how to indicate work in progress versus ready to review how to handle orphan yards that you can't seem to get reviewed how to handle how to handle follow up yards how to keep your prs small and focused i think that would be a good for yeah as i did for for the reviewers and i'll just keep it to four for contributors also yeah so so let's not use word orphan but we use all the stock prs yeah about that all the prs and issues um how do you uh yeah oh yeah follow up issues maybe something about do you need to have an issue before you submit any kind of pr or is it okay to not yeah yeah um so we put that in our contributing guide and a number of other contributing guides put that in theirs as well that they as an example uh usually like you'll see something like this like it's okay for tiny things but if there's anything where it's like it could be misunderstood what's the motivation or what's the solution there needs to be an issue first we need to agree upon the solution first we're going to need for the fix yeah um also we were going to put that it's in the um it's in the issue template that we're going to add oh cool so it's going to say that when they open the pr cool like let me show you uh oh wait it's a whole lot of stuff but so we'll like prompt them we can prompt them I mean we can be very explicit here like you've got to tell us what what issue you're closing unless it's you know meet some criteria so we can be more explicit than this actually um so that may be helpful too nice okay I suppose maybe the project for whatever reason doesn't care and they just don't they just want prs and have to have the discussion the pr yeah I don't think it has to be in the contributing guide um it's like a must-have you know yeah I think that's something people could customize and decide to have or not um cool because some people don't care yeah some people do give us your code and that's all we care about because some people have no problem just closing a pr good oh well that's a good point time right there too like for contributors well should you feel bad if your pr gets closed and then for reviewers like is it okay to just close it what should you put in a comma something like that to set kind of expectations maybe to prevent hurt feelings so this is the pull request timeline it's saying when you interact with our project this is what you can expect it's not a guide for how to run a pr though oh okay I got you yeah we will have a guide okay about how to do a kind pull request oh cool all right in the future and that that's what something our working group will do cool you know what I mean yeah it won't be in the contributing guide itself so it'll be one that's just for reviewers yeah okay yeah it'll talk about how to how we expect what's our our like base level of like in order to be a reviewer on this project this is what we expect out of you um it'd probably be nice still to tell contributors hey there are a few kind of general cases where we might close your pr we'll make sure to tell you why but don't feel like we're not doing it as a personal insult to you we're doing it for reason x so that the project stays healthier I don't know whatever it is if if in the project it becomes a thing that maintainers find they have to close prs maybe yeah it goes in the contributing guide or I don't know it's just a thing as a reviewer I've I have feels because there have been times where prs have been kind of like they haven't been stuck but they've just been kind of dragging along and it's clear the contributors not into it anymore yeah I got one of those right yeah right so it's like it would be better for everyone honestly if the contributor was left off the hook or was let off the hook yep and they would free up the reviewer's time yeah I still think that would be better in the guide though than in the contributing the guide oh okay you know what I mean the the document where we have a lot more space where we're almost training and saying hey you just got promoted to being a reviewer here's some advice oh yeah we've tricked you into reading you know yeah oh yeah I get it whereas the this document is going to be read mostly by a new contributor and I don't know if we want them reading a thing that say we're probably gonna make closer PR welcome now yeah this is real yeah so like Porter for example is something that says this just for reviewers and it says like how to review a PR here's just some values you need to keep in your head that you can use to like judge how to make decisions yeah and whatever and then like what are the requirements gee Carol where did you get your merger requirements from yeah that's where I still are from for our doc so dude is this a document that anyone in the community should read oh no it's okay so is there a document that anyone in the community who just wants to write some code or do some docs would read this is just for people who have reviewer writes I mean I can read it obviously you can I can anybody yeah it's just people who can merge PRs on board yeah which is a very small group but so oh so you have a contributing dot md and that is what everyone should read if you're a contributor okay and then if you were a reviewer we have a reviewing dot md so if you can't meet these you will no longer be yeah you'll lose commit fit and to be honest like the things the things in here that matter is respecting people's time and for example um be kind like you can't be kind you can't stay on as a reviewer yeah so someone who is a contributor can read this and go you're not being kind you're not respecting my time you're not whatever yeah you know okay you are asking me to rewrite it in your style you are asking me to optimize for performance but without giving you know whatever you know it can it can be used in multiple ways I see we don't we're not a big enough project yet to need this but it's can be used to prevent someone who for no reason we could prevent them from becoming a reviewer but it then becomes a parent as a reviewer that they're not suitable they're not helping to keep an inclusive community yeah we can point to how they're being a reviewer against this document and then knock the back down to at least contribute if not not on the project at all I got you because some of these are very hard to to do if you don't actually have the same values you can't give lip service to some of these I guess is what I'm saying yeah I totally get that yeah I misunderstood this who this document was for oh okay yeah sorry oh I I totally get it but now I understand like who should like who you would give this document to yeah it prevents people from weaponizing our contributing ladder against us mm-hmm yeah cool okay that's the hope so that is the reviewing doc and you mentioned a contributing doc and that would that be for is that for just anyone who comes to the project and wants to write code so this is the this template right here is the contributing doc right yeah yeah so if you are a contributor this is what you must follow mm-hmm and it explains what to expect and what you must do in order to be allowed to contribute and then it's alternate for people who have the reviewing role is that other doc okay so should we should we have this for reviewer section here um I think what you've done is really great because when we think about here the life of the pull request we didn't want to take all of this right we wanted to somehow generalize what were things that you should think about if you wanted to write something similar okay and and uh these are things that you would have to think about okay as a contributor so okay yeah so I think that from a reviewer standpoint what would you want to think about as a contributor what would you want to think about yeah you can articulate some of these things any of these things please write it down in your contributing guide okay I think I get it okay yeah I think I get it enough okay we I'm not explaining this well we need to put some more words here um I have a feeling you are and I'm just not I'm dense right now oh I think we've gone over at this point I'm sorry about 15 minutes um I'll work on adding the introductory text for this and kind of set up the questions here like these are this is a like prompt yeah for you to go through an exercise and after you've gone through this exercise you can create a timeline for your own project mm-hmm how's that sound yeah it sounds good so I'll I'll I'll tweak that so that can I put some matter what we're doing here okay is it okay if I put something here of course okay SDA off is great yeah maybe just that to really clarify like we don't expect this but try to do something like this yeah so I think we're doing really well here on our contributing guide um I think we have two more things um and then we'll have hit all our topics so we're good uh I'll try to get that template PR done or template repo so we can get this in there okay and then maybe we can get uh a couple more eyes on it and see what people think try to word Smith a little bit more now that we've got like the main concepts laid down cool thank you so much I'm so glad you joined our working group yeah this is really nice to have this have this uh I don't know vibe effort um a big in a big organization haven't really seen this ever before oh my gosh I'm gonna immediately use this repo template to like make already we both yeah I'm gonna pull stuff to from here to Athens it's gonna help a lot for many things it's me good yeah cool well thank you for your time sorry we went over thank you this was great later later