4 Votes

[Mark Davis ☕️]

Let me set out some of our constraints first—so that people can understand
what we can and can't do—but we'd be glad to take suggestions that would
improve the voting process described on
http://cldr.unicode.org/index/process#resolution_procedure .

Our goal is to be able to let people submit data as easily as possible
(given that we have limited engineering resources). There are two big
issues:

   - How reliable is the data?
      - We have a mechanism in place to signal to consumers of the data an
      indicator of that status, called the 'draft' status.
      - We certainly don't want data that is malicious (like
      http://techcrunch.com/2015/05/11/google-shuts-down-map-maker-following-hacks/)
      or simply misinformed data (which is why we test the consistency of the
      data wherever we can).
   - What is the dispute mechanism?
      - If two or more people disagree, how do we resolve the dispute?
      (ideally, to get the most reliable data).
      - We also need to have stability—we don't want "battling data", where
      a field is X for one release, Y for the next, and then back to X.

We have refined the mechanisms that we use over time. While anyone can
enter data, it is marked provisional or unconfirmed unless we have some
reason to believe that it is more authoritative. We're not in a position to
judge the qualifications of submitters, so for that, we encourage people to
get some body (governmental, academic) that can stand behind their work.
Now, even if authority doesn't exist, the submitted data is still there,
and can be used.

Resolving the disputes is even trickier, and we continue to refine the
mechanisms. For example, if there is a tied dispute within those
representing a given organization, in the past we nullified the
organization's vote. We're changing that to use the most recent vote in the
current release.

If you have concrete suggestions for improving how we do things, we'd love
hearing about them. If you file a ticket, then we can be sure that those
are tracked (and don't fall through the cracks).


Mark <https://google.com/+MarkDavis>

*— Il meglio è l’inimico del bene —*

On Sun, May 17, 2015 at 1:51 PM, Yury Tarasievich <
yury.tarasievich at gmail.com> wrote:

> On 05/17/2015 10:27 PM, Erkki I Kolehmainen wrote:
>
>> Sorry, but it seems to me that you believe to be
>> absolutely right (which I am in no expert
>> position to challenge), but in that case you
>> should be able to convince other language
>> experts and users to support your position and
>> stop insisting that you should be able to
>> override earlier approved values just because
>> you say so. The purpose of the vetting process
>> is to produce generally acceptable values, and
>> the tickets complement it effectively.
>>
>
> The form might be better, but I can identify with the guy, nevertheless.
> This is the kind of a problem sort of built-in in the cldr process. Several
> years ago I just stopped investing the time in the native locale in cldr,
> because of the same issues -- fields being pre-filled on some
> nebulous/undisclosed basis, and then it's sort of irrevokable decision.
> Vetting, yeah, yeah.
>
> -Yury
>
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20150517/0b9d67d9/attachment.html>