likewise the distorted one so thanks so give me a second to go find somewhere else.
While we wait for Jenna to find a new spot I can throw the agenda in the chat
right Can everybody hear me? Yes Perfect. Yes. Yeah, I'm in transit and I found like the perfect quiet spot and then as soon as I signed into the meeting some new construction noise started. So that was awesome. Cool. Thanks Chelsea for sharing the link there. One more minute to join
just did you want to actually sharing your screen with the agenda?
Not at all
can everyone see it? Yes, perfect. All right.
Well, so it should be a fairly straightforward meeting today unless somebody there's two things that I wanted to cover. Oh, awesome. Thanks. Um, so first is just a quick update on the product proposal process. Since you and I have been working on this, we actually did a presentation to the Open edX community meetup last week, which is awesome. Resulting have a an updated set of guidelines. I also wanted to just touch base on the cutting edge which is which is awesome. Anybody like any anything else?
Okay, cool. Um, so just a quick update on the proposal process. Just if you don't mind clicking that link there. The review process is in the context of presenting to the community made up last week, we came up with a more clarified set of guidelines and how the review process works. So I've linked this here. Just want folks to have a chance to take a look at it over the next couple of weeks. And what we're trying to land on here is a clear set of guidelines around what needs to be reviewed when it needs to be reviewed and how that review process happens. And so the goal for 2024 is to basically get everybody in the community on boarded onto this process so that we can completely shift the LSPR review process left, which means we'd be getting proposals coming in before any code is implemented. Which gives us a chance to do the review and make sure that projects are being implemented in a way that aligns with the platform strategy. So just wanted to let everybody know that your document exists and if you have a chance to give it a review and estimation on Santiago, anything you'd like to add to that
no, no right now, maybe. Maybe now that everyone's know that these exist. People here in this group who help us to review new Pro proposals. I think that Yep, we have some in the in GitHub,
I think. Yeah, there's a link at the very bottom. So all of the proposals that have come in over the last like, two two months or so. It's it's been quite successful in many ways. Like we've we've been almost too successful with it and that we now have a whole backlog of proposals to get reviewed, which is really great. They're organized at the moment and a folder and every it should be clear what the topic of every proposal is. So if there's one that jumps out to you, one that you're interested in for your own clients or for your own use cases, and you'd like to take a look at it, please have a review of it. Add comments into the wiki and that's that's sort of the way to get involved.
The second thing I wanted to just let this group know about is we wanted to get a regular release planning group up and running. And so Redwood is going to have a lot of new features coming coming into it including tagging, thinking, some of the new work around content libraries, including aspects v1. And so we wanted to open up communication dialogue between the product Working Group and the build test release group really early in the process, so that we're not scrambling. You know, come April May, at the end of the release to get stuck. In. So there's going to be in January, kind of like a kickoff meeting for this. If anyone in this group is interested in joining that. Please join that slack thread. The goals for that group again are to kind of align VTR and products on getting the release out the door see where we can streamline communications, see where we can better like basic core products philosophy into that release, and also involve more community stakeholders who are likely to be early adopters to the processes more informed any questions or comments about that?
Over to the VA and let the release management and I can just that's helpful. Sure well, I don't have a lot of details on on this one. So I don't have anything specific to share. And it's actually not exactly my point. It's more something that I promised that I would come to mention. My Cheese away. It's more points and that comes from the contributor meetups and sprint updates. There have been a couple of long discussions around how MFE is being released. With with a few issues over the last iterations of this so again, probably others will be able to talk about it this much better and also in in the BTR. Group. But basically, the here seem to have been that some of the MFPs have been brought up, but haven't necessarily followed all of the criterias around like, what do we expect an MFP to do and etc and may be that to your to the point China in terms of the way the project working group will be following the additional new features because employees are just one of those features. And on to the second point because PTO working group is actually often the ones scrambling at the last minute to make sure that everything works correctly. But one of the points during the discussion is that it seemed to be my central coordination point or at least a way to check that any new feature any new MFE being added. Those follow the criteria that that we set as a project back, maybe the developers would be bringing up might verify some of the technical aspects, but it might not deploy into turf for example, or it might not have been tested a certain way it might not have translations, these kind of things. And so yeah, like the generally the discussion was very about the fact that having some kind of person centralizing and checking that the feature is The MFE or any feature actually being added will actually follow the different criteria that we have in place seem important and that currently there isn't that and the reason why I bring it here is that one of the points during one of the suggestions would have been that this could be a good thing to have a project perspective on. So people weren't sure if that meant that that person would be a project manager. But that at least in a number of cases, the product perspective was missing on that. So again, that's where it probably ties into the year two previous one, Jenna because that's sounds like part of what the the product review process is meant to address. But there might be like a specific perspective to keep in mind for admin fees which have like a lot of points that the third, we do a lot of them and so again, not necessarily my point. So I don't know if anyone has questioned if I will be able to answer everything. But I promised I would bring that up because that has been like a recurring sell point for multiple members in the group and in the BTR working group. So yeah, I just wanted to know what you demand and deny if you think that fits into the product review and if so, how and then I'll bring it back to the rest of the
Saatva Yeah, I think it actually ties directly into the idea of this revenue release planning group. I do think products does need to be more involved in The MFE process, but it's got to be more of like a coordination between somebody from products, somebody from The MFE Working Group and probably somebody from VTR as well, which is exactly what this regular planning group is intended to do. And maybe that's our first specific agenda point with that group is landing on a set of criteria for what's what MFE standards and NFV needs to meet or at least that's a topic I've kind of touched on a little bit with a dolphin in the past, but I think we need to get to the point where they have clear guidelines for that like guidelines that are as clear as the product. And I think it's actually the right one to do it because we'll have perspectives from products from DTR. The MRP as well. Is there in the context of the committer. What are their hopes from that group who should be involved like who is who have brought this up in the past or anybody you think should be involved in that group?
Probably, I mean, like you mentioned, there is a lot of ties into the BTL working group. So there might be also folks on on that side. I don't know. But I can definitely make sure to ping when people would need to check the notes because that was a few weeks ago, well was the most impacted. But, but yes, and I know that there were plans also around that because it was presented in the organization and he had mentioned that there would be probably a meeting around the planning of the next release around that. So that sounds great. And that sounds a good first step. I guess the following question would be like, will we always land that in the in the context of a specific release? Because I see the reasoning in in the sense that it's often scrambling to release it in a specific release that that creates the the urgency. That said, I'm guessing that this will happen for a number of features. And do you see that, like the PTR working group plans and planning for Redwood thing with the previous point, which is the project release itself? I'm guessing those are two sides of the same coin, right.
Yeah, I think so. I think one of the goals I think I'd like to bring for that group is how do we get release like feature releases to be more iterative and phased in the community releases, right? So that's kind of how that how it has worked in the past, right? It will these will happen on edX at any point, but then it eventually gets kind of punted to the community release, you know, six or seven days before the release happens. So I'd love to get to a point where we have like a set of criteria for when a new feature is being released into the core products. What's What do we need to do in order to accompany that and to make it iterative, right, so what release notes need to be written along with the release when it happens? So those aren't being put together two days before the release? What kind of documentation needs to happen, what kind of configuration documentation needs to be circulated? I'd like all of those things to happen when new features are released in and of themselves, rather than just, you know, put into the community release so that we have all of that stuff built up over time. Over the six months and six months. Between releases rather than leading straight to
see, do you see that list of things that need to be done on a specific feature be something that is brought up during the product review or is that a separate process because it is true there? Is a product path and but there might be technical paths? And they might not all?
I think it can start with the product or the process but there's got to be a follow through with that as well as calling this once it's time to write the technical documentation. Um, so it may actually be that this is an extension of a specific product tools process as well. And that would be a good time to start looking at looking at that as long as we as a community instance running rather than working at EXPO
I couldn't completely am because that was working. At least a little bit for me. So you were saying that we will be starting with probably with the product working group. So in the product review, and that would tie into the list, but that would probably be another list that would be prepared separately and would that be from like multiple PTL side? That's about I couldn't get?
Yeah, I think it would be a combination of btrn products and maybe we extend part of the product review process and have like a part to like a sequel. And we have a set of guidelines for like product releases. So what needs to accompany a product release there needs to be released. notes written from a product perspective, there needs to be some sort of like demonstration video. For more marketing purposes. It needs to be technical documentation, or it's the documentation around configuration. Those would fall more on the BTR side or whoever the technical team for the feature is. But I'm glad you're bringing all this up because it's illustrating that we need the same sort of guidelines in place for product releases as we move on to so you know that it makes sense to me that that would start you can start that conversation in the context of planning for redwood and then use that as like an experimental space see how that lands
Alright, that makes a lot of sense to me. I'll make sure to your previous question that the people that that were most impacted by that and mentioned it in the in the meetup inform the first of what we just said there, and that they didn't know also how to join the meeting in January. So you mentioned the best way for them. That would be to go to the Slack channel. Is there already a data meeting setup that I can pass on to them? There's
a poll and that slack channel for us to pick the person indicate which would be in January sometime.
All right, sounds good. Thanks, Dana.
And VMFS. And just as a side note, like the NFP plus is gonna be really critical to read what as well, because all of the studio MFPs are likely going to be landing in Redwood hopefully that as the goal. And so the earlier we can start the conversation about like, which what kind of standardization so we want to be able to meet the MFE inclusion in the community that is better so that we can hopefully get the Studio
makes sense because usually it's true that right before the next release, and that's exactly the wrong moment to have this conversation. So Yeah, makes sense.
Thanks for bringing that up. All right. Is there anything else anyone would like to add to the agenda?
Nothing else then we can give everyone back about half an hour of time. And just ask that everyone takes a look at the guidelines for the product review and we will have space on again in January.