BTR requirements for an MFE to be included in a release

[ghassanmas]

Update: the requirements list will live here: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3561521275/Requirements+for+an+MFE

---

The FWG was discussing how to ease the process for BTRWG when deploying or adding a new MFE in a release, one thought we had is to get a list of requirements or/and features that an MFE should have (from BTR perspective) so that these requirements would be thought of or worked in advance.

For example, @davidjoy mentioned that there were issues regarding i18n strings, and to make specific components/elements customizable..etc.

Also, we can issue a cross-collaboration between MFWG and BTRWG to brainstorm how to make the job of BTR when releasing an MFE easier or with less friction (coming out with a list of requirements is just one way to think of).

[arbrandes]

From today's BTR meeting:

• Find out what new MFEs will make it to Nutmeg?
• In particular, find out about Discussions and Learning.

[NeOneSoft]

Hi @arbrandes hope you doing well!!. As I understand this is still under discussion right?Thank you so much!!

[arbrandes]

@NeOneSoft, yes, this is very much still under discussion!

[arbrandes]

This is what is known to date:

Tracking

This is the main ticket that tracks this question generally: couldn't find any duplicates.

The frontend roadmap item that more closely tracks this is openedx/axim-engineering#417

Wiki

There's an old MFE Definition of Done page in the wiki. This is more pertinent, particularly starting with the Architecture Concerns subheading.

BTR

The actual checklist the BTR group used for Lilac can be found in one of the related tickets, such as #29. It goes, in relation to each MFE:

• It passes a minimum standard of documentation: at the very least, the READMEs should have descriptive text that includes use cases, screenshots, and particularly, documentation on that MFE's environment variables.
• Its basic feature-set (as documented above) works reliably with the rest of the Lilac codebase.
• It's deployed by default using the Native Installation, and deployable as a plugin using Tutor.
• It is internationalized (i18n), localizable (l10n), and passes minimum accessibility (a11y) standards.
• It has a header and footer that are customizable via npm aliases: https://edx.readthedocs.io/projects/edx-developer-docs/en/latest/developers_guide/micro_frontends_in_open_edx.html#overriding-brand-specific-elements
• It is compatible with the @edx/brand system: https://open-edx-proposals.readthedocs.io/en/latest/oep-0048-brand-customization.html
• It uses CSS utility classes in a branding-friendly way. (i.e., don't use things like 'bg-white')

Discussions MFE

There's also a checklist on the Discussions MFE roadmap item (openedx/platform-roadmap#106):

• Is this feature enabled by default? Is it currently enabled?
• Is this feature internationalized?
• Is this feature theme-able?
• What's the production status as of the date of the code cut-off? 10/6: After rolling this out to edX customers, about 100 bugs and fixes were collated and are currently being addressed. Timeline for completion of bug fixes is end of Oct/early Nov.
• Documentation:
  • Link to Product blog
  • Link to "How to enable"
  • Link to any other relevant technical documentation

[arbrandes]

Copy-pasta of a post I made in the forum:

Do we need to include every MFE in that list in Tutor/Olive?

TLDR: No.

MFE developers (as of now mostly employed at or by 2U) are aware they can't remove a feature in edx-platform before the MFE that replaces it is officially accepted as being production-ready by the community. This should apply to each MFE in that list, and it means we don't have to enable any of them for Olive if we don't want to.

How do we decide which ones to include?

TLDR: Don't know. We need to decide how to decide.

While the ultimate decision on whether an MFE is ready is in fact up to the community, and in particular, the BTR group, there is no official method to arrive at this decision. This is a problem we should fix pronto, precisely so we can answer the question of which ones to include.

This comment in the ticket where we're tracking this question is a collation of the information I could find. Please refer to it and add your comments, including which MFEs you would like to have included, and why. Once we have a reasonable idea of where the community's opinion lies, we can start to narrow down the list in a technical fashion: by checking each MFE against the criteria.

(And yes, right off the bat it looks like a sine qua non criterion is whether the MFE supports runtime configuration.)

Product considerations

TLDR: Let's consult the Product Working Group as well.

There are product considerations to take into account. Ultimately, I think the list will be narrowed down a lot by them. I'm not saying they have ultimate say, but it doesn't make sense to start maintaining Tutor support for an MFE if it doesn't make sense to make it part of the Open edX product at a given point in time.

I've started discussing this with @jmakowski, yesterday. The short of it is that my job will be to try and put all stakeholders together (mostly asynchronously, such as via this post) so we can decide ASAP which MFEs to work on for Olive.

[kdmccormick]

Relatedly, we have proposed OEP-57, which would create a system for deciding what needs to be enabled by default in the named releases (the "Core Product Offering"). I encourage all of BTR to review it and I am hopeful that this will make things easier when the Palm release rolls around. I recognize that an unmerged OEP isn't extremely helpful for deciding what goes in Olive :P

[kdmccormick]

One criteria I’d add is: Has the legacy version of the frontend stopped working on master?. If yes, we’re forced to either get the legacy feature fixed, or to include & enable the MFE. When it’s unexpected, this scenario drives me crazy and represents an absolute failure of our deprecation process. Yet, it’s still something we need to look out for when considering MFEs for release.

[hurtstotouchfire]

@arbrandes Do we have a ticket somewhere tracking the list of potential MFEs and their status as far as potential inclusion?

[arbrandes]

@hurtstotouchfire, this is where the raw list is being gathered:

#200

[ghassanmas]

One criteria I’d add is: Has the legacy version of the frontend stopped working on master?. If yes, we’re forced to either get the legacy feature fixed, or to include & enable the MFE. When it’s unexpected, this scenario drives me crazy and represents an absolute failure of our deprecation process. Yet, it’s still something we need to look out for when considering MFEs for release.

@kdmccormick for this and also for documentation purpose, I have just opened an issue about changes of toggles/settings between nutmeg and olive #204

[arbrandes]

This is where the master list is now being tracked:

https://openedx.atlassian.net/wiki/spaces/COMM/pages/3561521275/Requirements+for+an+MFE

Please leave your comments and suggestions in there. The list is supposed to be modified organically.