| Table of Contents | ||||
|---|---|---|---|---|
|
Charter
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 to improve overall community alignment around it.
Acts as a technical advisory resource.
Prioritizes empowerment and facilitation over “Do It Yourself” execution of its backlog.
Outcomes
The frontend working group strives to improve the Open edX platform through:
...
We accomplish these outcomes by identifying and prioritizing areas of greatest need or opportunity across the community, and then finding the most appropriate way of executing against that, whether that’s through consulting with a stakeholder to have them help build it, blended development, or working on it ourselves.
Members
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.
Name | Company, Team |
|---|---|
Adam Stankiewicz | edX, Enterprise |
Ben Warzeski | edX, Content |
David Joy | edX, Open edX |
Want to join us? Learn above membership and what it means below. |
Membership
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 and learn about our ecosystem. We welcome members of all skill levels or stages of their career; you don’t need to be an “expert” to join.
...
Right | Responsibility | |
Merge | Commit/Merge privileges on all frontend-focused code repositories. | Ensure 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 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. |
Communication
The tasks, roadmap, and workings of the Frontend Working Group are open to the Open edX Community. In the spirit of this, our communications should take place in an inclusive way. This means preferring asynchronous over synchronous and public over private.
Slack: #front-end in the Open edX workspace.
Email: TBD
Calendar: TBD
Rituals
Working Session
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.
FedX Standup (edX internal)
The FedX standup (“frontend at edX”) is a weekly, internal-to-edX “scrum of scrums” meeting where representatives from the organization’s squads share updates, challenges, decisions, and impacts for visibility. We envision this meeting continuing and being an important source of input for the Frontend Working Group (FWG). FWG members in attendance can facilitate bringing this feedback back to the working group.
Decision Making
Unless otherwise noted, the Frontend Working Group will make decisions by lazy consensus.
...
Decisions will be communicated to the appropriate channels and stakeholders (see “Communication” section above).
Accountability
The Frontend Working Group will hold itself accountable primarily by two means:
Developing, prioritizing, and making meaningful progress towards 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.
FAQ
How does the Frontend Working Group differ from the FedX Working Group?
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 that this is now a public working group, and is no longer “frontend at edX”.
How does the Frontend Working Group differ from the Paragon Working Group?
The Paragon Working Group (PWG) is a design-led, (currently) internal to edX, group that meets to manage the design system side of Paragon and vet new components according to edX’s product development needs. Members of the Frontend Working Group who work at edX may wish to go to the PWG’s meetings to help participate in that part of the process, but that is a choice they can make and has no impact on their membership in the Frontend Working Group. PWG has its own charter, goals, and governance.
...