Unicode® Technical Group Procedures
Updated June 2024
Scope
These procedures apply to all activities of Unicode Consortium Technical Groups, including but not limited to meetings, email lists, submissions, as well as development of specifications, documentation, data, and code.
Table of Contents
Terminology
| Technical Group (TG) |
Includes Technical Committees (TC) and Technical Working Groups (WG) |
| Technical Committee (TC) |
Technical Committees are established by the Board of Directors and are the primary bodies responsible for making Technical Decisions. The principal activities of a TC are the development and maintenance of its associated technical standards, technical reports, software, and data files in accordance with the purpose of the Unicode Consortium as stated in Article 1, Section 1 of its Bylaws, and in accordance with the scope of activity defined by the Board for that TC. The content of a TC’s associated technical standards, technical reports, software, and data files are defined by the set of proposals approved by it, on the basis of these procedures. |
| Technical Working Group (WG) |
Technical Working Groups may be established by a TC, in consultation with and subject to approval by the CTO and CEO, to perform tasks at the direction of the TC and/or develop proposals and recommendations for Technical Decisions for approval by the TC. They may be standing working groups set up to address specific technical or operational domains on an ongoing basis (e.g., CJK character encoding, Emoji, CLDR infrastructure, or digitally disadvantaged languages advancement), or they may have a particular scope of work, and be disbanded once the relevant tasks are completed. All proposals and recommendations made by a WG are subject to approval or further action by the establishing TC; the WG does not make any Technical Decisions on its own. |
| Organizational Member |
Refers to a Unicode Consortium Full, Supporting, or Associate Member. This excludes Liaison, Individual, and Student Members. Full and Supporting Members have votes in TCs, while others do not. See Membership Levels and Bylaws. |
| Organizational Member Representative |
A person designated by a Full Member as representing that Full Member in Unicode Member Meetings and is entitled to cast the Full Member’s vote in Unicode Member Meetings. See Membership Levels and Bylaws. One such Representative is singled out as the Primary. |
| Delegate |
A person representing an Organizational Member to a particular TC. Delegates to TCs are designated by an Organizational Member Representative to represent that Organizational Member to the TC. One such Delegate may be singled out as the Primary. Delegates from voting Organizational Members (Full or Supporting) are voting Delegates; Delegates from non-voting Organizational Members (Associate) are non-voting Delegates. Delegates in this context and for the definition of attendance and quorum includes any proxy. |
| Invited Expert |
A person who is invited to actively participate in a Technical Group - at the discretion of the Leadership. The participation may be short-term or ongoing. |
| Observer |
A person who is invited to attend a Technical Group to attend for the purpose of observing - at the discretion of the Leadership - but not actively participating. That is, the observer may request to speak; however, the Leadership may deny the request in the interest of focusing on the work of the Technical Group. |
| Leadership |
Collectively refers to the chairs and vice chairs of a Technical Group |
| Technical Coordinating Group (“TCG”) |
Governing group consisting of the CTO, the Chairs of the Technical Committees, and the CEO. (Others may be included where their attendance is useful.) It is not considered a Technical Group. |
| Attendance |
A voting Organizational Member is said to be in attendance to a TC meeting if at least one of its Delegates attends the meeting. |
| Regular Attendance |
In a TC, a voting Member is in Regular Attendance if it is in attendance for 3 of the last 5 meetings of the TC. In a WG, a person (excluding Observers) is in Regular Attendance if they are present at least 3 of the last 5 meetings of the WG. |
| Technical Decision |
A Technical Decision is one that makes material changes in any of the following:
- Conformance or recommended behavior in a technical standard
- Recommended behavior in a technical report
- Public (ie, non-internal) API signatures and semantics in production code
- Changes in data (character properties, CLDR data files, etc.) that affect conformance
- Changes with an impact on backwards compatibility
- Material changes in a Technical Group’s procedures, policies, or scope.
It does not include copy-editing, internal APIs, data-file generation code, test code, survey-tool code, or other routine decisions that are normally made to advance operations. |
| Minutes |
Minutes capture all material decisions made at the meeting and should capture material discussion topics; they may also capture discussions. |
| Closed Caucus |
A portion of a TC meeting in which all people except for Leadership and TC Delegates are excused. |
| Representative |
A person designated by the leadership of a Technical Group as representing the Technical Group to another Technical Group or external body. There may be more than one such representative, and the term of the authorization may be permanent or limited in duration. |
| Recommendation |
A suggestion or proposal as to the best course of action. Note that “recommendation” has the normal English meaning, and is not being used to mean “standard” as in W3C usage. |
Leadership of Technical Groups
All Technical Groups must have a chair. TCs must also have at least one vice chair; vice chairs are encouraged but optional for WGs. TC chairs and vice chair(s) are appointed for annual terms by the Board of Directors, but can also be replaced mid-term by the board. Acting TC chairs and vice chairs can be appointed by the CTO and CEO between board meetings.
WG chairs and vice chairs are appointed for annual terms by the chair of their establishing TC, in consultation with and subject to approval by the CTO and CEO, and can also be replaced mid-term by the chair of the TC.
Additional roles within a Technical Group, such as a recording secretary, may be appointed by the chair of that group.
In the absence of the chair, one of the vice chairs shall assume the chair’s duties. If neither the chair nor any of the vice chairs can be present at a meeting, and the meeting cannot be postponed, then:
- In a Technical Committee, one of the Delegates in Regular Attendance can be appointed as presiding chair pro tempore by the Unicode CEO or CTO.
- In a Technical Working Group, a person in Regular Attendance can be appointed as presiding chair pro tempore by the chair or vice chair of the establishing Technical Committee, or the Unicode CEO or CTO.
Participation in Technical Groups
Organizational Members are entitled to participate in all Technical Groups and may designate one or more Delegates for any Technical Group. Delegates may attend meetings of that Group, participate on the Group’s email list, and exercise the rights of the Organizational Member in a Technical Group. The number of Delegates from each Organizational Member may be reasonably limited by the Leadership of the Group in order to keep the Group to a manageable size. Delegates for a TC must be communicated to the TC Leadership by the relevant Organizational Member Representative. Delegates to WGs must be communicated by the Organizational Member’s Representative or by one of the Organizational Member’s Delegates to the TC in question. Members may change their Delegates at any time.
All other Unicode Consortium members (such as Liaison members and individual and student members) may observe or participate in one or more Technical Group meetings and/or participate in the Group’s email list at the discretion of the Group’s Leadership. The Leadership may also invite external experts to attend a particular meeting or on an ongoing basis, and/or to participate on the Group’s email list. Such requests may or may not be granted, at the discretion of the Leadership of the Technical Group in question.
Participation at any level, whether as a Delegate, Participant, or Observer or otherwise is subject to compliance with the Unicode Code of Conduct. Violations of the Code of Conduct may result in, among other things, the temporary suspension or permanent revocation of the right or permission of a person to attend meetings, participate in email lists, or otherwise participate in the activities of the Consortium. See also Unicode Legal & Governance Policies.
TC Meetings & Decisions
Technical Decisions are made only at the TC level. Other decisions (such as operational decisions) may be made at the TC or its WG level subject to the individual TC’s policies.
Technical Decisions are made in meetings or by email polling, as set forth below.
TC Voting Rights
Unicode Full Members in good standing have one (1) full vote on decisions, while Supporting Members in good standing have a half (½) vote. Associate Members have no vote, but have a right otherwise to participate. See Membership Levels.
The CEO shall determine whether an Organizational Member is in good standing, and shall maintain a list of the current Organizational Members in good standing and their voting status, available to the Leadership of each Technical Group. If there are questions as to whether a voting Organizational Member is in good standing, the question should be referred to the CEO as soon as possible prior to any vote.
If a voting Organizational Member has more than one Delegate at a meeting, only one Delegate may cast the Organizational Member’s vote. That Delegate is known as the Primary voting Delegate for the Organizational Member, and determined by the following process.
- If a Primary Delegate for the Organizational Member is present, that person casts the vote.
- Otherwise, the remaining Delegates for that Organizational Member shall determine who should vote. That person takes the role of the Acting Primary voting Delegate in all matters below.
- In case of disagreement among those Delegates as to who should vote, then there is no person in the role of Primary Delegate for the voting Organizational Member, and the Organizational Member’s vote will be counted as “abstain”.
TC Proxies
A Delegate of an Organizational Member may designate a proxy, in the event that the Delegate is unable to participate. The proxy may be a representative of the same Organizational Member organization, or a representative of another Organizational Member organization, or any other person the Delegate chooses to designate, other than Unicode employees or contractors. The proxy designation from the Delegate must include the following specifics:
- The duration of the proxy, such as a single meeting day, a single meeting, or during a certain span of time; and
- The scope of the proxy, such as whether it is limited to certain topics, or to support or object to certain proposals, or be open-ended.
- The powers of the Delegate that are granted: all (ie., participating, proposing, and voting) or just a subset (e.g., voting only).
Designation of a proxy should be done in writing (email is acceptable), but may be done orally during a meeting provided that the minutes of the meeting capture all the required specifics of the proxy. A proxy may be revoked in the same ways, or may expire by its own terms. A person may hold and exercise multiple proxies.
Establishing a TC Quorum
A quorum for any particular TC meeting is established with the attendance and proxies of Delegates based on voting Organizational Members in Regular Attendance, weighted by vote. The weighted sum must be ≥50% of voting Organizational Members in Regular Attendance, weighted by vote, and be no less than 2.
For example, if 4 Full Members (4 votes) and 2 Supporting Members (½ + ½ =1 vote total) are in Regular Attendance, then a quorum is established with 50% of 5 votes. If there are Delegates of 2 Full Members plus 1 Supporting Member Delegate, the weighted sum is 2.5 and a quorum is established.
Technical Decisions may only be made if there is a quorum at the time they are made and recorded. That is, if there is not a quorum at part of a meeting, no Technical Decisions may be taken during that part of the meeting. In the absence of a quorum, work may continue on administrative issues, logistical issues, operational issues, the development of proposals, and other non-decision-making activities.
Organizational Members are encouraged to grant proxies to allow for quorums to be reached; these can be standing proxies if desired. See TC Proxies for details.
Decision Process in TC Meetings
Proposals may be submitted by any Delegate. The group may also provide mechanisms for proposals from other organizations or individuals, but is not obliged to consider or respond to such proposals. Proposals may be submitted and maintained via an issue tracker, a document registry, or other mechanisms.
When a proposal for a Technical Decision is introduced for the first time in a Technical Committee meeting, any Primary voting Delegate can ask for the decision to be delayed to the next meeting, to allow time for study. The chair will normally honor the request, save under exceptional circumstances (which must be noted in the minutes). An example of an exceptional circumstance is an issue that needs resolution to unblock progress on meeting an important milestone or release date.
In a meeting, decisions on proposals are typically made by consensus among the Primary voting Delegates in the following way: A Delegate or representative of a WG will make a proposal for a Technical Decision to the TC. The chair will ask if any Primary voting Delegate opposes the proposal or wishes to call for a vote on that proposal. If there is no such Delegate, this will be interpreted to mean that no Primary voting Delegate objects to the proposal, and the proposal therefore passes. If on the other hand there is a call for a vote, then the chair will call for a motion from a Primary voting Delegate. If it is seconded by a Primary voting Delegate from a different Organizational Member, the chair will call for a vote. The Primary voting Delegate from each voting Organizational Member may then vote yes, no, or abstain. If the sum of the weighted yes votes is greater than the sum of the no votes, then the proposal passes. Abstain votes are not counted in the decision but are reflected in the minutes for a complete record.
While Technical Decisions are only made by TCs, other decisions can be remanded to WGs.
- For example, triaging of proposals submitted via an issue tracker may be remanded by a TC to a WG. The WG marks up the issue (priority, status [accepted, rejected, to investigate, …], …) and marks the issue as triaged. The TC can accept the triaging by consensus at their next meeting, where at that meeting any voting member could request that the status of an issue be reconsidered by the TC as a whole.
- Similarly, a class of issues involving operational decisions may be delegated by the TC, such as release checklist (aka BRS) issues delegated to a release management work group, an infrastructure work group, or to individuals.
- TCs may also delegate communication work to WGs, such as corresponding with authors of proposals sent to the TC.
Precedents
A TC may establish a Precedent, which places restrictions on future decisions. Once a Technical Decision has been made, a Delegate may propose that it be a Precedent. Approval requires a two-thirds supermajority, meaning that the number of yes votes is at least twice the number of no votes. A precedent may only be overturned or amended by a two-thirds supermajority, as well.
The TC must maintain a publicly posted list of all of the Precedents it has established.
Stability Policies
A TC may request the establishment of a Technical Stability Policy. A TC may also request that a Technical Stability Policy be overturned or amended. A Technical Stability Policy may only be established, overturned, or amended by unanimous agreement of all members of the TCG.
The Consortium maintains a publicly posted list of all Technical Stability Policies, currently at Unicode Technical Stability Policies.
TC Decision Process by Email
Meetings are strongly preferred over email for making Technical Decisions because meetings allow for more robust discussion and consideration. However, decisions may be made using a group’s email list (typically when there is urgency for a decision to be made before the next meeting) with the following process:
If there are disagreements from Primary voting Delegates, then any one of those Primary voting Delegates may call for a letter ballot. The Leadership will issue the ballot by email to the voting Delegates in Regular Attendance to the TC, with a 14-day duration. Primary voting Delegates respond with votes yes, no, or abstain. The quorum and resolution process is the same as in a meeting, except that the resolution of the ballot does not have to wait for the end of the period. If at any point during that period, a weighted majority of Delegates of all Members in regular attendance are either in favor or against the proposal, it passes (or fails, respectively) and is recorded (as per Recording TC Decisions).
Recording TC Decisions
All Technical Decisions must be recorded, either in the minutes of the TC meeting or in some other written mechanism such as an issue or bug tracker. If a Technical Decision is made via consensus, then the decision is recorded by consensus, or simply recorded as accepted. If a Technical Decision is made by formal vote, then the number and weight of the yeas, nays, and abstentions must be recorded, and any proxies.
Because Technical Decisions are limited to TCs, this requirement does not apply to WGs.
Appeal of TC Decisions
When new information has arisen, a voting member may propose that a past technical decision be revisited. If that is rejected, then the voting Organizational Member may appeal a Technical Decision of a TC with the following process:
A Delegate and that Delegate’s Primary Member Representative send a notice on behalf of the Organizational Member to the Technical Coordinating Group, with a concise statement of the issue and the rationale for why the decision should be reversed. The TCG will then hold a meeting to discuss the issue with the appealing Delegate and Primary Organizational Member Representative. If the TCG believes that the TC fully considered the issue, it may choose not to act, leaving the original Technical Decision to stand. If the TCG believes there is value in the TC reconsidering the issue, the TCG will refer the issue back to the TC for further discussion and a new vote.
If the Organizational Member remains unsatisfied with the outcome of this process, then the appeal is forwarded to the Board of Directors for consideration. The Board may vote to affirm or overrule the TC’s Technical Decision, or may choose to refer the issue to a vote of all Full Members.
WG Decisions
Working Groups do not make Technical Decisions, but rather make recommendations and proposals for Technical Decisions and/or engage in other operational activities. In addition, WGs often include outside experts as regular participants.
Decisions on recommendations are generally made by consensus among the regular attendees. When a consensus cannot be reached, the alternative proposals should be listed in the recommendations. WG members dissenting from a consensus recommendation may file a separate proposal to the TC stating their case. Even when there is consensus, it is good practice to include reasoning behind the choice being made for any complex decisions.
Each TC can define any further processes for decision making for its WGs, including what constitutes a quorum (if any), and a voting procedure (if necessary).
Meetings
Meetings may be in-person, virtual (video or teleconference), or hybrid (allowing participants to be either in-person or virtual). All in-person meetings must be announced at least twenty (20) days in advance; all virtual-only or hybrid meetings must be announced at least two (2) days in advance.
The presiding chair of any meeting is tasked with ensuring the orderly and expeditious conduct of business and has the following powers and duties:
- To set and manage the agenda
- To control the floor and recognize speakers
- To call for, limit, and close discussion and debate
- To approve (or not) and enforce a closed caucus
- To ensure a respectful and professional atmosphere for the conduct of business
- To prevent, limit, and end any disruption, including by requiring a disruptive attendee to cease speaking or to leave the meeting
- To enforce the requirements of the Unicode Code of Conduct as necessary
In addition, the presiding chair in a meeting has the power to decide any question concerning interpretation or application of these Technical Group Procedures during the course of the meeting.
Outside a meeting, the chair of the Technical Committee shall decide any question concerning interpretation or application of these Procedures for the TC and for its WGs, if any.
Recording or broadcasting by any medium (including photography, video recording, audio recording, etc.) of meetings is generally not permitted. In exceptional circumstances, the presiding chair may authorize recording or broadcasting of a meeting or portion of a meeting, provided that all Delegates and the site host affirmatively consent (which consent shall be recorded in the minutes). If any attendee who is not a Delegate does not consent, the chair has the discretion either to exclude such attendee from the meeting or to decline the request to record or broadcast. Recording or broadcasting the meeting is not permitted if persons are present who do not consent.
TC Meetings
All Delegates to a Technical Committee have an equal right to be recognized by the chair, and may raise points of order to check procedural matters and questions on agenda topics. Liaison, Individual, and Student Members, as well as any other non-voting participants (non-voting Delegates, Invited Experts, and Observers) may participate in discussion at the discretion of the presiding chair. Such permission can be granted on an on-going basis (until revoked) and/or for a particular topic or discussion.
In addition, a Primary voting Delegate may request a closed caucus; if the presiding chair approves, then non-voting attendees (including non-voting Delegates) are required to leave the meeting for the duration of the closed caucus.
Taking Minutes
Minutes must be taken for all meetings of any Technical Group. At a minimum they must record the date, the location (including whether it is virtual), the names of all attendees along with the Organizational Member they represent (if any), and any proxies. Names of attendees and the Organizational Member they represent may be abbreviated, if a table or key is provided listing the correspondence between the abbreviated names and the full names and Organizational Member (if any).
Decisions other than Technical Decisions should be recorded but are not required to be recorded, as agreed by the Technical Group in question.
Minutes may, but are not required to, reflect the substance of any discussion or debate. A Delegate may request that their comments be included or not included in the Minutes, but the decision remains in the presiding chair’s discretion.
Draft minutes of Technical Committees shall be made available to all meeting Delegates within 7 business days of the meeting. Final minutes shall be made available to meeting Delegates within 7 business days after the next meeting. The TC must set policies as to whether meeting minutes (in whole or in part) are made publicly available, or not. The TC sets similar policies for availability of minutes for its working groups.
Public Review Issues
From time to time the Unicode Consortium seeks formal public review and feedback on specific proposals by posting Public Review Issues on its website. Public review issues are created by TC chairs or vice chairs, or the CTO or CEO. Each issue has a number, title, summary, and deadline for receipt of public review comments. Technical Committee decisions are not bound in any way by the existence or the wording of a public review issue, nor by any input received during the course of public review.
Confidentiality
The Consortium strives for a balance between transparency and confidentiality. Openness and transparency are core values. However, there are times when confidentiality enables candid and robust discussions among participants, including Organizational Member organizations, to participate fully and support the best technical outcomes. There may also be other circumstances when confidentiality is necessary, such as member confidential information or to keep a security issue in code private until it has been addressed.
For these reasons, the Consortium reserves the right to decide whether, when, how, and to what extent to disseminate information regarding Technical Group activities and decisions more broadly within the Consortium and outside the Consortium.
The TCs have established, and are free to further develop, procedures and timelines for the publication of decisions, proposals, meeting minutes, and so on. These may be specific for a given Technical Group, to allow for the different needs and circumstances of the different Technical Groups. For example, some activities and documents of the UTC are public from the start; the ICU agenda/minutes are fully public.
In contrast, many decisions and minutes are published only at a later date. Still other elements of Consortium activities may largely remain confidential in perpetuity, such as specifics of internal discussions and votes.
Unless overridden by the applicable Technical Group procedures, all attendees at any Technical Group meeting or participants in a Technical Group email list, direct messaging channel, or similar medium are required to treat as confidential to the Consortium all of the following information unless it is allowed to be made public by the TG’s procedures and timelines.
- Technical Group meeting and email list agendas, topics discussed, and the specifics or contents of any discussion (including written communication, such as email);
- Any decisions made by a Technical Group;
- Consortium documents, including Technical Group proposals, submissions, discussion documents, and drafts of documents (submissions include UTC documents, public GitHub comments / issues, CLDR Survey Tool submissions, bug reports, and so on); and
- The identity of any other attendee or list participant and/or the Organizational Member they represent, as well as any positions they took or arguments they made or votes they cast.
Of course, the author(s) of a submission to the Consortium may make that submission be public. And certain methods of submission (such as public GitHub comments) are by their nature public. A Technical Group may also reach out to experts for comments on a proposal that is not yet public, provided that the expert is made aware of their duty to abide by these confidentiality requirements.
If there is any question about the application of the Technical Group’s procedures, the participants must ask for permission from the presiding Technical Group leadership. For example, in the UTC attendees may ask for permission to make public that a given set of characters has been approved for a release, a request that the Chair may grant or deny, as appropriate.
In addition, meeting attendees and list participants may not make public or otherwise disseminate information relating to the identity of any other attendee or list participant and/or the Organizational Member they represent, or positions they took, arguments they made, or votes they cast - other than what is in public minutes, issue tracker or public GitHub repository - without the additional permission of such other attendee or list participant.
Notwithstanding the foregoing, a Delegate may share information internally within the Organizational Member they represent to the extent necessary to function effectively as Delegates.
![[Unicode]](https://www.unicode.org/webscripts/logo60s2.gif){kind=small}
