Open edX Contributors Discussion - Feb 20 (Reupload)
8:16PM Feb 21, 2024
Speakers:
Xavier Antoviaque
María Grimaldi
Jorge Londoño
Felipe Montoya
Cassie Zamparini
Sarina Canelake
Omar Al-Ithawi
Adolfo Brandes
Keywords:
release
people
btr
fix
bugs
review
contributors
community
proposal
maintainer
objectives
bit
pull requests
upstream
open edx
discussion
specific
year
testing
mentioned
Oh, thank you. So perfect. We have the recording started. So I guess we can start. So again, if someone is able to their screen
which would just specifically include your life insurer. Okay.
But the domain book basically justify that second step as the agenda. I don't think anyone added anything more to the wiki page. So
So if we look at the backlog. So it's not on screen yet, but brought up like the topic that you were mentioning, Philippe, with the change to you the layoffs, which generate changes in general in the community. So I've taken it under the angle of like the, the impact that it has on the the elephant factor, because there is already work being done by the new maintenance working group in terms of finding replacements for the area of the code that the code base that you will be divesting from. And and we still have to see exactly how much of that is left afterwards. So there have been so thanks, by the way. It didn't. It wasn't really great that you already had like, a list of things you would you offer to maintain. So thanks for for that. civil organization organizations, that axiom has done it on their side with Brayden has done it for open crab. So we have a few lists. And if you follow different threads, the big thing is to look at the link that I put in the ticket get 118 you can click on it, maybe I'll get that's the first one in the upcoming meeting agenda. So on those links, if you haven't seen those threads yet, there are all the details yet on. So that's the first second column first issue.
The first one in the follow up or left side, the elephant factor increase? Yeah, exactly.
That's an interesting title for it. Yes,
yeah, because I didn't want that to cover up the scope that is already covered by the mind and working group. Because they're already looking concretely at passing on the maintainers, we have some initiative on our board that are helping with that, especially in terms of announcing like trying to get more attention for maintainers or potential contributors, which we can come back to the next column afterwards. But it this also means that it has an impact on the project as a whole in terms of like, far we we govern ourselves, and etc. So some of that are, of course, like, specific to maintenance. But some of those are more like broad, I think for the project, because like when we increase the elephant factor, it means that actually more organizations or individual contributors are covering like at splitting the load on the project, in terms of maintenance and new development between more people. So that also means that we need to be careful that if there is anything that needs to be adapted to facilitate that, we need to do that. And I've made a few suggestions around that. But I see that you have your Philippe
Yeah, there was a comment from before we're going to hold my hand up, but we propose some requests and when we want it to be maintainers. And our ideas to this week start the process of nominating some people for the three salaries, the ones that have big lesson 70, some of them repulsing proposer are subjects of interest by you or by other people, but those that haven't been marked by anyone else interesting. We are expecting to start proposing like nominations also. I would hope this week that we'll see how that progresses.
Well, that's great. Thanks a lot for leading the charge on that Philippe because that I think that that represents well actually that kind of change, where I share a lot of the things are led by, I guess axemen, the in that situation around the the maintenance working group. And some of that comes from decisions from to you like which areas to divest from. But a lot of the rest means also that we need to take a little bit more initiative than then keep doing. Exactly, exactly. So. So it's great that like, not that there is a space for that we do something with that. Because if it was just removing repository from maintenance, but we didn't take the opportunity to actually step up to that to the task attic. That would be missing the opportunities. So yeah, it's really great. Thanks. So, yeah, I mean, we're, it's already ongoing discussions, and we have a bunch in progress. But that, I guess, I will be curious what people around here think that changes for bam, like, so on Nginx. Side, you've mentioned that this allows you to, to step up a little bit, I think that we we do it, the thing. Mahindra, you were interested in contributing a bit more, for example. And I would be interested in other people's take like to sign up, for example, if you if you have some thoughts about that, because I think you've been involved in quite a few of those conversations. So I would be curious to hear what you have to say. Yeah, sure. I will look into it. Yeah. Oh, sorry. Yes, yes.
I did hear my name. But my cat was getting up to something very bad. So I was correcting his behavior. So sorry, I'm paying attention now.
No, no priority first, of course. Yeah. Now we were talking about the the change around maintainer ship to you following the layoffs and etc, but the reorganization of the project around that. And I was asking everyone, including you. So that's why you are out your name? What, what people think, like needs adjustment or what, people? On your side? I think you you've been on quite a few of the discussions on the axemen, probably to your side. So that's why I would also be because what do you think? All
right, I'll let I let Jorge go first because Suzanne does up.
It just wanted to make sure we are aligned in in in something we are discussing in the BTR, so we received a proposal. series of recommendations from ACC seem to improve the current Open edX release process. And one of the items there are one of the recommendations includes them maintainers being the people in charge of fixing the bugs that are reported by the PTR after the testing process is is is completed. So I don't know if you are considering this to be included in the list of responsibilities for for for every muntaner in this new life like strategy to attract people to to this role. So I'm I'm going to share where the discussion is happening in the chat. But I think it's important to take this into account.
Good call Jorge.
Yeah, that's probably something we should align on the XM Sykes they think that the people like for Neil is not involved in the product stuff. And the product stuff is not as people writing the product stuff has not necessarily been involved with the maintainer. So we should probably come to an alignment on what we actually think the expectations are. I think my expectations would be at least baseline that if somebody makes a fix, like if Adolfo is maintaining a repo, and I'm testing something on Bter and I see a bug and I fix it in a Delphos repo. I think my baseline expectation is that Adolfo was very responsive to the needs of the release, and prioritizes that in review. I think it's a good question. If the maintainers would be responsible for actually fixing the problems in the repo. I think it makes a lot of sense. I think we're also asked maintainers to do a lot. So there's probably like a balance of like, kind of all hands on board in my mind when we're trying to get a release out the door.
And also, with code, I'm always worried when the people who introduced the bugs aren't the ones we'll fix them afterwards, I know that it's not always possible, because if someone just drops by and, and puts a pull request and then disappears, obviously, someone has to do it. And maybe that makes sense to, to have like the maintainers assigned for this as a bit more as a last resort. And we think because a lot of the contributors just by volumes tend to be and stay in the community. And I think when there is a release blocking issue that has been introduced by something, at least, if we can identify what that is, we'll probably make sense first to turn about the person who introduced the issue, or request or something might make sense for that person to fix.
The issue is that oftentimes is not even someone that introduced the word. It's just like the natural decay of software. So it has to be working like coaching, but I think as changing the repo itself, but it's not working with to Toby 18, for some reason that no one quite understands, or it's maybe well understood, but it is not like someone actively change it. Because I agree with Terry has taken the expectation that the maintainer should respond to the fixes, that's, that's quite an upgrade. But ideally, if they can go and solve the issue, practically software.
So a big a big part of this. I've been involved in already one situation where I'm, you know, the proposal we made to be TR is already part of it. So the idea is that in the future, every PR that lands, everything that's merged in the in the core product, right, whatever that means. Part of the definition or part of the requirements is that it works with Twitter, right? In other words, it works with the release mechanism where where with we release Open edX, right? So in the future, there's there's going to be much less, or man or a lot less released blockers that are related to this. Right. So right now, I dare say that 90% of the release blockers are, you know, pieces of code that don't work very well, with Twitter, getting fixed at the last minute, going forward, this is going to be less of a problem. And I'm a sponsoring, I'm responsible for reviewing the studio MFE conversion that's happening now. And it's landing in, in Redwood, and we're already catching a bunch of of that kind of problems, right? And the hope is that when released, a comes around or like when testing comes around, none of those issues are actually going to be present for the relief. Oh, yeah. When tutor does braking changes. Yeah, that's that's more of a non defense kind of thing. But
in that case, we just in a normal maintainer, ship role responsibility when when some upstream dependency breaks, that's, that's understood, I think part of the maintainer role is to upgrade to that fix whatever stuff that is in there. So Twitter is not white upstream, but I guess it's kind of a little internal upstream for the rest of the project. Right. So all downstream, I guess it depends on how we look at it, but it might make sense for each person to to fix that
was also part of the suggestions to BTR to improve the release process. One of them was for Twitter plugins to have a nightly branch and have them be tested continuously somehow, you know, let's not wait until the month before release, to see if the upstream code is going to work. Right and be surprised that it doesn't just have that be tested regularly. So if if the upstream let's call Open edX upstream, right, so if upstream breaks something, we catch it way before fasting, but that may be a little bit of fat was the land still right, but we'll get there. For now we
have hurry, Serena, go ahead and just
building on what Adolfo said, I've been thinking about this for a while. And like, even if BTR did a basic set of smoke screen tests once a month, we probably be in a better place when it came time to do the release testing. Yeah, that's a good. So maybe that's something as product takes over the testing, we could identify some top tier tests to just run through. I'm thinking, you know, login and registration like that has to work. Like that's non negotiable. We have to ship that working. And there's, you know, probably some core tests that we could just run and some basic like, does this work on tutor tests? That would give us you know, a big leg up.
Yeah, I agree.
Or like, yeah, Philippe, when tutor does braking changes to test then
this is through an ongoing discussion, mainly in the VTR and the working group, but I will definitely reach out to to the maintainers working group to to ensure we get their their insights here, because of course we are, we are adding some new responsibilities to them. So setting we should have included them. I mean, the beginning, but anyways, we are still in time for that. And we are looking forward to to keep this discussion open for at least two weeks more, because we have to make some decisions, if we want to include some of these recommendations for for redwood. So I would like to invite you all to review this proposal if you haven't, haven't done it yet. But I will, I will reach out for sure. Fenelon. And another people sorry, for this.
I just wanted to say that. Like if if I maintain your repository officially, and there's a bug in it, like that's immediately my top or if so, right, like, who wants to have to maintain a repo that's buggy and can't be released? Because of it? I mean, what I'm trying to say is there should be some words that say as much somewhere but there can totally be sort of a grace period. So that people don't get
Yeah, I think I think my my question is like should people who are testing the release, who could fix a bug entirely be able to throw all the bugs over the wall, and then say, oh, it's the maintainers fault. If the release deadline isn't missed, is missed? Like, I would hope I would hope we have a community spirit of getting these things fixed together, and that for sure, the maintainer needs to prioritize reviewing and merging any, like bugs that come in. I think it's like I I think I just like writing a lot of these proposals over the past like six years and thinking about community, I just really want to avoid super hard and fast rules that like make maintainer ship seem desirable, or allow people to pass the buck on responsibility. Like, I just kind of want to think like very carefully about the way that we word expectations and thoughts around this. Like should a maintainer not be able to go on vacation because they're otherwise they'd blocked the release?
There shouldn't be a backup maintainer.
Sure, I'm just like, no. Yeah, sorry. Jorge, I think you were first
just wanted to say that even though than that, what what what do you what usually happens is that every person here in the community receives a lot of help from from everyone for a specific task. I just think it is important to to to get some clarity about like the ownership of for for a specific task or for a specific role in the BTR, for example. We have a release manager, it is his or her responsibility to get there, his his his his tasks done for every release. And that does not mean that he's not getting any help from the community. So So Oh, I didn't see any, like red flags on specifying if the ownership of fixing the bugs falls on the, the BTR, or, or the maintenance working group, I think that it's important to, to try fight that
by I percent agree that what should exist is matter and they should be posted publicly. So we all have this expectation. But I don't think they will be a surprise at the point in time where we release this large group of software packages that work well together. It's well known at this point, we're in release like 18 of, of the open x as a whole. And so can they go on vacation? Yes, for sure. But if they have a dangerous responsibility before they go on vacation during the release, they should proactively go and say like, Okay, I'm going on vacation. But if you're interested, this, if something should fail, please contact this person who is in the capacity to fill in for me. So long, and I'll join them vacation and and hopefully, required for it. But just sort of practically do so. That in before the most reason, when we proposed that we weren't going to imitators that's something that we expected would happen in any case.
See Maria? First? Yeah.
Yeah. Yeah, I just wanted to talk from my experience as a book treasurer in the VTR, we usually, well, I usually I can talk for other people. But I usually try to when we are in this testing period, we have a list of bugs. And we try as book treasures to fix them. That's, for example, my priority. I have a list of bugs. And we usually try to categorize them as release blockers or not. And if the bug is in my domain, I tried to fix it. I don't usually, for example, if it's a new fee that I don't really know, I try to open a new an issue in the MFP and try to contact someone to help. But I usually try to fix it if it's within my my domain. So yeah, it seems reasonable that maintainers should fix their box, their reports, but what if they don't? I actually left a comment a few days ago, a few weeks ago, I don't know when I was reviewing the proposal. And I don't know. I mean, what if they don't, it's not necessarily their priority, to fix the bug that we're finding maybe, I don't know. It might be a million reasons. But when isn't a good time for us, for example, as book traders, because the description or book trader is we tried fixing the bugs that are in the release. So when is it a good time to step in and say, you know, I asked for help from the maintainer, and I didn't really have an answer, or they just told me, you know, that's not my priority. I just can't fix it right now. When is a good time just to step in, because it is well described in in the role, one of the jobs or the book treasure to try to fix the box. And that's why we tried to do every release. There are some barriers, still open stuff, but they are not released blockers and that's our main job. And so, that's one of my concerns about just, you know, just putting all that responsibility on the maintainer. So, yeah, that's from my experience.
Severe you go and then Philippian. Me.
Okay. Well, this, while I do agree that we need, like an attitude that's collaborative, but I think generally in the community, we have it. So like, I mean, that doesn't mean we always do everything that we need to do, but I think people are generally helpful. I also don't necessarily take the fact that we want to have a clear assignee as like putting necessarily all lot on the person's back sometimes is just really useful to know what's expected of you. And because the worst is genuinely when several people think someone else might be responsible for something, and to nobody's bad will is just it will like everyone while I've waited on someone else. So having that clear, like, oh should be supposed to do things, even if, at the end, someone, the somebody else helps or whatever, it's a good thing. Again, it makes sense for me to have like the maintenance as you make responsibility, because after all, they maintain that code base. So like, like the book kind of stubs with them in a way. But it's true also that if they don't do that, or if they go on vacation, and etc, some like other people need to be empowered to also fix the issue, especially if it's not moving. So I think probably follow up on your question about when is it appropriate to kind of step in, it's a bit like for the review of the pull request, I think if someone is not responsive after like, after a week, if you don't have any answer, clearly the person is not being responsive. And I think in that case, it's fine to fix it. And probably even before that, I think on upstream pull requests right now, it's basically you can, from the get, go, take on the review of the pull request, even if there is a maintainer, and etc, as long as you feel comfortable doing that. And I think it makes sense probably to apply that to fixing bugs. If you feel comfortable fixing a bug, you don't necessarily I think need to ask the permission from the maintainer, you can already send something that will probably gain some time to the maintainer, even if they wanted to do it, and it's just the maintainer is, is there. If nobody else does that, if none of the bacteria, none of the core contributors, or none of the contributor in general has done it and the bug is still there. While they are there kind of as a backup or to coordinate, what happens if they're on vacation or things like that more as a responsibility than this little person always doing the work.
Just wanted to add that maybe it is important to emphasize the tasks related to the kinetics release process happens. Every, I don't know, like, six months or something like that, we're talking about just four months a year, where we're, we're these people based on the proposal we are making these containers should should should be able to to help the BTR fixing the bugs. The team is reporting. Right. So we don't know if if every working group shares the same sense of urgency. We, we we experience in the BTR for every optimatics release, because it feels like that. It feels as if it feels like, like we have we have a huge commitment when our shoulders and of course we are we are eager to accomplish it. But I think the main idea of the proposal we're making is to share some some some tasks of of the current workload we we are we are we are having every for every open attics release. So verdict working group was the first working group to to, to step in, and, and, and, and make a proposal for increasing their commitment. For every kinetics release. They would be in charge of the testing process. So it will be nice as well, if if if we can have some more hands to help us in in that specific process. Specifically, the containers help on fixing the bugs. So again, I don't know if we are sharing the same sense of urgency of something that I consider is one of the most critical processes we have in the community every year, which is the release of every optimatics version. You're raising your hand. Hey, nice to see you. Hello, this.
It's been a while. So yeah, I'm wondering if there is anything that's because obviously one of the bottlenecks in In open index is back end and front end engineering. But I'm wondering if there are other bottlenecks for the BTR that could be announced, for example, I was thinking the other day that we might have, we might be able to dedicate some of our QA capacity. So like we were talking about, let's say whitebox QA would that be helpful
that would be totally helpful. You just need to coordinate with the BTR testing manager.
Okay, because I figured out that Felipe with with some puppet I progress has been made.
Yeah, we're
gonna have a changeover probably testing manager for redwoods. So there are no names yet. Okay. So, yeah.
Yeah, I Yeah, appears out. I figured that we could use some capacity, but still bottleneck.
That's awesome. Thanks so much.
Alright, sure. So yeah, um, I like a very light announcement. I'm no longer with have similar as a start seeing 22,023. So right now I'm building a local team in in Jordan and mostly Middle East. So it's still not really that well developed, like as a as a full capacity, because obviously, this is it's been like, almost a year. But I'm fairly certain that we can, this is the moment that we can start can be contributing back to the to the community because that's like, I mean, as soon as we see an opportunity, obviously, we're like still opening pull requests, but there is no, this kind of a specific and predictable commitment. And this is the area that I would like to start with, which is basically VTR QA. Someone goes through tests the whole thing and make sure that basic things looks good, because we know that automated test can really be helpful. But sometimes, it doesn't catch few obvious things. Well,
and right now, we don't have any automated integration tests. So it's all manual, eventually, we hope to have some right now. It's all manual.
Yeah, you're right. You've raised a really good point about that. Like, I'm evitable. Yeah, thanks. This is great.
Thank you very much. So great. Yeah. So so we'll keep you in the loop. Probably in in March, we'll be releasing the testing plan. So that would be the right moment for for for a start that helping us in what we're doing. And
maybe what you can do to try to inspire other people in the community to do that a bit like, the next day. The open club site is comment on the thread that there is on the forum, I put the link in the chat mentioning that, like what you'd like to contribute, because then that shows that bench of people trying to push that up so that
yeah, you're right. Yeah. Like, Well, are there things that you like keep tracing is the payments and E commerce stuff? Um, I would love to start contributing into that area. However, our use of it is a little bit flaky. So sometimes we use it sometimes you don't? So um, yeah. It's with the two new updates. I think that's a little bit like even more confusing.
Yep. I mean, you don't have to commit to something, you wouldn't feel comfortable. But I think especially on step one, nobody's doing anything, even if you do a little bit. Or if you can just guarantee the basic parts of maintainership. That will probably be a net win. Even if you can't like really push the development forward or etc. Too much. Already, that would be great. And even even just with the testing part, even if you're not sure about committing to specific maintainership, just mentioning what you just mentioned, this way, other people will see that, that that you're keeping in
good points. Thanks. Thanks.
Thanks to you. All right, we have 20 minutes on the meeting item. I know that it's a big topic and an important one. So maybe a quick round two. Would you like to continue on that? If so, like, maybe bring up point or if, if, if not, we can continue with some of the other topics and keep that async for the next time. But again, it's an important topic. So does anyone want to discuss this more? One time, two times, three times. All right, let's get to the next one on the list. So that's actually something I think, gets you introduced that picture a long time ago, but we haven't had a chance to get through that, I don't know, if you want to do that now, just deprioritize it.
Well, so, so, so, this actually came from, from a sense of, not knowing personally, not not knowing what what we actually achieved, as a community during last year. So in the end of, of, of, of every year, I, I tried to run like, like a personal retrospective of, of, of the efforts and working on in my job. So, so one of them is, of course, the Open edX community. But it was really hard for me to, to understand what was like the overall impact we we achieved last year, right. So, so after that, maybe I concluded we, we didn't have a proper framework of objectives, that could lead us quickly Galge What was our impact as a community during a specific period of time, so, at Arrow next we have been using OKRs for around two years. And even though it is it is a typical framework that is easy to understand, it is very hard to implement, right. But it is quite useful, or it has been very useful for us. So I was wondering if we could have something similar in the community to understand more, what was our output? What was our our outcome during the year, so I know, we have our, our community roadmap and and this year, we are aligning the product roadmap with the, with the Open edX releases, which is awesome. And and, and it is way more clear now. Which features we're planning plan. But in the end, what I would like to look for is, is is is why why did we do that in the first place? Yeah, in the first place. And and afterward, once all the effort was executed, what was the final result? What was the impact of of, of the release, or of all the projects we are, we are working on in the community, which again, leads me to that lack of, of of having one two or three objectives that, that I could have, like a highlight your notes for for a specific period of time. So that's more or less the rationale behind this proposal. But I don't know how like how important this is considering all the things we are we are working on right now as a community and considering the recent context. We, we we gain from from the to you situation. So maybe this is a discussion for next year. I don't know. But this is what I had in mind in the first place.
No one wants to say something about that.
I would just be curious to see some examples of what that looks like.
So
I guess what I mean is I don't know if you want to drive this idea forward, Jorge. But if you do, I would submit a write up anywhere like in the wiki or something just with some examples as How would this work? Right? How do you think this would work? Because right now I have next to zero idea how, what OKR even means, right? I mean, I know what the acronym means, but I don't know what it looks like. So
Here's a great I love them
that that that could be a nice next step making posts, where we explain briefly explain the framework and providing some examples that I could work for the community. Now that we were discussing about the impact factor that links to an Ikea Nokia we have at ednext, it is quite easy to make an example with basically the objectives to do said, result driven objectives instead of output driven objectives. So it is not about executing tasks, it's about achieving a specific result. So, if we're talking about, for example, the LM five factor, we're talking about reducing the dependency the company has on to you, right, so, so, of course, we will have to do a lot of things for for for reducing that dependency, but in the end, what we're looking for is to reduce that elephant factory. So the objective would, would aim to reducing that, that elephant factor two a specific number, we decided to community, but it is something like that. So it's everything about results, and not about the tests that could lead to that specific, specific result. But if you're okay with it, I can take that a commitment of explaining the theory in a brief post to hopefully continue the conversation there.
Yeah, I mean, that it's actually like, summarize, you can do it in like two sentences. Like, basically, it's a framework that's supposed to be more flexible than like KPIs. Because KPIs are like really driven as like, exact things you have to do. Whereas like OKRs, are supposed to be like, you have this objective, and the objective should be pretty high level. And you have these key results that you think will support the objective. But the teams who have to display those key results can use whatever strategy they want to do those key results. So like, Chrome as a project was driven by OKRs. And their their, their objective was become the best browser. And their key results were like, numbers of how many things how many people would adopt their browser, and each department would say, how can we drive those numbers? Like what is like what does advertising do? What does engineering do? Then you kind of like allow the teams to figure out their own best way to achieve the results. But you have like a sense of a sense of objective that the whole team, all of the teams are sharing, basically. It's a management tool to prevent my micromanaging. At the end of the day, that's what it is.
Put forward, you mentioning how they about whether that would be useful to know or not, I think, yeah, like, like, like you mentioned, we have a lot of stuff to do. So probably I probably we want to start small, I guess. But that. But to me, it seems useful. Also, if only for the discussion, leading to deciding what our goals are. That's usually a really useful discussion. And given the current context, you know, like, making sure we agree, I don't know, like, do we all actually like or want to increase the elephant factor? stuff? Like, for example, we have a big backlog of upstream requests waiting. So that could be a good, okay, we need to get the response time or number of pending ones, or the average length or whatever, something to better value? I think there are a few things like that in the current situation that might be helpful, actually. So it could start simple, maybe with the explanation of what the framework is, like we mentioned, but maybe you could start suggesting some OKRs that you think would actually be good to set, not just examples, but what do you think would be what would be your take for the OKRs for the Open edX community, and then we can all add or comment on this and then that will bootstrap a bit that conversation on on something very concrete. And that can just be a list for the for the first year that we put in a wiki and next year, we look at that and maybe we do something a bit bigger. And and maybe the second thing that I wanted to mention is that Edie spent some time, some time ago looking at That's sort of kills like the things like the elephant factor and etc, stuff that comes from that. So it might be worth looking at that. I think he's still as an instance of grim while running. So you have some numbers actually, that are already extracted. I don't know how helpful that is. But that might be something to keep in mind. Again, we have a lot to do right now. So maybe that could be for phase two or something. But just
as I said, you mentioned that we're in year two of using OKRs LMS. internally. And from our learning curve, the weather, the objectives are the weather the key resorts, and that the team can do is so if we do this, really then that discussion, what are the objectives of the community is perhaps the most important, because then everything else can derive from hearing and should not be taken in for him? If and when you decide to propose something, that's brilliant, but then a lot of decision needs to be made a lot of discussion with zoom in on that, because otherwise, it's easy to say like, those those objectives seem reasonable to be looking forward. But that is what we've learned from the use of internet.
So I will open the discussion at a synchronous leave. We can continue that conversation there.
Alright, great. Thanks. Okay. So next ones, now we go to the follow up on elements in progress, and so on, in terms of advertising, contributors, to take more responsibility, and permission rights, and just leave that in the spotlight and with everything that we discussed before. So some initiative that just quickly mentioned signer did call recently, then there is the thread that was started with veggies and Nacho plus the goals of the maintenance group. So I think we get plenty of calls, I think Tim still has to kind of announce more broadly, the changes that were made, in terms of acceptances, maintainers, and rules for review LSPs, that were relaxed a bit to help with resolving the queue. So same thing, so that will keep going. And I think there might be also at some point, some meeting of providers, try to see at the partner level, what can be done, so that that will keep going for a while, I think. So I think this one is what they can get off. But if anyone wants to do something more in there, as it is, it's still there, welcome. Alright, none, then the next one core contributors as backup reviewer. So that's one of the two changes that I mentioned that Tim will be announcing more broadly. But now this has been implemented. So basically, core contributors are backup reviewers, on the repositories, at least any repository that contributor feel comfortable dealing with the the upstream review, while nobody's already doing that, you can feel free to jump in. So that's reserved for good co contributors. And in terms of at least having a binding plus one because we have 1000s of types of core contributors, but that's specifically good. But I think there will probably be something similar implemented on the product side, I think it's being discussed kind of like the rules for assignment and etc. And then I guess, guess, do you want to give a bit of an update on the discussion on the road side for for reviews, product reviews? I don't know if you if you have the be informed that
or not? Yes, I think we're waiting for everything on with regards to the survey, and Ellie's going to be so that's kind of just been put on hold and yeah, if that makes sense. Project
creatures assignments. I meant, you know, like, like the assignment of reviewing parts of the like some of the project review proposals and etc. Either un signed actually also involved in that
you're muted I think this Yes.
I don't know if you're speaking because I can't tell you right now.
Okay, there we go. Sorry, my my earphones died and it just everything just went haywire. Sorry, can you just repeat everything you just sit? Yeah.
So it was just as part of the like, I was just talking about the upstream reviews on pull requests, and I was talking that this was specific to the code COC contributors, and that there would probably be something similar for on the product level to have more contributors being involved in the reviews, and etc. So that's, that's okay.
So you know, I didn't I didn't I didn't I didn't hear you properly. Yes, at this stage. I wasn't in the product called the the core working group last week, but Ali said that there was some discussion around it. And that's still up in the air, and they need to come up with a good plan to see how this would would all be, how are we going to take up? Sort of reviews, etc? And how are we going to distribute it as well. So it's all just a little bit up in the air at the moment, but it is discussion around it. And I think we've been discussing it async as well.
Thanks, thank you. I did not notice that. So yeah, I was saying, Okay, sounds good. So we'll get some update probably next time on this. Since we have like only a few minutes left, just get things through the at least the most important priorities. Yeah, there is still the debugging of persistent grade issues, which need reviewers. So I guess on that one, I will follow up with Braden, because I don't think anyone on this call would be able to help. I mean, if you feel you can help, please jump in for sure. Because I've been looking for one for a little while. But I guess with with the kind of pull requests that there is currently after in this case, but if there are actually some that some of your pull requests that being blocked or product videos or etc, don't hesitate to bring it up in the retros. I will try to prioritize those because there is quite a big list. And yes. Alright, so the next time is on the OSPF guidance. So we've talked quite a bit about that. Feedback on cost, print check skins and retros. I guess in one minute, before the end keys to see do you want to give a quick update of where we are on the survey?
Just muted. I'm on mute, at least hoping to send that out. This week, we were wrapping it up. And we're hoping to start sending things out so that we can start because there's quite a that's actually blocking quite a few things. But people have been reviewing and yeah, so we're moving forward on that. And then also we can make up so we make some changes with regards to the list of low CC chickens. We had a bit of a downward slope. Last Last word was good. This sprint we just had a bit of a downward slope on the chickens, but hopefully we resolve that.
But the current sprint like the one that you published today, we actually had,
so there was Yeah, so there were 33 last sprint that checked in and the sprint we were sad actually people, often my chicken responded, and I think we had 22 now, so I reported on 20. So I think we just also needed to find, but this will happen with the survey is when the cutoff is and maybe cut that off, because they're now my reporting is a bit messed up because of because people are checking in late.
Right. Well looking forward to that survey, because I think it's quite good. Yeah, it's going to be interesting to see the answer from all the cards. Really. And if you haven't reviewed it by the way, it's it's probably getting a bit too late. But if you're curious, you can see the questions.
Now please add extra views and it'd be great.
Okay. And I think we are getting two times so unless there is something that's One wanted to discuss today that we haven't had to cover yet.
Just wanting to rip up a little bit. The main two things we discussed during this meeting, the first one was all the efforts the community is working on regarding the maintenance needs considering again that to your situation. So that's something for Neil, if I'm not wrong, misleading, so haven't seen any like, like, call for helps regarding that. I know, from from from internex Filippis is attending those meetings. But anyways, if if you need any help from the BTR, or from other members in the community with just yell loud for that, and secondly, the proposal I mentioned, we made for improving the current kinetics were released testing process and shared the link in the chat. I also added the link in this specific GitHub issue. So please, if you have the time, review it and leave your comments there. During the next two weeks, and by the beginning of March, we will wrap up everything and make some decisions. make some decisions for for the redwood release. So it
sounds great. All right. So we are time I see people dropping so thanks, everyone. Thanks to them. Good discussion. See you in a month.
