4 Votes

Mon May 18 12:24:37 CDT 2015

The bar is not high for *adding* language data. The bar is a bit high for
getting the *status* value increased. That's where I think we could use
some suggestions for improvement.

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

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

On Mon, May 18, 2015 at 10:19 AM, Shawn Steele <Shawn.Steele at microsoft.com>
wrote:

>  The weakness in the process is emerging/unsupported languages/markets.
> If one of the big companies isn’t behind a language, it’s kinda hard for
> users to get support for that language.  Granted there’re lots of reasons
> for that, but right now the bar is pretty high.
>
>
>
> -Shawn
>
>
>
> *From:* CLDR-Users [mailto:cldr-users-bounces at unicode.org] *On Behalf Of *John
> Emmons
> *Sent:* Monday, May 18, 2015 6:00 AM
> *To:* Mark Davis [image: ☕]️
> *Cc:* cldr-users at unicode.org; Yury Tarasievich
> *Subject:* Re: 4 Votes
>
>
>
> 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 [image: ☕]️ <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 <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
> _______________________________________________
> 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/a2108ec7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: emoji_u2615.png
Type: image/png
Size: 1616 bytes
Desc: not available
URL: <http://unicode.org/pipermail/cldr-users/attachments/20150518/a2108ec7/attachment-0001.png>