Identify MFEs and new repos earlier and review the processes for enabling them. Advocate for better documentation and easier configuration while thereās still time to make changes.
How do we make sure strings in frontend-app-communications are sent to Transifex?:
These are included as official in Olive.
The message are properly handled in the code, but they are not being pushed to Transifex.
FE App Component is another issue, it is not tagged as itās a library. Thereās also a bug for this library that needs to be address. Adolfo Brandes has context on this issue and will investigate.
Usually this means we will push out the acceptance dates/leave things in āproposedā until we have a good solution/migration path for the people affected.
Demo of open-response assignments with custom rich text editor via Summernote
Abilities to download, save, and write multiple drafts
āBackpackā functionality that allows you to save and retrieve student data from earlier open response problems. Thereby allowing you to have a kind of first-draft, second-draft, and so on system.
Resources:
Course Template Builder with hx-js and backpack included (easiest method): HX Template Builder
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.
OpenCraft
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.
RaccoonGang
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.
Next quarterly conference proposal: Bett in London
TOC nominations will start on August 29th - please look out for the blog announcement next Tuesday and help spread the word to get more voters involved
Looking for recommendation on voting apps - we used CIVS last time
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
Latest news
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:
LWMOOCs conference (October 11-13) is accepting Poster Submissions
Reach out to Mary Ellen Wiltrout on Slack or via the LwMOOCs website: IEEE LwMOOCS 2023
Would anyone like to highlight any past or upcoming events? Let us know in the comments!
3. Projects
Are there any new or ongoing projects youād like to discuss? Get the conversation started in the comments below.
Took part in the Aspects beta redesigned the arch approach for flexible groups in the campus initiative reviewed the Hide from TOC proposal Reviewed PRs #33059#33006#33219
Felipe Montoya
I worked on Lowfi Wireframes for the LTI MVP.
Cassie
Attended part of the Developer Experience Working Group meeting (Sep 11) Attended the Open edX Community meetup (Sep 7) Browsed through Slack and Discourse. Translated / Reviewed strings for fr_CA in Transifex for the edx-platform project. Got access to the openedx-translations project in Transifex. Translated / Reviewed strings for fr_CA in this project. Because I am one of the only contributor with an instance of ecommerce I tried looking at [ECOM > Create a course seat] > After creating course I am not able to open its detail page Ā· Issue #301 Ā· openedx/wg-build-test-release Ā· GitHub.
What do you plan to work on in the upcoming sprint?
User
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.
Pierre Mailhot
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?
@pdpinch I see that @Michelle_Philbrick is already on it, though it looks like we still donāt know who can review on this. Similarly to my comment above to Braden and @itsjeyd ā do we have a way to tell who has commit rights and can give a binding on the repo? And @pdpinch any suggestions on who could be a good reviewer for the PR, even if they donāt have the rights yet? From Contributors to openedx/frontend-app-gradebook Ā· GitHub I also notice that @kmccormick has some commits on it - maybe you can help? CC @arbrandes too since this is frontend.
@sambapete I see that you have been able to make progress on this, and got help from @regis - great!
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.
For frontend-app-learner dashboard, the Aurora team owns that repo and is slated to take on maintainership for it in the current phase of the maintainership pilot (final confirmation pending).
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.
Aside from core contributors that are members of frontend-all, Sofiane Bebert has write access to the frontend-app-gradebook repo according to the wiki.
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 Sounds good I had been meaning to check in with you about the status of recent conversations about labeling, so this update was very timely Thanks!
@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?
Latest news
:
quince.master
quince.1
Meeting notes
Anything to add?
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.
Thanks!