you so I'd be How does the autopilot work? Does it just like report back to you with all of your notes and you go through it
at the end of every meeting that I'm in that has that in it, I usually get a link to the notes that I admit I've never clicked on
Have you ever asking how the autopilot works like does it just report back to you with all of your your meetings and you just decide like what to look at and what to ignore?
Well, it's not really just for me actually. It's like the books and gets transcript and does a summary and normally it sends it to everyone who is in the meeting. So it's a way to like, follow a bit more async. So especially all the meetings for me to where to like, stay in touch with more meetings and the ones I attend while trying to expose that. Still testing right now we're still in that phase, but it was reasonably useful. Like if you don't trust it too much.
Is it accurate or
not? Is that's why you can't completely trust it. But especially the transcript if you read through it, you're able to go a lot faster than just watching the meeting. And if that applies, like it's usually it's written weird when when it's wrong, you can click on that button it will actually play the person saying that so actually, you can recover from from the earthquake. Got it? Cool.
Sometimes it's more accurate than my memory of the meeting. Like if I'm responsible for writing the notes, it's very helpful.
Exactly. Like the best communication is like to use it as a raw draft for notes. And to correct that and then generally, that's the fastest of my career. Cool. Got it.
All right. So there's a couple of things on the agenda today. I think Santiago's on holiday today. So I wanted to touch base first on the redwood feature list and some of the work that's been underway over the past couple of weeks to plan for redwood. So this has been going on across a couple of working groups and it directly ties back to the conversation we had in this group. I think it was at the end of December, it was the meeting just before Christmas, when suddenly you'd brought up a number of questions around like MFPs and structures and opera like operations for including MFPs and the release. So there's been a couple of subsequent meetings that have happened between now and then around budget planning and I want to make sure that this group is pulled into that conversation because it's really, it's going to be contingent on like the product working group, The MFE working group, and the BTR working group, kind of all coordinating together to get Redwood over the line. So I want to go through that and bring this group up to speed on those last couple of meetings and on the release list. And then I wanted to touch base on the work in progress product reviews as well. There's a little bit of a backlog that I'd like to get through target by the end of January. So what just wanted to touch base on that status as well. Anything else? Anyone would like to add to the agenda
I think it's it's already containing those but I'll be curious how this will be like to the roadmap like and, and to interface to things but I think that's more minor.
Yeah, we can talk about that for sure. So let's actually let's just dig in then to the spreadsheet. So I wanted to make sure that everyone is aware that this spreadsheet exists and kind of walk through it since this is the we we did this with folks from BTR and The MFE group in the planning sessions. I wanted to make sure again that everyone here is up to the same speed. So the idea of this behind this spreadsheet is a reflection. There's a little bit of context first. So in terms of planning for releases, one of the goals I think for Redwood is to shift the planning so that we're doing more intentional curation in decision making about which features we include in the release, rather than kind of waiting until a couple of weeks before the code cut off and seeing like which features have been contributed. In the past it was like kind of driven a lot by what edX had dumped in there and not a lot of thought given to like which features to include which which do we not include? I think it's important for this group going forward to have more of like a say in terms of what what's included and what's not. And also, I think what's significant about Redwood is that it's the first release where like more than half, probably even like three fourths of the features are coming from everyone across the community instead of just EdEx. So it's a much more like diversified set of features that's being contributed, like every pretty much everyone here on this call has been involved in like shaping those features. And so we have an opportunity to like get ahead of planning those features and know what the documentation looks like what the what the UX looks like, what the impact and what the ROI of the features are, before they're even implemented, which is has not been the case historically, right. When edX would contribute a feature would often just get kind of thrown into the code at the last minute and we'd have to do like Peter pinch would do some archeological digging to try and figure out what the feature even is. And so the idea behind this spreadsheet, which is intended to it's it's pulling directly from the roadmap, but there's I think better it's easier to track in the spreadsheet form for now. The idea here is to track every single epic at that we want to include in Redwood and also make like intentional decisions about what we're including. And so, in terms of strategy, there's a set of features that support the unique value proposition of Open edX. In this case, these are features that support like competency based education or more flexible pedagogy so these are like the content tagging projects, the aspects projects. There's features that fortify platform strengths. So focusing on assessment capabilities, I think it's going to be a bit more of a focus for sumac and teak looking forward. And then there's a set of features that kind of fill parody gaps around platform UI around LTI support in the admin experience. So the types of features that we're we will make intentional decisions about including either fill, you know, some sort of unique value proposition and help to fortify our strengths or it fill parity gaps in terms of definitions in the spreadsheet, so there's four statuses that I would like to start tracking for these projects. The first status is product definition. So in this case, product specs are being worked on or maybe the UX or UI is being designed. Then there's a technical discovery phase where approaches are being tested and refined on the technical side. In some cases, maybe these happen at the same time. In other cases, they may be more sequential. There's an implementation and refinement phase. So once the product once the PRD is written and the approach is decided on then it will be implemented. So your work is in development, and it's undergoing user testing. And then there's ready for community testing. So in other words, the feature is done and it's ready to go into the community release. So it's ready to be handed like to the BTR group then for testing. So if we look at this spreadsheet here, I've got it structured. So you can see here there's like a Gantt chart where you can see each of those those phases. So product definition, for example, implementation, some are ready for testing. So it's organized here by initiative and then by like major epic within that initiative. So for example, aspects project has five major epics associated with it. Eventually, I'd like to link to the GitHub tickets here. So it was it this kind of ties to your question of how does this connect to the roadmap? The idea would be to eventually connect you know, links to the tickets Once the work is in progress in tracked and GitHub. So if we filter this four on and then I've also got it sort of scoped out for the next four releases, so Redbooks, sumac, teak and whatever you ends up being. So if we just filter for Redwood now it's possible to look at more granular breakdowns of what's expected. So I've got the Gantt chart here, kind of broken up into just very general generic two week sprints that kind of span each month. So January, February, March. The idea is that for most projects, except aspects, we want the work to be complete by mid April because that's when the code cutoff is we may be pushing that into May based on some conversations with BTR whether that's gonna be possible or not. So the idea is that we can now work backwards and say like what needs to be done for each of these projects before the cutoff in mid April or May in order to ensure that these can be included in Redwood? So again, for us, we've got a couple of Epics for aspects. The key sets of reports that we're going to include in aspects and why those are important credentials has a redwood project in terms of the credibly integration, which is going to enable us to connect the digital credentials to the course level and deliver credentials at the course level, which is exciting. Xavi I know one of the things you're asking last time was like, where do we track Developer Focus things as well, these are those are integrated here. as well. This is not just, you know, product oriented, but also platform oriented. So a Django 4.2 upgrade is coming. Elastic Search needs to be upgraded for Redwood as well. There's a bunch of redesigns around UI so the files and Uploads page has a brand new design. We're doing a bunch of work for libraries. So there's about nine epics here for libraries and libraries overhaul. There's a little bit of a question as to whether these are going to be complete in time for Redwood we may do more of like a sneak peek or a prototype for redwood and then do a full release of a library overhaul in sumac. LTI reusability is a work in progress. There's a bunch of MFE pages that are being converted and redesigned as well. So again, Xavi your question last time around connecting The MFE process. We did a workshopping session in person last week here in Boston around connecting like the product process to the MFP process and there's now a set of criteria that we'll be using to review and the fees for inclusion in the releases. So there's documentation around that that will circulate. But basically all of studio is going to be converted to Emma fees and will have gone through a redesign with with Paragon in time for Redwood, which is exciting. Mobile is still a question which mobile epics will be able to include. Um, there's a no JS upgrade. Aura is probably not going to make redwoods. I'm gonna switch that to sumac. Same for roles and permissions. The new sidebar navigation is up and coming and we've got we've got budget budget to push us over the line which is exciting. And then of course tagging in taxonomies and some uploads to the updates to the video uploads process. So as of now it's looking like everything here on this list is like fingers crossed, we'll be we'll be ready for redwood. There's a new group in progress as well. Does it come up last time as well called our Redwood release planning group, that group is meeting the second Thursday of each month in order to kind of coordinate just like status updates on these projects. There's folks from BTR there. There's folks from The MFE group there if anyone from this group is interested in joining as well. I think it'd be good to have more product representation there as well. Just to make sure that we're all kind of aligned on on what's up and coming. So that that meeting is now part of the working group calendar. So you can find it just through the open edX Working Group. Calendar. It's again, it's every I think it's the second Thursday of each month. We'll we'll do status updates and we'll also talk about more products like what we can do in around product marketing and making sure that all this is more out in the open. So that's kind of like a quick a quick overview of this. I think it makes sense to keep the status updates in that planning session rather than rather than in this group. But again, I wanted to make sure that everybody here was just sort of in the loop on what was happening with with this and make sure everyone had a chance to take a look at that at the spreadsheet. And then going forward like talking about sumac talking about teak I think it would make sense for this group to have more of a we can use this this meeting to have more of a like planning sessions around the curatorial process like which features are we going to include which features does it make sense to align to the core product so we can sort of convert some of these product working group sessions into planning sessions for sumac and then for teak as we as we get more towards the beginning phases of planning for those
thoughts, comments, conversations you'd like to start?
I mean, I think this is great. I've been following along. And I think the release meetings on the third day is going to be super helpful. So keep it up.
Thanks. Yeah, I'm excited to see more planning and that's one of the main things that it's good to see that thanks.
And speaking of planning, Oh, way, oh, when would be the right time to say if we think maybe something won't necessarily make it in this timeline.
Like any any working group, I think would be good to bring it up or even just, I think if there's one in particular, like we can certainly even talk about it now. uncommenting in this Excel sheet would be another way to do it. The whole point of like, the whole point of this is to unearth those red flags, right? Like is there potentially something that's not going to make make the release? So like, if you wouldn't be able to attend the redwood planning session you can flag like a comment in here. Just add my name to the comment. I like we want to keep that keep those like processes of unearthing slow or potentially like delays as as early as possible. So,
okay, but the redwoods meeting would be preferable to this spreadsheet or either way. Other way. Okay. No problem. I don't see any problems at the moment. I'm just keeping my eye on row 53 for the search.
Yeah. I think we'll have to coordinate ally around I think we can probably have like a smaller scope for this in terms of like an MVP release of the search. And I know it's also we, in the planning session that we did in person last week. We also on Earth a contingency on line 13 which is the upgrade to Elastic Search, or maybe something else like it was unclear as to whether upgrading to Elasticsearch was the right approach or whether a different search back end was preferable. So it may be that we have to push this the whole search initiative to sumac which wouldn't be the end of the world I think it would be a nice fast follow after the tagging in the libraries. So it's kind of there's two kind of contingencies on that. And I know that there's some open questions still around usability feedback on the UI as well. So
you have a sense of like, so like, say it kind of come. I know that a lot of different people are working on all of these things, but for things that might have like resource overlap, do you have a sense of like, what your highest priority things are that you really want in Redwood versus things that like, it's, I don't know, like the top three things that we really want to get in Redwood so that we could maybe focus helping those efforts get over the line?
Mmm hmm. Top three, I would say tagging aspects in the sidebar navigation. If I did just like choose three off the bat. I think those deliver the highest value and they work together. in interesting ways. And the sidebar navigation is there's like such momentum behind this point that I think to hit read would what that would be would be perfect. Things like search and search is a nice fast follow, right? It doesn't it doesn't block the use of tagging in any way and it just builds on it. And so if we have to do a fast follow and sumac, that's fine. The other big big project is libraries. And I guess a quick update because I'm not sure if everyone in this group has been in the loop on this as well. But edX as of about last week totally dropped all of their work with content libraries. They're not going to take it at all going forward. So it's going to be picked up by I think a team of folks from XM from open craft from schema education. And we're going to reframe this we're no longer calling it libraries v2. We're gonna call it libraries overhaul. You can see the epics here. And I'll link. Actually another link I should add to this Excel sheet is probably links to the product documentation. So I'll do that after this call so folks can take a look at the user stories that have been we've been building for these. It's, I would rather move more cautiously with libraries and make sure that we actually launch what we want to launch with this rather than continuing to do like half half launches, which has been the case for this over the past couple of years. So if libraries gets pushed out to sumac, I'm okay with that as well. I would rather do it correctly than than not at this point.
That makes a ton of sense. As you're doing coordination, like it's January so it like seems far away and then like in two days, it'll be February and it'll seem a lot closer like it's two days but like the beam changes I don't right now know if this is possible, but it would be worth kind of thinking about how could we get people helping each other out with final code reviews or final implementations to get those top things over the line? Rather than get ourselves in a situation where we actually get very little into Redwood but we have a bunch of projects that 80%
Besides code reviews, what would be other areas where we can you could see needing we could see needing to leverage like shared work.
Yeah, off the top of my head. The only other thing I can think about is more senior engineers, maybe not coding but maybe doing like two hours worth of code pairing or something to kind of help bootstrap up a more junior developer. I don't know what developers are working on what projects but yeah, I've just I've definitely seen it before. When we had like at toasts. We had very hard hard deadlines. And it would so often be the case like every three releases or so we'd get ourselves in a situation where we had all these features at 80%. Yeah.
I think the idea of like picking the top, like prioritizing them out the gate makes a ton of sense. And that's something else that could be built into the spreadsheet as well. Like we could do, you know, high medium and low priorities. And then maybe do maybe actually use all like all hands on deck each meeting to ensure just like a quick status, check those top priorities in this group in The MFE group and the BTR group and the redwood planning group just to make sure we all stay in alignment and can identify any red flags early.
Yeah, because I think the one I would be slightly concerned about is the sidebar navigation just because there have been so many cooks in the kitchen there. And I don't have a clear picture of who is doing what or how their what their path to getting the code merge into the platform is and even if that's all the help they need is just to come up with that timeline and the people they need to tag for reviews and can just like instantly having reviews happen the day or two after they're tagged rather than waiting five or six days. Like that makes a huge difference. Yeah, and that's
actually I wonder if there's also a better way we can build just regular status or like progress upgrades into this Excel sheet as well because and this is a good example of it. We've W GU is going to take on the the UI implement UI design for this. They're going to it's actually it's exciting. It's the first time that we've been able to get like a resource sharing agreement in place with the with the super user, which is awesome. So they're and they've already done some. They've already done their own implementation of it. So they've got quite a bit of data as well. They've done a B testing, because they've got a big pool of data that they can pull. So they're going to do the designs for it. Chelsea did a power session yesterday on getting the PRD over the line, which is awesome. So we've got we've got product specs written we've got WG ready to take on the UI. They're aiming to have that done by the end of February which means we have like three Sprint's to do implementation. We still need to figure out who's going to do the implementation. And you know, that's that's a quick turnaround which has just been three Sprint's but it's occurring to me as I'm talking that we should probably figure out how to get better status representation into this Excel sheet as well as well as update the ownership because that's not clear here. Like who owns besides our work, so
yeah, I I kind of wonder if that should be a separate sheet. I mean, you could join them together at some point, but like it's nice to kind of just have a roadmap view without a bunch of specific implementation data. Yeah.
And also, since those theories are we like all those different teams working on doing the features in alignment that they are also going to be targeting the release or is it something that we've deduced from your face? I know that some of those epics they are actually initiated by axiom so it's a lot easier I guess, to set the deadline but for the other one like
yeah, tracking tracking, like, deadlines is probably another another area that we could have here. I think going forward, like regardless of who is driving the project, whether it's X number or whether it's someone in the community, I think we still want to adhere to deadlines as much as we can live without getting too much into like the trap of the waterfall method. But that's probably something that we could better track here as well as like, what's the intended target? The Gantt chart is kind of intended is intended to sort of track that as well. This is a this is updated in real time. Like I'm trying to update this on a weekly basis. So if it's an inflamation implementation and refinement stage, that's actually where it is and the part of the redwood planning sessions are to gut check like is, for example, the tagging important export project. We've got it currently targeted for this sprint to be ready for testing. We check you know, check that once a month is that does that look like it's still on track?
And maybe it makes sense to have something that's like a column that you can flick on if it's at risk. Just to kind of raise that I'm going to talk about this at the next release planning meeting or next working group meeting.
And maybe status for conference level or something like that. Yeah.
I'm guessing that all those project days some ongoing coordination that needs to happen even though even just for the fact that there needs to be a checklist done for all the features for the actually get released and etc. So I'm guessing there will be an ongoing discussion for which release are you targeting for each project, and probably need to be a plan one, one that change or because I've been thinking that some? I don't know if all of those things are already aware that all their work is targeted for the release. But if they are not even just communicating that and not just to the projects are now but also the blockers because they also know when to target things. Like when we get to that finish line might also already know what is blocking. Yep, yeah, that's a good point.
Serena, what do you mean by pre implementation? early implementation technical support.
So I'm thinking in particular about the sidebar navigation, like whoever picks that up, like, can somebody senior in the community, talk to them about their proposed implementation their diagrams or like whatever they have for an hour or two before they even start so that the implementation is one we approved? And I think to an extent that is included in some of the like the product proposals, but like, for, especially for a feature we really want to push along, like, let's be explicit to make sure Dave or Kyle or for Neil or Braden, or somebody like takes a look at these high value quick implementation features and make sure they're going they're going in the right direction from the get go.
Yeah, and it would probably make sense to do that. After the UI, right? Like, so we read the specs, we have the UI, we kind of thumbs up on the UI, and then the UI is going to drive the approach. Right. And so getting them involved at that that stage it sounds like would be the best the best point
I think that's true for most features, but I wouldn't say that's necessarily true for all features. I think for like something I mean, thinking about tagging, right? There could be initial architectural discussions about how we're going to architect tagging without having a UI defined yet. There's something like sidebar nav. It might be worth talking to somebody in February because if we don't get a UI till the end of February, and then they don't even think about architecture until March. I mean, that's really cutting things close. Yep.
Yeah, I would, actually plus one, instead saying that because in the past, we had big projects with people coming from the community, and especially if the developers will be doing that I'm not used to going through the upstreaming process that might be extremely painful. Like we had a few of those in the past. So
yeah, and I think I, I will add a little clarifying comment here, but like, I don't think we have to do this necessarily for every project, but like when we're talking about tight tight timelines and high value projects that we want to aim for a specific release, we really need to be supporting as much as possible. Right.
And it kind of goes back to the like, again, identifying what the top three ones are, that are we absolutely want to get over the line at like, you know, at almost any costs. So in identifying things like like that, so like the sidebar would be an example where we may want to get somebody involved earlier on in terms of technical review than not.
Yeah, and I think you know, some of it really depends on who exactly is going to be implementing this because if it's somebody say from from WG EU that you probably have a lot less experienced than, like, say, if it's open crap to like, internally have resources and a large amount of platform knowledge. So yeah, I'm just kind of like, because we're not sure it's just something to call it.
Yeah, WG EU has said that they they don't unfortunately have the engineering resourcing at the moment, which is maybe okay in the long run, because if we're looking at a tight turnaround it like like, you know, same point if they don't have as much experience at the platform, it may make more sense to have somebody internally do it.
All good feedback. Any other questions or comments feedback?
So maybe, maybe it makes sense to do like a standing at a standing point to the agenda, just to do a check in on the status of the top projects each each time we meet and see if there's anything required from the product side. In terms of ongoing status updates or coordination as these go along. So that we can on Earth stuff like this, like which ones might need to have early, early input from tech teams and that kind of thing.
All right. The only other thing I had on the agenda today was a quick just a quick update on I've lost my oh here on product reviews. There are a handful that I am aiming to have done by the end of this week, um, Santiago, those are the ones for the Spanish Consortium. I wanted to make sure that the rest of the Spanish group ones get over the line by the end of this month. So those outstanding ones are like highest priority. Again, this list is I've consolidated this list here in the Open edX product Speight working space. So there's the first page here and it is now the overview of the review process. And then the second page is all of the proposals or links to the proposals. So again, just kind of an open call for anyone who's interested in doing reviews. They are here there's a overview or a template of how to do the reviews here. And I think Santiago had just popped on Santiago, we're gonna prioritize the ones for the Spanish group by the end of this month.
All right, anything else anyone would like to touch base on?
Yeah, there have been some questions in the product room about the product core definition. I know that's not something we've looked at in a while. I'm not saying we need to necessarily put it on the agenda and have a long conversation today. But it might be good to have a stance coming out of this group about what our plans are with that definition.
Yeah. Mats, as of the end of last year completed his first pass of research. And one of the final tasks he had was to get all of that into a public space on the wiki. So I will put we can pull that in and into the working group space. The whole point of getting all of that research into the public space was that it's there as like as baseline competitive research for folks doing like research for new new areas of the product or want to look at competitive research for for anything. And he focused on like, what I think would be the first set of core features that we want to include, which is all focused on teaching and learning. I think in terms of defining it from there, there's maybe our next focus would be on identifying areas where there's duplication. So for example, questions around like cohorts in teams, for example, do we need both of those features, the research is there and it's now it's a matter of like developing a point like digging into the research and looking at developing a point of view on it. And so, maybe, I mean, I don't want to there's already so much on the plate for redwood. I don't want to pile even more on to it, but maybe looking looking ahead to like future releases. We choose one or two areas per per release and focus on developing a point of view and it's like a deprecation process if we need to. And we can do it. It's kind of section by section where there's areas of duplication in the core content grouping is one assessment is going to be a key area of focus anyway for sumac and so are most likely 2025. So that can be another area where we can do quite a bit of deprecation. But I think doing it kind of iteratively in small chunks or focus areas of the platform is is maybe the way to tackle this and make it look kind of like a sustainable project.
Okay, I think that makes sense to me. So I feel like the answer to the questions that were asked is we've done market research and here's a link to all of our market research. And now we need to take the next step which is synthesizing all of this research and coming to an opinion about where we stand for core product. Does that seem right? That seems right. Cool. Is that stuff on? The wiki? Because I can I can reply to that.
Yes, let me find I'll find the link and I'll send it I'll actually just put it in the agenda.
That sounds great. And so then I think the next question would be, how does this group begin tackling that and maybe that is something that we could discuss in our next meeting and Farmout some work? That
sounds good. Cool.
Santiago.
Yes, I have a question. Of the related with with this thing is the revision approval process. Right now we have in this confluence document with the process to review and approval proposal. But I think that we have to specify better the mechanism of both I think a How can in in the pilots that we already do that we already did. We just discussed in our conflict and post and at the end we come into an agreement between the two parts to you people and community people. And it's like, self approval is like a soft agreement of the future. Or the future. We in that code in that pose. We come up with a solution like okay, these could these loops, okay. And we think that these should be in the core product. That's the conclusion but I think that we can we have to improve that mechanism of voting. I think in these meetings may be a I don't know. A How can what is the mechanism that we use to come into a conclusion and approval on not approved something? Yeah,
actually, and actually like now is probably the right time to think through that matter, right. Everything through that mechanism because to you and Alex are no longer reviewing things. Like that's, I think that's pretty, like well known and documented at this point. And so that the kind of soft approval process that we had initially laid out when we did that prototype is I don't think we can rely on it anymore because we're not going to get the input that we need anyway, from edX to you. And so it's kind of like an opportunity for us to maybe redefine what approval could look like, like consensus based approval, maybe that's driven by court, the core products framework or something. And I think like Santoyo you didn't actually put forward a proposal of like, that was more consensus based and so maybe we go back to that and we look at that as a as a starting point. Instead, I think it's it's better than having to rely on like the repo owners. If that makes sense.
If I understand a is a a axiom on the community will not longer to approve things. Just to you
know, the other way edX and to you aren't, are no longer doing any reviews and so it's up to the community and axon that's up to the community. Really to drive decision making forward.
Yeah, so who is the owner of the repos right now, if it's not to you,
you it's, oh, it's an open quote. So it's like it's an open question around the maintainer ship. I don't know if Serena is if you have more of a insight into what that current like, I know it's kind of in transition at the moment.
Okay, okay. Okay. Okay, Arca,
we have to there's just a lot of work that needs to be done. Just like kind of in all aspects of the project. And the work that needs to be done around maintainership is we need a a more formal program, which we are starting. We've been calling it the pilot program for a really long time. And I think that that didn't really incentivize a lot of people to participate. Well it's not a pilot anymore. We kind of know what it means to maintain a repo and we are going to need people in the community to maintain repos. And if people in the community don't want to maintain repos, we're gonna have to think about not having that component in the system anymore. I mean, that's kind of the way it's gonna go.
Okay, yeah, I'm just saying so we are going to create a framework to define who is going to be the owner of each repo, but is still a work in progress. Yeah.
Cool. I don't think owner is the right word. I wouldn't use the word owner. There's maintainer who is responsible, ultimately forgetting things reviewed and getting things updated. But we as a project own the direction of the project, and particularly the product working group, own the direction of the features, but not I don't think anyone I don't I don't want to use the word owning when we're coming to a specific repo.
So do you think it makes so the way we had sort of gated the decision making process before was that we needed final approval from the repo owner of a PR you know, if there was a end user facing feature attached to it? It sounds like maybe in this new framework, that's that's not the right way to think about it. Right? Maybe it's more of there's a product driven decision around inclusion of the PR or inclusion of the proposal under review, and that is like a recommendation made to the maintainer of the repo and that kind of that recommendation drives the decision of who's ever maintaining the repo about whether they incorporate the PR or not.
Yeah, I think that's correct. And I don't think it needs to be the case. If, say a repo has two maintainers, but they have 17 core contributors. Like it doesn't need to be the case that those two maintainers have to look at every single poll requests. The core contributors on that repo also have enough stake in that they are allowed to press the Merge button for a pull request. They say they deem meets the requirements for being included in that repo
do strongly agree with that, that he made that rule? I'm not sure people know that right now. I just read some comments and and yet, we're unsure how to get some approvals in areas because from the problems we just mentioned, so that will probably still have to be announced in publish, I think, right sign up.
Yeah, and it's a solid question about how to expose the names of people who are core contributors to a given repo. I know Michelle talks about this a lot. She's like, I don't know who can merge to a repo. And it's like, we don't have a great way of looking that up. I mean, you can you can go to the GitHub people's tab and you can search for a user name, but that's like, that's not great. You don't want to search for like 20 usernames to try to find one who can merge to a given repo.
I just want to check if I understood. It repo will have a container or two containers, but the approval at the end will come of those two containers or from the core contributors that are contributing to that repo in like a kind of voting process or something like that.
Yeah, that's that's the way like there's our steady state should go but we have some steps to get there and we have, you know, a lot of community members who are going to need to step up and start volunteering to maintain repos and to become core contributors. Yeah, totally.
are thinking about how like how product can can help with the PRS that are attached to like, end user facing features. And maybe in terms of the steps that we take in the review process of the proposals. We focus on like making recommendations right about whether something gets should should get maintained or get merged into the repo or not. And that recommendation stays then with that set of PRs all the way through getting to the point of being implemented or merged. And then that is like the data that who's ever maintaining the repo they the data that they need about whether it gets so like the product recommendation comes with the PR right when it gets to the point of being merged. Into the repo. And so there's not a question about whether this PR is, like valid or not, right? It's already gone through the approval process. And so, at the stage of like reviewing all of the proposals, it's we need to get those proposals to a point where there's like the product recommendation about whether it's included in the core of the product recommendation about how it's implemented, and you know, how the approach is implemented, that stays then with the PRS to the point where they go to who's ever maintaining the repo and then all that data is there for them to to merge or to not merge?
Yeah, I think that makes sense. I think we're in sort of, in between state where it's not clear, who's maintaining every repo, it's not clear who are core contributors on every repo. So I think a lot of this especially for the high value, quick turnaround things is going to have to be somewhat of a manual process. But I actually, in some ways, kind of prefer a manual process to start with, because we don't necessarily know everything we're solving for. And if we do, we try to like connect everybody manually, we'll get to a point where we're like, oh, we really needed XYZ solution to like make that go faster than we can just implement the right thing.
That makes sense. So the brook approval is just like a suggestion. The maintainer decide. Take the final decision, right.
I think it's probably stronger than a suggestion. Right? It's like it's a recommendation. Yeah. And, and I think we can probably Santiago, we should look back at the templates, like the documentation for how to do the reviews and we should, we can change some of the wording there. So it's no longer contingent on like the owner of the repo but it's more contingent on like the product recommendations.
Yeah. On Demand Junior can a reject the VR because of technical things. I think not. To the pro thing because the recommendation is clear. Or maybe because product ideas and we have to come back to the product review. Yeah. Yeah, okay. Yeah, I understand. And a, who is going to be the the heartbeat of these brainwork new framework, approval process.
What do you mean like who's going to
you? Like the owner at the responsible person of a pushing this project within this framework? To create it.
You mean to create that review process? Yeah. Yeah.
These processes, assign maintainers. Assign core contributors to each repo. That part is, I think the hardest part.
I think, yeah, we have a working group for this. It's called the maintainers working group. So we're just I'm not even sure you've had our first meeting yet. But these are some of the problems that we seek to tackle.
Okay, cool. Cool. Understand.
As far as the the it occurs to me, Jenna, that as far as like the product recommendation goes, I mean, that's kind of what the product requirement like roadmap ticket is you know, like, as long as that is linked in the in the pull request description, you can trace back, the thought behind it in the fact that the product team of the Open edX project really wants this and that might be easier than like having to go in and comment on pull requests.
Yeah, I mean, that's the ideal process, right? Like if if there's a review that does happen before the code is implemented, that's the stage that we want to get at right for everything that's being contributed. Anyway, I think there's still PRs that are coming that have not gone through the PR process the review process yet. So we're kind of in this like half and half state where we've got reviews for product you know, some products product features that haven't been developed yet. And we still have PRs coming in from stuff that's already been implemented. So we're kind of like in this half and half state.
Gotcha, that makes sense. I will take an action item at the maintainers working group to bring up the sort of like how are we how are we matching reviewers with pull requests? And also how do we, how do we allow a pathway for the product team to say, this needs to go and read would this needs to be prioritized? And how are we like balancing that because it's like product might say this needs to be prioritized, but we might go Yeah, but we need this Django 4.2 upgrade. Having like, an open path for conversation around that is going to be something that's unnecessary.
Yeah, but I think that when the maintainers are assignment to the rebels, these will be like part of the conversation part of the process. detail of versions, those things will be easier. Yeah, the hardest part is the motors.
Cool, that working group is Thursday. So I won't forget, I hope at 830 in the morning, so maybe I'll forget but I'll try not to. Cool.
Do you want to maybe report back at the next working at the next product meeting as well? Yeah,
absolutely. Cool.
These guys have a good face. Thank you, Serena.
Awesome. All right. Anything else?
Just if you need something, a you can count with me with time or whatever you want.
Awesome. Thanks, Santiago.
Yeah, I think the one thing I'll say for people, I guess we have two organizations represented here. We'd like to make sure that each organization is represented in the maintainers working group meeting. So that's Thursday, this Thursday. Every I think it's every other week. I think we're actually doing async and we do synchronous once a month, but this one on Thursday at 8:30am. Eastern Time. It'd be good to have representation from at least one person from every organization that we've gotten the community so if you've got somebody who could attend that would be great.
Nozaki none of your engineers are interested in maintaining
none at all.
All right. Well, if nothing else, we will we can end five minutes early and see everyone in two weeks
