We have been trying to tune the voting process, see
. The goal is to balance stability with flexibility.
Occurrence of "draft" in country locales: http://www.unicode.org/cldr/data/dropbox/misc/draft_in_country_locales.txt
And non-country locales: http://www.unicode.org/cldr/data/dropbox/misc/draft_in_noncountry_locales.txt
- Gratuitious changes in country locales: pt_PT has lots of such from pt (= pt_BR)
- We want people to be able to make fixes where needed (it is frustrating to request a fix, but not have it confirmed because people don't look at it)
- But we don't want to have "wiki-battles": how do we "protect" against bogus data, while allowing needed changes?
- Set a higher bar
- on changes to "critical" locales (union of principal's main tiers, intersected with those that are fleshed out well)
on country locales.
- Allow multiple separate votes for TC organizations for non-critical locales. For Vetter status, two sets of eyes should be sufficient. Downside is "deck-stacking".
- Vote on "logical groups" (eg sets of Months) as a whole.
- Show country locale differences as "alts".
- Save votes for "active members" across releases. See 2095.
- not feasible for this release.
Our current voting process is at http://cldr.unicode.org/index/process#TOC-Draft-Status-of-Optimal-Field-Value
The key points are:
- For each value, each organization gets a vote
based on the maximum (not cumulative) strength of
the votes of its users who voted on that item.
- If there is a dispute (votes for different
values) within an organization, then the majority vote for that
organization is chosen. If there is a tie, then no vote is counted for
- Let O
be the optimal value's vote,
be the vote of the next best value, and G be the number of
organizations that voted for the optimal value.
- Assign the draft status according to the first
of the conditions below that applies:
|Resulting Draft Status
|approved - critical loc
||O ≥ 8 and O > N
|approved - non-critical loc|| O ≥ 4 and O > N|
||O ≥ 2 and O > N and G ≥ 2
||O ≥ 2 and O ≥
- If the draft status of the previously released
value is better than the new draft status, then no change is made.
Otherwise, the optimal value and its draft status are made part of the
In our previous version, approved
required O ≥ 8.