4 Votes

[John Emmons]

Thanks Mark for (hopefully) putting this topic to rest.  I take great 
pride in working with the people who contribute tirelessly to this 
project, and there are many of them.

The processes we've put in place over the last decade, while not perfect, 
are there to give us the highest quality data we can.

Open source does not mean uncontrolled source.


Regards,

John C. Emmons
Globalization Architect & Unicode CLDR TC Chairman
IBM Software Group
Internet: emmo at us.ibm.com




From:   Mark Davis ☕️ <mark at macchiato.com>
To:     Yury Tarasievich <yury.tarasievich at gmail.com>
Cc:     "cldr-users at unicode.org" <cldr-users at unicode.org>
Date:   05/17/2015 06:28 PM
Subject:        Re: 4 Votes
Sent by:        "CLDR-Users" <cldr-users-bounces at unicode.org>



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

— 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
_______________________________________________
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/20150518/2a2c88c9/attachment.html>