 All right. Welcome everybody to June. It's June 1st. And this is the hyperledger technical oversight committee call. As you are probably all aware. Two things that we must abide by the first is the antitrust policy. So we do not participate in any any activities that are prohibited under any antitrust or competition laws. The second one is our code of conduct, which is linked in. So for an announcement today, we do have the standard announcement of the deaf weekly developer newsletter that goes out each Friday. If you do have something that you want to include in that newsletter, please do leave a comment at the link that's in the in the agenda. For quarterly reports, we don't have any quarterly reports that are due today. I don't think we have any outstanding quarterly reports. I think they've all been merged. So thank you all for that. We do have still the sawtooth report that is past due. I haven't seen anything on there since last week. When I spoke to the sawtooth community so we're still looking to get that in to us. As far as upcoming reports we do have the cello one that is due today, and the firefly one that is due next week. Any questions at this point or announcements since I forgot to ask if anybody else had any announcements. Victor. Thank you. Well, there is a small announcement with the message in the chat. I've published the LFX mentorship platform issues. It is an article with the things that we can actually improve in LFX platform. So we request these changes because the use of the platform was really inconvenient so far. And hopefully it helps. I'm not sure well where to place this article. So if somebody could help me with announcement in discord and how to place it in wiki properly that would help a bit. Thank you. Yeah, it looks like Rai just put a link in the TOC chat for this meeting for the first meeting thread if you would like to take a look at talks about the LFX mentorship platform issues unless this is the actual link that you were referring to. Yes, I believe it is if it's okay. Great. Yeah, I guess we'll have to take a look at that and see what it has to say and we should probably get the LFX mentorship team involved in helping with any sort of issues that might occur on the particular platform. Okay, any other announcements or any comments up to this point before we hand it off to David. Okay, I will take that as no. So, David is going to present to us why to contribute to hyper ledger. I think David if I recall correctly, part of this is also to get feedback from the TOC and focus on the call to help improve this. Absolutely. So are you able to see my screen. Yes, we can see your screen. So, yeah, to your point, I mean, we're trying as we talked about last week we're trying to create some resources that will be helpful for everybody on this call and all the other maintainers to have conversations with people on your end about why working in the open is why it can help meet your organizational goals. So yeah, absolutely we want your feedback is this the right track is this something that would be useful. You know, are we hitting the right points are we reaching out to the right audience, I think one important point to cover that are no brought up last week is there's probably going to be a lot of different audiences so maybe not going to be just one presentation so I think I am just sharing one presentation today but we might need to iterate on this and, you know, change it for for different people and have different points so just keep that in mind as I go through this is by no means done, and it's also just for one specific audience that I had in mind so this might not be the right content for a different audience so we might need many versions of this so one point of feedback maybe a this was good for your audience but what about you know these other people to you know and we might need a whole different approach so just for that context the audience I had in mind for this one was I had just noticed recently that with restarting the work on Explorer and bro as labs it's been interesting to see that those projects, even though they were end of life did have users, and once we end of life to them they showed up and said hey I was using that. My, my thought was, let's try to get in front of that so that's the audience here like let's reach out to people who are using a project but not contributing to it yet and that again is one audience and there may be other audiences to so I'll just go through this and again, any feedback you have is certainly welcome. I'll do this I'll scoop over because obviously we know some of the basics but I was going to start with just some information around open source collaboration and talking about that. But I think the core of it is this part about why contributing adds value and again I think, in many cases I think we just assume that people understand that because hey you're here right. If you became a member or you're you're here in a call, obviously, you are in the community to some degree so we just kind of assume you understand that getting further involved with that would would add value but I don't think we have always made that explicit in the past or, or as explicit as it could be so. I think it's really helpful this to be very clear about this so I think here are some points I think are relevant for people. Again, really looking to your feedback but I think one point that's very relevant is showing up and using open source is one thing but contributing is a totally different light if you use open source. You're kind of taking whatever is getting created by other people but if you're contributing yourself you can shape the direction of the project to fit your specific needs and use cases. And again, I think this is really relevant for, for example, the explorer users, and they were using but not contributing to it. They were kind of at the mercy of whatever the other contributors made right but I'm sure they had their own needs. So if they were contributing to it they can shape the project of the, you know, shape the project in the direction they wanted to go in. And then again for the explorer one. If you contribute to a project you can make sure your project you rely on stays active and doesn't stop right I think up for a lot of people they're not familiar necessarily with the mechanics of an open source project and they don't realize that projects could you know go into life so in a minute I'll talk about the project lifecycle and I think that's helpful to inform people about to. I think another really compelling argument for come for why contributing to open source is useful as you can decrease the time it takes to, you know, get something done and accelerate the work of the project I think, you know this is something where you can say, if you do it all on your own it's going to take a certain amount of time but if you can do this with a much wider community and other people are doing other parts of what you want to do because they also show the same goals you can get stuff done quicker right. And then I think lastly you can tap into a worldwide group of people who are interested and want to help right we have people from all around the world who are interested in something similar to us we all have a similar mission by being here. And you really could tap into that group. So these are a few points. Others down below, but I don't know, I'll pause here for a minute. Are these relevant, are there any big points that you think are missing at this point, because this is kind of the core, the core kind of why part. The rest is kind of getting into more examples and more mechanics of how. Equipment would be it'd be really nice to, while this is necessary in this form, it would be really nice if you can share the list of comments the list of statements. I'd like to go through them and and sort of think through each one I think I think there's more to it that could be done and tweaks made but I'd love to just see them as a list. I don't know where that is, or how I could get it but I mean separate from separate from this presentation like formatted differently or just like a literal list in a comment so that I can see them one after another they're really nice concise. I'd love to play with them a bit and think about. Sure, sure. Just a copy paste into something. Sure, I'm taking a note that's great copy paste. So just easier to just easier to go. I think through them all and and. Think about what we find each one. Sure. And yeah, and then we can format them into a nice presentation. The thing I'm thinking is it's, it's somewhat missing the selfish motivation of the individual. I'm looking at what's and adding some and I might have missed them and that's why I want to see them all sort of together is. You know that that idea that that you can contribute or put a portion of your team on to contribute to it and have and still build something that that that is your own to to build off of. And there's a balance there and I just, I want to make sure that's in there and just to see them overall together. That's a good point yeah just because yeah exactly you, you can then create your own thing even if it's done in the open you can still have a part of it yeah I think that's good point. Oh yeah absolutely I can format this copy and paste and put it in a different format so it's easier to scan and edit and play with. I guess if I could throw one more. A lot of what we do is based on standards and protocols and again that sort of it's in your interest to build out these common components so that you can build value for others around those but if you don't, you know if we don't build the core components together and open forever, you don't get that you don't get that ability. You can't do it alone that type of you can't do it alone so again, maybe covered in there I just would like to see. Yeah, so good. Yeah, I just want to say Steven I did just put in the thread for this meeting. I copied and pasted them from the presentation into single message so you can take a look there and see all of them together and see if there's something that you think might be missing too. And that goes obviously for everybody. If it's easier to see them together. And I'm guessing in the chat, you probably put a link to this presentation that I probably could have looked at to. I could definitely include the link to the presentation but yeah. I think it's on the agenda, but yeah we can drop it. I'm guessing that it's in the agenda I probably could have just gone and looked at that but so. Thanks. And everybody should have access if people don't let me know I think I'd set the permissions everybody could view and comment but if you're having access issues let me know double check. But it's helpful to even thank you and this brings up a point I have a few other kind of why comments later and it felt to me that you we could probably have 20. I didn't know what the right balance was right like, and again that maybe speaks to the audience right, like if we have 20 really good reasons. We don't have to share all 20 with every single person maybe some are going to be more relevant for one audience and so maybe we can having them all on the list we can kind of pick and choose hey for this audience these four things are what's going to be really compelling right and then you kind of pull those out and use those right. Any other comments before we move on. Okay. So, as I mentioned before I think at least in this case where people maybe aren't familiar with the project life cycle is really helpful to go through that. I think everybody here is familiar with it so I won't spend a lot of time on that but you know I think, again for the audience and I hadn't mind on there, it's useful to help people understand that you know when a project doesn't have anybody contributing to any more that it is possible for the to see to come in and say hey this is no longer active. Maybe this is now dormant or maybe this is deprecated or maybe it's end of life and so I think, you know just explaining people to people who maybe are familiar about the life cycle felt useful in this and going into the story of hyperlibrary ledger explorer again felt useful. Again, maybe not for all audiences but here, just to explain that this was an active project, the existing explorer, excuse me the existing maintainers had changes that made them move off the project there was nobody else to carry forward so moved into life. And if there were users right that's not having users or not is really not the important part about the life cycle it's really who's showing up and contributing right so you know we kept. And we heard this with composer to I think there's many end of life projects where we could point to this but you know people show up and said hey I was using that, and I, again this was the audience so I wanted to share this particular message with. It was just amazing to me, you know, we heard that people were not only using Explorer but also can making it better internally on their end and just not contributing those changes backs right it feels like there's, you know, they see value and improving it, but we hadn't made the case about why contributing those changes back so this to me felt like a gap I heard it at the last member summit we had. You know I've heard it kind of anecdotally when people show up and said hey I was using that why did it moved into life it just feels like we have not made the case to those people if you're making improvements to it internally and not contributing those back right. But it has been really encouraging to see that organizations have been, you know, now that it has been in life to have shown up and they're now contributing this as a lab so this is just talking about that story. Before you move on. Yeah, if I may, I just wanted to take a couple of ideas. I mean, the first one is well, you know, just because we're kind of project doesn't mean people cannot keep using it right. It's just a way for us to signal, well this is no longer maintained. Right. But maybe indeed we also the other point is, you maybe we need to to more to be clear, you know that this is about to get archive unless somebody, you know steps up and decides to become a maintainer. Yeah, I don't know if people are surprised when we do it. That's the point is like, you know, if they. Maybe we don't do a good enough job to say hey we're really going to archive this thing unless somebody's, you know, stands up say okay I'll take it over. I think that is a good point maybe a bit more of a communication campaign. Or, you know, identify that hey this is about to be, you know, well, and then give it a space of a couple weeks to yeah, maybe communicate more I mean I think that's a good idea, although I think the challenge is we don't necessarily know who those users are right I mean we don't have a list we don't necessarily have a list of who's doing what and we heard that with Ursa right I think we had a conversation with some Ursa maintainers and they're like oh I know that these other organizations are using Ursa but we'd never heard of that right. Yeah, that's true but maybe we can still post it on the, at least on the repo and try to. Yeah, use them we do have the use the channels that we have right I think yeah, I think that's a good point to more of a campaign in advance of this in the future. Because I think we do it among ourselves that's for sure. We know that this is so visible externally that this is going to happen. Sure, and obviously not everybody's on these calls right I mean, exactly. Well we know they're not. We probably never look at that maintenance. So, you said you had a couple points was there another. No that was it that's the second point is the communication aspect. That being archived doesn't mean they cannot stop using it. Yeah, I mean they cannot keep using it. So that's a good point I'm taking that note to our room is next. Thanks. I think adding to your point regarding a new maintainer can spit in my question or to the to see over here would be, would we be open for them for let's say a new maintainer to completely take over the project. When the project is in let's say graduated state or or a state which requires maybe more attention like that. Is that something that we want to go over with or we do something to the projects like current lifecycle so that the community still get the indication that it's a new maintainer set that we have. Or like how any thoughts on that part. Are you suggesting that if a graduate project goes to end of life and somebody wants to bring it up that would go back to incubation I think that's obviously would be in alignment with our project lifecycle because the way that we have it right now. For it like if say somebody wanted to bring hyper ledger explorer back to a top little project within hyper ledger, we would have them go through the proposal process again, right. You could consider there to be like a dotted line between end of life and proposal. If you will but yeah I don't think you'd go directly from graduated to brand new maintainers that doesn't seem like the right steps because you would expect that if you were getting new maintainers and then the existing maintainers would be the ones to bring those people in. Right. Um, yeah I think I'm connecting to the previous comment that was my my question related to. Let's say we decide or we can we notice that a particular project needs to be well and let's say even if we find a communication means to spread this word. And we find new set of contributors interested in that particular project. What would happen to the. Projects current state. Do we still go ahead and make it a well and then ask the new set maintainers to propose. Yeah, so David, if you go back to that project lifecycle slide that you have. I think that the important steps are the dormant and the. The end of life states so if you're in if you're in dormant state you can you can see that there's no way to go to graduate it even if you were in graduated. It goes back to incubation. If you're an end of life, then you have to go back to the proposal there's no way other than proposal if you're an end of life. Deprecated deprecated goes to end of life I suppose there could be a deprecated somehow back to incubation but we don't have that currently in our life cycle. The expectation if it's deprecated it's, you know, got 6 months to be maintained by the existing maintainers and then it goes into life. Jim. Yeah, Tracy just a comment on that the red arrow pointing back. As a follow up to your comment earlier, I feel like in the situation where a project is becoming dormant so the current maintainers are essentially nowhere to be found. We as the TLC may have maybe in the right place to do to do something more so that we can evaluate the situation on a case by case basis and see if the new proposer. The new committer who proposed to become a committer has enough of a track record to become one and basically override the, the current maintainers right to bring this maintainer in. Rather than saying, well, we have to find the current maintainers and get them to vote you in there and there's no other way. Yeah, no, that makes sense. I think, I think the thing that I want to ensure that doesn't happen is that we have a graduated project that is truly dormant right now maintainers have gone away. And somebody comes up and says, Oh, I'll take it on. And then it stays in graduated state that just seems a very wrong sort of place to be right because these new maintainers that are coming in don't necessarily have the track record of allowing it to be graduated and the expectation would be, you know, that project that is graduated has a set of diverse maintainers. And I would think at that point you probably don't have a set of diverse maintainers. Yeah, I totally agree with that. I think definitely agreeing that there's no no pointer from dormant back directly to graduate it so not arguing with that this is mainly for the specific mechanisms of making the the arrow from dormant back to incubation happen faster in certain situations where you can step in and make that happen. Yep, I think we're on the same page. Any other comments about this part or, and I'm keeping on the time and I know there's another topic after me so I can go through the rest of it fairly quickly but but happy to keep talking about this, you know, in the future or we could find kind of another forum to work on this together but I definitely would be happy to iterate on it with people here. David just to that point I know Peter is not quite ready today so if we do go longer. I'm sure Peter would be happy to give you his time. Oh, if that's the case. I'm happy to whatever works best for Peter. That is the case. Okay, well I won't I won't rush through it. So this slide I did it before I think it's missing the Ursa logo I created this a few weeks ago I can come back and add that but just again to explain to people that hey, a number of projects have you know now that we're several years old you know we kind of seen many projects at this point kind of go through the life cycle and let people know that hey, this is something that happens. Here I pulled this is somewhat of an appendix I was really interested to hear from this I had it again going back to our point earlier I think there's all sorts of why is I think you know there's probably a dozen or more different why is and I had pulled these out I didn't put them in that main section because I wasn't sure how many of those we wanted I didn't want to necessarily throw you know 12 different reasons of people but I pulled these reasons about why to get involved with an open source community from a different couple different places these were some why is I saw in one of the links foundations. Training courses around, you know contributing to open source and I thought these were still relevant so I wanted to share these with a group and if one or one or two of these seem really, you know really compelling we can, you know, bring it up and elevate it and put in more of the, you know, the main part of the presentation but you know. Again, I think we can come up with a bunch of different why is but I don't have any of these on here seem particularly compelling. I guess this goes this one's going to be that was going to highlight it sorry about that. This one around the standards I think that spoke to what Steven had talked to earlier so that one seems like maybe something we would want to bring it up to the main part. Anyone, any of these other ones seem really other than the standard one seem really interesting or useful or compelling. I'm wondering if we can make some of these like sub bullets to the to the main ones, or somehow combine them and I think that may be part of what Steven was talking about wanting to take a step back and look at how these could be structured maybe combined. Yeah, that's a good point yeah I'll put yeah I will follow up with that so yeah we'll put them all in one list for sure. Maybe add them on the list maybe we could rank them maybe we could put plus ones next to ones that seem really compelling to us and then we have a sense of which ones, you know, or maybe some will bump up as main points and some will be like sub bullets that support those main points Yeah, it's a good point. Yeah, for sure. Well the this is from a different this is from a Linux foundation research project that had come out recently or research report rather than come out recently again focusing on why, you know why somebody might want to get involved. And again you can see several more points yeah I'll do that I'll copy and paste all of these into one one long list but again I don't think there's any shortage of reasons it's really what are the ones that are going to be compelling for the audience that we're speaking to right. And Stephen, how's this handle. Yeah, one of the things that I've been noticing and seeing happen and I don't quite know how how this would fit into this but I wanted to throw it out there which is the, the thing not to do, which we've seen a number of people, basically fork the project for their own use. And so a bunch of stuff, and then say, Oh, we're going to contribute that back and so they have to undo, you know, sort of have to do a whole bunch of work to be able to contribute it back. And, and, and how to get people to understand that's a really bad thing to do. It doesn't help you doesn't help the community doesn't help anybody. And so I don't, these are all sort of good things to do that's a that's a bad. It's not to do and I don't know how it might fit in here but I, I'd really like to get that message to a bunch of organizations, because it's, it's painful to see like they, they know that this is just the wrong way to do it but yet they're, they've put momentum in their organization that's how it works like they don't think of, of, of doing it the right way. Again, I don't know if that helps but I just thought I throw that out there to the community it's sort of say wow. When you see that it'd be really good to stop people from doing that or make clear, you know, how, how unhelpful it is. And that is a good point and yeah maybe we can have some sort of anti pattern slide or something on that but I wonder also just to explore how, how do they end up that way I mean what's your guess I mean. So if I heard you correctly you're saying they know that that's not the right thing to do, or at least some people. Part of it is the organization you know the larger organization the people working on it know that it's not so good but the larger organization doesn't understand open source doesn't understand how to contribute doesn't understand, you know, other parts of it and so in talking about it to those leaders in the company say you know not only do you get these benefits but you actually wind up hurting yourself if you do it in a way that doesn't support open source, which I think speaks to the conversation we had last week like it feels like largely the developers know that open source has value but yeah it's really the people. So is that like the legal team or the executives again just kind of understanding the different audiences we need to connect with do you think yeah. I agree it's the it's the executive and legal team in that they haven't realized. They haven't put in place, the ability for them to contribute so people just don't know what to do like the people doing the code don't know what to do or even the you know the leaders of the of that part of the organization doesn't know what to do. Yeah, so yeah. So in that case, yeah we don't need don't need a developer focus conversation for that right. Yeah, here. I just wanted to add, I agree with everything that's just been said but I wanted to add that we could also put some hints or clues down in the read maze for the contributing guides that says that the leading upstream is preferred contributions can go in there instead of forking and I'm saying this because I have seen in the past developers who just default to the path of least resistance and the path of least resistance often is just describe which is oh let me just fork it let me do a bunch of changes in a way that I know wouldn't actually get accepted as a contribution on the upstream repo but it doesn't matter right now I'm just trying to get it to work I'm just getting done by the end of the sprint by the end of this deadline that I have at my day job and and a lot of times they also either don't know that this is kind of a foot gun on the longer term or they just have no choice because of the deadlines. So I think just as kind of an off topic apart from these slides but we could also take steps to call this out explicitly advanced because we don't necessarily get as a matter of fact we probably don't get to have actual conversations with most of the people who end up using the projects as dependencies we don't get to have an interruption there and say hey we think we should do it this way because they just see it on the internet it's freely available and they start using it. I think you have some really good points Peter and I think that fits with things I've seen before I think often people can make rational decisions that maybe aren't to your point like are maybe detrimental to for them in the long term but at least in the short term like you just like you said I have a deadline and it's going to take longer to do it though right quote unquote right way open source way right because it would take longer right you'd have to go through this whole process and talk to other maintainers and get a review sometimes it's just quicker to do it yourself so maybe what we'd want. We can structure this in a way maybe where we have a list of why is not to maybe and maybe that gets to what you and you know the we acknowledge maybe why people don't contribute sometimes maybe and say hey these. These are maybe valid in the short term but it's going to you know maybe have some points about why longer term that's going to you know really hold you back right. Yeah, I think it helps if you call out as in if you explain that we understand why these things are being done and they're aware of them. Thank you. I think you could strengthen that first bullet basically by saying, maintaining a fork, you know, on any kind of you know long term is a huge no no I mean it's a real pain and I mean I can tell you an IBM we are strongly discouraged by the groups from managing forks for that reason. Everybody was tried that knows that this is not a good idea, but maybe in the short term it works right maybe it's all probably that's what I mean, but that still means your plan is to contribute back as soon as your fork and make some changes. If you don't have that plan, you're setting yourself up for trouble. Yeah, alright, that's good feedback yeah I think maybe in that part is really missing from here the why why would you make decisions initially. And then you find yourself in a hole and then you have yeah and then it's even harder and then that's all the more reason not to do it like well it's just easier for us to not do it at this point. Any other comments on either of these sides. Again I'll pull this out into one doc but go keep going. The next is more just like if we've sold people and why then it gets into the how and I think again. I've often jumped to the how in the past like I think you know we've done a whole get how to get involved in the community presentation, and it was mostly about the how so you know I think that the how is great once you've sold somebody on like why to do it but I think the how these come first but I think none of this is going to be new to anybody and I can just go through this quickly but you know I think this is all stuff that's been around for a while so just adding it after the the why part. And then that was the end of it. I would, I guess, a high level question, would something like this be useful for you I mean do you do see yourselves taking a presentation like this and having a conversation with people on your end. I think it's useful, David, I think that, you know, it may even be useful to have something that can just be shared that doesn't need the voice over. It's some sort of paper right that people can read obviously the shorter the better but you know, or even like just having having this recording where we've had these discussions. And people can listen to some of these comments that have been made, I think would be very useful to really, you know, help drive the point about why it's important to contribute. Yeah, great. Bobby has her hand up. This is great and I know that the onboarding task force we're working on getting the six spots where people come into the community. Narrow down to four personas so that the four personas that are hitting hyper ledger. And this is great for like two out of four of them right now so definitely incorporated in the onboarding information and stuck in the documentation library when we figure out, you know, how that great. Thank you very much for this safest time. Yeah, I'm glad it's useful. And to Tracy's point about shorter is better maybe we could leave off the house stuff we can just say hey if you want to learn how, you know, there's a whole another set of resources to get resources to check out right. And link to those. So I think my two main takeaways are let's put all the reasons why to in one place and kind of iterate on them as a group and then really understand which are the most compelling and then maybe identify a separate set of why not to use that we've kind of talked about on the call but aren't currently in the slide and put that in there to kind of acknowledge that hey maybe in the short term this seems like a good idea to do it this way but your reasons why not right. Anything else that feels useful or missing that. If we take another pass at this dad. Peter. Just wanted to say that and I think it's pretty great already and thank you for the effort put into it. Sure, happy to yeah if it's going to be useful for people and happy to do it. Okay well I can take another pass and then share it, you know, in the future and get more feedback. Good. All right. So, Peter, we have, I guess, one of two choices here. We can either talk about what this task force is going to be on this call. Or we can wait until next week to give you an opportunity to put together some initial thoughts that we can actually review together. Up to you as to what you want to do. I think we could talk about it. I have some ideas and I would love to gather more input more ideas from everyone else, and then sit down and compile the actual document. So, yeah, I have a few ideas that I can go through real quick right now. I don't have slides, I'll just say them. And that's okay. Yep, sounds good. So one is to produce a best practices document about GitHub workflow actions. There is very extensive and high quality documentation about this made by GitHub themselves but it's it's big. It's not something that you can quickly digest in a few minutes. We could have a very quick getting started document that has a ton of links to the deeper, more detailed GitHub documentation that it leans on very heavily. So I'm not trying to say that we should reproduce anything that GitHub already has because they do have high cost documentation on this in my opinion. But for anyone who's just getting started with it, a five minute intro on it and and something that shows them how things in other projects have been done that are actually working and things that we think are great. If there are patterns that are too specific to be in the GitHub docs as best practices, but we think they should be encouraged and we can put those there as well. And then two more things. The other one is, I figured that we could do a general checkup of existing CI workflows of graduated incubated projects where the execution times are high. The prime target and suspect for this is kexti because I know from rise statistics that we have been running a lot of CI time we have 15 plus container image build some of those take half an hour to build. And so I'm assuming maybe at least a few other projects have a similar problem, maybe not to the same extent but I figured we could go through all the task force members, myself included I'll volunteer myself first for everything. We could go through some of these CI jobs and take a look at what is it that actually takes a long time and how could we eliminate some of that time. And then also boil that down into another document that or it could be part of the best practices document just as learnings. And third one is more of a moonshine kind of thing that is really just a personal interest of mine on improving things is evaluate or try to find self hosted open source owner alternatives to what build jet is offering commercially. But in a way that the backing infrastructure the servers that are running the CI jobs are provided through some very cheap mechanism like a spot instances or other for party cloud providers that have competitive pricing such as I don't know, had sir, they have very cheap instances compared to the big players. I have no idea if this exists. I have no idea if if there's issues with this but the task force should look into it and produce a report saying we have looked into this we have tried it and this was the outcome and it doesn't matter if that was success or just a conclusion that it cannot be done for whatever reason or maybe just doesn't exist outright. But we should have a document for people in the future who are wondering the same thing. We should document it we have gone down this path and we've attempted to do that, and then reach conclusions. And then, so these are mine, but if anyone else has anything that you can summarize in a couple of sentences or less and I am I am ready to take notes and I will add all those in there and then we will have a kickoff meeting where we can give you up those and we can filter them down depending on priorities. Peter I took notes while you were talking and I did put those three items in the chat for this for this meeting so just if anybody would like to review those and see there's anything else I'd like to add to this best practices for Automated Pipelines Task Force. Just FYI that's out there. Thank you very much Tracy, you're the best. Well, Peter, I'll add some comments I do like the first two for sure I do think they make sense for this particular task force. The third one the moonshot. Yeah I mean if if somebody has the time to go out and evaluate and see what exists that's great I don't think it's necessarily a requirement for this. For this task force but obviously I wouldn't stop anybody if they have the time and energy and desire to make that happen. I agree it's heavily optional and definitely the word moonshot. I meant to imply that there's a 98% chance if not it not working out because if it was that easy it would have already been done. But yeah, I just figured why not throw it on the list and then see what happens. And then just a question to Steven to put you on the spot I think you were the one who originally suggested this particular task force for Automated Pipeline best practices is there anything else that you were thinking to get out of this. I think that gets the main thing I was looking for I guess was making sure that. Yeah, I mean I think it covers it how to do a release how to do, you know, what to do on merge on a merge what to do on a release, how to publish. You know those getting consistent on that I think you know I look at other projects and I see what, for instance team most done on AFJ and it's not done he just left. I got called them out and he's not even here. And that team is done an outstanding job on on their repository and all of their tools and their, their pipelines and, and I see the just inconsistencies across and that's what I was aiming at so I think this is a really good, really good progress on getting there, and will really help other other other groups, you know, within a project, we you know within a repo. Good stuff. Thanks for that season. Any other thoughts on the task force, Marcus. Yes, I think I absolutely agree with Peter I mean back best practice document about how to use get up action for instance that would be pretty cool. On the other hand, I believe that back best practice document should also contain a mapping how the individual project performs that build on, for instance, locally at the developer, because I mean when you write get up actions whatever test you're triggering there I mean this is triggered on GitHub, but if then people would also use the same infrastructure to run the tests locally before they actually pushing the code. Someone has to spend some extra thoughts on how to set up the make scripts or whatever right. I think that should also be part of that best best practice document. So Marcus, you're saying it should be part of document how to run the CI jobs locally on the developer machine isn't how to verify that the change I just made will pass the CI but locally before actually push it. Well, I don't know if that's even possible if you can run the CI job in the same format. I have on GitHub locally, but I mean usually when you start a project you right start writing a makescript script and then you define something what would you like to run and then you are happy about the changes or the test passes then you push it to get up. And then the GitHub action will be triggered. And so I mean for my experience and then sometimes you start writing your makescript essentially twice once you can execute locally and then the other one which is understood by GitHub to trigger the job in a different way. And I think, yeah, for my experience there, I believe this is sometimes hard. Of course, really depends on the project but if we can also give some guidelines how to achieve that more or less easily. That would be great, I believe. I have looked into this specifically and I found this project that I've been testing out called ACT or ACT, I'm not sure how to say its name, I put the link on the Discord chat for you. I have managed to get it up and running and I have had cacti connector plugin test suites executed on it just by saying this is the ML file this is the job name go and run it. It was not trivial but it could be done but then I also had some failures with it on jobs that were working fine on GitHub so that technically theoretically possible but it's not as easy as it sounds like of course. But we could we could also add some information about this to your document just as I mentioned saying, by the way, this is something that the community is working on not necessarily the high political community but other people. And if you're interested in more of it then you can take a look at this project. Yeah, let's definitely look into that. Stephen. So oddly enough Marcus. I had, we'll bring you on some new maintainers for our project and they said exactly what you said yesterday which is how do I run this locally. It's all good to have it all there but I don't I hate put checking in code and then finding out that I'm failing tests because I haven't been able to run them locally so oddly enough, that conversation definitely comes up. One of the things I'm thinking of now is we're, this is getting into very great detail at on particular stacks and particular ways of doing things you know use GitHub actions for this. One of the things that we should definitely have I think is take it up a level to say these are the things that a good project has, you know, it has linting for code it has unit tests it has integration tests, and then provide, you know, the maintainers a list of what, what is good in a project and then pointers to particular ones because I think once you get to start to get down into particular details on things that are relevant only to some or have to be applied in different ways, you get into a level of detail that's impossible to maintain. So perhaps the best way is to point out, you know, good examples. And, and have people, you know, provide a slightly, you know, a top level here's the list of things that a good project does from this perspective and then here are examples for different types of stacks of good ones that are done that you can follow to make your yours better. And that maybe that's a more generalized approach to get to what we want to get to which is, you know, helping developers are helping maintainers make it easier to on board build deploy and and publish their their project. I agree. Checklists. I love checklists in general, because they're easy to understand, you know, they have a name and the headline and then it's just a list that you can skip through if you're scanning or skimming a document. Then you don't have to go for the entire checklist to understand what it is. So I think a checklist is a great addition to the best practices document that I was mentioning my point one, because it's easy digestible. All right, I think that was good discussion good start. So Peter, you were as prepared as you need it to be for what the initial kickoff of this particular task forces I think, you know, it's ideal when we start a new task force just to figure out what it is that we want to do, and come to some agreement on that, so that we're all heading towards the same goal, and that we're not thinking about different things and so good discussion for this particular task force. We'll see you obviously again in a few weeks when you come up again but we'll be focusing on the items that we talked about. So Rama, I think you were also either volunteered or voluntarily for the badging life cycle task force so I think you are up on the schedule for next week. Tracy, can I get another week's space. Sorry. I'll be prepared for the week after. Yeah, I am so yeah I know I don't, I don't time me up for leading that and I appreciate that and I'm happy to do that but yeah, thing next week is going to be a little bit of a paper deadline so Okay sounds good. Let's see I think the other two task force that we have then would be the next one on the schedule then would be security for Arun. So Arun are you ready to close out the security task force next week. I think we had the meeting this week. I'm not sure if the meeting happens next week on the art. Tracy sorry to also be in the can we not move this up camp, but it would be great if we had another week for that just to go to the open SSF. Okay. So, Bobby I'm not sure if you'll be ready next week will, I mean I think the other option is obviously if nobody's ready next week we can see if anything else shows up on the agenda and if not potentially cancel for next week. I will definitely not be ready for next week. All right. No problem. I can volunteer for the reviewing process that CNCF follows and no hard shared me a few resources that I can go through. I can share them in the to see channel as well. Okay, for the project for the project review. Correct. Okay, let's make sure then that that's on the agenda for next week will have that. If anything else shows up will include that as well. So with that, we are right at time. We will talk again next week. Thanks a lot Tracy. Yep, thank you. Thank you. Bye.