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}
