Standards/Roles

Depending on the standards organization, there are several different roles for participants, with different time commitments, responsibilities, and processes for taking on and transitioning.

General Participation

There are a number of ways to participate in open standards in general, from incidentally to regularly, that Mozillians are encouraged to pursue within their time capacity and other responsibilities.

Open standards workmodes typically involve one or more of the following areas of technical work: chat, email (lists), issues (usually on GitHub), specifications, tests, test suites, reports, and to some extent charters of different groups.

Depending on the standards organization, you may want to read one of these first to get an overview:

• Standards/Participating in a W3C Group
• Standards/Participating in TC39
• WHATWG

For these in general, you can choose to get involved in any number of the following ways, each of which is a good way to learn about open standards development by active participation in one or more groups:

• chat — join a chat channel for a group. Depending on the group, they may use IRC, Matrix, Slack, or possibly some other real time chat software or service. Introduce yourself, get a sense for what people are talking about, and when you have questions about what people are discussing, ask. This is perhaps the most informal way to participate and a good way to get started in most groups and get a sense of the group, topics, scope, and whether those match your interests and work. Different groups have different policies about their use of chat, some are logged, some are not. Ask if you are unsure.
• email lists - most groups have a public email list you can both browse archives of, and join if you want to receive messages in your email client. Similar to chat, but a bit more formal, email lists are another good place to both learn by reading, like chat but with longer posts. These days many standards groups use email more for coordination rather than technical discussions (which are typically in GitHub). Email lists can be a good place for high-level questions about a group or its scope which are not particular to a technical specification, or longer term vision and plans for the group (beyond its charter).
• telcons - most groups hold regular synchronous teleconferences, some audio-only, some with AV using various tools (Zoom, Google Meet, Jitsi). You may be able to ask a chair of a group if you can observe a meeting to see if you are interested in it. If you want to participate in a teleconference, plese see the above linked pages for participating in particular standards organizations.
• issues - most groups use public GitHub repos, usually one repo per specification, sometimes for the entire group (like CSSWG). If you are implementing a specification and have questions or find problems in the specification, browsing their issues is a good place to start, and file an issue accordingly for the problem(s) you encounter with a specification (ambiguities, contradictions, etc.)
• pull requests - similarly, most groups are open to anyone creating a pull request to submit corrections to a specification. You may want to participate in the above roles first for a while before filing your first pull request. If you see something simple like a typo or a grammatical error, feel free to file a small focused PR, preferably only for that one file, and without altering anything else (e.g. whitespace). Even this small act though may require that you sign an IP agreement (or officially join the group). For actual technical contributions you may want to collaborate with a colleague and have your work reviewed before submitting your PR.

Most standards groups workmodes are designed so you can show up and contribute a little, or show up a lot and contribute a lot, or vary depending on your other time commitments and this is by design.

Specific Roles

• group member - before joining a standards group, please read the wiki page related to the group's standards organization and ask any questions you may have to your manager or a standards lead (you may use the #standards channel in Mozilla's Matrix or Slack instance). If you are officially affiliated with Mozilla, you will need explicit approval from the Mozilla lead for that standards organization to join the group.
• face to face meetings — as a group member, in addition to telcons (see above) you may want to participate in group face to face meetings. Most group meetings are hybrid these days, with a remote participation option (group's choice of Zoom, Meet, or Jitsi). There are additional benefits to participating in-person, such as the informal conversations during breaks, meals, and informal gatherings between meeting days. Participating in-person typically involves travel expenses, and thus you should check with your manager accordingly.
  • meeting observer — one exception: sometimes there is an opportunity to observe an in-person meeting, such as during a multi-group meeting week like IETF or TPAC. You may be able to request permission from a group (co-)chair to join the in-person meeting as an observer. Observers are expected to not actively participate though you should be prepared to potentially answer questions if asked by a group member. Consider your role there secondary to group members, whether co-workers, colleagues, or others. As such, consider such factors like sitting in a back row of chairs or back or edge of the room rather than at tables with group members.
• editor (or co-editor) - after participating in a group’s technical discussions for a while, you may either want to or be asked to help with formally editing a technical specification in that group. Depending on the group and the specification this will require either a marginal additional amount of time and responsibility, or a lot more time and responsibility. If you're not sure ask other colleagues in the group what is expected. You should in any case, both bring this up with your manager and give a heads-up in the #standards channel before committing to signing-up as an editor. This will be a good way to explore any particular risks or concerns and help you succeed as an editor.
• chairing (or co-chair) — similarly but on a longer timescale, you may be interested in or asked to help chair a group. The details of the responsibilities and time commitments for doing so vary so greatly that this will require a case-by-case assessment. Similar to the editor role, you should bring up this possibility (or even aspiration) to your manager, and ask about it in the #standards channel long before you have to make a decision about it.

Out of scope

For now the following roles are out of scope for this page, and you should directly ask your manager if you are interested or invited to any of them:

• running for elected position, e.g. IETF IAB, W3C TAG, AB

See Also

• Standards
• Standards/Participating in a W3C Group
• Standards/Participating in TC39
• WHATWG