 Welcome everybody to the December 8th hyperledger technical oversight committee call. As everyone who's on this call is aware two things that we must abide by the first is the antitrust policy notice that is currently displayed on the screen. And the second is our code of conduct which is linked in the agenda. All right, so for our agenda today we have the standard announcement of the depth weekly developer newsletter goes out each Friday. If you would like to include anything in that newsletter, please leave a comment for consideration at the link that is in the agenda. As far as meetings for the holidays, I thought we should probably cancel the 22nd, the 29th and the 5th to make sure that everybody who is on holiday can enjoy those holidays and not have to worry about the technical oversight committee call. I'm not sure whether we'll have content for next week and we'll decide that next week as to whether or not we have one next week, but definitely for the holiday that I'd like to make sure that we cancel those meeting. Any other announcements that anybody on the call has. So this is regarding hyper ledger blockchain explorer project which was recently deprecated or enough life cycle, I guess, and there has been interest in multiple among multiple community members. So it's going to be like people are looking into adding certain features to that project and seeing in further improving the project and bringing it back to life. So it's going to be a discussion tomorrow, 8am Eastern time. And the calendar link is where exactly for people who might be interested in joining that. Right, I need to work with David and getting it up on the calendar link. Okay. And then yeah. I think if I understand correctly that the code base has been moved to the labs area so it's currently a lab and not a project. And if that would like to come back to be a top level project at some point in the future it will have to go through the project proposal process. Okay, so if you know of anybody else who is interested in the project please bring them to the call tomorrow. Thanks for any other announcements that anybody would like to make. I don't see any hands. Nobody coming off mute so I'll take that as they know, as far as quarterly reports, we did have the cello report come in this week. I did not see any comments on that I'm just hoping it now just to make sure that nothing new has come in overnight that I may have missed. You know, it looks like the only comment here is from from David Boswell about social media posts and marketing for the 1.0 release that's coming out. Looks like we still do have a number of TSE members that have yet to review the document so we'll, you know, look to see if there's anything that comes out there. Any questions though that anybody does have from that particular project report the cello project report. Hey Tracy I did have a question on the documentation and the lack thereof was the same comments from their last report I still didn't see much update in that in that area. So I just putting another comment in there. Okay, and it's that there needs to be more documentation for the cello project you think before the window releases what you're asking for. Yeah, what's in there is completely lacking if I'm a newcomer trying to pick up cello I just can't figure out anything. Okay, Bobby, have you in the learning materials working group has anybody been working with the cello folks on any sort of documentation or anything there. No, it hasn't but David and I had a meeting this week about how we're going to change learning materials working group to help support that more with task force and one of them will be that documentation task force. Okay. Thanks Bobby. Didn't mean to put you on the spot there but I know you had helped some other projects in the past and I didn't know this one was one that had come up or not. The documentation working group was going to support all of those efforts to make it simple and work together with us to help them attain the documentation they need to get newcomers onboarding easily. Okay. And Jim, when we get there this might be a best practice that we want to add to the checklist. As we are thinking about documentation. That was kind of my, my, my subtle way to say they need to really drastically improve documentation to the experiment one dot one dot zero. Yeah. Okay. I'll read this week and set something up to get started. Yeah, I appreciate it Bobby. That's great. Thanks Bobby. All right, any other comments about cello at this point. I will note that Firefly also did come in early this week so I did include the link there on the agenda will definitely include it next time as well but just FYI that one did come in. If you haven't had a chance to look at it yet, please do so. And I guess I can ask the question, because it does look like a good number of people have already taken a look at that. Are there any comments or questions about the Firefly report at this point. All right, resounding now. So last week we had talked about a couple of things one we had talked about the different task forces and closing those out. And one of the items that came up when we were talking about the project health task force was potentially creating a checklist where we would move some of the questions that we have in the project reports to some sort of spreadsheet and maybe try to sort of the project health type things into this particular sort of checklist of yes no do we have these things that are included. I started this with the list of the things that we have done in the past. Last year, right, we've created the common repository structure. We've created the maintain our guidelines and we've proved the inclusive naming proposal. And so I basically included all of the items from there whether or not they were a must or should they are included here. And most of these I specified whether they were required or recommended, but not all of them. Maybe I need to go back and do that for the ones I missed there but you know these these items, none of them should surprise us as we have approved these things in the past. I did want to have a discussion and see if there were other things that we should be adding to this list. I'm happy to, you know, take those notes and start to add them here directly in the document. Any thoughts, things that we should add to this list. I don't have things to add but I'll just say, I like it. A all in one location is very convenient and I wish this had existed previously so it looks like it's pretty inclusive of the things we already have. I can't think of anything new but I think this would be a good thing going forward and we'll add to it as we think of things. Yeah, and Dave and others that what I was thinking here is that we would probably create a separate tab for each of the projects that would be a copy of this template. Right and as we as and when we add things to the template we would also add them to the individual project tabs. So that again one place to go to see, you know, do our projects support the best practices. If so, where can you find that so that it's also somewhat of a appendix or an index, I guess it's the right way to say that right that basically allows people to quickly find the information so that if they're interested in say, becoming a maintainer of one of the projects they can go find out how what does that take and how do I, how do I become a maintainer what are the steps I have to go through. So yeah, I think that's kind of the idea here. Peter. Quick suggestion, and I'm going to make a change to this would be okay if I moved the required slash optional information into its own column so let's go triple by it. Sure. Yeah, we can definitely do that. I'll do that I'll have a few ideas for optional stuff, but nothing to add on the required front. Okay. Come lush. Maybe information about the LTS releases. And other things like even a couple of open source project I have seen. So, you mentioned about the kind of the project implementation, like was the real time of the production implementation of the particular open source project. So, do you have a list of production uses. Yeah, so so like for example suppose if you see any suppose if you go to any open source projects, they mentioned about like who are using this particular project. Yep. Yep. Okay. Sean if you scroll down, I am editing as we speak. So, yeah, at the bottom I added this question do you have a list of production uses to the document can blush. I also added your LTS release. LTS release as well on my 25. All right, I know. Yes, hi. I mean, I say again what's been said before this would be great to have for sure. It feels like I wish you could populate some of this automatically but my question really is, how do you deal with the fact that many projects if not all have multiple repositories. Are you going to just focus on the main one or Good question. I know I have that same question in my head and I don't know a good answer to that I really appreciate thoughts here. Right. I mean, in my mind there's two ways that come to my mind of how we can deal with this. We have a separate tab for each repo. I think this is going to make this a very long spreadsheet. And that may be too overwhelming for people. Maybe I have a third way we could create a separate one for each project and then have repo. We have questions and project specific questions. Right. We could the third option which was my original second option was we do it for project. And in the location column we have multiple locations one for each repo. So yeah I think those are the three that come to mind but I'm like would love to hear your thoughts on what you think is best and the fourth or fifth option that might be better. Yeah I mean I don't claim to have the right answer either. That's why I bought it up across my mind. I think you know practically speaking at least as a first step focusing on the main repository seems like a reasonable thing to do. Otherwise it's going to become very quickly overwhelmed and very hard to manage. I think it's better to have less information that we can keep you know I correct keep it up to date, then trying to encompass everything and then, you know, it's going to become obsolete before you know and then it defeats the whole purpose. I would note in how people use this that they're aware and maybe maybe there's something that needs to be done at the project they've also that, you know, I'm thinking out loud so I might have to rejoice. But, you know, I wonder if it's up to the project to point to the other refokes and then provide additional information. And to some degree you can figure this out by just the name usually you can find that out. Maybe more can be done in that area of the project. Yeah, and I don't know because you've said that I guess a fourth option that has just now come to mind is what if we required this in the read me. For each of the repos. So I was looking for a pointer to this from the read me where basically the information existed as an index to the project so that people knew where to find things within that particular repo. Okay, Arun. Thanks Tracy so I was looking through this list and thanks for aggregating in one place and I like it. Now that I see this list. So thinking of some of the bigger projects are some of the projects that have wider scope. It could be as simple as for instance, let's say fabric samples for instance, a repository that may get contributions from multiple folks in each interested in some aspect of it some few folks and then on the, let's say bringing up of a test net, whereas few of them could be interested in writing samples on the chain code different languages. Having, I know like Fabric team is doing good job, but maybe we can recommend another file called something like owners, which the chromium like defined earlier, which allows us to define folder level ownership right. There can be reviewers and reviewers can who specializes in that particular field that either it could be that part of in that folder of a project or in that part of a project and then approvers only when they approve it goes into the main base. Yep. And that would be an owner's file would be recommended I think right. Right. It's not a mandate. It's recommended. Yeah. Okay. Come lush. So I think, like, another just point right there are multiple projects and sub projects, maybe we can also have a having a list of sub projects. So it will easily identifiable to the people, like which project related to which particular repose. So, for example, suppose the fabric having multiple subject could be included in the in the deposit. Okay. On this sheet it seems like it's important for us to just to call out that most of these are required on a per repo basis even if you try to save energy you still have to have something there for either a legal compliance reason, or because if it's not there you're doing the activity indicates like doing the testing or implementing the conventions and so, you know, one of the hopes is that as we get our linting linting tool kept up to speed is that it's very easy for us to run this against the repositories and get a picture overall of where the project to that. Because there is going to be a constant struggle to keep some of these things up to date and one of the things that's important when project decides to make lots of sub repositories is that they understand up front what they're signing up for. Because I think one of the things that happens is often the sub project is kind of a matter of maintainer convenience, or it's a matter of, you know, it's just more easier to use the programming language tools if I don't have to worry about more than one programming on a per repo. And they don't realize all of these things end up duplicated as a result. I agree. I'm not sure what specific change if any we need to make to this to reflect that. I just wondered if in required and recommended if there's something we can call out about whether they can link or whether they have to duplicate the content. I think we could probably just link from one to the other and I know we've had that debate ad nauseam and the repository structure and the maintainer guidelines so it may be that just the content that's in that link document is enough. Yeah, completely understood, I think. If I remember correctly and we'd have to open it. But I think in the, let me see if I can open it here and just take a look at it. I think in the maintainers guidelines, we have was it the maintainers got like no it was the common repository structure in the common repository structure we do have a comment. I remember about these files must contain specific comment specific content. So I think the license the code of conduct and the security are the three that we list as must requires specific content. Is that is that what we should be marking then is those three as these require specific content. And then the other files are the variable content once. Yeah, I just wanted to where we say file required. We could put a note in this in this list it's just, it's really nice as a maintainer to have something like this spreadsheet where I can just go. Just go through and make sure each thing is ready to go, because it makes the pull requests a lot easier to follow if I can get them all through at the same time. Yeah, yeah. It is the security. I just said them. My brain obviously is not awake at this point. Security license and code of contact that are the ones that are special. Maybe, maybe the reason that my brain is not able to keep those in my head is because a security and license where's the code of conduct here we go. So these three are the ones that are special, if you will, I'm just going to mark them highlight them in some way so we remember that we need to do something special with these. Thank you, Nathan, for that. I will make sure to do that. Any other comments. Anything else we should add Jim I feel like what I want to add around documentation is something like do you have tutorials. To reflect kind of the comment you made about the cello one. Are there other sorts of documentation that people think is extremely important to make sure that that exists for our projects. Yeah, I'm kind of torn a little bit here. I feel like a active project will naturally have good documentation because that's the only way to get the community to be able to pick it up and use it. If a dot if a project is lacking basic documentation. It's a sign that nobody cares about it. So that's, that's kind of what's in my head. So maybe we can say best practices is having good documentation but really, if you don't have that. How can you be effective project. Okay, I obviously have no idea how to use sheets. I added, do you have documentation as one right as very possible that some of our projects that are incubation haven't gotten to the documentation yet and so that will end up being a no. And then I added the second question of tutorials on use. I, I want to, I want to avoid the use of the word good, because it's very subjective, what good means. And I'd like to be more specific if we could if there's other things that we think are necessary in the documentation that would make it good in our mind. Right. What, what does that really mean to us. Yeah, maybe I'm overlooking it. But I feel like as a developer, when I first time see any of the code basis and like, unless I know that code base, I may be interested in knowing how to build it locally, how to test set of my test environment. So, I know there is a testing code point, which is put as recommended. And I'm just not sure if it considers to build and test, if that's what it meant to be. Is that number number 19. Yeah, no. That is truly testing code so I added lines 31 and 32 here. Do you have build instructions probably in your documentation. And then the second one. Do you have documentation to help a contributor understand the code base. I think that's what you're asking for is it. Maybe not the code base and at least the build instructions if possible, because there could be let's say, some of the some of the projects would be using make files, some of them could be using a rest space is once and they couldn't have multiple flags in there. And as a first time contributor, I may understand how the programming language works, but I may not be able to comprehend the multiple options which are provided in those files. Yes, I know about the project right so maybe there should be an option say if you are a developer and if you're building. If you are contributing and here is how you can build locally. It allows us to gain confidence that you have tested, and it gives you confidence that you are able to build it. Yep. Okay. Poppy. The documentation task force our goal and hopefully will be finished by the end of the year is to get some recommendations for projects and incubation to take their GitHub repositories and put them through these templates and have user docs and again I completely agree with everyone who said that the documentation is a direct reflect on how the project is loved. So, depending on how much work went into describing steps in the GitHub is is as good as your documentation. When you say, the only thing that I have a question on is when you say you're more talking about how to tutorials. I'm not sure how you could get the community all to do that in a uniform way, unless you supply a template that each project has to do for that specific reason. Yeah, I think that tutorials are going to be very dependent on the project at hand. Right. I think it's important to have those tutorials but I don't think it's necessary to reflect what type of tutorials if you will. Okay, other thoughts. I know I'm not supposed to use the chat here but I could, I just wanted to paste a link so there is some kind of documentation that I was talking about personally this benefited me when I mean long back when I started contributing to this project. Any other thoughts, anything else we should add to this. Peter the the column you requested the required recommended is this kind of the idea that you had there. Yeah, that works. That works. I'm glad you had something else in mind. My first idea would be slightly different, but this is perfect it serves the purpose. It's it makes the data structural just the same way. Yeah. It wasn't a jab. I'll clean this up a bit. I think, you know, some of these other things that we had that are marked yet as required recommend it. I'll check the whatever we documented when we document it say the maintenance guidelines or the common repository structure and make sure that they have whether or not it's a required or recommend it. So the things that we just added, I'm guessing these are all recommended practices since we just kind of added them. They weren't things that we thought were necessarily required, but happy to be told that you think something should be required if it should be. Okay, so for the moment, I'll make them all recommend it. And then if for some reason at some point in the future we decide that they should be required we can have that discussion. Any other thoughts on this before we close this topic. Just I think it's a great idea. Generic from the platform. So maybe you said it before and I missed it so what's the plan now. I mean, how do you go at filling out all this data. Yeah, so I know I thought I could maybe potentially take a first stab at this by going through for the different projects and marking whether or not they exist and where I found them. And anything that's left blank, turn that over to the, the projects to allow them to update it or change it as the case may be if, if I got it wrong for some reason. Does it sound like an appropriate next step. If you're willing to do the work. I don't think it is, you know, Jack, but I think it's a bit unfair. I don't know why you would have to carry the load here. We have people from different projects, even within the TSE loan, I think it should be spread around so that at least one person per project volunteers to do it for their own project. And then there may be some that for which we don't have anybody. Yeah, that would, that would work or we could just say for the next quarter reports please fill out the initial spreadsheet as well. Interesting idea. Okay. I'm happy to do either way if somebody wants to volunteer to fill it out now that's great. I'm not going to force anybody to do that, but I do think yeah definitely I want in the next quarterly report. If it hasn't been filled out or it's partially filled out for the projects to complete that. I see I'll volunteer to do fabrics. All right, thanks. First, first year. Yeah, so we have a precedent. I'm going to change that link that I have right now it's coming only I'm going to change it to editor so that anybody can go ahead and edit the document going forward. So Tracy will have this as ongoing or just one time capture. Assuming some projects may not have all of them checked. Do we want them to progress so eventually they have all of them checks. I think that would be ideal Jim right as that we do get to a place where they are all checked. I think it. The more that people and projects of, let's say the more that projects have checked these I think the more advanced they are. I think there's, you know, potentially a question of. And this was not something that did but maybe we also want to look at the incubate incubation exit criteria and see if there's any other things here that might be good questions to include. We also tell us where the projects are currently being incubated whether or not it is getting close to to being something that they would request to go active. So, yeah, I don't think this is a one time thing I think, you know, the problem that we have is that once people fill it out they think they're done, but things change in the projects right new repos are added. People, you know, may may do things differently in the code right they may have changed some stuff. Some of these will definitely feel like they're static but I think there is the need for us to, you know, look at this ever so often and make sure that things are up to date. Yeah, that's how I'm thinking about it as well so given that it's probably a good idea just to tie this up with the quarterly report. Either expand is the section where we do the yes and no checklist or link link to this from that section. And we'll clarify what does require mean. What does not doing the require Intel. Just prevent me from graduating or there's other other consequences. Yeah, I think. So two things Jim one on the project reports what I thought I'd do is replace the current section that we have the yes no questions and just replace it with a pointer to this document so that people can check their project and make sure that it's up to date. Right. And then related to whether or not a project has not completed a required stuff I think that is the time at which we become a bit noisy with them as the TOC and we say when are you going to do this. I know I've seen that a lot in the project reports in the past right where where it's been the case that a particular project hasn't completed something, maybe in the inclusive language statement or something and usually a question comes out in that project report when are you going to do it or why haven't you done this and I think that's still the appropriate type of steps for us to be taking. Yeah, cool sounds good. All right. Any other volunteers for anybody who would like to volunteer for any other projects. Yeah, I'll do the far flat one. Okay, thanks Jim. Thank you volunteers. Anybody want to take on any of the other project. How could you catch. And bevel. And bevel. Okay. Thanks Peter. Anyone else. Okay. Great. So the, the, the link is now editable. So if you do open it again, you should be able to see that you can edit it. I have nothing else on the agenda for today. Does anybody else have anything they would like to bring up in terms of logistics. What was the idea to create a tab for each project. Yes, or a column. A tab. Yeah. Okay. Which is just basically a copy of the template. Any other topics for discussion today. Well then I appreciate that. Thank you. I think maybe just one comment before I let you guys go. I know you guys were all excited. We hit that lead button. The, the TSE. I think we said this last time. The TSE. Election is currently in the hands of the governing board. So we're expecting results back from that. In a week. Probably early next week I think is, is the timeline for that. I think we're going to have to wait until once those results are final. As far as the, the new TSE that's coming in. One of the things I was thinking we might do for a TSE call next week is if we do have the results. Potentially we'll get some of the new joiners to come in and we could potentially have a discussion on. You know, a transition type discussion where the people who are. Provide some thoughts and insights into. Things that they've done and I would like to see maybe being continued in the next year and then maybe some input from the new TSE members as far as. What it is that they'd like to accomplish in the next year. So. What for. When the final results actually come in, if it shows up in time or not, but that's, that's kind of the current thinking and kind of what's happening. With the TSE election. All right. So that's all I have, Jim. You did come off and did you have a question. No, I was ready to say thanks to Tracy. Yeah, so that's it. I will let you guys actually hit the leave button now. So thanks again for your thoughts and your discussion today. Thanks, Tracy. Thanks. Bye. Tracy. Bye everybody.