Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MFEs documentation & reviews #108

Open
antoviaque opened this issue Jan 1, 2024 · 3 comments
Open

MFEs documentation & reviews #108

antoviaque opened this issue Jan 1, 2024 · 3 comments
Assignees

Comments

@antoviaque
Copy link

antoviaque commented Jan 1, 2024

This issue is to follow up on a topic from the contributor meetup working group (imported from https://openedx.atlassian.net/wiki/spaces/COMM/pages/3934289923/2023-11-28+CC+Working+Group+Meeting+Notes )

MFEs documentation & reviews

  • Presenters: @arbrandes @pdpinch
  • Notes from previous meeting:
    • 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 to attend many meetings or monitoring many Slack channels.
  • Action items:
    • Edward Zarecor to propose to Jenna Makowski to lead a meeting release management for the next release Redwood in January
    • @jalondonot will ask Maksim about the possibility of him continuing as the release manager for the next release and, if not, will start looking for a successor.
    • @jalondonot will create async discussion spaces for reviewing the scope for Redwood and will include Jenna in the discussion.
    • @ali-hugo would bring up the topic of ownership for pushing new MFEs (or features in general) with the product working group
    • @nedbat would be investigating the 3 repos in the edX Github organization that start with 'front end app,' one of which is private, and let @arbrandes know the outcome.
@jalondonot
Copy link

jalondonot commented Jan 9, 2024

09/01 Contributor Meetup Update:

  • @jmakowski1123 has scheduled a meeting for planning the redwood.1 release for 11/01.
  • Regarding the repos in the edX GitHub, 2 of them are solved and 1 is still stuck.

@antoviaque
Copy link
Author

The first redwood meeting happened: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3995107330/Redwood+Meeting+Planning+1+Jan+11+2024 - to follow to see how this helps to address the points above for Redwood.

@antoviaque
Copy link
Author

antoviaque commented Jan 22, 2024

There is now a spreadsheet to coordinate the list of features for Redwood: https://docs.google.com/spreadsheets/d/1tWgp9LXNg4sfWYd_0ghNl6qfIZZ9851MtGBXPeSgzFs/edit?pli=1#gid=0 - this, with a process to get features accepted in there through reviews, should help guarantee that features are now planned properly for a release, and documented. We will now need to see how that works out in practice for Redwood :)

A monthly standing meeting for release planning has been agreed.

Subsidiary topics:

@jalondonot jalondonot self-assigned this Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Blocked / Waiting
Development

No branches or pull requests

2 participants