...
The Frontend Working Group is responsible for stewardship of the frontend of the Open edX platform. The working group exists as a technical advisory board, curators of our frontend strategic roadmap, and to empower the community to execute on our shared challenges and opportunities.
...
Is public and open to members of the Open edX community.
Has a backlog of tasks sourced from the community.
Maintains a public roadmap and strive strives to improve overall community alignment around it.
Acts as a technical advisory resource.
Prioritizes empowerment and facilitation over the “Do It Yourself” execution of its backlog.
...
Approachability: Our platform should be comprehensible and simple to work with, providing powerful functionality without requiring a long ramp-up period or specialized domain knowledge.
Composability: Our shared libraries should be composable, reusable, and un-opinionated in service of our ability to leverage them into new use cases.
Extensibility: Our ability to extend our platform while maintaining a small, stable core is a central tenant of the Open edX architecture.
...
Joining the Frontend Working Group is a great way to participate in and support the Open edX community, improve the health of our platform, and to up-skill upskill and learn about our ecosystem. We welcome members of all skill levels or stages of their careercareers; you don’t need to be an “expert” to join.
...
That said, knowing the capacity we have available is helpful for planning help plan purposes. If you’re able to have a more formal time commitment or are an edX employee working to engage more with the rest of the community, we’d love to have you formally devote a portion of your time to working on the priorities of the group. We suggest a time commitment of 20 hours a month, or 8%, toward the priorities of the group. This level of commitment lines up with the expectations of the Core Contributor program.
We will regularly revisit time commitments from members to understand our ongoing capacity , and will maintain a list of what folks are able to can commit.
Time commitments
Editorial note: we’re just getting started! The folks listed here are those who have officially committed to spending at least 20 hours a month toward the working group’s priorities.
...
Right | Responsibility | |
Merge | Commit/Merge privileges on all frontend-focused code repositories. | Ensure the approved review process is upheld and be on-call to address issues with recently merged PRs. Follow the merge timing guidelines. |
Maintain best practices for design, security, accessibility, and compliance on merged code. | ||
Own | Review PRs and suggest technical changes in designated repositories. | Learn and advocate for clean code, quality, and architecture principles and practices (per repository’s definition of done) |
Co-establish technical direction of designated repositories. | Documenting and reviewing decisions in ADRs (and OEPs) and maintaining READMEs, How-Tos, etc. | |
Co-maintain a prioritized backlog of needed technical improvements of designated repositories. | Negotiate and allocate a regular percentage of time toward technical upkeep, including refactoring and other items listed in this column. | |
Ongoing upgrade and feature maintenance and other ownership costs of designated repositories | ||
Training | Appropriate onboarding for using our frontend technology stack. | Educate others to help spread frontend domain knowledge throughout and beyond the working group. |
Training on new workflows/technologies. | Participate in the formalization and documentation of training and best practices. |
...
The Frontend Working Group envisions having regular working sessions in which we perform backlog grooming, roadmap planning, process improvements, and whatever else it takes to keep the working group running. That said, we want to have a bias toward inclusive, asynchronous work.
There Their sessions are held weekly. One every two weeks on Thursday at 15:00 UTC, and the other on the alternating weeks, also on Thursday but at 11:00 UTC. They are staggered in this manner so that potential attendees can pick the time that is more comfortable for them.
For more specific details (such as meeting room URLs), either subscribe to the Open edX Working Group calendar (which contains all working group meetings, not just frontend ones) , or be on the lookout for session-specific issues on Github (such as this one, for instance). Session summaries are also posted bi-weekly to the Frontend category in the forums, including video and chat logs.
...
When a decision must be made, proposals are presumed to be approved unless any specific objections objections arise. The method may be summarized as “silence is consent”. Lazy consensus empowers members of the Frontend Working Group to take initiative while lowering the cost of governance.
If there are objections to any given proposal, further deliberation will be conducted amongst group members to weigh the pros/cons of each proposal. When objections to a proposal does do occur, individuals are encouraged to come up with at least one alternative proposal for discussion.
In practice, with lazy consensus, an individual may make a proposal with adequate supporting details and state that, without explicit objection, the proposal will start to be implemented within a reasonable amount of time (e.g., 72 hours) to allow other members of the Frontend Working Group to review the proposal and to make any relevant objections. This approach ensures enough time is allotted to account for differing timezones time zones and asynchronous review of proposals.
...
The Frontend Working Group will hold itself accountable primarily by two means:
Developing, prioritizing, and making meaningful progress
...
toward a backlog of frontend-focused initiatives.
Understanding and benchmarking the “state of frontend development” for Open edX engineers as discovered by metrics and KPIs like those described above. This includes frontend developer surveys to gauge net-promoter score (NPS), improved efficiency of UI development through Paragon, and common accelerate metrics such as deployment frequency.
Metrics (Draft, TBD)
Frontend developer surveys (e.g., net-promoter score)
Frontend accelerate metrics (i.e., lead time, MTTR, deployment frequency, fail rate)
MFE adoption in the community
Frontend contributions
Paragon
Speed up UI development
Reduction in a11y issues
Consistent UX
Downloads (i.e., “popularity”) of core frontend libraries such as
@edx/frontend-build,@edx/frontend-platform, and@edx/paragon.
...
The FedX Working Group is the prior iteration of the Frontend Working Group , and was internal to edX only. The only part of the FedX Working Group that remains is the weekly “FedX Meeting” for edX employees. This meeting is a “scrum of scrums”-style update from engineers in the edX organization where we talk about what our squads are doing, any challenges that we’re facing, decisions we made, or impacts we may have on other teams.
The moniker “FedX Working Group” will be retired in favor of “Frontend Working Group” - this is in acknowledgement an acknowledgment that this is now a public working group, and is no longer “frontend at edX”.
...