Researched MySQL HA options to run inside Kubernetes. Jhony Avella will create an issue to open the conversation on this topic in the Harmony Project
Experienced problems hosting ClickHouse in Kubernetes because of the amount of resources it consumes. An external machine running the service was implemented as a workaround, however, other options like using a ClickHouse cloud service could be considered.
Jhony Avella worked on fixing issues related to infrastructure creation on Harmony PR 41. He will work on the Karpenter implementation through Helm.
Exploring Kompose as an option to bring developer environments to Kubernetes.
Worked on Grafana dashboards for monitoring.
Gábor Boros already provided feedback on the PR 41 in harmony. Some comments are still pending to be addressed.
There’s no ETA for the assessment to determine if the Harmony project could be used in production installations.
Working on running ClickHouse and superset in Kubernetes.
Analyzing alternatives to deploy production OpenedX instances with minimum resources. Some options include the classic Kubernetes Local installation and Kubernetes deployments with lighter K8S distributions (K8S single server?)
Testing Harmony to deploy OpenedX. Positive feedback was provided.
Problem to solve: How to extend MFEs in business specific ways
Ed is going to schedule a summit to propose a specific recommendation for solving this problem.
1.12. Product Working Group
Chair: Jenna Makowski
UX/UI Working Group
Jon Fay from 2U took us through the latest version of the designs for the new Studio Home page (feel free to leave comments and questions on the file). A few things we discussed:
the UX for filtering and sorting courses,
when course end dates should be displayed and when they might not be necessary,
what type of content is searched when the user enters text into the search bar.
Santiago from EduNext ran a mini usability test with Cassie from OpenCraft. The test focused on 2 of the main user flows within the Content Tagging MVP:
One: the flow in which content authors add tags to units,
Two: the flow in which users search the course outline.
The test lead to some interesting realizations! EduNext will be conducting the same usability test with a handful of superusers, and Ali Hugo will then update the wireframes for the MVP accordingly.
Mobile Working Group
Since our last update, we have kicked off a number of projects in development and discovery. During our weekly meetings we have reviewed a number of documents as well focused on identifying the gaps between the edx mobile app and the new open edx mobile apps. Additional details below per project.
Mobile API Updates - #fc-0031-mobile-api-migration-axim-raccoongang
Development has started to update edx-platform and other services with the right API changes necessary to run the new open edx mobile application. (Approximate delivery date end of September.)
Quick Win Feature Gap Project - In Consideration
In consideration is a project that should close 13/38 of the feature gaps identified by edx mobile team relative to new open edx mobile apps. A few improvements to video experience (5/13), app upgrade messaging (3/13) and others are included here. Development sizing and product / design definition are in progress currently - Project - Quick Win Feature Gap List
Learning Site Selection - In Consideration
In queue for mobile development consideration, should allow for providers to build single apps for multiple open edx sites / clients to lower cost to offer a mobile experience to learners - Project - Learning Site Selection (FC-25a). Initial set of product requirements and design mockups available on project page for review.
Other projects in consideration that are earlier in the requirement definition process listed below:
What do you plan to work on in the upcoming sprint?
Translating and reviewing strings for fr_CA in Transifex. Start looking at Quince since the cut for quince.master is now less than a month away. Build-Test-Release Working Group meetup (Sep 18). Translations Working Group meetup (Sep 20). Browse through Slack and Discourse as usual.
I will likely continue my work on adding type hints to the platform.
@jalondonot Maybe a solution to this would be to include someone from the BTR working groups in reviews of new repos & MFEs going forward? @itsjeyd Do we have a way to implement this for all PRs with our current processes? I’m guessing we currently only have a formal process for the OSPRs - but maybe we should have one for all PRs, to enable things like this?
Actually, another blocker reported by @pdpinch could also benefit from that:
We have talked about introducing a bot for helping to manage OSPRs - maybe it could help more broadly, by suggesting/pinging reviewers based on the code that’s being modified?
You’re right, we only have a formal process for OSPRs right now (at least as far as I’m aware).
In that context we could consider making it part of the workflow to ping members of BTR working groups on PRs for new repos and/or MFEs.
However, to avoid introducing another source of ambiguity with the potential of slowing things down, @Michelle_Philbrick and I would need a concise reference on who to ping for which repos/under which circumstances.
In terms of implementing something like this for all PRs, I’m not sure where I would start with that to be honest At least if we’re talking about manual steps to add to PR review workflows, I think it would be challenging to get all teams to adopt and consistently apply those to the repos that they own. Offloading this type of work to a bot (as you suggested) would probably be a better option here.
As far as core contributors go, the wiki doesn’t mention anyone having access to the frontend-app-learner dashboard repo, specifically, but aside from Adolfo there are two more people with write access to frontend-all (Brian Smith and Viktor Rusakov); they might be able to help out.
Good point. @pdpinch what do you think? Would you be a good person to ping in these cases?
To be eventually able to treat contributors on an equal basis, we will need to treat all PRs the same - we are still a few steps away from that, but it could be good to start thinking about how to approach non-OSPR PRs (which are basically the 2U PRs right?). Ideally, once we have solved current issues, neither categories should require much work from you – only supervising it to ensure it goes well, and that nothing gets forgotten. Maybe the MFEs PRs could be a first step in figuring that out; introducing reviewers outside of 2U on those PRs would probably be the main element to figure out.
@itsjeyd Ah good point. Are there things that would help you or @Michelle_Philbrick to get automated through that bot – for example having the bot suggesting/assigning/pinging reviewers based on the code that’s being modified?
And related to this and your last answer – it looks like currently it is a bit tricky to tell who to ping on some parts of the code. Maybe having to specify this to a level that a bot is able to ping people on its own would help simplify things, too?
Non-OSPRs are PRs coming from members of 2U and Axim.
At the moment, @Michelle_Philbrick and I aren’t monitoring non-OSPRs at all. The volume of OSPRs coming in is already quite large, and I worry that extending the scope of the OSPR Manager role to monitor non-OSPRs as well would have the opposite effect of what we’re trying to achieve (= getting PRs reviewed and merged more quickly), at least in the short term.
Since this conversation started from a concrete issue pointed out by members of the BTR Working Group, it would be great if they could lead the charge on defining what their ideal process would look like?
I can’t speak for @Michelle_Philbrick but personally I would be happy to review the outcome of that work and provide input from the perspective of OSPR management as necessary.
But considering the points mentioned above (= volume of OSPRs to manage and ongoing efforts to resolve bottlenecks in existing processes) I don’t feel I have the bandwidth to take on this work myself right now.
Definitely! Right now, information about who to ping is spread out over several resources – a few public wiki pages about the CC and maintainership programs, Open edX Backstage, and a spreadsheet that is available to Michelle and me but not the wider community. For maintainership specifically, information from the wiki and Open edX Backstage overlaps to a large degree but last I checked the wiki seemed to be a bit ahead of Backstage.
If we could unify the different resources somehow and find a way to make the information that they provide more discoverable (e.g. by having the bot surface it on PRs like you’re suggesting), that would be great – it would not only help Michelle and me in the context of OSPR management, but also empower PR authors to get in touch with reviewers themselves.
Hi @antoviaque! Re: triaging 2U PRs, I don’t think that’s something the Community Project Managers should be responsible for, to be honest. That would be a full-time job for someone, and I’m not sure we should be triaging 2U’s internal PRs (which we don’t know anything about - they also include blended projects specific to 2U). I don’t think this was ever really on the table for us to do. I know I don’t have capacity to do it.
The Community Project Manager role was to make sure our community contributions were handled promptly, and that contributors were welcomed and helped along in the process. Maybe this is something we can confirm with @e0d ?
@itsjeyd@Michelle_Philbrick To clarify, I’m not suggesting just extending our current OSPR process to all PRs - that would definitely be too much work. If anything, I think we need to make sure you both have less work to do, by automating things like pinging the right reviewers. Imho it would be a better use of your time to allow you to focus on things like escalating PRs that don’t get attention, or monitoring the time it takes to merge PRs to proactively suggest improvements – ie things that actually require human attention and inventiveness.
My remark about non-OSPRs is more about the fact that rules should apply uniformly within the community – so for example if we say that we should have a documentation review step on PRs creating an MFE, this should apply to all PRs, not just OSPRs, and having a single process that applies across the whole community would help to ensure that. And this way, if we make changes to the bot, to the merge rules or the review process, everyone is affected and benefits from it equally.
@itsjeyd Would you have enough information currently to be able to suggest a way to unify these resources, and write a proposed specification for the bot to automate this? @nedbat has mentioned CODEOWNERS as a possible approach. If not, what are we missing?
@antoviaque I feel like I have a high-level understanding of the available resources and how to use them to get the info that I need for OSPR management. But I don’t have a detailed list of things that are currently missing, redundant, or maybe even inconsistent. So as a next step it would make sense to have a closer look and document that. I was going to do this in the context of Faciliate monitoring and guiding of OSPRs · Issue #103 · openedx/wg-coordination · GitHub – the third and fourth item from that issue are precisely about this topic
@antoviaque Ah, ok, gotcha. Automating pinging of the correct reviewers would be amazing! I’m not entirely sure how the bots work, but I’m guessing we’d (all of us in general) have to make sure it stayed up-to-date (e.g. if someone leaves a 2U squad and another person takes their place, the bot would need to know to send it to the new person / someone would need to update it). Still an awesome improvement, but maybe something to consider?
@itsjeyd let me know if I can help with anything related to any of those items #103 / #104!
As far as CC’s reviewing OSPRs (which would be awesome–especially for edx-platform), we still need to clarify with 2U how that would work. There’s a gray area of what’s OK to review / merge if 2U hasn’t gotten to it. For example, if a squad is at capacity, or they haven’t responded in 2 weeks (or longer), the PR might still be something they would want to know about / review before we have someone step in and merge it – BUT, unless they tell us that, there’s no way for us to know.
For me, this is one of the biggest issues at the moment. It would be great if squads could at least peek at the PR and if they don’t have time they can tell us to hand it off, but without good communication I see things getting messy. Right now, months can go by with no response–Kelly and Ned have been super helpful with the stalled PRs, but it shouldn’t get to that point. I think by formalizing it somehow it would be beneficial to everyone, especially if there are agreed-upon guidelines for who can merge and after how long.
@Michelle_Philbrick Agreed, it’s important to have good prior communication on this, whether it is when the PR comes up, or preemptively ahead of time if we know there might be times where timely communication would not be possible. We don’t want to surprise anyone!
The best would always be to be able to communicate quickly on individual cases – this way we are always sure. But yes, the crux of the issue here is that it is currently unclear what should happen when that quick communication can’t happen – right now it just goes to the default, which is to block everything.
Maybe it is actually what some of teams that don’t/can’t answer want, to block everything until they can come back. But maybe not, and they would be happy to pass on the judgement call to someone else in these cases? Independently of what we think the rule should be at the project level, as a first step maybe that’s something we can discuss with individual teams, and see what they think? Maybe we could do a concrete proposal to handle these cases – what do you think would be most important to get buy-in on?
@antoviaque@itsjeyd - Heads-up that today at Maintainers Office Hours we (Ed, Kelly B., Ned, Adolfo, Jeremy B., and myself) discussed possibly changing the way we label / handle maintained repos vs. unmaintained repos. Essentially, some 2U teams aren’t seeing all the PRs they’d like to see in one place, so they’re trying to solve for that, as well as for ironing out the issue of when CCs or other reviewers can step in for non-maintained repos (especially since some of them sit open for so long).
Obviously, in an ideal situation, all repos would be maintained (which we hope to get to), but for now, we’ll probably need to change things up a bit in order to get things pushed through and not stalled waiting for reviews.
Nothing has changed for now, so @itsjeyd we’re just continuing with what we’re doing. This is just a heads-up that these issues are a priority for everyone. Axim / 2U are trying to work out some potential board / automation items for GitHub to solve for what the teams need as far as views across several different boards. After that gets worked out, it will be more clear what you and I need to do going forward.
@Michelle_Philbrick The fact that it’s not an OSPR is due to it being opened by @FarazM ? It seem to come from @regis and fixing an issue @sambapete had issues with, and that he brought up in a core contributor retrospective. Maybe they can speak better about its urgency, but it seem to be a contribution of interest to the community - is there something we could do to convert it to an OSPR?