Tracy Kuhrt: Alright, welcome everyone to the June 2 hyper ledger technical student can make the call.
Tracy Kuhrt: As you are aware, do things that we must abide by the first is the antitrust policy notice that is currently displayed on the screen.
Tracy Kuhrt: And the second is the code of conduct that is linked in our agenda so as far as announcements go, we have our standard.
Tracy Kuhrt: def weekly developer newsletter that goes out each Friday, if you have anything that you would like to include in that please leave a comment on the wiki page that is linked in the agenda.
Tracy Kuhrt: And then does anybody else have any other announcements that they would like to make.
Tracy Kuhrt: No okay so for quarterly reports we have the hyper ledger cello report that came in this week.
Tracy Kuhrt: As far as I could see we only had the one question that I put in and mauer has responded with that, with an answer to that so.
Tracy Kuhrt: I don't see any additional comments, but I also only see that two of us have had a chance to review this so given that I will leave this on the agenda for next week, so that.
Tracy Kuhrt: Everybody on the TC will have a chance to review that particular report.
Tracy Kuhrt: And then the firefly report is coming to next week.
Tracy Kuhrt: So we'll look to to see that coming.
Tracy Kuhrt: Any comments on the quarterly reports.
Tracy Kuhrt: No okay so as you guys may have seen I did send a follow up email to quilt.
Tracy Kuhrt: Their quarterly report was coming up, I think, next week or maybe it was this week, and so I sent them an email.
Tracy Kuhrt: asking if they wanted to keep the project in a dominant state or move it to end of life and they responded with it, it was probably time to move it to an end of life state, so I created a PR specifically in the quilt.
Tracy Kuhrt: repo and it was approved by.
Tracy Kuhrt: approved and marched by.
Tracy Kuhrt: The main characters so.
Tracy Kuhrt: I just wanted to make sure that we were aware of that in I just get a maybe a game may vote just to confirm that we are moving that to end of life for the tasc.
Tracy Kuhrt: Any comments before we have the vote.
Tracy Kuhrt: Welcome
Nathan George: Oh, just for the record the the quilt project came out of the Web payments working group the w three C and did a lot of interesting things for identifiers.
Nathan George: For blockchains that track financial assets and it has done a lot of interesting thoughts work that affected what we chose to do with identity, especially when we worked on.
Nathan George: Cross chain identifier work for the did specifications so big thanks to everyone who worked on the project and brought to its current state, but it hasn't been active for quite some time as Tracy very well knows, and so.
Nathan George: It was good to see that folks were around to reply to the pull request to move to an end of life state.
Tracy Kuhrt: yeah definitely thanks Nathan.
Tracy Kuhrt: As as we've said in the past to the other projects that have gotten to end of life state.
Tracy Kuhrt: You know, obviously, thank you for being part of the Community to the hyper ledger quote folks if they were to ever listen to this in the future.
Tracy Kuhrt: And thank you for the work that they have done on that project and i'm working towards bringing inter ledger to hyper ledger.
Tracy Kuhrt: Any other comments.
Tracy Kuhrt: Okay, all right, would you just take us through a not a roll call vote, but just.
Tracy Kuhrt: approved abstaining type.
Ry Jones: sure.
Ry Jones: well.
Ry Jones: Nobody there's no motion to vote on, and nobody second at the non motion.
Tracy Kuhrt: Oh, thank you right.
Tracy Kuhrt: you're not it's certainly her.
Tracy Kuhrt: Fear second.
Nathan George: i'll make the motion thing is, I hope, approve the request.
Ry Jones: Okay.
Bobbi Muscara: i'll second.
Ry Jones: So in the matter for the tasc moving call to end of life Is there anyone who wishes to abstain from the vote.
Ry Jones: Is there anyone that objects or wishes to vote, nay.
Ry Jones: All in favor say Aye.
Aye.
Ry Jones: Motion passes by voice spoke.
Tracy Kuhrt: thanks for your thanks for keeping me honest too.
Tracy Kuhrt: Alright, so in the discussion items, I just wanted to call out specifically that we have had to PRS that ended up getting merged into the TC repo one to rename ci to open ssl.
Tracy Kuhrt: And the other, to add the security related mandates for graduation to the yeah ignition extracurricular so.
Tracy Kuhrt: I would see if anybody has any comments here the kfc about those particular PRS because I know that they didn't go through a formal vote here, but really just what do that the github.
Tracy Kuhrt: PR process, so if anybody has any comments now it's probably a good time to have this coming.
Tracy Kuhrt: Okay um so that is as far as I know, the end of the normal TC meeting, but if anybody has any other items that we should talk about before we hand it over to Jim.
Tracy Kuhrt: raise your hand, let us know.
Tracy Kuhrt: Alright, so Jim I think it's a few.
Tracy Kuhrt: to walk us through that the task force on project help.
Jim Zhang: All right, thanks Tracy me share my screen.
Jim Zhang: Okay, so um we didn't.
Jim Zhang: We didn't have a off cycle meeting.
Jim Zhang: But we did have a lot of good discussions in the last Task Force meeting in this tasc time slot.
Jim Zhang: That was then in April so just as a refresher we went through the other dimensions that we believe are important to reflect a projects, health and that's in this column it's into large categories, focusing on Community side or focusing on the code side.
Jim Zhang: On the on the Community side we had growth as one dimension and diversity retention maturity friendliness friendliness and responsiveness on the cold side we had usefulness production readiness fundamental metrics docs and amount of innovation.
Jim Zhang: For this call, I like us to discuss.
Jim Zhang: Given these dimensions, what type of data we think are.
Jim Zhang: useful to support.
Jim Zhang: To support them, so we can get some measure from data to reflect on each dimension, before we dive into that.
Jim Zhang: Any questions on.
Jim Zhang: Any aspect that we discussed last time so altogether, I see there are.
Jim Zhang: There are 11 of them.
Jim Zhang: No that's great okay so let's dive in so i've got a bunch of.
Jim Zhang: ideas.
Jim Zhang: So we can go through them, and if you don't think they make sense, we can strike them out.
Jim Zhang: Or, if you have additional ideas, then we should add them, and so we put this.
Jim Zhang: Together okay for project growth.
Jim Zhang: We want this to be reflecting.
Jim Zhang: How many people are becoming newly interested in this project, and there are so interested that they start contributing either in discussing new features.
Jim Zhang: Discussing drawbacks, or even contributing code so.
Jim Zhang: I was thinking we can tally the definitely mostly driven by github data.
Jim Zhang: number of contributors to the code base.
Jim Zhang: scraping the the PR data and issues data that where people log requirements.
Jim Zhang: or just submit a bug report.
Jim Zhang: don't know if there are specific things we, we need to look at for both PRS and issues.
Jim Zhang: To get real contribution versus.
Jim Zhang: You know, casual one time thing and then they never came back I know Tracy did a lot of work in this area to try to use PR and issues there and get hub to to define who are the casual ones who are the the strong contributors and who are the.
Jim Zhang: recurring or repeated contributors, so all that work can be applied here.
Jim Zhang: Also, we want to look at.
Jim Zhang: This court if possible.
Jim Zhang: So here, I think we need to consider a technical feasibility.
Jim Zhang: Is it possible to.
Jim Zhang: to analyze discord and see.
Jim Zhang: For a particular project.
Jim Zhang: Which user you know, keep showing up week after week, and have sustained discussions.
Jim Zhang: That can be a good indicator of contributors that are mostly contributing ideas in discussions, rather than code.
Jim Zhang: So do do these makes sense.
Jim Zhang: for growth.
Hart Montgomery: So, first of all, a somewhat orthogonal practical question where should we be commenting in chat for this discussion.
Hart Montgomery: i'm assuming we want to do discord, but do you want to do in the tasc chat or the.
Hart Montgomery: That related Task Force chat.
Jim Zhang: let's go ahead and use the task force chat there's one tracing created for the health data.
Hart Montgomery: Okay yeah I see it, great.
Hart Montgomery: And secondly, I think this is a great start Jim I would also include other things like documentation, you know are people working on that.
Hart Montgomery: And you know I guess Community outreach so are people starting to do like meetups you know, is there, you know.
Hart Montgomery: Outside evangelism I guess.
Hart Montgomery: Over outside evangelism takes place.
Jim Zhang: Thanks.
Jim Zhang: kitten Keith clarify the.
Jim Zhang: The meetup the outside evangelism aspect you mean people leaving for example.
Jim Zhang: In a particular region meetups focus on on firefly.
Hart Montgomery: Recently debbie absolutely.
Hart Montgomery: Okay, understood like are people trying to grow, the project basically.
Jim Zhang: yeah.
Hart Montgomery: This is like you know just things, we know that generally work to help get more contributors like these things are people doing them.
yeah.
Jim Zhang: That makes sense that's a good one.
Jim Zhang: And I think this will be mostly just asking people right and have a place to.
Jim Zhang: to lock them.
Hart Montgomery: Sure, well, I mean, these should all be logged in our events right.
Jim Zhang: that's true.
Hart Montgomery: Now they're always it certainly people occasionally do things on their own.
Hart Montgomery: But whenever.
Hart Montgomery: Whenever people host a meetup or something you know we encouraged them to tell us right.
Jim Zhang: So do you think the the outside evangelism is a.
Jim Zhang: Is is data to collect it.
Jim Zhang: or it's just means to an end, because at the end of the day, if.
Jim Zhang: At the end of day, it should be reflected in the growth of the contributors in these areas right.
Hart Montgomery: Well, I think it's a it's a leading factor for those right.
Hart Montgomery: So if I want to be able to you know if I went to anticipate how I think growth is going to be in the future, I think, looking at that is really important.
Jim Zhang: Okay.
Hart Montgomery: Does that make sense.
Jim Zhang: yeah that makes sense.
Jim Zhang: If if a project is not getting.
Jim Zhang: Exposure through these meetups then we probably should encourage them because it's, as you said, it's a it's a good way to lead up to the.
Jim Zhang: To the appearance of additional contributors.
Hart Montgomery: yeah so the the earlier stuff is sort of you know, has the project grown and, like the meetup kind of thing is, will the project growth basically right.
yeah.
Jim Zhang: yeah.
Tracy Kuhrt: I think, maybe to figure out who the new interested individuals are if we could use some sort of page view count on the contributing empty file.
Tracy Kuhrt: Or if there's a different contributing that's in the document for the particular project that can be a way of seeing how many people have.
Tracy Kuhrt: expressed an interest by looking at their contributing guide, instead of just reaching out on discord or during a PR because that could then tell you how many people end up converting based on somebody goes to the contributing guide do they actually end up submitting a PR or not.
Jim Zhang: The contributor guide is that being our wiki or is a.
Tracy Kuhrt: So so according.
Tracy Kuhrt: To our.
Tracy Kuhrt: I don't remember what we call it, but the the folder requirements were all each of the projects is supposed to have a contributing empty file.
Tracy Kuhrt: As the initial entry point some of those actually have text directly in them, and some of them point to a.
Tracy Kuhrt: Contributing.
Tracy Kuhrt: A file on their read the docs or something like that so.
Tracy Kuhrt: I obviously that's that becomes a slightly bigger challenge when you're redirecting.
Tracy Kuhrt: To a different page but.
Tracy Kuhrt: yeah I think you know we at least have the requirement that everybody has a contributing indeed in their.
sleep okay.
Jim Zhang: yeah I think that's a good idea may be able to collect page views in some of them may not be possible, in others, depending on where they exist.
Jim Zhang: cool anything else.
Jim Zhang: On this particular one and I ever as a gic This is our This is our main interest is the growth of the Community.
Jim Zhang: So I think any ideas that we're not thinking we should talk about them.
Jim Zhang: Okay, so let's move on to diversity diversity is also very important.
Jim Zhang: We want this is fault tolerance right when one organization, for whatever reason, goes away at all, having diversity will keep the project life.
Jim Zhang: So the number of obviously number of orgs contributing to the code base that's probably the most obvious.
Jim Zhang: type of data, we should collect.
Jim Zhang: Do we have anything else.
Jim Zhang: That we should think about.
Dave Enyeart: In the fabric reports I usually put percent of commits and contributors from each organization well I usually focus it on IBM because that's by far the most usually so i'll say like how much percent is IBM how much presenters other.
Jim Zhang: yeah.
Jim Zhang: Thanks that's that's a good point.
Tracy Kuhrt: Also.
David Boswell: One other form of diversity, could be language translations, for example, and how many languages are talking to is documentation available and.
David Boswell: Although I guess I could also fall under perhaps you know friendliness.
Jim Zhang: yeah that's that's a good one, David.
Hart Montgomery: I think, contributing issues is also important.
Hart Montgomery: So sort of trying to measure who's contributing to the roadmap.
Hart Montgomery: Not only who's contributing the code.
Jim Zhang: So that would be also.
Jim Zhang: issues, and this for.
yeah.
Hart Montgomery: yeah.
Jim Zhang: Okay.
Hart Montgomery: But the the thing I want to emphasize is that you know it's people who are also contributing to the roadmap, not just for code itself right.
Jim Zhang: mm hmm if.
yeah.
Jim Zhang: yeah that makes sense.
Tracy Kuhrt: For the projects that have the rfc that could be a good repo to take a look to see who the contributions are coming from the world.
Jim Zhang: Our seas or he has.
Tracy Kuhrt: requested yeah yeah I just know that a number of our projects have I.
Tracy Kuhrt: distinct Repo for IFC.
Tracy Kuhrt: So for those projects if only one organization is contributing to that repo then maybe that there's not the diversity for the roadmap that tardies talking about.
Jim Zhang: that's a very important.
Jim Zhang: aspect thanks Tracy yeah We actually had as an example firefly had separate example Repo for firefly improvement request fire and we've had many open by by other orcs very significant architecture discussions.
Jim Zhang: that's a good one.
Jim Zhang: Okay, so if that's it for that one let's move on to retention, so this is about keeping.
Jim Zhang: Keep attracting the interest of contributors.
Jim Zhang: longevity.
Jim Zhang: So, having having the contributors that we recorded from those efforts do they continue to show up.
Jim Zhang: Month after month, both in PRS and discord I guess the same type of data, but different, but a different.
Jim Zhang: A different way to analyze them.
Tracy Kuhrt: We could do something around so for.
Tracy Kuhrt: Our retention I previously had in the project reports, the number of people become inactive in last month.
Tracy Kuhrt: Meaning that they hadn't made a contribution in over six months.
Tracy Kuhrt: As well as the.
Tracy Kuhrt: Can a number of repeat contributors, that you have.
Tracy Kuhrt: Like if somebody is only contributed once done, I think that's you know it's good but it's not what we're looking for somebody who continues to come back and contribute.
Jim Zhang: OK.
Jim Zhang: let's continue of maturity so maturity is mainly.
Jim Zhang: As we're going through the analysis of these dimensions maturity should be a.
Jim Zhang: should be a.
Jim Zhang: sort of a qualifier so that.
Jim Zhang: Maybe on the particular aspect, it should be treated differently for young project versus a versus a mature project.
Jim Zhang: and maturity it's probably a subjective thing that is not directly correlated to age, but we could definitely look at was the first line of code or first commit.
Jim Zhang: was started that's the start of life.
Jim Zhang: and frequency of releases.
Jim Zhang: could reflect.
Jim Zhang: The maturity of the projects.
Jim Zhang: I don't know if that's.
Jim Zhang: We probably can have a discussion about this, the idea was which your projects tend to have more regular cadence.
Jim Zhang: And they usually can do the release on that, on the cadence active projects may have faster cadence but they they tend to be more.
Jim Zhang: irregular more on demand.
Jim Zhang: And certainly.
Jim Zhang: less active and less mature prod projects will have.
Jim Zhang: Less amount of releases so longer cadence between releases.
Jim Zhang: Does this make sense, do we think that's a fair way to analyze maturity.
Tracy Kuhrt: So you have your hand up.
Tracy Kuhrt: It was probably before this question so.
Hart Montgomery: Oh no, it was for this question but.
Hart Montgomery: Thanks Tracy.
Hart Montgomery: yeah, so I think the frequency of releases is a good metric of maturity it's not necessarily like you know, are you releasing every week.
Hart Montgomery: But you know, do you have a schedule and are you roughly adhering to that schedule, so I think that's a great thing Jim and I, you know you should leave it in.
Hart Montgomery: On the other hand, I think, other things that are great indicators of maturity our documentation.
Hart Montgomery: I consider, you know I don't consider a project mature unless it has you know at least reasonable documentation.
Hart Montgomery: And finally, like you know certain best practices, come to mind like I would not consider a project mature, for instance, if it were not following the best security practices things like that right.
Hart Montgomery: Security practices are the ones that you know come to mind to me but i'm sure there are other others that people could think of and suggest.
Arun S M: It could also include the test courage that debate.
Arun S M: Any new code gets added to release process.
Arun S M: That destination for somebody to become come maintain ours from committing.
Arun S M: single purchase.
Jim Zhang: He will automatically calculate test coverage, making sure they're not dropping that sort of thing.
Arun S M: It so since we are looking at and so majority of the project, it could also a mature project or tab so best practices can span across the spectrum.
Arun S M: That would include the the way they engage with the Community members.
Jim Zhang: The last part you said, can you repeat that.
Arun S M: Sure, so I was thinking more in terms of following best practices that will have a roadmap for somebody to become a maintainer if they want to start contributing.
gotcha.
Tracy Kuhrt: Okay.
Nathan George: burn touches on something that's even more important here with it's harder a lot harder to measure, and that is.
Nathan George: Does the Community have some cross organizational way of organizing their progress mean they have some sort of roadmap or active and regular discussions on what should and shouldn't be built in when i'm and.
Nathan George: I don't know that that's a metric or if it's kind of a pass fail, is there such a thing that we.
Nathan George: can ask our watch for.
Jim Zhang: mean.
Jim Zhang: Is the.
Jim Zhang: Is the leaders involving the be in defining the roadmap.
Nathan George: yeah like the example here is I show up with really great new idea to improve your project, where do I go who do I talk to how do I find that out it what's the.
Nathan George: what's the Cross organizational way of coordinating critical in this sprint or should it go in next quarter.
Jim Zhang: yeah so we have.
Jim Zhang: feel like this is somewhat the Jason to Franklin us to contributors, but I don't think it's captured anywhere else.
Jim Zhang: i'll leave this in in here.
Jim Zhang: that's a good one, thanks Nathan.
Jim Zhang: Okay, so let's move on to the next one friendliness, this is for contributors potential contributors who have good ideas do they feel they are being accommodated and they can have meaningful discussions.
Jim Zhang: So some obvious things is this project define good first you issues.
Jim Zhang: These are things to help potential contributors get their hands dirty just go through the basic practices of doing a build and making small fx and then propose a PR.
Jim Zhang: as easy as possible once someone has been able to go go through this end to end it's much more likely they can they will contribute more in the future so that's that should be.
Jim Zhang: a really good thing.
Jim Zhang: can be measured in our new contributors being on boarded.
Jim Zhang: Week after week.
Jim Zhang: Next, one is a bit subjective can new ideas to be accommodated.
Jim Zhang: Ian, even if they may lead to forking up the code base.
Jim Zhang: This was actually discussed on the last call.
Jim Zhang: Having robust discussions.
Jim Zhang: To solve concerns from the Community.
Jim Zhang: Rather than brushing them off encourage them to create a new fork if this is this is if this can't be accommodated in the same code base.
Jim Zhang: That reflects, you know that the the core committed is really care about those new ideas from new contributors.
Hart Montgomery: yeah, so I think this is actually really important and you're you're touching on a core fact here, Jim so one of the things that I really like to see is sort of.
Hart Montgomery: How far out of the way our existing maintain owners willing to go to help new contributors so it's sort of like if a new contributors submits like a flawed issue or a flawed PR.
Hart Montgomery: You know how far the maintainer is willing to go to help them right, so I will credit Peter is someone who does an excellent job here when someone comes along to cactus with something that's not you know perfect Peter will usually go out of his way to help them a lot.
Hart Montgomery: And that's really fantastic and that's really good for the Community.
Hart Montgomery: So one metric for for sort of this.
Hart Montgomery: In this sort of indicative of this is, you know what's the time to land PRS are committed, Sir issues but mostly PRS for sort of core maintainer or core contributors.
Hart Montgomery: versus new contributors right, so you know, are the are the maintainer you know, addressing the the actions created by new contributors, and I think this is really important.
Hart Montgomery: I hope that made sense.
Jim Zhang: yeah it definitely does.
Jim Zhang: So we're we're I think we're actually talking about a.
Jim Zhang: An idea I don't know if we actually talked about how this will be captured.
Jim Zhang: The type of data that needs to be collected to reflect this.
Hart Montgomery: So I think you could correct you could collect this you know, in some way like you know.
Hart Montgomery: The PR or the issue analytics from new contributors versus existing contributors, right now, you would expect it to be a little faster for.
Hart Montgomery: Existing contributors than new contributors, but you don't want it to be like galactic for new contributors right where, if someone like creates a PR and it's just never looked at right.
Jim Zhang: yeah.
Hart Montgomery: Like PR is closed, without comment is another like thing that's.
Hart Montgomery: You know that I personally discouraged.
Jim Zhang: yeah.
Hart Montgomery: I guess sorry.
Tracy Kuhrt: I was just gonna say I added the last line to kind of capture what heart said there and I also add it to the first line, and besides good first issues help with tag and then give you have.
Tracy Kuhrt: Help wanted that implies that you have somebody who's willing to help you in in going through the PR process and working through a particular issue together, so I added that to the friendliness as well.
Jim Zhang: yeah so thanks Tracy yeah this This makes sense.
alright.
Arun S M: Thanks very, so I think are covered, one of the questions that I wanted to ask how long a PR book take from a new contributor and.
Arun S M: How far is the Co maintainer going to do help them out the second part to, that is, with.
Arun S M: respect to taking an input from the new contributors are taking in new ideas right that's a topic that Jim also kind of brought up.
Arun S M: I know, in the past, people used to ask questions on rocket chat and that used to lead to discussions and eventually.
Arun S M: Maintenance if they like it, they would go and add that feature, or if they don't they would probably discuss and say is that we are not going to take do anything with that.
Arun S M: And then we decided that will go with raising issues with all the repositories but I don't think so that's consistently in a bar across all projects because some of the projects are still not using.
Arun S M: github issues as as a source for taking in inputs, I know some other some of them are strictly following it so.
Arun S M: I think that's also a measure of friendliness of there should be a consistent way where somebody can come in and say this needs to be done, and probably start a discussion around that.
Jim Zhang: So RON you're saying is the project.
Jim Zhang: defining a clear way for anybody to to.
Jim Zhang: raise a concern or or an idea.
Arun S M: sure we can consider that I know some of the projects may still be preferring an external to like China.
Hart Montgomery: So another thing that I think could be useful for measuring this is sort of rp ours and other issues and things addressed in a somewhat fivefold manner.
Hart Montgomery: So you know basically like maybe they're not getting merged, but you know are people sort of you know commenting on and reviewing things.
Hart Montgomery: In the order that they're coming in.
Jim Zhang: yeah.
Jim Zhang: cut the line because your court manner.
Hart Montgomery: I mean obviously not all PR or equal right, you know if there's like a security fix it's not the same as.
Hart Montgomery: You know, an improvement right, but in general the.
Hart Montgomery: And in some PR so good in some PR you know less good right.
Hart Montgomery: But, in general, there should be some sort of process of addressing things in order right.
Jim Zhang: yeah.
Jim Zhang: Okay.
Jim Zhang: that's awesome great ideas.
Arun S M: Right, so I think, since we are talking about friendliness, should we also consider the project meetings I noticed all projects are advised to have their own maintainer meeting or maybe competitors mating gatherings that happened at the bi weekly or once in a month.
Jim Zhang: Other.
Jim Zhang: Right.
Jim Zhang: This captures your idea right okay all right.
Nathan George: I just wanted to add to the address to an order.
Nathan George: it's not so much about, but there are addressed viscerally in chronological order, but that there is a defined order and that every Organization has fair access to that order.
Nathan George: An example of what we've seen in the past, where the process is broken, is where.
Nathan George: The primary organization, where all the containers are set their own internal corporate roadmap and everything for that happens, like clockwork on schedule.
Nathan George: But anybody who comes with a change from outside of the organization, they have to wait through an undefined other process, so you might see a pull request will pull requests get merged in two or three hours when they're part of that org but three or four days they're outside.
Jim Zhang: enjoys the.
Jim Zhang: So these in yours you're saying there should be a.
Jim Zhang: A well defined practice to the fine how the party list of issues to be revealed.
Nathan George: yeah but but it doesn't.
Nathan George: have to be chronologically just has to be fair, and you know obvious.
Nathan George: meaning if I come with a critical security patch of course that might get merged well, well before you know someone's here to add a new API.
Okay.
Jim Zhang: Thanks for adding that basin, shall we move on to the next one, I feel more and more.
Jim Zhang: responsiveness becomes very similar to friendliness, maybe we should consider merging them but responsiveness is mainly how how quickly, things are done.
Jim Zhang: Especially in terms of when they come from outside quote unquote outside.
Jim Zhang: outside of the core maintainer group.
Jim Zhang: it's very similar to Franklin is because when you are responsive you're demonstrating a friendliness to new contributors, and of course you are, you are responsive to within the core maintainer as well because everybody wants to to get the right thing, done.
Jim Zhang: So, shall we go ahead and merge responsiveness and friendliness into a single one.
Tracy Kuhrt: part.
Hart Montgomery: So I think this is useful to separate I think Nathan illustrated it really well when he mentioned that there's you know, there can be a core group of containers that are very responsive to each other, but not necessarily.
Hart Montgomery: responsive to to outside contributors.
Jim Zhang: mm hmm.
Hart Montgomery: And i've also seen projects where the maintainer are very slow to respond to each other.
Hart Montgomery: So I think it's fine to have this as a.
Hart Montgomery: As its own category.
Jim Zhang: So basically this is looking across the board, how, in general, things get get done.
Jim Zhang: Exactly yeah.
Hart Montgomery: Okay.
Jim Zhang: That makes sense.
Jim Zhang: let's keep them separate still.
Jim Zhang: So that.
Jim Zhang: applies to both PRS and issues in github and also on questions that are not responded to how.
Jim Zhang: Do we know if that's even possible to measure.
Jim Zhang: Like can can we can we tell the difference between some somebody making a comment or just a statement versus asked me a question in this court and if there's no reply.
Jim Zhang: This This seems to involve some sort of Ai to actually understand if questions in this Court are being addressed or not right.
Tracy Kuhrt: What made them you had your hand up before that question.
Tracy Kuhrt: I don't know if anybody has a good answer for your question.
Nathan George: I was gonna say I don't have a good answer that question I think right i'm not sure how much sleep and automate that, though.
Nathan George: There might be some best practice of how us, we should acknowledge every post in some way and we could train them encounters on that so that it could be measurable it just I don't know I don't have any ideas on how we would do that.
Nathan George: The thing I was going to say, is, I think, Jim comment hit a real important tool, which was.
Nathan George: Anything that can be measured across everybody who contributes, I think, is more of a responsiveness metric that friendliness metric and it felt to me like.
Nathan George: we've added a lot of things to friendliness that might be able to be in responsiveness because.
Nathan George: We can't measure them on a who's new versus who's established basis, especially when we consider contributors who might only be doing drive bys on the code, but might be very, very active on the calls are on the email list um so it feels to me like.
Nathan George: Focusing or or pushing more of the metrics over to the responsiveness side might give us a more accurate view of what's going on.
Nathan George: In at least in the case of like the no special treatment or.
Nathan George: there's a roadmap in place some of those things seem more were like of fairness, or responsiveness, as opposed to maybe friendliness, a new new contributors.
Jim Zhang: yeah that makes sense to me.
Jim Zhang: That we could we could basically be the more objective measuring overall responsiveness.
Jim Zhang: cool.
Right.
Hart Montgomery: So they said, I agree with you, I don't think we can get you know perfect information on this.
Hart Montgomery: But I think we can you know cut some of these responses we can handle some of these statistics, with respect to friendliness, by looking at like statistics for containers versus statistics for contributors right or statistics by company right.
Hart Montgomery: Because we have all of that information.
Hart Montgomery: So, while some of these may be difficult, I think it's probably still possible to gather them, and you know I know that a lot of this stuff you can do with a couple clicks NL fx right off the box.
Nathan George: I say to that yes, that sounds great.
Jim Zhang: awesome.
Jim Zhang: Okay um.
Jim Zhang: So yeah, by the way I see people are actually doing co editing so that's great I know Ryan has been targeting people to do that on the on wiki.
Jim Zhang: So let's move on to to code and see if we can finish everything on time.
Jim Zhang: usefulness.
Jim Zhang: Is the project being adopted by customers and tire kickers are people actually use them using them, I was actually thinking about this, we were announcing end of life for quilt.
Jim Zhang: Do we actually know if there are being used by customers would be great if we if we do and say yeah.
Jim Zhang: Maybe end of life but it's it's it still got strong adoption it's just not moving forward in terms of features that's very different than a project that's been.
Jim Zhang: In hyper ledger and no one uses it right, so I i'm really curious, how do we get this so obviously we can ask and have people tell us.
Jim Zhang: How do we do that is the question.
Jim Zhang: Several things we could use.
Jim Zhang: docker pose.
Jim Zhang: But this can be skewed you know if if there are very frequent test runs against a particular projects you're obviously can I get a lot of darker polls that can skew the.
Jim Zhang: matrix.
Jim Zhang: released binary downloads probably the same idea.
Jim Zhang: and the next one was, I think idea from David like we could tag resources that announce the usage of a particular project and have that be tallied in some fashion and publications.
Jim Zhang: political project generates.
Jim Zhang: Do we know if it's practical to collect this and we want to create some sort of channel for our customers and developers to tell us the projects that are using.
Jim Zhang: Like maybe we can organize some campaign.
Jim Zhang: With Davis department to to encourage you know be encouraged the world to tell hype pleasure what they are using.
Jim Zhang: ideas like this.
Jim Zhang: Any thoughts.
David Boswell: I mean, I think we move, we can tap into this could be an opportunity to work with the cigs, for example, you know we can just ask them if we give them a format for how to, as you say tag things I mean we can try to.
David Boswell: encourage them to do that, I know that there's a lot of discussions about what's getting used for what you know.
David Boswell: solution and in the cigs levels, I think that's where some of that data lives, and then we have the case study you know library to where that information is available, so those are those are the thoughts that I had about where we can get this information.
Nathan George: I think we also have to acknowledge that some of the most interesting things will never find out about is one of the reasons I really liked the hackathons that happened around the world, because often someone would show up who had not.
Nathan George: been on our radar at all in any other way, and they were doing something interesting but they wouldn't have talked to us if they didn't have been have a local opportunity to do so.
Nathan George: So I think we should make sure when we add this metric we acknowledge this is what we know about it's not happening.
yeah.
Jim Zhang: yeah, I think, for the most part, this is.
Jim Zhang: Pulling information from from the outside world, unless we create some some sort of channel and encourage people to do it, we probably will never find out.
Jim Zhang: Okay, so sounds like the the the the action here is.
Jim Zhang: I guess i'll work with with Dave and Tracy in heart and see if there are things we could do here.
Jim Zhang: I think it'd be great if we if we can collect the sort of information it's great marketing material for the high pleasure brand.
Jim Zhang: Alright cool.
Jim Zhang: I wonder if the certified vendors right.
Jim Zhang: might be an interesting resource.
Jim Zhang: see what customers from their point of view are using which technologies.
Jim Zhang: Maybe we can reach out to ask them.
Jim Zhang: All right.
Tracy Kuhrt: Okay, unless.
there's a distribution.
Ry Jones: deal you're not using the correct microphone.
Daniela Barbosa: Oh sorry, can you hear me now.
Daniela Barbosa: yeah all right um there is a.
Daniela Barbosa: list for the HC SPS but the ch CSP or just for hyper ledger fabric right now.
Daniela Barbosa: But many of them do work across projects.
Jim Zhang: yeah.
Jim Zhang: cool it'd be okay, for us to contact them to to ask these sorts of questions right.
Daniela Barbosa: Then yeah.
Daniela Barbosa: We are awesome.
Jim Zhang: that's great.
Jim Zhang: um so let's move on to the next one, by the way, anybody is welcome to you are to make additional edits after the call, so we only have four minutes left.
Jim Zhang: Production readiness.
Jim Zhang: We want to see if it's already past one dot zero what's the test coverage of the code base.
Jim Zhang: Do they publish performance and real reliability testing data is the user documentation of high quality anything else for this part.
Tracy Kuhrt: Bobby.
Bobbi Muscara: yeah, I just wanted to supply if we run out of time that the learning materials working group is currently creating a badging system for documentation to move from incubation to graduated status, you must have all the pieces and we're working on that presented the tasc in the near future.
Jim Zhang: That would be a great thing to do, we would love to to have a sort of a standard view to the quality of documentation that it's very important thanks thanks for the working group for doing for doing that.
Tracy Kuhrt: And engine just.
Tracy Kuhrt: Because there's not here, he had last.
Tracy Kuhrt: last season, the last term for the TC suggested a badging.
Tracy Kuhrt: proposal, but it never made progress, we might want to go revisit that as we looked at matching it up with what we're doing here with the project health on to see if there's any additional sort of items that were included that budget proposal that we should be in the pudding here.
Jim Zhang: yeah yeah i'd be all for helping with that because I know from our own experience with firefly the team can definitely use help on.
Jim Zhang: what's the best way to write effective documentation right, so this will be also very valuable to the to the projects, because as developers, we know how to write good code, not necessarily write documentation and it's it can make a huge difference.
Jim Zhang: awesome.
Jim Zhang: So sorry this is taking longer than expected, so I think we have to stop now, I try to organize a off cycle.
Jim Zhang: Meeting to continue to finish this metrics and again everybody is welcome to to do more edits and add your thoughts there.
Jim Zhang: Thanks thanks thanks a lot for all the great discussions and back to you Tracy.
Tracy Kuhrt: Alright, thanks, Jim yeah so.
Tracy Kuhrt: As Jim mentioned feel free to edit this stuff and add additional items or commentary to it.
Tracy Kuhrt: he's capturing it under the task force.
Tracy Kuhrt: Section there's a project health Task Force and he's got some meeting notes so feel free to edit that and get your comments available, and with that i'm going to close the meeting for today, thank you all for joining, and we will see you again next week.
Hart Montgomery: Thanks Tracy.
Jim Zhang: fizzy.
Sierra banks.