Tracy Kuhrt: So, welcome to the April 21 hyper ledger technical steering committee call, as you are all aware, two things we missed by by the first one is the antitrust policy notice that is currently displayed on the screen and the second is our code of conduct.
Tracy Kuhrt: So for our agenda today, we have our standard announcements.
Tracy Kuhrt: A Dev weekly developer newsletter goes out each Friday if you'd like to have something added to that newsletter please leave a comment on the wiki page that is linked in our agenda, and the second announcement is the hyper ledger global forum is still accepting CFP.
Tracy Kuhrt: For just over a week more and I did see yesterday, I think it was yesterday and announcement come out that there are also an extra day of workshops that are.
Tracy Kuhrt: open and so, if you'd like to submit CFP for a workshop leave those are now available on the CFP site as well Oh, and then the heart is the call for program committee volunteer still open.
Hart Montgomery: So I clicking the unmute button, yes, we are looking for a couple more volunteers so, particularly if anyone on the tasc is interested in joining several people already have please feel free to reach out.
Tracy Kuhrt: Any other announcements that anybody has to make today.
Tracy Kuhrt: Alright, see no Hansen, nobody coming off mute I will take that as we know, so we've got the quarterly reports I did see the.
Tracy Kuhrt: hyper ledger fabric report come in either last night or this morning, which, but it was in my inbox this morning, so I Dave, thank you for that.
Tracy Kuhrt: i've seen a few people have already had a chance to look at it, but we'll make sure that's kept on the agenda for next week for everybody to have the opportunity to review the fabric report.
Tracy Kuhrt: Next week is the hyper ledger sawtooth report that's do, and of course we always have the calendar out there for people to take a look up.
Tracy Kuhrt: So with that, I do have one item that i'd like to discuss from the T is T PC business this week around the tlc responsibilities, the issue that we reviewed last week in rtc meeting and I believe we've got about six or seven sort of check marks already in the.
Tracy Kuhrt: In the issue itself as far as approvals I did see one change David, I think that you suggested that came in there.
Tracy Kuhrt: just add an extra s to one of the words, but I think that's the only specific change that i've seen a request it.
Tracy Kuhrt: was thinking, maybe we could have a vote almost to see if we would like to formally approved this in a PC meeting, but if anybody has any sort of discussion here that we should have before that, or we don't think we're ready yet now is the time is because.
Aruna S M: I guess, there is one more item to be added Point number nine personally I did it in one of the comments I sorta.
Tracy Kuhrt: So I think we.
Aruna S M: All want.
Tracy Kuhrt: To do we want to add implicitly the subscribing to the tasc.
Arnaud J Le Hors (IBM): yeah i'm happy to do put that in with the with the S missing that Dave spotted.
Arnaud J Le Hors (IBM): yeah, as I pointed out it's it does to be in the city and Lisa wouldn't be numbered nine because that's the Charter least but that's the detail.
Tracy Kuhrt: yeah make sense.
Tracy Kuhrt: Okay, any other comments or concerns.
Ry Jones: So I guess I just thought of one.
Tracy Kuhrt: In.
Ry Jones: Along the same lines.
Ry Jones: What about joining the github org.
Ry Jones: Is that a requirement.
Peter Somogyvari: I guess.
Tracy Kuhrt: I guess if they want to be informed of the.
Tracy Kuhrt: issues that are coming up on the tsp hyper ledger slash gc repo and that would probably be a requirement as well.
Ry Jones: Okay, there are a couple that aren't but it's.
Ry Jones: We can address that later, I think.
Tracy Kuhrt: Okay.
Arnaud J Le Hors (IBM): yeah I mean, as I said before, I mean we can always expand on it and we trade it's not the end of the world.
Tracy Kuhrt: that's right yeah if we come up with other things that we want to add to this after the fact.
Arnaud J Le Hors (IBM): And I suspect this kind of small things are not controversial by any means, just like you know, so we can just schedule Leah agree through a pull requests and.
Arnaud J Le Hors (IBM): Small additions.
Tracy Kuhrt: completely agree on oh.
Tracy Kuhrt: Okay, any other questions or comments any objections to us voting I guess would be.
Tracy Kuhrt: Where we're at at this point.
Arnaud J Le Hors (IBM): So, to be clear, I mean we're talking about approving this pull request with the two additional changes which is adding this requirement, about being on the Ts mailing list and the github or.
Arnaud J Le Hors (IBM): And and adding the missing s.
Adding.
Arnaud J Le Hors (IBM): it's funny after all, you know so many people looking at it is like we still miss it and it's like oh wait.
Arnaud J Le Hors (IBM): But it's good.
Arnaud J Le Hors (IBM): yeah.
Arnaud J Le Hors (IBM): So i'm happy to approve this of course.
Tracy Kuhrt: Alright, so shall we take that as emotion, or no.
Arnaud J Le Hors (IBM): Yes.
Tracy Kuhrt: We have a.
Nathan George: Second.
Tracy Kuhrt: Alright, thanks anything um.
Tracy Kuhrt: you're right do you want to lead us through but it doesn't have to be roll call vote, but just uh.
yeah.
Ry Jones: All those who wish to abstain.
Ry Jones: abstain or some.
Ry Jones: All those in.
Ry Jones: who wish for the motion, not pass please say, nay.
Ry Jones: And all in favor say Aye Aye captain.
Ry Jones: Motion passes.
Arnaud J Le Hors (IBM): Thank you.
Tracy Kuhrt: Thanks Ray.
Tracy Kuhrt: And thanks for putting that together for us and for all the input that we had from the TC on that.
Tracy Kuhrt: particular issue, so as far as I know we don't have any any additional on PC business this week, but before we get to the task force discussion is there any PC business that we should be talking about that I did not know about or didn't include in our agenda.
Ry Jones: I did for this issue on and then.
Ry Jones: Dino.
Ry Jones: found a pull request.
Ry Jones: I would just like the dsc to.
Ry Jones: You know, read this over and add comments on dale's pull request we don't have to discuss in this meeting.
Tracy Kuhrt: Okay, thanks for that I will.
Tracy Kuhrt: have to review is that pull request 33 I think it was.
Danno Ferrin: 33.
Danno Ferrin: All right.
Tracy Kuhrt: So yeah pull request 33 on the TT repo.
Tracy Kuhrt: we'll make sure we include that on the discussion items for next week, but feel free to have a look at that before we get to next week, any other PC business anybody would like to bring up at this point.
Tracy Kuhrt: Alright, see nobody coming off mute or raising their hands, I will take that as a no so Jim I guess it is up to you to walk us through the task force discussion for a project health dashboard.
Jim Zhang: sounds good thanks Tracy Mr sharing.
Jim Zhang: Okay, so I created the task force page and there will be a page for today's minute, but I guess, just as a refresher for everyone for the background of this.
Jim Zhang: This thread.
Jim Zhang: We were talking about project reports in early January, and there was a follow up action to to think about what kind of data can we pull pull together.
Jim Zhang: To January, some sort of.
Jim Zhang: Report.
Jim Zhang: For every project.
Jim Zhang: Whenever the tasc needs to make decisions on the health status of a project, this could be a status change on the project from innovation to active, or vice vice versa.
Jim Zhang: or four laps to to go into incubation.
Jim Zhang: Just feel like if we have the right types of data than a lot of decisions can be made much easier and faster.
Jim Zhang: So there's already pretty good sources of such data, such as the insight.
Jim Zhang: By Linux foundation and there's also previous efforts in particular made by Tracy and others.
Jim Zhang: to generate reports, based on github data.
Jim Zhang: So this effort is to kind of pull together all the all the thinking and get this.
Jim Zhang: get this.
Jim Zhang: take it to the to the finish line, basically, so we can have these be hosted somewhere or maybe there is something that can be embedded in every report just by default.
Jim Zhang: So every every report will have this be automatically generated from all the data sources so that's the that's the thinking behind this effort and.
Jim Zhang: there's a running issue in github that has got contributions from many people thanks for everybody who's participated and and the result of the discussion we've got so far.
Jim Zhang: Is captured.
Jim Zhang: here.
Jim Zhang: On this page.
Jim Zhang: But I want to start with the High Level goals, so we can talk about it and agree, and then we can get into.
Jim Zhang: The details, so I think the High Level goals as as displayed here is together and present rich set of data about a project can be both top level projects and labs and enable data driven decision making at tasc.
Jim Zhang: Specific tasks to be completed number one, we need to define the types of data that makes sense, this has been what.
Jim Zhang: The participants on this effort, have been focusing on.
Jim Zhang: What are the types of data that would help with the decision making is it on code is it on person is it on activity that sort of thing and then we should decide how to collect that kind of thing.
Jim Zhang: Given the data we believe are useful, where to find it, how to collect them and based on the discussions we've got so far, some of them.
Jim Zhang: will be available programmatically but others we may have to resort to manual contribution manual collection.
Jim Zhang: For the list of deliverables for this task force, I think we should.
Jim Zhang: document, the decisions.
Jim Zhang: In the github issue or maybe there's other better format to document what we decided on.
Jim Zhang: And we should discuss with the Linux foundation insight it team.
Jim Zhang: about enhancing the dashboard and the gathering of the data.
Jim Zhang: and generating reports.
Jim Zhang: Such capabilities are missing today there's a lot in there, but some key capabilities are still missing.
Jim Zhang: And for the if we have data that has to be collected manually, then we need to publish some sort of recommended practices, so the Community can make the information available, and we can collect them.
Jim Zhang: I like to think we could accomplish everything in three months if that's not at that time turns out to be too optimistic probably six months.
Jim Zhang: At most, and we should time opposite.
Jim Zhang: So.
Jim Zhang: let's let's let's look at what we've got so far, so this is just capturing the input from the previous discussions in the.
Jim Zhang: In the in the issue, so I can go through these items and but everybody, please feel free to jump in on any of these points, and we can discuss more so.
Jim Zhang: We put this in edit mode Okay, so the first one first category is Community I think that's that's a no brainer that it's a key success to the to any projects is a diverse active Community that cares about the code base.
Jim Zhang: So we've got five subcategories and underneath that growth.
Jim Zhang: Is the Community growing diversity is it looked after by a single org name organization, or does it have a diverse source of contributions which tend to make the project more viable in the long run.
Jim Zhang: retention is for contributors do they feel their input are are being respected being valued and their code contributions are getting to the main branch and getting to customers hands so they're delivering value.
Jim Zhang: or skip maturity to the end, because I was having trouble.
Jim Zhang: articulating articulating this so maybe someone else can help with this one responsiveness is kind of.
Jim Zhang: tight to allow the others, is how responsive is the current contributor group.
Jim Zhang: or two to potential contributors, maybe they reached out on discord or through a PR or they are they given attentions are due diligence being.
Jim Zhang: given to their to their contributions.
Jim Zhang: So.
Jim Zhang: maturity I I feel like this came from David I don't know if David is on.
David Boswell: yeah.
Jim Zhang: i'm here now is can.
Jim Zhang: Speak to this yeah go ahead.
David Boswell: So basically I my thought of maturity, was it gives context to the other stats there so, for example, if you're a brand new project have only been around for a month or two.
David Boswell: Your stats are very likely going to look different from somebody who's perhaps you know, been around for a project has been around for several years and has a different.
David Boswell: The Community is going to look different right, I mean, I think, for example, that new project.
David Boswell: Probably won't have the same sort of organizational diversity, so it helps give context right I think something that might be a red flag.
David Boswell: For a more mature project, for example, if you if you didn't have organizational diversity after.
David Boswell: Three years, for example, that might be a red flag, whereas if you don't have organizational diversity and you just started that's not a black right, I mean it's natural for a new project that just came from one organization, for example.
David Boswell: To not have that diversity, yet, so I think it's just a way to help set context for those other projects and I meant diversity here are maturity here, in the sense of.
David Boswell: You can measure it simply by age, for example, or the stage, you know, an incubator project is going to be less mature in this sense, and I graduated projects that's all I meant by that.
Jim Zhang: Okay gotcha.
That makes sense.
Jim Zhang: So I guess this maturity is more of more of a qualifier rather than a category by itself.
Tracy Kuhrt: Well, Jim I would I would add, specifically, maybe a couple of bullets there why around when was the first code commit.
Tracy Kuhrt: And then maybe another around frequency of releases.
Jim Zhang: yeah okay.
Tracy Kuhrt: Because I think i'm more mature project is well I think when you're when you're.
Tracy Kuhrt: Like if you look at fabric right I think they have quarterly releases that's a pretty mature project are able to you know get to a place where they can plan for releases every three months and successfully do that.
Tracy Kuhrt: versus you know, maybe a newer project hasn't quite figured out when they should do releases or how often or how they manage that whole process, so I think you know that's the sort of thing that I think about when I say frequency of releases.
Jim Zhang: Okay gotcha.
Jim Zhang: Are they are they able to stick to the published really schedule that reflects the maturity.
Jim Zhang: yeah yeah definitely makes sense when you're working on still working on like core foundation of the architecture.
Jim Zhang: You could easily step into unforeseen complexities and previously published schedule be blown out of the water versus if it's a mature code base and it's just adding enhancements than that it's much easier to.
Jim Zhang: to stick to the schedule yeah that makes sense.
Jim Zhang: Any other comments on on these aspects on community itself are we missing any important aspects as far as the health indicators of the Community itself.
Jim Zhang: Okay yeah we can always revisit this later so i'll continue.
Jim Zhang: For the code aspect.
Jim Zhang: that's obviously another important.
Jim Zhang: dimension for project is the code itself and so far we've got two categories.
Jim Zhang: One we call usefulness.
Jim Zhang: Which is.
Jim Zhang: How are the general Community reacting to this projects functionality, it can be really cool can have a lot of coding there, but if people are not using it it's indicator that it's either way ahead of its time or maybe there's a better solution somewhere else so.
Jim Zhang: usefulness is.
Jim Zhang: Our Is this the right solution for the right problem.
Jim Zhang: Is the is the problem that's being addressed or a real problem, how many people are struggling with it so that's that's the that's the usefulness aspect.
Jim Zhang: notice that we didn't really.
Jim Zhang: capture some sort of.
Jim Zhang: Popular aspect for code, how many lines of code is in the project.
Jim Zhang: How active is the code being pushed.
Jim Zhang: I don't think it's.
Jim Zhang: A necessary good indicator to the health status of a project, because you can be working on something you know just among the few people.
Jim Zhang: That pushes ton of code and you know, there are 10 PRS every day, but if if you are the ones who only you're the only ones work here who care about this code base for a long time that's indicator that.
Jim Zhang: This is not very useful to the general general Community.
Jim Zhang: Okay.
Dave Enyeart: Good on that point, I do think the commit rate is important and how it changes over time for a project I don't think that's captured anywhere here.
Jim Zhang: Committed rate.
Jim Zhang: How many lines of code are being pushed in.
Dave Enyeart: or number of commits per month or something like that, and then you can look at that over time.
Dave Enyeart: Like in the fabric reports, I always put a commit for the quarter number, and then I compare it to the previous year, so we can kind of get a feel for is it less active or more active.
Jim Zhang: I guess that's.
Jim Zhang: It feels like a different dimension.
Jim Zhang: cuz your fabric, the usefulness is is out of the question so that's that be established, first, I think things like rates is a useful indicator right.
Dave Enyeart: yeah I agree it's probably not under the usefulness category, but I think somewhere, we should capture it.
He.
Jim Zhang: We need something.
Jim Zhang: placeholder.
Jim Zhang: Think of something to call this.
Dave Enyeart: could be like based metrics or something because it's kind of a fundamental.
Dave Enyeart: metric.
yeah.
Nathan George: Well, and maybe to say something more about that were the production readiness and the usefulness is really trying to measure the growth.
Nathan George: Of the project this metric seems to be monitoring for when a project might cool down or when a project might be.
Nathan George: starting to become less interesting, for whatever reason, so there's probably a few other statistics we could put in here that would help us understand if maybe people are moving off on to other ideas or off on to other projects.
Jim Zhang: Good plane.
Tracy Kuhrt: And Jim Hart has his hand up I don't know if you're able to why you're.
Jim Zhang: Sorry yeah I wasn't able to.
Tracy Kuhrt: Make sure to keep track.
Tracy Kuhrt: Of.
Jim Zhang: yeah Thank you, I appreciate it.
Jim Zhang: yeah hard go ahead.
Hart Montgomery: hey Jim so I like this one thing that I don't see mentioned here that I think is important and I don't know where we want to put it as documentation.
Jim Zhang: yeah.
Hart Montgomery: So I don't know whether that goes under code Community or what.
Hart Montgomery: But I think it's an important thing and and we should have some it should be included in this document.
Jim Zhang: If I agree, I mean people can get their hands on how easy or difficult it is that's a.
Jim Zhang: Pretty critical, I guess, this would be more of a manual or subjective measurement.
Jim Zhang: Right, the quality of the docs I guess we're mainly referring to the quality of the dogs right heart.
Hart Montgomery: Well sure, but just the existence of documentation to various different things right.
Jim Zhang: and
Hart Montgomery: So yeah both.
Jim Zhang: yeah okay that makes sense.
Tracy Kuhrt: And Bobby has her hand up as well.
Bobbi Muscara: yeah i'd.
Bobbi Muscara: Like to i'd like to help you out with that piece because we're working, we have a task force in the learning materials development working group right now to create some kind of badging.
Bobbi Muscara: That will fit into the existing structure so we'll talk later, but I would like to be a part of that piece, because our task force will be reporting on that shortly.
Jim Zhang: awesome I appreciate that.
Jim Zhang: So we can talk in more details, how to sort of wrap these aspects into a.
Jim Zhang: into a badging.
Jim Zhang: Criteria and have it be captured in a more concise manner.
Jim Zhang: that's great so we haven't talked.
Jim Zhang: About this, this part.
Jim Zhang: I believe this was brought up by heart during the discussion.
Jim Zhang: Production readiness.
Jim Zhang: it's kind of related to the usefulness, which what naturally to this being used in production and the team working on making it production ready.
Jim Zhang: so obvious indicators include has been a one dot zero release what's the test coverage performance and reliability tests.
Jim Zhang: And I guess documentation is somewhat captured here.
Jim Zhang: yeah so this would apply more to the top level projects, but even for labs a good documentation would be a.
Jim Zhang: Pretty big.
Jim Zhang: factor to be considered when this lab is brought brought up for.
Jim Zhang: For proposal to become incubation.
Jim Zhang: Okay, so I guess, overall, we feel pretty good about the aspects on the code aspect.
Jim Zhang: Anything else we should consider.
Artem Barger: So, Jim I don't I don't know what the best could take a degree to put this year, but the problem might consider something that is related topics it reflects the.
Artem Barger: Innovation around the project so, for example, the amount of a you know resuscitation so resource publication, that is a around the area, the technology that the project has been developing is producing.
Jim Zhang: See it's not it's not it's not directed the code.
Artem Barger: But it's a you know we are working in the Boston area that is kind of you know everything is in distributed system cryptography consensus on server and you know.
Artem Barger: it's supposed to be quite a lot of research for your on this effort, so I think that this indicator of might reflect the innovation around the project and the direction the project is heading towards.
Jim Zhang: So do you think makes sense, it falls under usefulness.
Jim Zhang: may be.
Jim Zhang: This is more research effort so even though it's not being picked up by regular users by it generates research publications and it's being cited in.
Jim Zhang: In other people's work.
Jim Zhang: he's like this belongs under usefulness.
Artem Barger: So it might reflect the foremost, but I think that you know it might might be to basically devote a completely separate second section that you know stands for innovation.
Artem Barger: Because you know, a shelter project, in my opinion, has to innovate, the once in a while, and you know if you'll be able to capture the level of innovation that brought up by the project might be might be good.
Jim Zhang: But yeah.
Jim Zhang: yeah go ahead.
Hart Montgomery: yeah I think this is a good topic we can measure it, you know reasonably well by looking at like a printer archive for all of the other like.
Hart Montgomery: Research publication websites this it measures you know academic interest in something, and it will let us know sort of like you know what people who are interested in the most cutting edge technology are you know.
Hart Montgomery: Are are following great.
Hart Montgomery: So you know this, this is definitely something it's something I have sort of done myself actually about a bunch of these projects, and I think it's a good metric.
Hart Montgomery: To.
Hart Montgomery: measure as art and put it sort of how cutting edge, something is.
Jim Zhang: yeah okay.
Jim Zhang: That makes sense.
Hart Montgomery: i'm referring to the ar XIV.
Jim Zhang: yeah that's what I was trying to spell.
Hart Montgomery: The Horace.
Jim Zhang: Only manage the three.
Jim Zhang: Letters of that.
Tracy Kuhrt: hey if it hasn't signed up as well.
Jim Zhang: yeah go ahead.
Nathan George: i'm a classic quote is you manage what you measure.
Nathan George: And so I like how we've kind of separated some categories here of the different numbers and what we think that they're useful for because one of the dangers here is if we put the wrong numbers in front of the wrong audiences they'll try to optimize for things that might not be healthy.
Nathan George: For example, it would be, it would probably be a bad thing if a project tried to maximize their e print air XIV numbers by themselves.
Nathan George: Have or if they tried to increase a number at the expense of the stability of their community, so I wonder if, once we finished kind of this all the things we might want to look at it would be good for us to.
Nathan George: split this dashboard of statistics to the more than one category, because some of these things are things we would want to put in front of me taters and say you should watch these, but some of them are not because they could lead to optimizing the wrong things for sustainability.
Jim Zhang: That makes sense you're saying, if a project is not really driven for innovation, it they shouldn't be staring at the stairs or the dashboard this category is always zero.
Nathan George: Well, or likewise a lot of early stage project might really need to worry about how many people are contributing and how often are they contributing.
Nathan George: But a stable project might need to say we need to get people to bundle their commits better because the thing we need to optimize for is maintainer burden as opposed to onboarding more more people, so I.
Nathan George: It feels like we need to give some thought to the life cycle of the project and which statistics are most important web, because if we can help the maintainer focus on the right things it'll make the job, a lot easier if we make them focus on everything it'll make your job, a lot harder.
Jim Zhang: yeah.
Jim Zhang: Do you think this captured your concern here.
Jim Zhang: Sure okay cool appreciate that.
Ry Jones: I will point out this document is in edit mode so like other tlc members to feel free to.
Ry Jones: jump in.
Jim Zhang: Here definitely thanks for that reminder.
Jim Zhang: Okay, let me go ahead and date.
cool.
Ry Jones: I just met in terms of you know, we do we multiple people can edit at the same time.
Ry Jones: yeah so other people wanted to jump in here and help edit.
Jim Zhang: So I guess for today's call i'd like to focus on making sure these dimensions are as complete as we can manage and then we can we can use follow up calls to talk about detailed measures to collect them.
Jim Zhang: So I guess on both categories are there any other things, we should consider, or is there a complete new categories, where are missing here.
Nathan George: there's a couple of early pipeline interest things that sometimes are worth looking at it sometimes you're not.
Nathan George: Like how many stars or forks there are other repositories how many people have signed up for the mailing list or how many how many users are inside of the chat channels, where it may not indicate act actual activity, but it might indicate that.
Nathan George: There are folks we have the opportunity to invite to create that activity.
Jim Zhang: So i'm.
Jim Zhang: Trying to capture.
Jim Zhang: What What this means in terms of the data that can be so you're saying there could be a different dashboard that is presented to early early stage projects.
Nathan George: um well when I said that I said it a lot like, if you remember the statistics page that I showed us before it talks about kind of.
Nathan George: A new contributors versus mature contributors versus inactive contributors.
Nathan George: there's this kind of.
Nathan George: People who are poking around expressing interest.
Nathan George: kind of part of the the contributor pipeline of people just they're signing up for the mailing list and they're lurking or they've started the repository because they want to watch to see what might be happening next.
Nathan George: year if we think of the maintainer is is kind of managing a.
Nathan George: pipeline of new traders, that they have the potential to onboard seeing a lot of activity at this stage of the pipeline might eat it's time to.
Nathan George: invite people to do something or go go get your ticket repository and label whole bunch of things as good first bugs if you see a bunch of people kind of wandering by and starting to stop and stare it's a chance to invite them to join.
Jim Zhang: yeah.
Jim Zhang: So that that's more of.
Jim Zhang: Not measuring the health by helping the helping the providing the data to the mainers so they can they can.
Jim Zhang: Better grow the Community.
Jim Zhang: So this is not so much helping the thc the judges more to help maintain nurse to grow.
Nathan George: yeah.
Nathan George: yeah and for me that's ultimately that's what ptsd is trying to do and measuring as well as that.
Jim Zhang: I guess yeah I guess.
Jim Zhang: that's correct.
Jim Zhang: Okay, so.
Tracy Kuhrt: On the maturity section I don't know if this is right place for it or it's a good.
Tracy Kuhrt: measure of maturity, but the number of good first issues Nathan, when you said that that.
Tracy Kuhrt: popped into my head is something that maybe.
Tracy Kuhrt: We would want to be able to look at as well.
Jim Zhang: yeah so we're saying.
Jim Zhang: A mature project should have more of these are the other way around.
Tracy Kuhrt: I think that a mature project should have them because it indicates that they're willing to work with others and and I don't know, maybe it goes under at different.
Tracy Kuhrt: Maybe it's not maturity, maybe it's something else, but I just feel like it says something about the Community if they're willing to bring on new contributors and mentor those contributors through those good first issues.
Jim Zhang: gotcha, so this is kind of a is the Community is.
Jim Zhang: Project friendly to new contributors.
Tracy Kuhrt: yeah that's probably a good way of looking at that so maybe it's a completely different sort of metric under Community.
Tracy Kuhrt: And heart has his hand up as well.
Hart Montgomery: yeah I was just going to suggest exactly your last point there Tracy I think this is really important, and I think we could have a whole category on.
Hart Montgomery: Ease of new contributions or sort of new person onboarding great.
Hart Montgomery: We would like projects to have sort of smooth ways for new people to get involved.
Hart Montgomery: So you know.
Hart Montgomery: Good first issues is is adjust one of these things right.
Hart Montgomery: There are a lot of other different things that some projects do to help new contributors.
Hart Montgomery: So yeah I think this is where the whole category.
Jim Zhang: Or do you think this country is that category.
Hart Montgomery: Sure yeah.
Jim Zhang: Okay cool.
Jim Zhang: that's.
Nathan George: Great I was just going to challenge, whether that's a different category than responsiveness I think how how this is.
Nathan George: How you respond to new contributors is is an important metric of responsiveness, and I think one of the things that we often see and why one of the why of.
Nathan George: How we measure time result vr is time to respond to questions is to make sure that there's not kind of a hidden decision making cabal.
Nathan George: inside of the project, where some folks get their issues responded to quickly and other folks get their issues perpetually ignored.
Nathan George: Because that's a good sign that the projects having internal conflict or is likely to fork or have other troubles, and I think these friendliness numbers kind of all fit into that kind of a category of is everyone.
Nathan George: committed to working together and responding to one another.
Nathan George: Are.
Jim Zhang: Tracy, what do you think.
Hart Montgomery: Well, you know responsive how we've.
Hart Montgomery: You know.
Hart Montgomery: The way we've defined responsiveness right now is more about like.
Hart Montgomery: Time to communication, you know if we want to make a more general definition of like Community responsiveness that's fine.
Hart Montgomery: You know I thought it.
Hart Montgomery: I thought responsiveness had meant something more specific, but if we want it to be something broader that's fine too.
Hart Montgomery: You know, however, we classify these things or incorporate them into categories, you know it's it's not as important as it sort of just all being mentioned so i'm really fine with, however, we want to present this.
Jim Zhang: How about this, I think, maybe there's an aspect you guys are trying to capture Tracy heart is how easy is for someone to solve to get self started to to sort of.
Jim Zhang: know this is something they can they can get their hands on before even talking to people, this is sort of their first impression kind of thing.
Jim Zhang: Whereas responsiveness is more once a contributor has done something after have having you know evaluated this.
Jim Zhang: Then, how are they being treated by the by the maintainer group, because if you didn't have a good list of these things, it would be pretty difficult for a contributor to to get started right.
Jim Zhang: And then responsiveness wouldn't be reflected at all because there's no communication.
Tracy Kuhrt: And thank you, they go hand in hand.
Tracy Kuhrt: I think that you know somebody starting out first issue they're probably going to be asking a lot of questions and then their.
Tracy Kuhrt: Time to get a response on say discord is going to impact, whether or not they can be working in the issue or not right was that first impression that they got of the.
Tracy Kuhrt: Community something that was a good first impression, or it really just turned them off completely and they decided they'd go spend their time where they you know felt more welcomed into the Community and sorry rude I started speaking before I noticed, you had your hand up.
Aruna S M: No research so as him like I can speak now yep um I think on since we are on this topic right, one of the hard thing right now for us to measure or you know something's happening over there is.
Aruna S M: When we know their contributors and then understand the code base, and they would like to proceed with the contributions, however, they are not aligned to the projects roadmap or.
Aruna S M: What project maintenance currently think of right, so there is definitely a conflict of interest among those contributors and how would they like to answer them are.
Aruna S M: Where would they like to take it up from there, so I have heard such concerns earlier in a couple of projects, but.
Aruna S M: I don't know I think that's a bigger can of worms if we were to discuss that topic and I don't have answers as to how to measure or how to call can we win might understand that something like this exist internally to those projects.
Jim Zhang: So just make sure I understand you're saying.
Jim Zhang: Do we want to detect the situation where there are conflicting priorities within the maintainer group of a project.
Aruna S M: you're trying.
Aruna S M: To prevent.
Aruna S M: This is to prevent either of them from stopping to contribute, or you want to prevent them from creating a new coke off after project altogether.
Jim Zhang: Okay.
Jim Zhang: me too.
Jim Zhang: yeah splitting up the beauty, so the.
Jim Zhang: Have we have we seen evidence of this happening, either now or before I mean this is definitely a.
Jim Zhang: theoretical possibility but we We believe this is happening and it's it should be a concern.
Jim Zhang: By how important how hyper do you think this is.
Aruna S M: So it can answer if something like this happened, and to my understanding is I could see something like this happening in the past.
Aruna S M: Is it still happening I don't have an answer for that, in terms of priorities, since we're not seeing it anymore, when we should take it up some time but maybe not as a priority at this present.
Jim Zhang: yeah I feel like this is more on a case by case basis, I can think of, you know.
Jim Zhang: I don't, mind you know, giving this example because I think is public knowledge, the split between is hearing and mean that and if you're in classic right that's probably a good example of.
Jim Zhang: A Community splitting to quite quite independent code base because of their their parties and philosophies.
Jim Zhang: Sometimes it's it's not necessarily a good thing, sometimes maybe it is a good thing to allow that different approaches to to become different communities, so I I feel like this should be evaluated on a case by case basis.
Danno Ferrin: On the Amina classic split I think it's a bit more nuanced than that, but basically classics become a downstream distribution of maintenance.
Danno Ferrin: So that's another way that communities by split one might stop being you know, the main one and mine might become a downstream and just do what they want, on top of it, because you know the Kobe says split all the code for the most part flows from a network in the classic work.
Jim Zhang: yeah I agree.
Jim Zhang: majority of the enhancements still applies to both code base yeah definitely.
Hart Montgomery: I mean, I think, communities could split for totally benign reasons to that are.
Hart Montgomery: they're actually quite good right, I mean like you know essentially right sort of indie Forked off both areas and ursa right, and I think those were both positive forks right, it was hey here's this component.
Hart Montgomery: You know we're using it, but other people want to use it to what you know people that don't want to use sort of our main.
Hart Montgomery: thing why don't we work it off so it's easier for them to use right, I think you know those were you know I think certainly positive examples of of projects, putting off right.
Jim Zhang: yeah.
Nathan George: Well, in some sense that's what gets that the thing that's hard to measure here, which is.
Nathan George: A project needs to be friendly enough to new ideas, so that those new ideas can incubate within the project as opposed to having to create their own new space outside of hyper ledger to explore that.
Nathan George: That new or interesting idea right because it's that's the paradox of open source is that the easier, you are to fork within your project, the less likely someone will have to make a new venue or a new Community in order to explore their idea and what we're trying to get at here is.
Nathan George: Is there's that kind of conflict or sheer that makes people want to leave, or is there that kind of collaboration and friendliness that makes people want to say, I disagree with you, but I want you to watch and see if i'm doing something dangerous tell me.
Jim Zhang: yeah definitely agree there, so I put that under friendliness to new contributors or new ideas.
Jim Zhang: Any other big ideas, I guess, we have one more minute, and then we should wrap up and give the floor back to Tracy.
Jim Zhang: So.
Jim Zhang: We probably should talk about the the cadence of the call I guess i'll model, the other task forces to have one off cycle call.
Jim Zhang: Probably should.
Jim Zhang: Self organize to decide on the the timing of that.
Jim Zhang: Through discord.
Jim Zhang: cool so I guess right, you would have to create that channel for us right.
Jim Zhang: That has for us.
Ry Jones: That that ability has been delegated to all Members with the tlc role.
Jim Zhang: so great.
cool just.
Ry Jones: feel free.
Jim Zhang: will do.
Jim Zhang: Thanks right.
Jim Zhang: awesome so i'll publish this and then.
Jim Zhang: coordinate with.
Jim Zhang: Those who are interested to continue the discussion on a off cycle call schedule and then we can go from there appreciate everybody's input today and.
Jim Zhang: give it back to you Tracy.
Tracy Kuhrt: Alright, thanks, Jim thanks for taking us through this.
Tracy Kuhrt: Next week the things that I know that are going to be on the agenda are.
Tracy Kuhrt: they're just all slipped my mind, they were right there another gun so that pull request from Dan oh.
Tracy Kuhrt: The review of fabric and then I think we're back to the beginning of the task forces so we'll be talking about project families next week, so if you have any additional input on the project families that you haven't added to any of the wiki pages, or the word document, please do that.
Tracy Kuhrt: And we'll make sure that we can continue that discussion next week so with that i'm going to close the call so thanks for attending today.