CHAOSS Evolution Working Group, 9 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CHAOSS.Evolution.WG.Sept.9.2020

Description

CHAOSS.Evolution.WG.Sept.9.2020

A

This record, is it recording? I guess it is yes. Cool awesome. Well welcome everybody to the evolution meeting on september 9th uh 2020..

A

um uh I know there's some stuff from from last week that you guys are talking about that. Shawn told me about um sorry that I haven't been on the calls for a while. I was working my internship, which was all day every day, so I I didn't have time to make these calls and then, after it ended, I just had some some personal stuff and school getting started up. So I wasn't able to make it for a couple weeks in a row, but I'm back for good now, at least until something happens again so.

B

A

Won't have yep, I won't be able to drive too much today, but um I'm happy to to help take notes if there's particular things we want to talk about from from last week. I know sean mentioned um that you guys were talking about changing the language of reviews was one thing that he mentioned. Did I remember that correctly.

C

Yeah, so there are two main agendas in this: one is changing, the name and other is on dependencies.

A

A

Dependencies like code dependencies or like inter metric dependencies.

C

B

Independent code dependencies is, is what so dependencies becomes a focus area, and then evolution can decide how they want to what metrics they want to create to look at dependencies. uh Okay and then there. The interesting thing about dependencies is that we're going to try to run that as a focus group in or a focus area in different uh working groups, and each working group will look at that focus area from a different perspective.

B

So it's a bit of an experiment.

B

So, regarding our agenda about dependencies, we want to think about how we would explore dependencies within evolution. What are the metrics that are important to us? What is the question that evolution would want to answer about dependencies.

A

Okay, um have we, I do see some stuff down here, um I'm looking at the agenda from the meeting on the 26th. Is this all just brainstorming about yes like what we could look at okay, yeah.

B

That was also kind of the the conversation about does. Does dependencies even belong in evolution? Maybe it's a risk metric.

B

uh Maybe it's maybe it's a value metric and uh through this discussion uh through the discussion last week, I think we we took it to the community meeting and we kind of decided that we were gonna kind of do the experiment and try to run dependencies as focus area and all the working groups or or in whichever working groups want to do it.

A

Okay, so okay- um and that was just just this past week- the community meeting right so we're still very early on in the stages of this experiment. Yep.

B

Very early, okay- and my guess is that if we can, if we can establish a question that we want to answer, we will probably be the first working group working on dependencies. I don't think that conversation has really been had yet anywhere else.

A

B

C

Maybe we can see like uh what kind of dependencies evolution working group is looking for.

A

Sorry, can you say that again bernard, I miss that I'm.

C

Saying like what kind of dependencies evolution working group is looking for in their focused area,.

B

That's like like isn't that us, aren't we the evolution? Yes,.

C

D

C

I'm like I'm, focusing it to the evolution, so, okay in the process of project evolution, is project dependent on anything, maybe liabilities, be it uh koda, beeps people whatever. So what is our as a evolution group focused on the dependencies? What can we think that's what I'm trying to brain is from here.

D

A

A

I think breaking up the types of dependencies that we want to look at just overall probably would be helpful, and then we can kind of further refine and say these are the types that we want to look at. um That's when we can go about it. We could also just go about trying to think of generic questions that we would want to answer related to dependencies and also evolution and kind of tackle it from that way. um Is there um did so? How did? How did the the discussion about dependencies come about was?

A

Did somebody specifically ask like hey somebody outside the queen? You say I want dependency metrics. Was it just some? We we brought it up in a meeting and it kind of just evolved into this. Let's, let's.

B

Try this out because he's curious.

A

B

Been getting requests from outside of the community to start exploring dependencies, and I think those those requests also match uh some interest from within this within the community to uh explore dependencies as well, uh but the uh I think, the the thing that started us down this conversation was a request from outside the community. I believe.

C

I think it was request from uh asia, pacific meeting, especially.

B

Okay, yeah, possibly.

E

Okay, so I have a q, a question we could answer so something like uh what uh how do dependencies affect the the project velocity? So in other words, if we, if there are more dependencies or more outside libraries or projects that are we're dependent on a project, is dependent on, does that enable a project to move faster, to close issues faster to ship releases? Faster, would is that is that kind of what we're talking about. I think with regard to dependencies and evolution specifically.

B

Yes, yeah, I think so, should we should we dock or is this being documented in the uh yes.

A

um I just heard it would you say that I uh you could phrase the did you you guys want to share my screen. Would that be helpful yeah? That would be helpful.

A

um So this is how I phrased that elizabeth, how do dependencies affect the project velocity and does having more or less of? Is that the main distinction like more or less or maybe like a certain type or so even even a specific dependency like? Can we say that projects that use this framework have some sort of common thread?

A

Is that kind of the right idea.

E

Yeah, I think any of those questions could would be valid. To answer is the number of dependencies the types of dependencies the dependencies themselves. Specifically, I think yeah all of that stuff would be interesting to look at.

A

um Okay, there was, I had something that was related to that. It was something like.

A

Are there dependencies that I think, like tracking the maybe looking at what dependencies get added and dropped as a project matures like if they start using flask and then they drop it for django or they drop it and switch to their own? You know home rolled dependency. You know to do some some web requests or something. I think that could be an interesting question um like can you can you look at it at a project's dependency, chart and kind of get an idea of what else was happening kind of that's. Does that make sense?

A

I'm not exactly sure how you would answer that question or if you could, but.

E

Are you asking about um like a more a more stable dependency like a dependency that has a healthy velocity itself? Is that what you're talking about so like as the project matures? Maybe they switch to using something that is also maturing along with them, or I'm not sure what? If I said that right.

A

um This is my internet connection. It's unstable! That's annoying! Sorry, um I think, as that is an interesting question actually like do like looking at this. This project is maturing, and so is this one and you know they're both getting adopted at the same rate or something like that. But I think my question is more focused on like: can you use uh the changes in a project's dependency dependencies as a proxy for other events that happened like or or to make some like to say they switched frameworks or they dropped a bunch of dependencies?

A

And now it's it's more mature because they they took the time to do this or it's less mature because they added a bunch of dependencies because they just added a bunch of dependencies out of nowhere. Like you know in our is there kelly? Can you make those kinds of those uh those calls just looking at the dependency.

A

A

I also don't know if this relates exactly to dependencies and it's not exactly a specific question, but I think it would be interesting to also think about in the comments context of dependencies um package managers in some form, like maybe did you know, presence on package managers presence in like third-party package managers like do, I have to add like if it's a apt package and it's not in the main you know repository- does that I'm sure it affects adoption but, like you know, is, is that is that significant that it is or it isn't in this in this package managers index or something like that, um just as a general concept?

A

I think that could also be an interesting space to explore related to dependencies, but unless you guys feel like that's kind of too far outside the realm of specifically dependencies.

B

I think that's, I think, that's super interesting. I don't know what that metric would look like. Maybe maybe it's multiple metrics within uh kind of a sub sub category within dependencies.

A

um There was a audrey at one point used a project called libraries.io, um which you guys might have heard of um two. It did a bunch of it just had like a huge index of what packages needed. What other packages across a few like of quite a few different platforms like they had ruby gems. They had python packages, they had node and stuff in there. um I'm trying to remember we, we built some metrics from that like a really long time ago,.

C

Yeah I worked on that. I helped that get it up set up, so it was a v index which I developed for the dependencies.

A

That's right: that's right!.

E

I think maybe another interesting question would be around contribute contributors so like if there are more dependencies, does that also increase the number of contributors, because people might be familiar with one of those packages or one of those um dependent pieces of software? You know like um thinking of like frameworks and things like that. Would that expand the pool of potential contributors or would it make the waters muddier?

E

I think that would be kind of interesting to see.

A

Yeah I've, never, I would never thought of that. So like is there a relation between the numbers of contributors and dependencies in the context of like you know, does if there are more dependencies, then there's a higher chance that contributors would be willing, willing or able to to contribute because they understand these packages, but also it muddies the water is that kind of like yeah, I'm just trying to make sure I captured your thought totally.

E

Yeah yeah like if someone is using a framework that is really popular. Does that also expand, then your your pool of people that would be able to contribute or or would it just make it more confusing and then therefore less contributors? I think that'd be interesting.

A

um I saw this core periphery and episodic contributors was. I was skimming the notes last time. um Can somebody just give me like a elevator pitch on on what the difference between those three is. I I have an idea of what I think they mean so.

B

That that is actually that is actually based on uh what elizabeth was saying, and it's also based on a comment that she had made uh uh in the last in the last meeting. uh Core periphery and episodic contributors are a way of understanding uh where a contributor exists within the project and.

D

B

Then what can be interesting about that is when you look at when you look at dependencies or when you look at individuals that are contributing to other projects.

B

If you have projects that are dependent upon one another, a core contributor from one project could be a peripheral contributor to another project. That is, that has some sort of dependent relationship right. So.

F

B

The by by understanding the core, periphery and episodic contributors, you can kind of you can actually kind of map a picture of what interdependencies look like based on contributor contributions.

A

Okay, so just to to make sure that I click that I'm what I understand it's like, if I you know I, you could say, I'm a core contributor for auger, but if there's a sub repository, that's a side project of auger that loosely depends on it, and I make only a couple commits. I would be a core contributor for auger and periphery, for the other thing is that I.

G

Understand it correctly.

A

F

A

Yeah, that is interesting.

A

That made me think of something else, but I don't what was it.

A

Something to do with.

A

Well, maybe one thing that also we could look at would be.

A

Like kind of um dependency chart to project to like to code base size, that's not really an evolution metric. I don't think that's just kind of I don't even know. If that would tell you anything uh I'll. Think.

B

About that I'll just leave it for now. Okay, maybe it'll spark something.

B

Oh, I I added a goal by the way I don't is this. Is this goal fair to understand how project.

A

B

Affect growth, maturity and decline.

A

Yep, I would say so.

A

A

Do we want to specify a kind of dependency like code dependency or like contributor dependency, or should we just leave it generic and say we'll focus within a metric or within a more specific sub area?.

B

uh I think that's, I think, that's kind of up to us, I don't know if I would, uh I guess who who uh which working group owns contributors or uh my.

A

Guess is, I think, is it common.

B

Is that common yeah? So that might be so so to be honest with you that uh the the ratio of core periphery and episodic contributors, anything to do with contributors might actually be that actually might fit better in common.

B

um But I think we can still come up with these ideas and let common decide if they want to work on.

C

C

I think for us it will be more if we look at the version dependencies because in the evolution phase of project like from growing to maturing and maybe declining in, are we depending on the different versions of the dependencies?

C

In the code like if you are using a certain library, there is, like every library has different versions, so in the evolution phase or the version dependency is also evolving or they are staying constant.

B

So I'm hearing that you kind of want to focus on code dependencies. Yes,.

B

And I think that's I think, that's completely fair.

A

A

um It made me think of something: um oh my gosh. It was related to the dependencies involving and changing.

A

Oh gosh, what was.

A

A

E

Hey kevin: did you add uh that um that blurb right there did you add that to the common uh working group agenda, I can, if you didn't.

B

Which? Which blurb.

E

The one uh that comment that you have there, where it says, maybe common.

B

E

B

Nope I haven't.

E

B

E

I'll just drop it in their agenda to bring up in case they want to look at it.

B

A

Gosh I had a really good q. I had a. I had a really good question and I totally forgot it was activating uh whatever.

A

um Oh, maybe it was.

A

I think it was.

D

A

A

Maybe maybe it's, uh it would also be interesting to try to classify code dependencies even further like this is a framework like this is like this is a this is dependency. You have one of in your. You have one of these types, because this is the framework that you use and then you have some like, maybe utility ones, or maybe you have like some some in-house dependencies that you've rolled like other ones that we can say are definitively for, like you know, maybe.

B

You're doing form, input or documentation yeah. This is a documentation dependency. This is a ux dependency. This is a so.

C

It's like categorization of the dependencies.

B

Yeah types, types of dependencies or categories of.

A

A

Oh, I remember, but my question was: um I think it might also be interesting to try to look at uh like all of the downstream dependencies from a project like you know, out of all the projects that use react. um If you know it, I think the most interesting ones to be look to look through. It's like how many still use an unsupported version. Like you know, I don't know what version react is on, but it's like we're on react, 10 and long term. Support for six has stopped.

A

You know how many projects are still on six and below or just how many are at the different versions. You know, is there a pretty wide?

A

You know we have people using it from two years ago and also the most recent update is, or is most everybody using after a certain date or after a certain version, or is it you know, like almost everybody is using the up-to-date version. I think that would be a that could be an interesting question, something like that, um or is that way too simple? How many, how many versions of a dependency?

A

Actually, I think, that's two questions how many versions of a dependency are supported and also how many of those versions or for each version how many downstream dependents still use. That version, I think that's actually two questions. Yeah yep.

C

I think uh what I'm getting from this conversation is like. We are focused on the code dependency on library dependency and we are having different filters in that. So with that in mind, I think it's a good idea to if we start like brainstorming uh code dependency uh in a template like developing a code dependency as a metric, and in that we see okay, what are the different filters that can help us answer these kinds of questions.

B

You think this is just you think this is just one metric with a bunch of different filters.

C

Especially uh yes, uh um because, like version dependencies related to the code, dependency or library, dependency or like and downstream, is also connected to that having a different kind of filter in.

E

That, I might, I might be uh seeming pedantic here. I apologize for that. If that's the case, um but I guess I'm not. I'm not sure where the line is between what the risk working group would be considered would be concerned with versus us in evolution, because, because that to me, seems more of like a risk category or or something that they would be concerned about. You know just for potential bugs and holes and security vulnerabilities, not necessarily the the growth of the project, but I could be totally wrong.

B

So in my mind, I've always I've always kind of felt that the easiest way to to differentiate risk from evolution was, uh is production versus use where uh the risk metrics are about the about usage and the evolution? Metrics are kind of about production.

B

So that's just that's the way I think about it, so that may actually be incorrect.

E

uh Well, I think it's pretty helpful, so if it isn't.

C

Correct then, that's a shame, because that actually is really helpful. This is like, I really like this distinction, because it's clear because I always felt like risk and evolution are very interrelated, but this is a like fine line between them. Revolution is more on the production and risk is on, like assessments are used.

B

Yeah I like that a lot.

C

Maybe we should note it down the difference between evolution.

B

And risk obviously there's a little bit of blurriness in between them, because.

F

B

You can mitigate risk on the production end, so you have to you, do have to address risk, but just generally speaking, risk metrics are directionally they're viewing they're almost viewing it from the outside, whereas evolution metrics are kind of viewing it from inside the project. So.

C

So it it's like more of a cyclical where risk is suggesting different bunch of things based on their assessment and evolution can adopt them in the course of time. In the.

B

B

So that I wrote so there are.

A

Two to what sorry I might have missed.

D

A

B

Yeah I wrote, I actually wrote two questions here and they're both I think they're both the same question just for written from different perspectives, um yeah yeah.

C

A question: do we, do we have a code, dependency or library dependency or like package dependency.

C

So I I feel like uh in software development, like you, use the library as other source on which you rely on and use it in your on software, or we just copy the code from other software and use it in our.

B

Dependencies just so the the first one I wrote here, I think that's almost a risk question.

B

Right and then the second one, this is probably the the evolution question.

C

That is also a risk question too.

B

All right, so how many well, how many projects are dependent on our project right? So no this can this could be about. This would be. This could be about growth right. So, as my as my project, matures more people are dependent upon my project, whereas.

F

B

One, how many dependencies does my project have uh like how many, how many, how many pieces of code are we dependent upon? That's a that's more of a risk question.

C

I I felt like both are very same: both can be for risk and for revolution like if they are depending on your code, and they are depending on your project. Both this is still uh people or projects are, depending on your project or your code.

E

I think you could also make the uh the the case that that could belong in value as well, because, like.

F

E

Much value is being is your project spewing out into the world.

B

This yeah, this the evo one could this could also be value right, yeah.

E

Yes, yeah, that's what I'm saying.

E

So maybe we should ask comment about that, one as well, since we kind of made a few. I don't know.

C

That's where it's getting more uh blur that it is involving all different working groups.

A

um I agree first of all, um definitely going through this. I think it's become very clear that there's a I mean, obviously there's a lot of cross-pollination, but um one thing that I that I thought about. While you were um well you're talking about that is- and I don't mean to totally change the subject away from this, but the idea of a code dependency versus, like the term code dependency versus a library or package dependency.

A

I think we should maybe at least put down like write down that we should think about that language difference, because you could almost say that a code dependency is if I write one class that does some functionality and then another class that depends on that class to provide some functionality. That's a code dependency, but I think what we're mostly talking about is libraries or packages. Like the nod said, like I take this source code from you know, I take this code that somebody else wrote completely.

A

That's not part of my project and incorporate it into mine. um I think there are definitely interesting questions to be answered about both of those types um and I think both can very easily fit into evolution.

A

But uh it's just like um a minor language thing that I thought about. That might be a a distinction that would be useful in some contexts.

C

So, uh for example, if I take a if somebody else has written a class I've taken that class and used it in my own program writing I have just taken the class, but now I'm not depending on that class. So if that class is updated or not, that doesn't affect my code because I just copied as exact code, whereas in terms of library I'm pointing to that library and I'm relying on that library. If that library gets updated and my pointer gets broken, that is a difference.

C

A

I mean I agree, but I would be. I would be fascinated to see the cases where directly copying one class from the source code of a library would give you the functionality, like I'm not sure how. How often that happens, because I don't know how often that would work. I agree that they're different things and that it would be hard to you know it's they're, both providing they're both a dependency, but I've never just copied the code, the source code for an other for another library and dropped it into mine and made it work.

A

I just I'm not sure that that.

C

A

C

I understand I understand you.

A

C

A

You understand me correctly.

C

But uh what I'm trying to communicate is there are different developers who just don't want to use entire every a particular class is useful to them and that's where they feel like this is only functionality I can get from this particular thing, and I just copy that code and embed it in my program instead of like relying on the whole library which carries a lot of weight and memory things. That's what I'm trying.

A

Okay, I think so. Are you saying more like I'm using this one, only using this very one specific thing from this library versus using ever like a lot of things from this library.

C

A

Okay, okay, I understand you know um yeah. I think that's also. Actually a great point is that there's definitely there's even weights to how much you depend on on a on a project because, like yeah, if, if I depend on this library for one it's, you know, I need a helper function to do this, one weird date, time, calculation and one part of some optional path. In my application, it's different than if it's the main framework, I built my entire application around. um I don't know if that's.

F

A

What you were where you were getting at, but that's what that made. That's what that made me think of.

C

So what I was trying to communicate from this was like code dependency is, I don't know, I just copied the class, but I'm not depending on it, whereas in library or in package, I'm relying on that entire package. If that gets updated or changed, I'm mr, like my links, will be broken or my entire software is going to be broken. If there is a change in that library or package, wouldn't.

B

Would an api dependency be a third thing.

A

Yes, um yes, yeah! Actually, because you don't even have any control over that yeah.

C

I think that's what exactly like in library we copy the library in our software, whereas in api we are not copying, we are just making a call, and if there is a change in the api, there is a more broken dependency chances.

G

But that is still a dependency yeah and if you are talking about code dependency from that, lower level of granularity is just at the level of abstraction, not really different from library dependency.

G

Because if you go to a library, you ask you start having classes, functions, method and things like that. It all depends on from the discussion line. It all depends on the level of granularity. Okay, maybe in terminology.

B

Maybe is that is that our first are those our first three metrics, then codependency package dependency and api dependency.

B

Yeah, maybe- and we just treat them as frequency counts to start and maybe add some.

D

A

B

That would be interesting, I think, um and any other any other metrics that we have can build on those once we've defined those three kind of base things.

A

Yeah, I think that would be helpful to define these three first or maybe even if there are other types we want to include. Like I don't know, um platform dependency like are you uh you know, are you a facebook plugin or I don't even know? That's that's. If that's a thing like are you? Are you a browser extension? Do you depend on the existence of some other third party for your application?

A

Okay, that that was a poor. That was a bad way to phrase that, but do you know what do you see what I'm trying to say like it's.

B

A yeah, that's a technology yeah.

E

C

Yeah it's a platform dependency like ios dependency or android dependency, or linux dependency or windows.

F

B

Kind of so platform slash technology dependency and then once we once we start talking about that, there's actually going to be there's, probably a language dependency too right.

D

B

Yeah so then we have. We have five different types of dependencies that we have identified.

B

And they're prop for the most part, they're, probably just frequency, slash identification, metrics right you, whereas you you count the you count the number of dependencies and you maybe list what they are.

B

So that not too complicated.

C

But uh one thing we also discussed is the grouping dependency. Is it like? Are we, depending on the container, are we depending on the documentation? Are we depending.

B

Oh container container dependencies is that.

B

That falls into did that fall in the packet.

G

So when we are talking about container dependency, is that not a kind of nullifying the policy why we are using container to begin with? For example, docker tries to solve all this problem of dependencies.

B

Right but it's basically a package manager, so doesn't that kind of fall under package dependencies.

G

Okay, like the npm, the brew and the pipe thing, the people yeah okay, so we have to really just make a distinction between uh infrastructure dependency like the infrastructure has a code like docker kubernetes, and things like that.

B

So would docker fit as a platform dependency. Then.

A

I think docker, I think you could make the argument that it would fit as a platform um yeah. I think I think I think that would be.

C

That wouldn't be that weird, I think it is lower than the platform. It's like you. It is providing you a basis for a platform, so.

G

It's more of an infrastructure which is.

B

G

Of different from a platform.

B

G

B

Platform would be part of infrastructure right.

G

Infrastructure will be part of a platform because it rests on a platform. For example, if you have a 32-bit machine, let's say you know, and someone has a 64-bit, then that is a problem of compatibility, and you know you can start talking about problem of dependence and things like that. But docker sits on any of this platform without any. You don't have to worry about those dependencies anymore.

G

B

So that so that we have another one that is infrastructure dependency yeah. So we have co-dependency package dependency, api dependency, infrastructure, dependency platform, technology dependency and language dependency.

A

And that quickly blossomed, there quickly from three to six.

A

um Not to add another one, but this probably could fall more under common, but uh and we kind of talked about just the idea of people. Dependency like columns like a bus factor.

C

Yes, yeah, that is already in the discussion, for even that is for the value like uh yeah I yeah or for them so like how many people are we dependent on.

C

So it's a bus factor, maybe.

A

um What could also be interesting and again, this probably does not fit here, but I'll just put it out there anyway, um a people dependency, but not in terms of uh code or um bus factor. Almost maybe like a like leadership.

A

Like you know, we have dependency on the chaos governing board and the leaders of the working groups, like obviously that's much more nebulous than than what we're talking about here um and probably warrants a whole other um other discussion. But that's that's something that I thought about it's like you know.

A

Are you sure you have the code dependencies for the people that are writing the code, but what about the people that are doing all the other work on the scenes, like leadership like project direction or planning or outreach or yeah? You know we.

B

Could have organization, we could have organization dependencies and funding dependencies as well, but I think those I think, those those probably fit in uh a lot of those I think fit in common if they, if they look at the contributor and organization dependencies, then those those good fit for common.

B

I totally agree.

A

um We've got, we've got what four minutes left. Four five minutes left.

A

A

I think I think that these these different types of dependencies that we've been talking about for the past couple of minutes are our first metrics either. I think they're good candidates for the first metrics, just because they'll allow us to say like okay. These are the types of tendencies we have and then, after we flush these out a little.

F

A

We can then start to put filters on them and start to think about them more robustly, maybe in terms of in terms of each other or more focused things related to these dependency types. um How do you guys think? How do you guys feel about that.

B

Yeah I'm going forward. I like it. Okay.

C

Yeah, so maybe if we go to the excel sheet of the evolution where we have focus areas so where.

E

C

Yes, where, where are we going to fit them as a proposed.

B

Metric, so I don't uh per previous discussions, I don't think we want to add any metrics to this that aren't being worked on. Okay, I could be uh listening. Am I remembering that wrong? I, but.

C

F

Considering column is there, so we can? Okay, if we are considering.

B

Considering that's considering for release, though it's not uh that's not considering as a metric, so the there's there is some worry that that this so this document is, is how we kind of organize and collaborate for our release of metrics.

B

If this document becomes a document just full of ideas for uh for metrics, then it gets it's going to get kind of noisy. So we don't get it. We don't want to put the metric in unless we are actually working on creating it.

C

So if you look at the definition on the very top the third row, considering nothing there, let's focus on it.

C

So it's nothing there. We we brain is from those six possible uh metrics and let's consider it now or let's refine them further.

B

C

What I'm basically.

B

I'm basing this on the previous discussions that we've had recently so.

A

Yeah, I I definitely I agree with the language. Maybe it's not super clear. It means considering for release, but I think kevin's point about using this. Only four things we are definitively working on, that we want to release and not using it as a work in progress is to.

B

Catch ideas right, yeah, yeah,.

A

Yeah yeah, don't don't.

B

A

Yeah, um I think eventually, they'll make their way in here, but for now it might be better to just have some it's like a space down here. Maybe we can capture some of these. These metrics- or maybe we just I mean we have it here.

B

I think uh to start, do we want to create? Do we want to create google docs around these, um and I mean because once uh yes, we have a google.

G

B

If we create a google doc for it, then I would then I would actually say: hey we're working on these and then and then to vana's point. I think we throw them in there with the with the google doc link and uh and throw considering on it.

C

Yeah, that's what I was trying to communicate like my step was first put it here and we'll have a google doc, but it's other way around. Okay, let's create a google doc and put it here in the excel.

B

Yeah, I was I I would just want to make the point that we don't want to use it to capture capture yeah. Of course,.

F

Not I I I suggested those on the based on like.

C

Okay, we have these six uh anticipated metrics for the dependencies.

A

um Okay, we're, I think, we're at a time we're at 9.50.

A

Screen um before we head off is there anything else? Also wait. We did shorten the meetings tonight to 50 minutes right, I'm not just imagining that no you're, not a magician.

E

No you're right, yeah.

A

We're done okay, okay, um I feel like this is really productive. Today, um I think we we got a long way and I'm happy we're working on getting some of these metrics uh maybe started I'll work on making those google docs, so we can index them in the metric sheet.

G

Okay, so when you make them, will you send a link on the mailing list so that we can just start getting on it.

A

Yep definitely absolutely, and if I, if I, if you don't see, if nobody sees that from me soon, uh please feel free to reach out and ask if I've done it. Yet. I might need a reminder: okay,.

B

If you, uh if you put the, if you add the links to the, if we have google docs for them- and you add the uh the links to the uh excel sheet, you could just send out a link to the excel sheet and just say: hey: we've added, okay, these depend metrics. That way. That way, you don't have to send out a ton of links.

A

Yeah, that's a good point.

A

All right! Everybody was uh good talking to you guys hope you guys have a good rest of your day and uh see you again soon.

G

Okay, thank you.

D

Bye, everyone bye, everyone.