2023-11-28 CC Working Group Meeting Notes

Follow-up - Debugging persistent grade issues

• Last meeting,@Dave Ormsbee (Axim) offered to connect with @Peter Pinch later to check on the issue

@Peter Pinch

•  Neither Peter or Dave present in the meeting

• @Edward Zarecor will respond in the thread to ask if this is solved

Follow-up - How do we make sure strings in frontend-app-communications are sent to Transifex?

• Not fully discussed during the previous meeting as @Pierre Mailhot was not present, but the topic was brought up in Slack.

• There seemed to be a blocker on the availability of Atlas for Quince, but it now seem available: https://github.com/openedx/frontend-app-communications/pull/156

@Pierre Mailhot

• Strings are sent to Transifex, to the Open edX translation project, will be used by Atlas from Quince (maybe, as some of the changes were made after the cut for Quince).

• Is MFE translation support production ready? Yes, since Olive.

• Not sure this has been tested by the BTR group. Not sure if it’s on the BTR backlog, but there is some issues items on the MFE projects

• You have to translate in both the edx-platform and openedx projects, risks of sync issues between the two projects - question for David and Omar to know when Atlas will be put in place. Will require some setup to transition between the two.

• For Pierre, not an issue for Quince for him, as he has a hack, but could be for anybody else not using English. This workaround could be communicated with others, but might require access to be granted by Eden & Omar.

• Quality control issue about MFEs being put into production

• @Jorge Londoño will be bringing it up with the BTR group and ask @Omar Al-Ithawi

• @Pierre Mailhot to see with the BTR group and @Peter Pinch about posting a warning about this in the release notes, and give a workarounds: use the JSON file of the translations, and use it with the feature in Tutor to override the language files

MFEs documentation & reviews

Action items from the last meeting:

• @Ali Hugo would bring up the topic of ownership for pushing new MFEs (or features in general) with the product working group

• @Ned Batchelder (Deactivated) would 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.

@Adolfo Brandes @Peter Pinch

• Product working group should be involved, so that it’s not just a technical decision to include a MFE

• BTR should be involved to validate that the MFE should be accepted or not

• Jorge: BTR: hard to tell what are the non-negotiable items from a product working group - what should be the release blockers? Need to get the product working group involved in the other working groups. In general, lack of shared goals between working groups - we don’t plan as a community.

  • Ed: If more people were in the current meeting that would allow to coordinate. Should also be working on what should go in a release right after a release.

  • Xavier: Should we have a product release manager for stable releases, as a counter-part to the more technical role of release manager, to be able to handle product-related topics?

• To help increasing the cross-over between working groups (such as BTR and product), it would help to do more async communication, which would help to include members of other groups in discussions, without having t