Frontend Working Group
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 our shared challenges and opportunities.
The working group:
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 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.
Outcomes
The frontend working group strives to improve the Open edX platform through:
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.
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.
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, upskill and learn about our ecosystem. We welcome members of all skill levels or stages of their careers; you don’t need to be an “expert” to join.
Membership is flexible. If you show up, engage in our conversations and participate in the working group, you can consider yourself a member! We don’t maintain a roster of this; we want folks to feel comfortable allowing their time to ebb and flow as necessary given their other commitments.
That said, knowing the capacity we have available helps us plan! If you’re able to have a more formal time commitment or are 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.
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. |
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 be inclusive. This means preferring asynchronous over synchronous and public over private.
Slack: #wg-frontend in the Open edX workspace.
Discourse: the Frontend category in the forums.
Issues: The working group uses the Frontend Working Group board on GitHub, which can group issues from any repository or organization. Alternatively, issues can be created in the group’s own frontend-wg repository in the openedx organization.
Rituals
Meetings
All public Working Group meetings follow the Recording Policy for Open edX Meetings
Frontend Working Group meetings are mainly used to communicate about ongoing frontend work, but also for roadmap planning, process improvements, and whatever else it takes to keep the working group running.
Sessions are held bi-weekly on Thursdays at 15:00 UTC.
For more specific details (such as meeting room URLs), subscribe to the Open edX Working Group calendar (which contains all working group meetings, not just frontend ones). Meeting minutes are posted to Frontend Working Group Meeting Notes; those include video recordings, chat logs, transcripts, action items, and more. The upcoming session is also listed: if you intend to add an item to the agenda, feel free to edit the corresponding page accordingly.
Asynchronous Communication
The group is currently in the process of moving towards a more asynchronous approach, with the intent of not only reducing the need for synchronous working sessions but to transmute those that remain into meet-ups. These tend to be less frequent but more generally interesting: show-and-tell and discussions around emerging technologies, rather than just discussing problems.
A lot of this already happens naturally in GitHub, the forum, or in this wiki, but because not everybody subscribes to those, the nexus of this asynchronous communication will be the #wg-frontend channel on Slack. Whenever anything important is happening, regardless of venue, it will be linked to publically in the group’s channel, so that:
Anybody can catch up with current frontend events by simply scanning the latest threads;
Discussions can still happen where they’re most useful and accessible (PR reviews remain in GitHub, long opinions in the forum, etc)
And while any kind of discussion, however impactful, is encouraged in Slack, keep the following in mind:
Prefer to have discussions in the public channel, rather than in private: this makes us more open, and thus, more inclusive, with all the advantages that brings.
Because of item 1, it’s okay to tag specific people in your public messages. A private message is no less annoying, and it can never be as directly useful to the community at large as a public one.
If a discussion is particularly important, document it in a more permanent and accessible medium such as in a forum thread, a wiki page, or an issue (maybe even an OEP or ADR!) in the appropriate repo on GitHub. Slack is great for fast, efficient communication, but bad at grouping and indexing it for future reference.
Decision Making
Unless otherwise noted, the Frontend Working Group will make decisions by lazy consensus.
Lazy Consensus means that when you are convinced that you know what the community would like to see happen you can simply assume that you already have consensus and get on with the work. You don't have to insist people discuss and/or approve your plan, and you certainly don't need to call a vote to get approval. You just assume you have the communities support unless someone says otherwise.
When a decision must be made, proposals are presumed to be approved unless any specific 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 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 (for example, 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 time zones and asynchronous review of proposals.
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 developing, prioritizing, and making meaningful progress toward a backlog of frontend-focused initiatives.
FAQ
I want to help out! Where should I start?
Say hi in #wg-frontend! But if you’re feeling shy, just take a look at our Help Wanted board and pick something from the top!
How does the Frontend Working Group differ from the Paragon Working Group?
The Paragon Working Group (PWG) is a design-led 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.
Latest News
Please refer to the following page for the latest updates on the group’s activities: