Xavier led the discussion with the team, which included participants from various locations such as South Africa, French Polynesia, India, Iran, Brazil, and the US. They discussed follow-ups from previous meetings, including persistent grade issues in the form. Dave offered to connect with Peter later to check on the issue. They also discussed the OpenEdX survey report, with Jorge mentioning that they were working on the implementation and hoped to share the final results soon. Xavier asked for input on the two options for accessing the stats report for individual instances.
Increasing User Feedback and Community Engagement
Xavier discussed the need to increase visibility and create opt-in ways for users to provide feedback during installation. Ed proposed the idea of a campaign to encourage community engagement when the new feature is ready for rollout. Xavier also mentioned the need for more channels to reach out to the broader community. The team discussed the possibility of a beta testing program to involve users in the development process and decision-making. OpenCraft asked about the incentives for users to participate in beta testing, to which Ed responded that users get to be part of the steering committee and have their voices heard. Xavier emphasized the importance of providing privileged access to certain users.
Progress and Plans for MF Projects
Xavier and Adolfo discussed the progress and future plans for two projects. Adolfo mentioned that the team, including Brian Smith and interns, is working on fixing the learner dashboard for the MF, which will be ready for Quince. Additionally, Adolfo said that the MF will be the first to use Atlas in a release, with the help of Brian, Omar, and himself. They are also planning to introduce a plugin architecture for the MF, with details to be finalized in the coming months. The team is still working on these projects, so it's not guaranteed that they will be ready for the Quince release.
Summit Outcome Concerns and Proposed Solutions
Xavier expressed concern about the outcome of the summit, questioning how to prevent multiple implementations from persisting. Adolfo clarified that no decisions were made at the summit and that attendees were assigned tasks to propose unified solutions for all discussed use cases. Braden and Kelly's teams have proposed course authoring and learner dashboard solutions respectively. Adolfo stressed the need for further exploration and development of these proposals, aiming to unify the Learner dashboard to address most of the discussed use cases. Adolfo, Xavier, Ed, and Xavier reviewed the project's progress and future plans, agreeing on an iterative approach with Adolfo's team developing the general direction of the learner dashboard. Ed emphasized the significance of having operational code and testing it in production, which everyone agreed upon regarding requirements. Adolfo made it clear that they were not working on Quinns but a different project, intending to achieve version 1.0 of the architecture or Plugin API within six months. The team also emphasized the need for caution to prevent multiple implementations of the project.
MF Documentation and Challenges
Adolfo and Xavier discussed the need for documentation to convert from Server side render templates to MF. Adolfo mentioned that there is a list of requirements for an MF in the wiki, which is being used by Brian Smith, Cindy, and Menna to check the Learner dashboard against. They also talked about the challenges of keeping MFs up to date, particularly due to breaking changes in upgrades. Adolfo expressed hope that these issues could be solved with the help of pyrol down the line. Xavier suggested that this list could be linked to as a preemptive solution to problems when getting an MF upstream into the main version.
MFS Dependencies and Documentation Review
Adolfo discussed the common dependencies between all Mfs and the necessity of updating them whenever the main app shell gets a library bump. Xavier raised a point about review level and documentation, proposing that there should always be a reviewer caring about the documentation when a new repository or Mfe is introduced. Ed emphasized the importance of capturing the work in a way that is actionable across the community. Adolfo outlined the current process for introducing a new MF, which includes a long-lived ticket with requirements and an implicit review process. He suggested that the ownership of these issues could be better handled by someone more product-focused, as they could coordinate translation efforts and features. The ultimate test for an MF is through Btr, where a plugin is made for the MF and added to the Test Plan.
Preparation Process for Releases
Adolfo expressed concerns about the current process of preparing for releases, noting that the workload becomes too heavy in the last two weeks before release and that the Pr (likely Product Release) comes only a couple of weeks before release. Adolfo suggested that this could be improved by having a single owner for each new MF (likely Machine Framework) to help coordinate efforts. Xavier and OpenCraft discussed the possibility of assigning a product review ticket for each MF, but Adolfo admitted that he wasn't sure if this would work. It was also noted that Adolfo hadn't been to the product working group in a while, and Ed suggested that the current process probably wouldn't change.
Micro Frontends Decision Process
Ed and Adolfo discussed the process of deciding which Micro Frontends (MFs) to include in the released code. Ed emphasized that the decision should be based on product requirements rather than engineering considerations, and suggested that the number of MFs could decrease over time. They also acknowledged the need for a group of front end architects to evaluate MF requirements and determine the schedule for inclusion in releases. Adolfo expressed difficulty in keeping track of new MFs and suggested that the Studio MF conversion be community-driven. The group also discussed the need for an agreement that core user interface elements cannot be deprecated in favor of an MF without a ready replacement. Finally, they discussed the lack of an automatic system to detect when a new MF is being worked on.
Edx Platform Feature Flags and Dashboard Discussion
Xavier, Adolfo, and Ned discussed the feature flags and the learner dashboard within the Edx platform. Adolfo mentioned the need for a new repository for the library that would implement a plugin architecture and suggested that they keep their ears open for new MFs. Ned revealed there are three repos in the Edx Github organization that start with 'front end app,' one of which is private. Adolfo suggested the idea of pushing for new MFs and other features, and OpenCraft agreed to bring this up in the group on Thursday. The team also discussed a new proposal from Jenna and Santiago about submitting contributions, with OpenCraft sharing the proposal in the chat for anyone to review.
Standardizing MF Development Process
Angie proposed a standardized process for developing Mfs, including criteria for identifying the owner of each MF and the skills needed for its development. Adolfo noted that some of these ideas were already present in the new MF roadmap issue. Ed emphasized the need to separate product requirements from technical implementation and suggested that product changes should be decided based on their efficacy. All team members agreed on the importance of measuring the impact of product changes. The team decided to further discuss these topics in the next meeting.
Next Steps
Adolfo will investigate if there is a way to detect when a new MF is being worked on.
OpenCraft will bring up the idea of having a product owner for new MFs in the group discussion on Thursday.
Ed proposed the idea of a campaign to encourage community engagement when the new feature is ready for rollout
Xavier mentioned the need for more channels to reach out to the broader community, such as an opt-in banner or news section on all Open edX instances.
Ali mentioned an upcoming beta testing program project to involve users in the development process and decision-making.
Ali asked about the incentives for users to participate in beta testing, to which Ed responded that users get to be part of the steering committee and have their voices heard. Xavier emphasized the importance for betatesters of getting privileged access to decision-makers, and becoming a reference among colleagues.
@Jorge Londoño mentioned that they are working on the implementation (option #1 in the django admin) and hopes to share the final results soon
Follow-up - How do we make sure strings in frontend-app-communications are sent to Transifex?
(and frontend-app-course-authoring, and frontend-lib-content-components that is using it)
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.
There seemed to be a blocker on the availability of Atlas for Quince, but it now seem available:
Follow-up - MFEs for Quince
Learner dashboard MFE future is uncertain. They’re still figuring out what to do about it. The idea is to get it ready for Quince
@Adolfo Brandes
Additionally, Adolfo said that the MFE will be the first to use Atlas in a release, with the help of Brian, Omar, and himself. They are also planning to introduce a plugin architecture for the MFE, with details to be finalized in the coming months. The team is still working on these projects, so it's not guaranteed that they will be ready for the Quince release.
@Adolfo Brandes mentioned that he, @Brian Smith and others, are working on fixing the learner dashboard MFE, which should be ready for Quince.
Outdated MFEs
From the last frontend meeting: “Many MFEs are stuck an old FE platform version because of breaking changes.”
Adolfo talked about the challenges of keeping MFs up to date, particularly due to breaking changes in upgrades. Adolfo expressed hope that these issues could be solved with the help of Piral down the line (cf draft OEP-65).
MFEs documentation & reviews
From the last BTR meeting: “can we make documentation/a checklist on what we need for a conversion from server side rendered templates to an MFE?”
“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.”
“ Maybe a solution to this would be to include someone from the BTR working groups in reviews of new repos & MFEs going forward?”
Xavier raised the point about new MFEs review for documentation, proposing that there should always be a reviewer caring about the documentation when a new MFE repository is introduced.
Adolfo outlined the current process for introducing a new MFE:
It includes a long-lived ticket with requirements (example) and an implicit review process. He suggested that the ownership of these issues could be better handled by someone more product-focused, as they could coordinate translation efforts and features.
The ultimate test for a new MFE is through BTR, where a plugin is made for the MFE and added to the Test Plan.
Adolfo expressed concerns about the current process of preparing for releases, noting that the workload becomes too heavy in the last two weeks before release and that the PR comes only a couple of weeks before release.
Adolfo suggested that this could be improved by having a single owner for each new MFE to help coordinate efforts.
Xavier and Ali discussed the possibility of assigning a product review ticket for each MFE, and review/assign it as part of the product working group meeting triage.
Ed suggested that it probably wouldn’t fit well with the product working group, as it’s often not product decisions. Instead, Ed suggested it would be beneficial to have of a group of front-end architects (including Adolfo, but not just Adolfo), who would be focused on questions about MFEs.
Adolfo mentioned the need to decide on whether a given MFE would be included in a release, and the group agreed that this should be a product decision.
The difficulty can also be to know about new MFEs early enough, they are often worked on separately before being brought to the project.
Xavier asked if there were ways to detect them automatically, which seem difficult.
Ned revealed there are three repos in the Edx Github organization that start with 'front end app,' one of which is private, and agreed to investigate for Adolfo.
Adolfo suggested having an action item for owning and pushing for new MFEs and other features, and Ali agreed to bring this up in the group on Thursday.
Ali also mentioned a proposed process for product reviews from Jenna and Santiago, which includes submitting contributions to the product working group earlier, before the PR.
Angie proposed a standardized process for developing MFEs, including criteria for identifying the owner of each MFE and the skills needed for its development.
Adolfo noted that some of these ideas were already present in the new MF roadmap issue.
Ed emphasized the need to separate product requirements from technical implementation and suggested that product changes should be decided based on their efficacy.
@Ali Hugo will bring up the topic of ownership for pushing new MFEs (or features in general) with the product working group
@Ned Batchelder (Deactivated) will be investigating the 3 repos in the edX Github organization that start with 'front end app,' one of which is private, and let @Adolfo Brandes know the outcome.
Frontend summit
Given the summit’s outcome, Xavier asked how we would prevent multiple implementations from persisting. Adolfo clarified that no decisions were made at the summit and that attendees were assigned tasks to propose unified solutions for all discussed use cases.
Braden and Kelly's teams have proposed course authoring and learner dashboard solutions respectively. Adolfo stressed the need for further exploration and development of these proposals, aiming to unify the Learner dashboard to address most of the discussed use cases.
There will be an iterative approach developing the general direction of the learner dashboard. Ed emphasized the significance of having operational code and testing it in production, which everyone agreed upon regarding requirements.
Adolfo made it clear that they were not working towards Quince but for the following release, Redwood, intending to achieve version 1.0 of the architecture or Plugin API within six months.
The team also emphasized the need for caution to prevent multiple implementations of the project.
@Braden MacDonald and @Kelly Buchanan's team have proposed course authoring and learner dashboard solutions respectively, and will be aiming to unify their approaches.
Product & UX meeting
Last core contributors update: “The Paragon Working Group would like to get members of the Product Working Group (and others in the community) more involved in UX discussions. This will allow individuals outside of 2U, not only to keep tabs on design updates, but also to help guide the design of Open edX. The idea is to start a cross-functional meeting for context/knowledge sharing around design. Anyone interested in getting involved?”