...
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 |
|---|---|
edX, Enterprise | |
edX, Content | |
tCRIL, Frontend |
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 take place in an be inclusive way. This means preferring asynchronous over synchronous and public over private.
...
Issues: The working group uses the Frontend Development on GithubGitHub, 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.
...
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 GitHub (such as this one, for instance). Meeting minutes are posted to Frontend Working Group Meeting Agendas and MinutesNotes, and those include video recordings, chat logs, and transcripts whenever possible. Upcoming sessions are also listed: if you intend to add an item to the agenda, feel free to edit the corresponding page accordingly.
...
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. (Which These tend to be less frequent but more generally interesting: show-and-tell and discussions around emerging technologies, rather than just discussing problems.)
A lof lot of this already happens naturally in GithubGitHub, 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 GithubGitHub, long opinions in the forum, etc)
...
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 that brings;.
Because of item 1, it’s okay to tag specific people on in your public messages. A private message is no less annoying, and it can never be as directfully 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 GithubGitHub. Slack is great for fast, efficient communication, but really bad at grouping and indexing it for future reference.
...
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.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.
...
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: