 All right, welcome everybody to the April 20th hyper ledger technical oversight committee call. As you're probably all aware to things that we must abide by on the call the first is the antitrust policy that is been displayed on the screen. And the second is our code of conduct which is linked in the agenda. So then, for announcements today we have our standard announcement, the Dev Weekly developer newsletter goes out each Friday. If you do have anything that you would like to include in that newsletter please do leave a link or comment on the link that's in the agenda. The second thing is a reminder. So I think it was a couple weeks ago heart had shared the security policy vulnerability disclosure template draft and asked for us to provide feedback. I know there's been a couple of people that have provided feedback for that but please do have a look at that and provide your feedback for heart so that he can make forward progress with that. And then any other announcements that anybody would like to make today. Sure. This is just for people that opted into the large runner beta. I apologize for the turbulence over the last week. I've talked to GitHub for quite a while. What I've done is set up specific groups for the runners. So that one project does not starve all the other projects. I'm working on adjusting the limits. They were set wide open at the beginning I think I've set it to five by default for projects that are in incubation state and a much larger number for projects that have graduated. I don't remember what that is off the top of my head. Let's just take a look in that really frustrating thing is you have to set that limit per type. So they have fabric has 25. They don't use windows that much they have five now use a bunch of latest that much they have five. So they're mostly using this so that's what I've set. If you run into really long delays please just reach out and say hey. Help me out. So. That's all I want to say. All right. Thanks. Any other announcements that anybody has would like to make. No. Okay. For quarterly reports we did get the fabric report in this week Dave thank you for that. If you haven't had a chance to take a look at that please do so I do believe there are quite a few outstanding reviews that still need to happen. So, but as far as what I've seen so far there are no questions or comments on that particular report, but any. Are there any questions that anybody would like to bring up here in the TOC meeting about the hyper ledger fabric report. Now, okay. And then for past two reports, the transact report a room did reach out last week after our call directly to Andre and Sean regarding the pull request. It has since been merged. The interesting thing about that pull request is the way that Peter wrote it basically says that the hyper ledger transact code base is now maintained as part of hyper ledger sought to library repository. It has been revised to me that we could think about the end of life for hyper ledger transact given the way that that's been stated is that it's no longer maintained within hyper ledger transact. Any thoughts on doing that. Peter. I agree. I think it makes sense to end the fly fit. But also, it doesn't matter too much to me as long as we have that link and the explanation saying go to the other link because that's where these this being maintained. Yeah, I could also see someone making the argument that end of life in it makes it sound like everyone just went home and it's over but it's not over it just moves over into thought to. So, I would also be willing to accept arguments like that why it shouldn't be shouldn't have some sort of big end of life sign on the GitHub repository. More interesting. As a question is the website. Like to be to be merged to two projects on the websites. Probably us. But yeah, to me nuts. That's more important. In my opinion, then the GitHub repository and the fly thing. Thanks, Peter. Any other thoughts on that. As someone that doesn't have a vote. I'm for it. There are a month late on this report. They said that the stuff move somewhere else. And selfishly, it would make my life easier. If we didn't have dead projects. The people ended up in in these contribution pathways that are over. All right, actually someone's two months now looking at the dates. Other other thoughts. Daniel. Just want to let everybody know. And I will again. And I will have a short review. They say the retailers do. What's being proposed and discussed. And hopefully by next week, they will show up in that. And talk to the team there. And Daniela. I guess the question that I have for you. Obviously knowing that you're driving. Should we think about creating a, an issue like we did for grid where we reach out to the maintainers to market as end of life? Or should we wait for. The conversation that you plan to have with Sean. I think we need to wait another week. Okay. Okay. Right. Did I just hear their reports just in one month? It's actually two months late. Okay. No problem. So we will. Yeah. Thank you, Daniela. We'll wait for that. And then let us know, Daniela, we can always open an issue like we did the last time as well. Just to get that resolved after the conversation. All right. So then the next one that we have is Ursa. That is. Just a month overdue for Ursa. I know there's been some comments. There was a reminder sent out on the 13th with a response that came back asking where do we submit this? So we will, we'll get a room to send another reminder today to see if we can get any sort of additional updates. My guess is obviously with IW this week, there's a possibility that people are. All right. IW and not necessarily taking a look at what needs to be done here. So we'll send out a message and see if we can get a response back on Ursa. Any questions, additional comments on the past two reports? Nope. Okay. So for upcoming reports, we do have the sawtooth report that is due next Thursday. So we'll keep an eye out for that and see if we can get the sawtooth report coming in. All right. So then as far as an agenda for today, topics for discussion, we do have a task force discussion on project best practices. Before we get to that, is there anything else that people would like to discuss? Anything else that needs to have the TOCs. Okay. So we can look at anything that we need to discuss. If I may, we are not late with your report, right? No, I don't think you're late with the Aroha report. I think that one's coming up soon. Okay. Oh, that's it. Okay. Right. Always going to do that too. Yeah. So May 11th is the next time that we've got the Aroha report to. Any other discussion items for today before we hand it off to Dave to walk us through the project best practices. Right. Dave, I guess it's up to you. Okay. Let me share. Okay. Do you see it? We do. All right. So going back up to the top, we've made a lot of good progress in the last few sessions going through these best practices. I think it's kind of, it's met my goals pretty much, I think in terms of providing a survey at kind of a high level. Summary of best practices with, of course, deeper discussions and other task forces and that type of thing. We're coming to the end of this. And I think we'll probably finish it out today with the last two sections around GitHub. Configuration and GitHub workflow. Suggestions. After we do this, then I can push a pull request into the TOC space to capture all this for eternity. Of course we'll, there will always be other task forces and things. So this will be a living document that I think we'll update over time and also have a lot of links to other good information out there. But I think this has been a really good survey. So let's dive into GitHub configuration today. This one's a little bit dry, but so it's good to define your GitHub configuration in settings.yaml so that they can be managed and tracked via pull requests. And I have an example here of fabrics and not saying fabrics is the best, but this one is pretty cut and dry. So there's nothing too opinionated here. I think the next one branch protection rules, there's a little bit more leeway for opinion. And it kind of gets into the weeds. So I don't know if we want to go through that in detail here. I was thinking maybe of going offline with Ryan and anybody else who is interested if we want to suggest a best starting place. But if you're not familiar with branch protection rules, let me just show you in fabrics. This is where you can really get into the weeds of the GitHub configuration. So there's just a whole lot of options. You know, some of these, I think we would definitely, as a TFC and staff have suggestions on, there are other ones that are probably up to the project. But it might be good to go through these with a smaller group of people and figure out which of these do we actually want to recommend. What if folks think does that make sense? I don't think you want to go through each and every bullet in this meeting, do you? There are some things that I want to, I would like to point out if you scroll up a little bit. So the, yeah, scroll down a little bit more. Sorry. Okay, keep going down. The require linear history basically does a rebase, gives you the rebase option on merge. And if you're trying to keep merges out, require a merge queue. I know that Bezu messed with that for a while and they found that it was really difficult to get working well. If you scroll down off this page, which branch is this for? Scroll back up a little bit. Do not allow bypassing of the above settings is either here or there. You have to think about who is going to do that. It's going to be people that are administrators. And I thought there was another setting in here. So do you see anything that we should change here? Do you suggest that we do this linear history? No, that's, I was pointing out because it's kind of a weird setting. I like linear history. I don't like merges. But I agree. But so would you recommend we check that one? It's, I would recommend that you do. But it does mean another round of CI. For merge. So it does make it slower. So they're pros and cons. Okay, so we'll leave it up to the project. Yeah. Yeah. And I'm looking for the one that says PR must be up to date before it's merged. Yeah. So that, that check box. Like triples your CI time before you can merge something. So if your project has this set. I would say don't do that. You know, it's because if I'm on a PR. And this box is checked. And I have merge approval. That means I need to rebase it to on main. Run the CI and then merge it. And then that runs the CI again. So you're running the CI when, you know, for it to be approved. Before I can merge it and then after it's merged. So I would really. Council against enabling that particular feature. And I think that's the only thing. That's the only setting there that. Really makes life hard. So maybe what I'll do is take a screenshot of this when I do the pull request. Assuming this is a good place to start. And I'll highlight some of the ones you just mentioned there as, as ones to consider checking or unchecking. Sure. And then last, so if you scroll down to show that status checks required. So that you were on it. And you can see that that window that says GitHub actions, the required status checks. I would say. Keep this. Limited. One way that you can do that is by using reusable workflows. And have a workflow. That's kind of the. The first Merck workflow. That the other ones are dependent on. Make. The success of that workflow depend on the ones that are important. And then just have that one or two of these checks. So DC OES, but all these integration checks, there might be like an integration. Test. Workflow. That consumes those workflows and reports one action. What that allows you to do as, as a maintainer. As you can change. What is required or not. Based on. What, what tests that consumes and you don't have to come in here and fiddle around with this interface. So it would make your life easier. So I think that's it. Peter. The last sentence you just said. I don't understand. I don't know very well how the workflow slash actions. Connections go. I'm going to take a look at some, some links. YouTube video. Anything that I could look at for details on how to. Check that out. Sure. The term that you want to search for, I'll get a link, but the term that you want to search for is reusable. GitHub action. Or using reusable GitHub actions. And that will. That will show you. And yeah. It will make life easier because then you can just edit the. When you check in a workflow. You can edit the dependent workflow. And if, if you don't want it to be required. You can set the. You know, if fail, don't worry about it. In the mass in the primary workflow. So I will dig that up. And I will show you. Yep. Primary workflow. But for me to set that up, I would, I would still need to send the pull request with the YAML change. Right. But that gets you away from having to go into the. The, the GitHub UI. And mess around with making certain ones require certain ones not. Okay. Okay. That sounds good. Anybody else want to highlight any of these settings? Okay. So like I said, I will take a screenshot of this, put this in the pull request. And highlight a few of the ones that I mentioned. David looks like Peter racist. Peter. Yeah. Sorry. It's me again. I just wanted to say that. One little optimization I found. Is if you. Merge. By hand, but on a rebase. Branch. Then. You can keep the same. Commit hash. On the main branch that you had on your feature branch. You just have to merge on the command line. And with the option that says fast forward only so that it does not create a merge commit at all. And if it was forced, then it actually just fail instead of doing the merge. What this does then is. After you merged. It is the same commit hash. So the CI. Does not need to redo everything when it went on the main branch. And. Calling slightly off topic with it, but the other good thing about this is that it preserves. The. Signatures, not the sign offs, but the signatures. So if you ever saw. A commit log on GitHub that had the little green label that said verified next to commit. That's because. The pull request was merged in a way that. The commit hash remained the same. As it was when it was on the feature branch. And this is kind of going into the other thing, which is the security. Aspect of everything, but I just wanted to put it out there in case people didn't know. Okay. So in one bullet, how, how do you do that? Rebase with fast forward option. Of it fast forward only option. So it's a dash dash. F F. Dash only. And then it's not rebase it's merge. But you do have to rebase it first. To make sure that the fast forwarding is. Feasible. Thanks, Ryan. Yes, like that. Okay. Yeah. So you were jumping ahead to the GitHub workflow. That's fine. Ryan finishes that. We can finish out the GitHub configuration. So the other thing I was noting is the code owners might be good. So if you have different owners per directory, this is where this comes in handy. I'll show the fabric example of this. So we have a separate set of doc maintainers or additional set of maintainers that can also maintain the docs. So we have a docs directory. So this is, I think, pretty common for GitHub projects to use. I didn't know about it at first when I was new, but it's a good thing to highlight, I think. And then lastly, using pull request templates and issue templates can help guide your users into opening good pull requests and good issues. And you can also do things like point out the discord chat channel. So in our issue template we have, let me pull it up. If you go to open a new issue, you get this template saying I want to open a bug or a future request. But you can also, we also say if you just want support or help, we have discord and a mailing list that you can go to instead. So you don't get a bunch of bogus issues that are just user questions for help. And then the pull request template is kind of the same thing. You know, you can make sure that they specify what type of change it is. If there's a release note needed, make sure that they run the checks themselves, that type of thing. So just a good thing for new contributors to be aware of as they're opening pull requests or new issues. Any other thoughts on these? All right. Hey, can you all hear me? Yes. Great. Sorry, I'm in the car as well. I would like us to consider more strongly recommending code owners. I get a lot of questions and I think other people do as well about, you know, people who are interested in a project. And they want to know who to talk to about some particular feature of the project. And the code owners makes this really easy to find for them. And, you know, potentially, you know, decreases the number of communication hops that they have to take to get to what they want. And, you know, sort of each hop has a chance of failure. So I would, you know, I don't know what other people think, but I would think that we would want stronger language on code owners. We also have the scope field in the maintainers document that we just recommended people do that might, that's more a little bit more free form way of doing the same thing. Yeah, either way, I think would be good. But I would like it, I think it would be great if we, you know, required or strongly recommended one or something like that. Because the code owners is a little, you know, that impacts your ability to maintain the file. So it's good information, but it also might be a detriment in terms of the project maintenance because often any of the maintainers can touch any of the files and sometimes they do need to. If we start putting a bunch of restrictions and code owners, that might tie the hands a little bit. Okay, so you think this is better in the scope? I kind of do, but maybe the thing to do is put a note in the code owners to see the maintainer scope list for kind of the more free hand way of communicating this. I think that's fine as long as this information is easy to find and communicate. You know, I'm okay wherever it is. So yeah, if, if, if you think that's too restrictive on code owners, totally. Well, I think it'd be project by project. Yeah, so I agree. I think code owners is the way to go for giving people the ability to do things, but not everyone that has the ability to do things is necessarily wants to be contacted about, you know, they're not the subject matter expert. They're just one of the code owners. So I like that having the note to say, hey, if you're trying to figure out who to talk to, please look in the maintainers file. As long as the maintainers file is up to date. Okay, sounds good. And one of the projects I'm working on in my infinite free time is to set up sheriff, which is a CNCF project. To maintain or ownership. I see you, Peter. The what that would allow us to do is have one repo where all this is expressed in terms of who does what, and then it automatically gets updated. But I took one by that apple. I could need it. And I'm getting ready to go back against it. Okay, anything else in configuration we want to mention. All right, so let's go to work flow. So anybody who's used to getting GitHub knows that there's innumerable ways of doing things with the same outcome. But I think there is value in defining a suggested path both, both for new users that are getting, getting up to speed on GitHub. And for the sake of project consistency of in ways of doing things on a certain project. I'll jump to the last bullet first. So in fabric, we have this. We have this. GitHub contribution suggestions. Walks you through everything from forking and cloning. To creating a feature branch. Opening a pull request amending a pull request. Cherry picking the pull request. Cleaning up your branches. So a lot of, of course, this information is all over the place on the internet, but it just was really helpful to put it on place and to have some suggested practices in here as well. For example, we recommend amending commits rather than squashing just because it keeps the commit history cleaner and the pull request description cleaner. So we can kind of put little suggestions in these types of documents as well. So I think that's been really helpful. And I've pointed a lot of new users to that document. In terms of the, some of the opinionated things. We prefer the rebase merging to keep the commit history clean a linear path. I think that's aligned with what Rai was saying and what Peter was saying as well. Does that make sense guys? It's a little bit opinionated, but I think it's. It's been a good thing that we've done. Like I mentioned, we'd suggest users amend commits. So if you don't really care about having tracking the full history of all your changes in a pull request, it's better to amend the commit rather than squashing it and having your, your porters pull request description stomped on. We use a couple of hands. Sorry, Rama. Sorry, just a question about the fabric guidance. So it doesn't look like it's specific to fabric and it looks like a lot of good information that all of the project could use. So what should we do? Should we, do you think it'd be good to move that to a more centralization or should different other projects which do not recreate the same document just linked to the fabric? Yeah, you're talking about this one. Yeah. Yeah, that's a good idea. It depends if there's enough agreement among the other projects that this is a good path. Okay. Are there other hands? Yeah, Peter's going to send up. Peter. I just wanted to say that the line that says amend commits instance question commits. I agree, but I would add something to. Clarify that if you already have multiple commits, then. I would recommend to squash them anyway. Just don't get into that state where you have to squash them and amend. Instead. Okay. Thank you. Right. So what I would recommend. Since we're basically recreating. Garrett via GitHub. Is that if you have a long chain of commits. Each of those commits. There's a good. Great. Great. Great. Great. Great. Great. Great. Great. Great. Right up that I'll find a thing on unlike what is a good commit. Each commit in your chain should be a. A topic or a, you know, a thought, right? In this commit, I'm changing. The way that this functions and adding tests. And then in the next commit. You can do a. I'm changing. Like some other thing. So, you know, that's. And I will point out that if you do a get rebased. That dash I. You can change the order of commits in your history. So you can go through and pick like the four commits. That were one thing, move them in one place and then set them to be, you know, using F instead of S. You can use F to, to fold them into one commit. And that way you present a linear chain of your. Of your. Of your progress. Separate into, into each commit being a topic or a part of that progress instead of the 400 commits or whatever that it took. You know, it does make get bisect a little bit easier. However. I would much prefer the way that. That you just outlined where, you know, each PR is small enough that it's just one commit. So that's, I don't know. A long way of saying, I love Garrett. You're. Sorry. Is it Peter. Yeah. Go ahead, Peter. I. I feel bad because Rama still has his hand up. No, I think you, you put your hand up. Oh, okay. Sorry. I, yeah. Okay. Okay. Then with all that said, then we should, we could also put down. Could or should. That. Next to the commit amending suggestion, which is that if you're commit crows to be. More than one logical, clear thing, then you should just open multiple port requests instead of stacking a bunch of commits into a single port request. But I don't know how deep this rabbit hole. Just want to clarify. So we have several different commits related to different features. We've only be able to. Combine those features. Corresponding to, I mean, combine the comments corresponding to a particular feature into one if they are contiguous, right? I mean, if they're all interspersed. Like. Do that. I mean, if I, if one commit. Is the. Related to particular feature one. Next time it is the feature to the third coming to feature one. Then it should work. So. What you can do. If I understand is if you do the get rebase dash I. You could. Change the order of commits. So that the two feature ones were next to each other. And then you can squash them. Okay. But if they're really two different things, you might want to make that two different pull requests. Right. Rather than squashing them into one. Could, could I share my screen for a second, Dave? Yeah. So I just picked a random repo. And I did a get. Did a. Get rebase head and dash three. So what I could do is go in here and say. This is actually part of. Because you come before that. And then I could go down here and say, you know, either ask to squash it and preserve the commit message or F. And fix it up. And then you have all the options down here. Like break, drop, label, reset. So, you know, get rebase dash I is. A really powerful tool for controlling your get history. So I would suggest taking a look at that. And I don't think that's available. In any way in the. You can go ahead and share, David. Okay. Yeah. I mean, we could go on and on with this, but I think rum is initial point is good that. Maybe we take this. Contributions doc with kind of the suggestions in it. And make this. Something on the. Hyperledger site instead of just the fabric docs. And then I misunderstood this question. I apologize. Yeah. So I don't know where we put this, but we'll find a place to put this and maybe open a pull request. And we can, people can inject their own. Ideas like we can, we can put the rebase dash I in here and things like that. I think that would go in. In the talk. Recommended practices thing. Okay. So that's where I would park that. I don't know. Tracy thoughts. Yeah, I think that makes sense. We have those guidelines on the talk site. We probably put that there. Yeah. I mean, we have to be a little careful because we can end up rewriting. Good documentation. If we go far enough, but. Try to keep it to the main points, I guess. Thanks Tracy. So I do want to say that I talked to some people at IW yesterday who are interested in submitting a new project. To hyperledger. And one of the questions I got was, you know, just a bunch of stuff about best practices. You know, taking developers who aren't used to open source and getting them. Into, you know, following open source best practices. So sort of, you know, the more the more public invisible, we can make this. And even the more detailed, I'm fine adding all of these extra details and tips that people have because I think people really appreciate it. Okay. Peter. One more thing I would add to either the top or the bottom of that document that ends up on the website is. Some reference to one of the discord channels where people could go and ask clarifying questions about this because I know that everything I know about get and how to do these things or how I like to do these things formed over years of trial and error. And I know from memory that. If you showed me the best practices that I am recommending today, if you showed those to me 10 years ago, then I would not have even understood half of what you actually mean by doing these things. So I think a lot of people would need some sort of more specific guidance. But obviously the documentation itself cannot answer all of those questions in advance because I'll be just impossible. And the giant rabbit hole. That would just lead to us updating gets documentation itself. So I would put a reference to some discord channel either an existing one or a brand new dedicated one that is like. Get help line or something. We also get a lot of requests. For. A lot of people show up in general. Skip through, you know, skip past the signup screen that says if you have questions about this, go here. And ask where they should ask questions. I would recommend I think that. So we have general we have like pound fabric. There might be. I don't know, like pound fabric dash newbie questions or something like that. I'm wary of 8 million channels. But, you know, it. We would need people from the project to be there to, to answer the newbie questions. So I, I don't know, I guess I don't have a fully formed thought about that, but. I will create the get questions channel. Yeah, I think that's a general one that would span across projects, right? Yeah, just general good questions for hyperledger users. Peter. I can volunteer to monitor the channel. I feel like I've gotten better at answering the questions. Just because a big chunk of the pull request previews that I do, or basically just do this fit get to do that with it. And then the contributors being like, what's what does that even mean? And then I have to explain it. So I anyway have plans to produce YouTube videos as well to just show what I mean. And me volunteering to help out with this channel and monitor it, they'll probably push me in the right direction of actually making those videos reality. All right. Peter. It may not be. But yeah, tag. They can tag me on the channel so that the knowledge is reused and I am not answering the exact same question 15 times every day. Good luck. This is good. I know, I know. And I just, I was just going to say, right? I just saw your get help channel show up. Yep. And I tagged everybody in there so you can see where it is. And I think you all have permission to edit the channel. So someone wants to. Make it less basic, please go ahead. And what's the name get help. Yeah, get dash help. Okay. Okay. Any other hands up. All right. Any other thoughts on these two. Okay. So like I said to summarize, I will create one pull request for this document. And then I'll do another one. For an initial. GitHub contributions document. Okay. Any parting words. Okay. Well, thanks everybody for the input here. All right. Thanks, Dave, for taking us through that. Thank you. Is there anything else with this task force that needs to be done after those pull requests? Or do we think those pull requests are basically what was intended to be accomplished with this task force? I think that'll be close to being it, but maybe put me on one last time on the agenda and four weeks or whatever it is. And we'll see if there's anything. There's probably a couple of loose ends that need to be tied up still. Okay. Sounds great. So thank you so much, Dave, for taking us through that today. Any other topics or anything else that anybody would like to bring up before we close for today? Nope. Okay. So I guess then for next week, we have the security task force as a reminder again, please do review that draft that heart put out there. Provide your comments and feedback on that. And I'm sure we will want to do a final kind of close out on that in the discussion next week. And with that, I will let you all go off to prepare for your next meeting and have a, at least a couple of minutes before then. So thanks all for attending today. We will talk again next week. Thanks everybody.