Some people on Mozilla Reps have inappropriate City-State

[Vladimir Krstic]

Some people on Mozilla Reps have politically inappropriate City-State

Greetings,

I've noticed that there are some people on Mozilla Reps site who have set their location as "Prishtina - Kosovo - Albania". Won't point the finger at anyone because I'm not sure is this mistake on site form for setting location or these guys did that intentionally. Still this is absolutely inappropriate and has to be fixed as soon as possible.

Let me explain why. Kosovo set as part of Albania undoubtedly presents idea of Great Albania, in other words idea of separatism under radical Islamic movement. Idea of tearing apart lands of Greece, Montenegro, Macedonia and more lands of Serbia on top of Kosovo. Separatism is "well" regulated by UN conventions and world law after World War Two. That being said it's absolutely inappropriate that this kind of ideas are presented through Mozilla channels. Lot of people can be offended by it, for example in Ukraine, Spain, United Kingdom, and of course Balkan countries I've mentioned before. To evade any confusion because I'm from Serbia - I don't say that Kosovo isn't independent or that is part of Serbia. I say that is not part of Albania.

There were various incidents with Albanian terrorist in Greece, Macedonia, Montenegro and Serbia in last ten years and there are lot of articles on internet about Great Albania so this topic is easy to confirm. Right now when I write this Albanian terrorist from Kosovo are attacking Macedonia with call to tear apart these parts of Macedonia.

Please work this out, investigate why these people have there location set like so and fix it.

Vladimir Krstic

[Michael Cooper]

I don't work on or with the Reps site, but I took a quick look at the code
for it [0]. The location fields on the Mozilla Reps site are arbitrary text
fields that users can enter whatever they like into. It was the users
choice to enter this inappropriate location. This isn't a choice Mozilla
actively made, nor any developer in the system, but likely something that
the reps in question chose to enter in their profiles. I'd suggest
contacting the people in question personally and directly about this issue.

[0]:
https://github.com/mozilla/remo/blob/master/remo/profiles/models.py#L101-L103

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>

[Majken Connor]

Reps portal uses OpenStreetMap. I believe before we had the user editable
fields you had to select a location on a map (though my memory could be
failing me on this). I have a memory of people complaining about it turning
up as Albania, but I couldn't find anything in my email history to confirm
that memory. It's possible that OpenStreetMap used to get this wrong, and
these Reps haven't updated their location since the portal was updated to
allow you to input the location yourself.

I've added Pierros who can correct me on any of this.

[Sheeri Cabral]

Majken - you may be referring to this, on the Mozillians Yammer:

https://www.yammer.com/mozillians/#/threads/show?threadId=518381225&messageId=518381225

--
-Sheeri Cabral
Manager, Data Team at Mozilla

File a bug for the Data Team -
https://bugzilla.mozilla.org/enter_bug.cgi?product=Data%20%26%20BI%20Services%20Team
Find the Data team on #data on irc.mozilla.org

[Majken Connor]

No, that doesn't look old enough. If I'm remembering correctly then it
would have been when the portal was first launched, and I could also be
remembering a discussion from a council meeting which wouldn't then be in
my email. Also, since we're talking a few years ago, I could just be
reconstructing a false memory!

[Gervase Markham]

On 12/05/15 03:57, Majken Connor wrote:
> Reps portal uses OpenStreetMap. I believe before we had the user editable
> fields you had to select a location on a map (though my memory could be
> failing me on this). I have a memory of people complaining about it turning
> up as Albania, but I couldn't find anything in my email history to confirm
> that memory. It's possible that OpenStreetMap used to get this wrong, and
> these Reps haven't updated their location since the portal was updated to
> allow you to input the location yourself.

That makes a lot of sense. There are several profiles which have this in
exactly the same form - as three linked words - and unless there has
been coordination, it seems unlikely that this will have happened by
accident.

Perhaps the next step is for someone to politely email these people and
point out that the field is now freeform text, that Kosovo is not in
Albania, and perhaps they might consider updating their profile?

If someone refuses on Albanian nationalist grounds, then come back. But
it may be that everyone agrees.

Gerv

[Pierros Papadeas]

Hey all,

Quick background on the issue raised:

- This has been raised 3 years ago when we first deployed the portal.
- The programmatic decision (which still stands) is that Country is a
drop-down list (coming from product-details, so not Reps specific) and
everything else is free-form field. [1]
- Kosovo is not included in product-details as a Country. [2]
- Those individuals have been contacted in the past multiple times,
and they are not willing to change their profile.

Personal comment (Reps module-owner-hat on): People should be free to
self-report what they want on their profiles.

Cheers,

~pierros

[1] https://github.com/mozilla/django-product-details
[2] http://svn.mozilla.org/libs/product-details/json/regions/en-US.json

On Tue, May 12, 2015 at 6:14 PM, Gervase Markham <ge...@mozilla.org> wrote:
> On 12/05/15 03:57, Majken Connor wrote:

>> Reps portal uses OpenStreetMap. I believe before we had the user editable
>> fields you had to select a location on a map (though my memory could be
>> failing me on this). I have a memory of people complaining about it turning
>> up as Albania, but I couldn't find anything in my email history to confirm
>> that memory. It's possible that OpenStreetMap used to get this wrong, and
>> these Reps haven't updated their location since the portal was updated to
>> allow you to input the location yourself.
>

[Boris Zbarsky]

On 5/12/15 11:28 AM, Pierros Papadeas wrote:
> - Kosovo is not included in product-details as a Country. [2]

Wait. Why not? This makes no sense to me.

At least assuming this is meant to be a "list of countries Reps might
live in". If it's not meant to be that, then we shouldn't be using it
that way.

> - Those individuals have been contacted in the past multiple times,
> and they are not willing to change their profile.

Change it to what? If the only options we are giving them are to list
their country as "Albania" or to list it as "Serbia", I can totally
understand them not wanting to switch from the former to the latter.

What was the actual request made here, if I might ask?

> Personal comment (Reps module-owner-hat on): People should be free to
> self-report what they want on their profiles.

This is in flat-out contradiction with having a predetermined list of
countries to pick from. Especially a list that doesn't even include all
the countries people live in.

-Boris

[Fred Wenzel]

On Tue, May 12, 2015 at 9:05 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 5/12/15 11:28 AM, Pierros Papadeas wrote:
>

>> - Kosovo is not included in product-details as a Country. [2]
>>
>

> Wait. Why not? This makes no sense to me.
>

I filed the request for this over 3 years ago[1]. At the time, it did not
go anywhere because ISO 3166 did not have a country code for Kosovo, and
that part of product details deals with ISO codes.

This state hasn't changed, the interim code "XK" that I suggested we use
remains[2].

> At least assuming this is meant to be a "list of countries Reps might live
> in". If it's not meant to be that, then we shouldn't be using it that way.
>

> - Those individuals have been contacted in the past multiple times,
>> and they are not willing to change their profile.
>>
>

> Change it to what? If the only options we are giving them are to list
> their country as "Albania" or to list it as "Serbia", I can totally
> understand them not wanting to switch from the former to the latter.
>
> What was the actual request made here, if I might ask?
>
>

I presume, the request would be to change it to "Kosovo" (meaning the
Republic of Kosovo, as recognized by 108 UN member states[3]).

I suggest the following:
- After a few years of deliberation, let's land Kosovo with country code
"xk" in product details. It'll just be in there, no one needs to use it if
they don't want to. I am still happy to patch and land that 1-liner patch.
- We can then suggest to the Mozillians in question that they can choose
Kosovo as their country if they so desire, but they are not required to.


By the way, the other country in that bug, South Sudan, also hasn't landed.
It *does* have an ISO country code ("ss") and is recognized by 123 other
countries[4]. Happy to land that too, unless there are remaining blockers
for that to proceed.


Opinions?

Fred


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=733417
[2] https://en.wikipedia.org/wiki/Kosovo
[3] http://en.wikipedia.org/wiki/International_recognition_of_Kosovo
[4]
http://en.wikipedia.org/wiki/Foreign_relations_of_South_Sudan#Chronology_of_relations

[Boris Zbarsky]

On 5/12/15 12:45 PM, Fred Wenzel wrote:
> I filed the request for this over 3 years ago[1]. At the time, it did not
> go anywhere because ISO 3166 did not have a country code for Kosovo, and
> that part of product details deals with ISO codes.
>
> This state hasn't changed, the interim code "XK" that I suggested we use
> remains[2].

OK, sounds like "product details" is the wrong tool for this job if it
requires ISO 3166 country codes. Or we should stop requiring them, or
something.

> I presume, the request would be to change it to "Kosovo"

This can't be what the request _was_, since picking "Kosovo" is not an
option right now, yes?

I agree that's what the request _should_ be, after we make it possible
to pick it.

> I suggest the following:
> - After a few years of deliberation, let's land Kosovo with country code
> "xk" in product details. It'll just be in there, no one needs to use it if
> they don't want to. I am still happy to patch and land that 1-liner patch.
> - We can then suggest to the Mozillians in question that they can choose
> Kosovo as their country if they so desire, but they are not required to.

This sounds great to me, given the limited information I have here..

> By the way, the other country in that bug, South Sudan, also hasn't landed.
> It *does* have an ISO country code ("ss") and is recognized by 123 other
> countries[4]. Happy to land that too, unless there are remaining blockers
> for that to proceed.

This sounds like a good idea too.

-Boris

[Adam Roach]

On 5/12/15 12:11, Boris Zbarsky wrote:
> On 5/12/15 12:45 PM, Fred Wenzel wrote:

...

>
>> I suggest the following:
>> - After a few years of deliberation, let's land Kosovo with country code
>> "xk" in product details. It'll just be in there, no one needs to use
>> it if
>> they don't want to. I am still happy to patch and land that 1-liner
>> patch.
>> - We can then suggest to the Mozillians in question that they can choose
>> Kosovo as their country if they so desire, but they are not required to.
>

> This sounds great to me, given the limited information I have here..

We should not be taking actions that make it look like Mozilla is trying
to independently determine what is and what isn't a country.

Delegating this determination to a body like ISO is reasonable and safe,
which is why organizations like IANA rely rather strictly on ISO's
assignments [1]. In particular, we should avoid making political
statements -- no matter how unintentional -- by omitting official codes
(like SS) or including unofficial ones (such as XK).

This means that we should act with reasonable haste to update our own
records whenever ISO issues an update, and we should reproduce the
officially assigned list verbatim. For ease of automation, there is a
subscription service (~US$350/year) provided by ISO for this purpose;
see https://www.iso.org/obp/ui/#iso:pub:PUB500001:en

The danger with the proposal above is that adding an unofficial code
sets a precedent that puts Mozilla in the position of having to make
judgement calls if someone were to request that we add X* country codes
for places like Tibet, Northern Cyprus, Chechnya, Catalonia, Kurdistan,
and ISIL. I'm not saying that any of these situations are directly
comparable to Kosovo; merely that each has a set of political
considerations that Mozilla is not in a position to safely evaluate.

____
[1] From RFC 1951, section 4: "The IANA is not in the business of
deciding what is and what is not a country. The selection of the ISO
3166 list as a basis for country code top-level domain names was made
with the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."

--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863

[Boris Zbarsky]

On 5/12/15 3:00 PM, Adam Roach wrote:
> We should not be taking actions that make it look like Mozilla is trying
> to independently determine what is and what isn't a country.

Then we should just make the "country" field here freeform and be done
with it.

> Delegating this determination to a body like ISO is reasonable and safe,
> which is why organizations like IANA rely rather strictly on ISO's
> assignments [1]. In particular, we should avoid making political
> statements -- no matter how unintentional -- by omitting official codes
> (like SS) or including unofficial ones (such as XK).

We're making a political statement right now by requiring people who
live in Kosovo to pick either "Serbia" or "Albania" as a country.

> The danger with the proposal above is that adding an unofficial code
> sets a precedent that puts Mozilla in the position of having to make
> judgement calls if someone were to request that we add X* country codes
> for places like Tibet, Northern Cyprus, Chechnya, Catalonia, Kurdistan,
> and ISIL. I'm not saying that any of these situations are directly
> comparable to Kosovo; merely that each has a set of political
> considerations that Mozilla is not in a position to safely evaluate.

That seems fair. That argument supports not using a country code here
at all and just making it a freeform field.

-Boris

[Mike Hoye]

On 2015-05-12 3:00 PM, Adam Roach wrote:
>
> We should not be taking actions that make it look like Mozilla is
> trying to independently determine what is and what isn't a country.

Pointing to the spec and washing our hands of the question is just as
much of a political statemet as making up our own list would be.

For what it's worth I think there's a third way, and deferring to
individual Mozillians' decisions about self-representation is preferable
to, and better in-line with our values than, adherence to any IANA/ISO
spec or inventing our own.


- mhoye

[Adam Roach]

On 5/12/15 14:11, Boris Zbarsky wrote:

> On 5/12/15 3:00 PM, Adam Roach wrote:
>> We should not be taking actions that make it look like Mozilla is trying
>> to independently determine what is and what isn't a country.
>

> Then we should just make the "country" field here freeform and be done
> with it.

Depending on how we use that field, that may be okay. Freeform makes
comparison and localization difficult. If you want to search for users
in a specific country, for example, you have to deal with issues around
misspellings, alternate alphabets, full versus short form country names,
inclusion of articles, different transliterations, etc. The goal of ISO
country codes was to eliminate this variability.

>
>> Delegating this determination to a body like ISO is reasonable and safe,
>> which is why organizations like IANA rely rather strictly on ISO's
>> assignments [1]. In particular, we should avoid making political
>> statements -- no matter how unintentional -- by omitting official codes
>> (like SS) or including unofficial ones (such as XK).
>

> We're making a political statement right now by requiring people who
> live in Kosovo to pick either "Serbia" or "Albania" as a country.

No, we aren't -- at least, we wouldn't be if we kept up to date with ISO
3166-1. It would be ISO's political statement, and it's identical to the
situation in which people in Kosovo need to pick either "Serbia" or
"Albania" when selecting a ccTLD to register under.

[Boris Zbarsky]

On 5/12/15 3:23 PM, Adam Roach wrote:
> It would be ISO's political statement

That may technically be true, but is not necessarily true as a matter of
perception.

-Boris

[Adam Roach]

On 5/12/15 14:16, Mike Hoye wrote:
> Pointing to the spec and washing our hands of the question is just as
> much of a political statemet as making up our own list would be.

No, it's delegating the problem to a competent body that has a specific
and detailed process for maintaining the information; that has tight
coordination with the United Nations; and that has representation from
the community that is authoritative on the matter (i.e., member states).

It would be an act of hubris befitting of Phaethon to think that Mozilla
would be able to step into that role without hitting catastrophic
political land-mines.

[Gervase Markham]

On 12/05/15 17:45, Fred Wenzel wrote:
> By the way, the other country in that bug, South Sudan, also hasn't landed.
> It *does* have an ISO country code ("ss") and is recognized by 123 other
> countries[4]. Happy to land that too, unless there are remaining blockers
> for that to proceed.

It'll be well more than 123 others now; that data looks old. South Sudan
is clearly a country; no-one else is claiming rights to it. We should
fix this.

Gerv

[Gervase Markham]

On 12/05/15 20:00, Adam Roach wrote:
> We should not be taking actions that make it look like Mozilla is trying
> to independently determine what is and what isn't a country.

That is very true. The best solution, however, is not to make the field
freeform, which has problems that others outline, but to stop labelling
it simply as "country".

Currently, in the rep profile public UI, it's labelled "location". If
there is a "country" field in the editing screen, instead we should
label it "country or territory", and accept any reasonable requests for
addition which represent an area of land.

This may mean we have the Catalan separatists asking for a listing for
"Catalonia" because they don't want to say "Spain", but if the other
option is requiring people in Kosovo to choose between "Serbia" and
"Albania", I'd say this is a better system.

Another option would be to make the country field non-mandatory (or is
it already?) and suggest that residents of Kosovo leave it unset.

Gerv

[Adam Roach]

On 5/13/15 05:01, Gervase Markham wrote:
> This may mean we have the Catalan separatists asking for a listing for
> "Catalonia" because they don't want to say "Spain"

That's a highly uncontroversial example, given that the area is
uncontentiously recognized as Catalonia. Your proposal only sounds
reasonable on its surface because you're ignoring the more problematic
designations I mentioned, like Kurdistan and ISIL.

This is a politically charged area with subtleties that would take
entire careers in political science to correctly understand, and it
could have real consequences that are difficult to foresee (would adding
Tibet to the list get the reps site blocked in China?). Mozilla doesn't
have the expertise to make reasonable decisions regarding what to
include and what to exclude in a list, and attempting to muddle our way
through it will be an incredible distraction.

[Adam Roach]

On 5/13/15 05:01, Gervase Markham wrote:

> Another option would be to make the country field non-mandatory

I think this is the cleanest way forward. Abstaining from providing
information like this in a profile should always be an option.

[Gervase Markham]

On 13/05/15 14:54, Adam Roach wrote:
> That's a highly uncontroversial example, given that the area is
> uncontentiously recognized as Catalonia. Your proposal only sounds
> reasonable on its surface because you're ignoring the more problematic
> designations I mentioned, like Kurdistan and ISIL.

Kurdistan is a valid name for a region, recognised by the country (Iraq)
in which it sits. Assuming the field is named "Country or region", then
there would be no political problem.
(http://en.wikipedia.org/wiki/Iraqi_Kurdistan notes "also known as the
Kurdistan Region ... The region is officially governed by the Kurdistan
Regional Government.")

> This is a politically charged area with subtleties that would take
> entire careers in political science to correctly understand, and it
> could have real consequences that are difficult to foresee (would adding
> Tibet to the list get the reps site blocked in China?).

Tibet is a valid name for a region, recognised by the country (China) in
which it sits. Assuming the field is named "Country or region", then
there would be no political problem.

I'm fairly sure this is a common way to solve this problem. I bought a
map the other day, which had the equivalent in the key of:

- - - - : country boundary
- - - - : regional boundary

i.e. the two were denoted the same. They just then ran this along both
borders of a disputed area.

The only example you have which might be problematic is ISIS, and I
doubt we'll get anyone from there.

I recognise the issues you are pointing out, but it turns out people
need to find a way of living, and so we are not the first people to hit
this problem, and it is not one with no solution.

Gerv

[Adam Roach]

On 5/13/15 09:17, Gervase Markham wrote:
> The only example you have which might be problematic is ISIS, and I
> doubt we'll get anyone from there.

You're making a class/instance error here. As an instance of a problem,
I suspect you're right. As a class of problem, much less so.

> I recognise the issues you are pointing out, but it turns out people
> need to find a way of living, and so we are not the first people to hit
> this problem, and it is not one with no solution.

Sure, and the other people who have hit this problem have deferred to
organizations who have expertise in the area. In the same way as the
United Nations could not reasonably offer an informed opinion on best
practices for multithreaded process synchronization, Mozilla does not
have any reasonable basis to make the kinds of determinations that
you're claiming we should.

In any case, it seems that we both agree that having a list of
ISO-identified country codes combined with an option to simply not
select a value is an adequate solution, which would seem to make the
rest of the discussion academic.

[Gervase Markham]

On 13/05/15 15:31, Adam Roach wrote:
> Sure, and the other people who have hit this problem have deferred to
> organizations who have expertise in the area. In the same way as the
> United Nations could not reasonably offer an informed opinion on best
> practices for multithreaded process synchronization, Mozilla does not
> have any reasonable basis to make the kinds of determinations that
> you're claiming we should.

You persist in claiming that my solution results in us making claims
about what is a country. It does not. In almost every case, people who
deny a particular named area is a country will accept that it is a
region. So if we put it in a field labelled "country or region" everyone
is happy; some people can believe it's a country, some people can
believe it's a region, and we don't have to specify which we are saying
it is.

> In any case, it seems that we both agree that having a list of
> ISO-identified country codes combined with an option to simply not
> select a value is an adequate solution, which would seem to make the
> rest of the discussion academic.

That would also work, if not selecting a value was acceptable to the
site maintainers.

Gerv

[Majken Connor]

The last set of posts are focusing heavily on how to solve the political
problem and ignoring the use case of the Reps portal. Adam pointed out " If

you want to search for users in a specific country, for example, you have
to deal with issues around misspellings, alternate alphabets, full versus
short form country names, inclusion of articles, different
transliterations, etc. The goal of ISO country codes was to eliminate this

variability," and this is exactly the point of having location information
on the Reps portal. People need to be able to find Reps near them, or in a
particular region.

I don't see how saying "we are going to use some sort of official list of
country codes" is a political statement, and certainly doesn't compare to
"we are going to actively choose which countries we recognize. By actively
choosing which countries we recognize it is much harder to deny support for
those political movements. However if we are using a 3rd party list where
we haven't made individual choices, we could still say that we support
those political movements and hope that they have success in being
recognized by the 3rd party (which I doubt we'd do anyway).

It would be interesting to consider the option of including any and all
country codes and allowing the user to choose. That would also allow
Mozilla to say that it is the individual who is making the political
statement. In the case of the Reps portal as well, it may be useful
information, depending on how high tensions are in a region it might be
best to allow people to choose someone in Kosovo who identifies with the
same country as themselves. Though I think the cons here would outweigh the
pros. Reps could then be targeted for their political affiliations, by each
other (hopefully this is unlikely!) or by outsiders.

On Wed, May 13, 2015 at 10:34 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 13/05/15 15:31, Adam Roach wrote:

> > Sure, and the other people who have hit this problem have deferred to
> > organizations who have expertise in the area. In the same way as the
> > United Nations could not reasonably offer an informed opinion on best
> > practices for multithreaded process synchronization, Mozilla does not
> > have any reasonable basis to make the kinds of determinations that
> > you're claiming we should.
>

> You persist in claiming that my solution results in us making claims
> about what is a country. It does not. In almost every case, people who
> deny a particular named area is a country will accept that it is a
> region. So if we put it in a field labelled "country or region" everyone
> is happy; some people can believe it's a country, some people can
> believe it's a region, and we don't have to specify which we are saying
> it is.
>

> > In any case, it seems that we both agree that having a list of
> > ISO-identified country codes combined with an option to simply not
> > select a value is an adequate solution, which would seem to make the
> > rest of the discussion academic.
>

> That would also work, if not selecting a value was acceptable to the
> site maintainers.
>
> Gerv
>
>

[Fred Wenzel]

On Wed, May 13, 2015 at 9:41 AM, Majken Connor <maj...@gmail.com> wrote:

> It would be interesting to consider the option of including any and all
> country codes and allowing the user to choose. That would also allow
> Mozilla to say that it is the individual who is making the political
> statement.
>

> I think that is reasonable, however, it's at the core of what is being
debated here. What is the measure for including a country? In the case of
Kosovo, it is *not* a UN member state because it is recognized by 108 UN
member state, but not by the remaining 85, and it is disputed by one.

The comparison to other regions that Adam made are not helpful because they
tend to not have as wide an acceptance, if any at all.

Kosovo is not listed in ISO 3166, albeit in the CIA World Factbook[1] which
takes its list from a US federal information processing standard (FIPS,
meanwhile superseded by GENC)[2].

If we defer to a third party entity, which we probably should, there's a
question which. Our choice of ISO 3166 has left many unhappy because it
pivots on UN membership. For the same reason, the US government issues the
GENC standard which is a superset of ISO 3166.

I took the freedom to diff GENC against our (normalized) region data:
https://gist.github.com/fwenzel/5259ec6ec8b98d90cab1

Not a patch that can land this way, but it outlines pretty well the
problems caused by strict adherence to ISO 3166 and the regions that we
might want to mention in addition to that.

~F

[1]
https://www.cia.gov/library/publications/the-world-factbook/appendix/appendix-d.html
[2] http://www.fgdc.gov/standards/news/GENC

[Adam Roach]

On 5/13/15 15:06, Fred Wenzel wrote:

> The comparison to other regions that Adam made are not helpful because
> they tend to not have as wide an acceptance, if any at all.

You're highlighting the exact danger that I'm warning about: creating
our own subjective guidelines around how much recognition is "enough" is
exactly the kind of evaluation that Mozilla ill-equipped to make.

> If we defer to a third party entity, which we probably should, there's
> a question which. Our choice of ISO 3166 has left many unhappy because
> it pivots on UN membership. For the same reason, the US government
> issues the GENC standard which is a superset of ISO 3166.

If we were a US-only project with a US-focused mission, I would agree
that FIPS/GENC would make sense.

However, given the worldwide nature of the project, I'd argue that it
makes much more sense to use a list determined by a multilateral group
of worldwide entities rather than a unilateral declaration published by
a single country.

[Gijs Kruitbosch]

This is all pretty hairy. The Netherlands Antilles has changed status so
often over the course of my (short!) lifetime that I honestly forget
what its statehood status is at this point. Checking wikipedia, it seems
Bonaire, Sint Eustatius and Saba are now part of a single municipality
that's part of the Netherlands (not to be confused with the Kingdom of
The Netherlands, which besides the Netherlands includes 3 other
constituent countries, namely Aruba, St. Maarten and Curaçao - and
citizens of all 4 of these constituent countries share a single
nationality, Dutch).

In other words, neither ISO 3166 nor the GENC are really correct here,
and although the recent past included a lot of changes, there is, to the
best of my knowledge, not as much controversy over the status of these
islands as there is over some of the other examples in this thread.

My point being, I am feeling more and more skeptical about our ability
to have an uncontroversial, 100% correct list at all times. It seems
like a freeform text field would be simpler.

If we're trying to provide people the ability to find others who are
co-located within some margin of error, why not allow people to just
stick a pin on a map and take lat/long information from there, maybe
with a radius to create some anonymity and avoid privacy issues for
those who are concerned about that?

~ Gijs

[Fred Wenzel]

On Wed, May 13, 2015 at 1:23 PM, Adam Roach <a...@mozilla.com> wrote:

> On 5/13/15 15:06, Fred Wenzel wrote:
>

> The comparison to other regions that Adam made are not helpful because
> they tend to not have as wide an acceptance, if any at all.
>

> You're highlighting the exact danger that I'm warning about: creating our
> own subjective guidelines around how much recognition is "enough" is
> exactly the kind of evaluation that Mozilla ill-equipped to make.
>
>

Of course, glad you understood my point.

> If we defer to a third party entity, which we probably should, there's a
> question which. Our choice of ISO 3166 has left many unhappy because it
> pivots on UN membership. For the same reason, the US government issues the
> GENC standard which is a superset of ISO 3166.
>
>

> If we were a US-only project with a US-focused mission, I would agree that
> FIPS/GENC would make sense.
>
> However, given the worldwide nature of the project, I'd argue that it
> makes much more sense to use a list determined by a multilateral group of
> worldwide entities rather than a unilateral declaration published by a
> single country.
>
>

I agree with that, though you are skirting the question of how big the
multilateral group of worldwide entities has to be to satisfy your
requirement for universal acceptance.

For the sake of comparison, here is what we currently have, compared to the
current state of ISO 3166:

https://gist.github.com/fwenzel/8848aebe89e349367719

Spellings aside, we're missing the territories created by the dissolution
of the Netherlands Antilles, as well as South Sudan.


Looks like retaining ISO 3166 is the lowest common denominator, in which
case the reply to OP should be: "They cannot pick where they live because
the region is not recognized by the group we choose to take the list from".
Case closed.

~F

PS: For further entertainment, I *can* become a W3C members if I find
myself to be a Kosovan: https://www.w3.org/Consortium/fees

[Majken Connor]

> If we're trying to provide people the ability to find others who are
> co-located within some margin of error, why not allow people to just stick
> a pin on a map and take lat/long information from there, maybe with a
> radius to create some anonymity and avoid privacy issues for those who are
> concerned about that?
>

There are some issues with this, though I'm not suggesting they are
insurmountable.

1. If you drop a pin in a map, you are providing incredibly accurate
location information, more specific than city level, and city level is as
specific as I am comfortable being myself. When we did have to do this, I
dropped the pin downtown, which is about 1h via transit from my house. So
it is fine for me, but it wouldn't work if someone were assuming the pin
drop were accurate and chose to reach out to me because of it (this seems
edge casey, and easily resolved after a short exchange).

2. Language and borders matter, and they matter more depending on where you
are. There is another Rep in Michigan who is closer to me than others in my
own country, but collaborating in person would require one of us to have a
passport and to cross the border. I actually inadvertently got John
Karahalis in minor "trouble" with customs because he was coming up once a
month to help with a regular event I was running. Would results presented
this way make it easy enough for a person searching to distinguish between
results in the desired country or would they have to mentally filter the
results to make them useful?

3. How would the person search? Would they have to equally put a pin in the
map? The current map allows you to zoom and pan, and gives you a list of
results based on which Reps are within your view. I've actually used this
functionality before and found it superior to a text search for the task I
was doing. However if I were going to try to find a list of Reps in Canada,
this wouldn't work so well.


I also want to point out that we should focus on what outcomes we're after
here. Are we just talking about improving the Reps portal or are we
suggesting Mozilla needs a policy on country selection (which would affect
other sites as well, eg Mozillians)? Most of the arguments here seem to be
ideologically based and so I assume are aimed at accomplishing the latter.
If that's the case, then who would be in charge of setting such a policy
once we're done giving our suggestions and who would be in charge of
implementing it? And really we should first ask who decides if Mozilla is
interested in having such a policy?

If we're talking about the former, and just trying to improve the Reps
portal then the suggestions should really be framed around the use case for
country search on Reps, as well as how realistic implementation of the
suggestions would be. Obviously updating the country code list, or changing
our source for such a list would be much easier to implement than an idea
that reworks the profile system.

BTW, it seems like Mozillians used to have the same problem, the results I
see for people in Kosovo say the are in Albania, however if I try to change
my location now it does offer Kosovo as a country. I believe Mozillians
used to allow you to freeform your location and now it seems like it uses
OpenStreetMaps locations.

[Kan-Ru Chen (陳侃如)]

Adam Roach <a...@mozilla.com> writes:

> On 5/12/15 12:11, Boris Zbarsky wrote:
>> On 5/12/15 12:45 PM, Fred Wenzel wrote:
> ...
>>

>>> I suggest the following:
>>> - After a few years of deliberation, let's land Kosovo with country code
>>> "xk" in product details. It'll just be in there, no one needs to
>>> use it if
>>> they don't want to. I am still happy to patch and land that 1-liner
>>> patch.
>>> - We can then suggest to the Mozillians in question that they can choose
>>> Kosovo as their country if they so desire, but they are not required to.
>>

>> This sounds great to me, given the limited information I have here..
>

> We should not be taking actions that make it look like Mozilla is
> trying to independently determine what is and what isn't a country.
>

> Delegating this determination to a body like ISO is reasonable and
> safe, which is why organizations like IANA rely rather strictly on
> ISO's assignments [1]. In particular, we should avoid making political
> statements -- no matter how unintentional -- by omitting official
> codes (like SS) or including unofficial ones (such as XK).

The ISO-3166 standard is controversial. It only presents the member
states' view. Many organizations have already changed to use regions
instead of countries because of this issue. See
http://iso3166.github.io/ for some of them.

> This means that we should act with reasonable haste to update our own
> records whenever ISO issues an update, and we should reproduce the
> officially assigned list verbatim. For ease of automation, there is a
> subscription service (~US$350/year) provided by ISO for this purpose;
> see https://www.iso.org/obp/ui/#iso:pub:PUB500001:en
>

> The danger with the proposal above is that adding an unofficial code
> sets a precedent that puts Mozilla in the position of having to make
> judgement calls if someone were to request that we add X* country
> codes for places like Tibet, Northern Cyprus, Chechnya, Catalonia,
> Kurdistan, and ISIL. I'm not saying that any of these situations are
> directly comparable to Kosovo; merely that each has a set of political
> considerations that Mozilla is not in a position to safely evaluate.
>

[Gervase Markham]

On 14/05/15 07:48, Kan-Ru Chen (陳侃如) wrote:
> The ISO-3166 standard is controversial. It only presents the member
> states' view. Many organizations have already changed to use regions
> instead of countries because of this issue. See
> http://iso3166.github.io/ for some of them.

That page lists one more example of a project which has taken my
proposed "Country or Region" approach - FreeBSD.

Gerv

[Tim Guan-tin Chien]

On Thu, May 14, 2015 at 6:03 PM, Gervase Markham <ge...@mozilla.org> wrote:
> On 14/05/15 07:48, Kan-Ru Chen (陳侃如) wrote:

>> The ISO-3166 standard is controversial. It only presents the member
>> states' view. Many organizations have already changed to use regions
>> instead of countries because of this issue. See
>> http://iso3166.github.io/ for some of them.
>

> That page lists one more example of a project which has taken my
> proposed "Country or Region" approach - FreeBSD.
>
> Gerv
>

Agreed. The Mozilla Project should just draft a formal policy like what
FreeBSD did, and stay apolitical by keeping a reasonable distance from the
ISO-3166 list. For years I have seen patches and website projects
accidentally go live without annotating the list nor understanding the
problem.

There should be a stakeholder who could stand up and fix this once and for
all. With a policy there will be a guideline to follow, and we can simply
identify any future instances as human error, instead of engaging in debate
like this thread again and again. There are more productive things to do
for the project.

Simply put, the project cannot afford any more feeling of resentment or
alienation. We won't go afar with dysfunction like this.

Thanks,


Tim

[Robert Kaiser]

Pierros Papadeas schrieb:
> - The programmatic decision (which still stands) is that Country is a
> drop-down list (coming from product-details, so not Reps specific) and
> everything else is free-form field. [1]

I think nowadays this should be revised. The Reps portal should not save
that info (and some others) separately, but instead should be coupled
with Mozillians via API and pull that data from there. It's reasonable
to require every Rep to be a registered Mozillian (and why probably do
that already).

As a side effect, the original problem would be solved as Mozillians
actually allows "Kosovo" as a country from what I saw.

KaiRo

[Mike Connor]

The world is a messy, complicated place. This is not the first or the last
time we'll be faced with conflict over various types of recognition. In my
time with the project, we've faced calls to remove and disavow entire
localizations, such as Macedonian and Kurdish, on similar
political/nationalist grounds. In general, we should steer clear of
politics outside of issues clearly tied to the Mozilla mission. To me,
that means we should be permissive, not prescriptive. To do otherwise
feels unnecessarily exclusionary.

Like Tim, I don't believe it makes sense to rely exclusively on ISO-3166.
All lists have inherent bias, and as a result crisp compliance with a
standard will inevitably be out of date (South Sudan) or create unnecessary
tension (i.e. Kosovo is neither Albanian or Serbian). We gain nothing by
passing the buck, and risk alienating members of our community in the
process.

I really like the FreeBSD policy, which aims to avoid sovereignty arguments.

http://www.freebsd.org/internal/i18n.html

> When listing countries or other geographic areas in documentation, menus,
mirror/FTP lists, or other contexts, it is important to introduce such
lists as "Countries or Regions" so that an implied sovereignty claim is
neither made nor denied to those regions which have their own top level
domains.

> The ISO 3166 country codes do not necessarily refer to nation-states
(e.g. Hong Kong) and should not be treated as such. Likewise the "official"
ISO 3166 short English names for those countries and regions which have top
level domains are in some cases controversial, and not all of them are
commonly used in the software industry.

> We follow the guidelines used by IBM, Microsoft, Google, and other
prominent software companies in their documentation in that Taiwan should
never be included with a distinction referring to the Republic of China,
People's Republic of China, or a national flag. Interpretation of the word
"Taiwan" is in the eye of the beholder, and The FreeBSD Project does not
endorse any particular position.
Robert's idea to share from Mozillians is a smart idea, and we should
really do that. It won't change the core question (how to resolve this sort
of territory question) so I think it's still a valid discussion, which is
why adopting a policy like FreeBSD's is appealling.

-- Mike

On 13 May 2015 at 16:23, Adam Roach <a...@mozilla.com> wrote:

> On 5/13/15 15:06, Fred Wenzel wrote:
>
> The comparison to other regions that Adam made are not helpful because
>> they tend to not have as wide an acceptance, if any at all.
>>
>
> You're highlighting the exact danger that I'm warning about: creating our
> own subjective guidelines around how much recognition is "enough" is
> exactly the kind of evaluation that Mozilla ill-equipped to make.
>
>

> If we defer to a third party entity, which we probably should, there's a
>> question which. Our choice of ISO 3166 has left many unhappy because it
>> pivots on UN membership. For the same reason, the US government issues the
>> GENC standard which is a superset of ISO 3166.
>>
>
> If we were a US-only project with a US-focused mission, I would agree that
> FIPS/GENC would make sense.
>
> However, given the worldwide nature of the project, I'd argue that it
> makes much more sense to use a list determined by a multilateral group of
> worldwide entities rather than a unilateral declaration published by a
> single country.
>
>

> --
> Adam Roach
> Principal Platform Engineer
> a...@mozilla.com
> +1 650 903 0800 x863

[Adam Roach]

On 5/22/15 16:07, Mike Connor wrote:
> The world is a messy, complicated place. This is not the first or the last
> time we'll be faced with conflict over various types of recognition. In my
> time with the project, we've faced calls to remove and disavow entire
> localizations, such as Macedonian and Kurdish, on similar
> political/nationalist grounds. In general, we should steer clear of
> politics outside of issues clearly tied to the Mozilla mission. To me,
> that means we should be permissive, not prescriptive. To do otherwise
> feels unnecessarily exclusionary.
>
> Like Tim, I don't believe it makes sense to rely exclusively on ISO-3166.
> All lists have inherent bias, and as a result crisp compliance with a
> standard will inevitably be out of date (South Sudan) or create unnecessary
> tension (i.e. Kosovo is neither Albanian or Serbian). We gain nothing by
> passing the buck, and risk alienating members of our community in the
> process.
>
> I really like the FreeBSD policy, which aims to avoid sovereignty arguments.
>
> http://www.freebsd.org/internal/i18n.html

The FreeBSD policy skirts the Kosovo issue in exactly the same way as I
proposed earlier: it punts the question as to whether to include it in
the list to ISO.

And the only issue with South Sudan is that Mozilla hasn't kept up with
the ISO list. South Sudan has been part of the official ISO list for a
long while. The error here is on Mozilla's part, and I support
rectifying that as soon as possible.

The FreeBSD policy boils down to two key points:

1. Don't call the things defined in ISO3166-1 "countries" -- call them
"countries or regions", and
2. Modify the official names for ISO codes when the official names are
controversial and a less controversial alternative is available.


I don't find anything in there to disagree with. I think it's a good policy.

But it doesn't support your argument that we should use a modified
version of ISO3166-1. That is delving quite squarely into, as you put
it, "politics outside of issues clearly tied to the Mozilla mission."

[Mike Connor]

> The FreeBSD policy skirts the Kosovo issue in exactly the same way as I
> proposed earlier: it punts the question as to whether to include it in the
> list to ISO.
>

It does? That wasn't my reading, it explicitly rejects the naming
conventions of ISO 3166 (which has TW as "Taiwan (Province of China)" and
otherwise does not require the usage of ISO 3166, at least not at that link.

> I don't find anything in there to disagree with. I think it's a good
> policy.
>
> But it doesn't support your argument that we should use a modified version
> of ISO3166-1. That is delving quite squarely into, as you put it, "politics
> outside of issues clearly tied to the Mozilla mission."

I think it's patently absurd (and likely offensive to those directly
impacted) to argue that we should require residents of Kosovo to identify
themselves as living in Serbia because ISO doesn't yet recognize them as
independent. We can and should trust an individual or group to exercise
reasonable discretion around additions to the list to reflect the de facto
reality of the world. The goal is to enable our community to connect more
effectively and support the mission locally. Being rigid here doesn't
serve the mission.

-- Mike

[Adam Roach]

On 5/22/15 17:09, Mike Connor wrote:
>
> The FreeBSD policy skirts the Kosovo issue in exactly the same way
> as I proposed earlier: it punts the question as to whether to
> include it in the list to ISO.
>
>
> It does? That wasn't my reading, it explicitly rejects the naming
> conventions of ISO 3166 (which has TW as "Taiwan (Province of China)"
> and otherwise does not require the usage of ISO 3166, at least not at
> that link.

The policy, as far as I can tell, is for application to things like this:

https://github.com/freebsd/freebsd/blob/master/share/misc/iso3166

And this:

https://github.com/freebsd/freebsd/blob/master/etc/regdomain.xml


Neither of which have entries for Kosovo.

>
> I don't find anything in there to disagree with. I think it's a
> good policy.
>
> But it doesn't support your argument that we should use a modified
> version of ISO3166-1. That is delving quite squarely into, as you
> put it, "politics outside of issues clearly tied to the Mozilla
> mission."
>
>
> I think it's patently absurd (and likely offensive to those directly
> impacted) to argue that we should require residents of Kosovo to
> identify themselves as living in Serbia because ISO doesn't yet
> recognize them as independent. We can and should trust an individual
> or group to exercise reasonable discretion around additions to the
> list to reflect the de facto reality of the world. The goal is to
> enable our community to connect more effectively and support the
> mission locally. Being rigid here doesn't serve the mission.

But what's the criteria for allowing this inclusion? Mike Connor's
personal opinion? If I requested an entry for "The Republic of Texas,"
what would be the grounds for accepting or rejecting it?

The problem here isn't Kosovo per se; it's the precedent. If we accept
new entries, then we need to define formal criteria for what rises to
the level of being acceptable, and what does not -- the only other
alternative is to use a subjective and possibly contentious evaluation
for each request. Both paths lead us to being forced into politically
dicey positions in the future.

[Fred Wenzel]

On Fri, May 22, 2015 at 3:28 PM, Adam Roach <a...@mozilla.com> wrote:

>
>> I think it's patently absurd (and likely offensive to those directly
>> impacted) to argue that we should require residents of Kosovo to identify
>> themselves as living in Serbia because ISO doesn't yet recognize them as
>> independent. We can and should trust an individual or group to exercise
>> reasonable discretion around additions to the list to reflect the de facto
>> reality of the world. The goal is to enable our community to connect more
>> effectively and support the mission locally. Being rigid here doesn't
>> serve the mission.
>>
>
> But what's the criteria for allowing this inclusion? Mike Connor's
> personal opinion? If I requested an entry for "The Republic of Texas," what
> would be the grounds for accepting or rejecting it?
>

As you know I agree with Mike -- to your slippery slope argument, if you
can support your claim for Texas with the diplomatic recognition by a
significant amount of other independent states, then by all means it would
be warranted.

The problem here isn't Kosovo per se; it's the precedent. If we accept new
> entries, then we need to define formal criteria for what rises to the level
> of being acceptable, and what does not -- the only other alternative is to
> use a subjective and possibly contentious evaluation for each request. Both
> paths lead us to being forced into politically dicey positions in the
> future.
>
>

And I actually agree on the definition or reproducible criteria. In this
particular case, we could literally pick any reasonable percentage, and be
done arguing.

You seem to be missing the detail that we don't actually have to solve a
territorial dispute here. We only have to answer the question "if I am from
Kosovo, am I welcome to call myself a Kosovan as a Mozillian?" That's not
an unreasonable request, and it looks like others have solved this problem
by assigning them a country code (XK) and moving on. As a reminder, we're
not talking about forcing anyone to use said country entry unless they want
to.

For the sake of productivity, have a draft policy:

"""
In some of its products, Mozilla displays a list of countries for users to
choose from.

To best support our international, diverse and multicultural community we
determine such country lists as follows:
- The basic list follows the names and country codes of the ISO 3166-2
regions and country list
- We shorten the name of Taiwan to "Taiwan" (<insert blob about leaving
interpretation up to the beholder>)
^^ in fact, we might want to change that to "we shorten some country names
to more commonly used variants", which will allow us to call Bolivia
Bolivia)
- We add a list item and appropriate region code for any other entity
diplomatically recognized as independent by at least 25% of UN member
countries.

<insert blob about not making a political statement but instead
acknowledging that we want to give reasonably established groups of people
the ability to identify as such when being active in the Mozilla community>
"""

Fred

[Mike Connor]

On 22 May 2015 at 18:28, Adam Roach <a...@mozilla.com> wrote:

>
> But what's the criteria for allowing this inclusion? Mike Connor's
> personal opinion? If I requested an entry for "The Republic of Texas," what
> would be the grounds for accepting or rejecting it?
>

> The problem here isn't Kosovo per se; it's the precedent. If we accept new
> entries, then we need to define formal criteria for what rises to the level
> of being acceptable, and what does not -- the only other alternative is to
> use a subjective and possibly contentious evaluation for each request. Both
> paths lead us to being forced into politically dicey positions in the
> future.
>

Let's not get into slippery slope arguments. We both know that's not
something that would pass muster against any meaningful criteria. Can you
name an example that would actually be widely controversial? If not, I
don't think this is a material concern.

There's no objective criteria on the table. There's just passing the buck
to ISO and washing our hands. I don't consider that to be a reasonable
solution, especially when there's an obviously broken case in play like
Kosovo. More importantly, I do not believe any rigourous, objective
criteria can be created that will reflect reality, as international
recognition is so heavility politicized as to be explicitly non-objective
in nature. This most definitely includes both ISO 3166 and GENC, as well as
individual states recognition of sovereignty.

I don't have a problem with entrusting what is inevitably a subjective
decision to a module owner. No two examples are alike, these situations
are complicated and there's no objectively correct answer. Kosovo is easy,
others not so much, and a smart module owner should be able to propose a
reasonable approach in most situations.

-- Mike

[Adam Roach]

On 5/22/15 17:59, Mike Connor wrote:
> Can you name an example that would actually be widely controversial?

Perhaps the Sahrawi Arab Democratic Republic -- I'd have to brush up on
Moroccan politics to be sure.

And, to be clear, SADR very nearly satisfies Fred's proposed policy that
we "add a list item and appropriate region code for any other entity

diplomatically recognized as independent by at least 25% of UN member

countries" -- current recognition stands at 23.8%.

Which raises an interesting case. If we had previously adopted Fred's
proposed 25% rule, then we would have automatically added SADR to the
list: they passed 25% recognition some time in the '80's, and remained
above that mark until Panama suspended their recognition in November of
2013. Would we have removed them at that point?

> If not, I don't think this is a material concern.

Can you predict the entire worldwide political landscape for the rest of
the lifetime of the project?

There are some very plausible, very near-term futures where an alternate
government that currently controls parts of what are widely recognized
as Iraq, Syria, Libya, and Nigeria begins to establish diplomatic
relations with other countries. It isn't hard to believe that, much like
the gradual diplomatic acceptance of the PRC in the '50's and '60's,
such an entity might gain recognition by a non-trivial percentage of UN
member states.

And that? That would be controversial.

[Ehsan Akhgari]

On 2015-05-22 7:38 PM, Adam Roach wrote:
> On 5/22/15 17:59, Mike Connor wrote:
>> Can you name an example that would actually be widely controversial?
>
> Perhaps the Sahrawi Arab Democratic Republic -- I'd have to brush up on
> Moroccan politics to be sure.

OK, so let's say that someone living in that region wants to be
identified as living in SADR. Why is that not OK? And why is it up to
us to decide that? And why would Mozilla care if the said individual
wants to be identified as living in the SADR or in Morocco?

>> If not, I don't think this is a material concern.
>
> Can you predict the entire worldwide political landscape for the rest of
> the lifetime of the project?

Nobody can, but what is the point of this question?

> There are some very plausible, very near-term futures where an alternate
> government that currently controls parts of what are widely recognized
> as Iraq, Syria, Libya, and Nigeria begins to establish diplomatic
> relations with other countries. It isn't hard to believe that, much like
> the gradual diplomatic acceptance of the PRC in the '50's and '60's,
> such an entity might gain recognition by a non-trivial percentage of UN
> member states.
>
> And that? That would be controversial.

It seems like you're optimizing for a different goal than some others in
this thread: avoiding making controversial decisions, and your solution
is to hand that off to another organization (the ISO.)

Let me just talk about one of the most controversial cases for a second:
ISIL, since you've mentioned it up-thread. Let's say that there are
people who self-identify as ISIL citizens, and they would like to be
part of the Mozilla community. What is the harm in allowing that
individual to self-identify as such for the purposes of their Mozilla
contributions?

I think this debate simply boils down to what goal we're trying to
achieve here. If our goal is avoiding controversy at all costs, then
your suggestion makes sense. But I would like to suggest that our goal
should be building a strong community that is open and welcoming to all,
no matter which part of the world they were born in, and live in, and
how they identify where in the world they live. With that goal in mind,
off-loading this decision to ISO makes no sense, since that is
effectively Mozilla taking a stance on what is and is not a country, and
taking away the ability of our contributors to make this call.

Cheers,
Ehsan

[Eric Rescorla]

On Fri, May 22, 2015 at 5:52 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

Well, it's worth noting that this thread started (going on two weeks ago
now) when someone complained about someone else using "Prishtina - Kosovo -
Albania" as their location. I suspect that the person complaining didn't
feel like we were fostering a welcoming environment.

-Ekr

[Ehsan Akhgari]

Of course. We need to make it clear that it is the user who has decided
how to fill that form, and what to put there, through the language
around the UI where this information is displayed. And we will
obviously keep receiving complaints from people who don't recognize the
states found on Mozilla Reps or other Mozilla venues, and we need to
keep explaining that to them.

You may argue that it's futile to keep trying to stop these complaints,
but I'd say that is OK, since the more important thing is for us to be
welcoming to individuals no matter how hey identify their location.

> I suspect that the person
> complaining didn't feel like we were fostering a welcoming environment.

Well, I have to say, with the current state of things, I don't believe
we are as welcoming as we could be in this respect too.

[Eric Rescorla]

On Fri, May 22, 2015 at 6:24 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

Could you elaborate a bit on what you are arguing for? A freeform field or
a method of extending the canonical list?

I'm quite comfortable with having a freeform field that people can put
anything they want in (including ISIL or Venus or whatever). I'm much less
comfortable with us having a canonical list that is curated according to
some idiosyncratic Mozilla standard. While I don't speak for Adam, I
suspect this is his view as well. Is this something you disagree with?

-Ekr

[Panos Astithas]

On Sat, May 23, 2015 at 1:55 AM, Fred Wenzel <fwe...@mozilla.com> wrote:

> - The basic list follows the names and country codes of the ISO 3166-2
> regions and country list
> - We shorten the name of Taiwan to "Taiwan" (<insert blob about leaving
> interpretation up to the beholder>)
> ^^ in fact, we might want to change that to "we shorten some country names
> to more commonly used variants", which will allow us to call Bolivia
> Bolivia)
>

This sounds like precisely the kind of policy that will get us into
trouble. Did you know that referring to what ISO recognizes as the "Former
Yugoslav Republic of Macedonia" as simply "Macedonia" is something that
even today will get some Greeks up in arms? Do we really want to get into
this mess?

I can understand either using ISO verbatim or using a free-form field
labeled "Country or Region", because in both cases we can legitimately say
in case of complaints "it's not our fault", but devising our own special
set of rules sounds like asking for trouble.

Panos

[Fred Wenzel]

Look at the data, we already do make those kinds of alterations, including
Taiwan and Bolivia.

I'm getting a little tired of far fetched examples in this thread.

~F

--
Sent from my phone. Please excuse my brevity.

[Mike Hoye]

On 2015-05-23 2:04 PM, Panos Astithas wrote:

> I can understand either using ISO verbatim or using a free-form field
> labeled "Country or Region", because in both cases we can legitimately
> say in case of complaints "it's not our fault", but devising our own
> special set of rules sounds like asking for trouble.

Here's Wikipedia's list of territorial disputes; there are dozens of
them. We have offices or community groups in several of them,
occasionally on both sides.

http://en.wikipedia.org/wiki/List_of_territorial_disputes

I've seen three general proposals in this thread, saying we can:

- Defer to the ISO spec. We wash our hands of the matter, in other
words. This sends a very clear message to our community.

- Use the ISO spec plus a bunch of extra rules we make up. Charitably, I
will call this a very bad idea. We should absolutely not do this.

- Make it a freeform text field and trust our people to exercise their
best judgement as members of the Mozilla community.

I think we would need a _spectacular_ reason to defer to a specification
instead of respecting our community members' decisions about how to tell
their own stories, and there isn't a reason like that in this thread.


- mhoye

[Nikos Roussos]

On May 23, 2015 11:40:36 PM GMT+03:00, Mike Hoye <mh...@mozilla.com> wrote:
>- Make it a freeform text field and trust our people to exercise their
>best judgement as members of the Mozilla community.
>
>I think we would need a _spectacular_ reason to defer to a
>specification
>instead of respecting our community members' decisions about how to
>tell
>their own stories, and there isn't a reason like that in this thread.

I can think of a technical reason. Having the country field as a free text removes any location feature we currently have and it's based on the assumption of a country being a predefined list (Find Mozillians on a specific country, KPI metrics per country, etc).

So naming the field "Country or Region" may resolve some issues, but the list should be a predefined one. And since this is not about the Reps portal per se, whatever policy we conclude to choose, it should be reflected on the upstream project [1].

[1] https://github.com/mozilla/django-product-details

--
~nikos

[Tim Guan-tin Chien]

Hi Mike,

On Sun, May 24, 2015 at 4:40 AM, Mike Hoye <mh...@mozilla.com> wrote:
> - Use the ISO spec plus a bunch of extra rules we make up. Charitably, I
> will call this a very bad idea. We should absolutely not do this.

Could you elaborate on this? Are you against a policy like the one
FreeBSD project do?
Keep in mind that the policy also states the field should always
labels as "Country or Region" instead of just "Country"; the political
interpretation of these geographic terms is left to the readers to
interpret.

Things don't necessarily need to be more complex than the industry convention.

[Gervase Markham]

On 23/05/15 21:40, Mike Hoye wrote:
> - Make it a freeform text field and trust our people to exercise their
> best judgement as members of the Mozilla community.

If we decide to take this option, then we can avoid many of the
downsides of freeform text by having an editable listbox - i.e. you can
choose an entry from the list (which might be the ISO list), and are
encouraged to do so, but if none of the options fits what you want to
say, you can type your own. The back end would then see which you had
done, and store an ISO country code in the appropriate field if what you
had chosen matched an ISO name, otherwise that internal field would be
blank.

People typing their own names would then show what they want, at the
risk of not being found in geographic searches. They can decide if
that's a trade-off they want to make.

Gerv

[Majken Connor]

Ok, and how would we figure out where people are on a map, or if they are
near each other in this case? I would guess it would be possible to use the
city data (what happens if the city is a contested region though?) or would
we be able to create aliases so places on a map have multiple names?

I also asked, and it didn't get answered, who is in charge of making a
decision on setting a policy?

On Mon, May 25, 2015 at 6:01 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 23/05/15 21:40, Mike Hoye wrote:

> > - Make it a freeform text field and trust our people to exercise their
> > best judgement as members of the Mozilla community.
>

> If we decide to take this option, then we can avoid many of the
> downsides of freeform text by having an editable listbox - i.e. you can
> choose an entry from the list (which might be the ISO list), and are
> encouraged to do so, but if none of the options fits what you want to
> say, you can type your own. The back end would then see which you had
> done, and store an ISO country code in the appropriate field if what you
> had chosen matched an ISO name, otherwise that internal field would be
> blank.
>
> People typing their own names would then show what they want, at the
> risk of not being found in geographic searches. They can decide if
> that's a trade-off they want to make.
>
> Gerv
>
>

[Mike Hoye]

On 2015-05-25 10:24 AM, Majken Connor wrote:
> Ok, and how would we figure out where people are on a map, or if they
> are near each other in this case?

We could let people put a pin on a map, if they're inclined to do so.

- mhoye

[Ehsan Akhgari]

On 2015-05-22 10:16 PM, Eric Rescorla wrote:
>
>
> On Fri, May 22, 2015 at 6:24 PM, Ehsan Akhgari <ehsan....@gmail.com

> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2015-05-22 9:14 PM, Eric Rescorla wrote:
>
>
>
> On Fri, May 22, 2015 at 5:52 PM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>

> <mailto:ehsan....@gmail.com

A freeform field is unfortunately not suitable because of the reasons
mentioned before (such as making it harder to perform searches because
misspellings, etc.), so at the lack of that, I think we should be open
to expending the canonical list using user-assigned code where
ISO-3166-1 fails to list a country in situations similar to the one for
Kosovo.

[Gervase Markham]

On 25/05/15 15:24, Majken Connor wrote:
> Ok, and how would we figure out where people are on a map, or if they are
> near each other in this case?

The map use case is easy - there can be few arguments about a person
putting a pin in a map. (Of course, the labels on the map itself might
be a source of argument.)

> I would guess it would be possible to use the
> city data (what happens if the city is a contested region though?)

One reason timezones in the Olsen Timezone file are named after
continents and cities is that cities actually change names less often
than countries. Also, it is more common (although not universal, of
course) for political disputants to agree on the name of a city even if
they don't agree who should rule it or which country it should be in.

> I also asked, and it didn't get answered, who is in charge of making a
> decision on setting a policy?

I suspect the module owner for the Reps website with, as always, right
of appeal to Mitchell if someone is deeply upset (a right to be used
rarely and judiciously).

If we want a Mozilla-wide policy, that would probably require Mitchell's
approval, or someone she delegates.

Gerv

[Eric Rescorla]

On Mon, May 25, 2015 at 7:44 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

Thanks for clarifying. Do you believe Mozilla should curate this list or
merely record whatever people want to put there? If curated, what should be
the conditions? If not curated, what if I want to put in "Sealand", "Mars",
or "People's Republic of Fuck You"?

-Ekr

[Majken Connor]

Earlier in the thread it was clear that people are proposing a Mozilla-wide
policy. The Reps module owner has already replied here.

I also already mentioned that we used to have to put a pin in a map and it
was a pain.

The Reps use-case is not to find out where the person you're looking for is
located, it is to find Reps located where you are looking. As unlikely as
that use-case is to be, we have it. I think there is also a similar case in
Mozillians, I have used it more than once to try to find someone in a
region for help with an event.

On Mon, May 25, 2015 at 10:46 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 25/05/15 15:24, Majken Connor wrote:

> > Ok, and how would we figure out where people are on a map, or if they are
> > near each other in this case?
>

> The map use case is easy - there can be few arguments about a person
> putting a pin in a map. (Of course, the labels on the map itself might
> be a source of argument.)
>

> > I would guess it would be possible to use the
> > city data (what happens if the city is a contested region though?)
>

> One reason timezones in the Olsen Timezone file are named after
> continents and cities is that cities actually change names less often
> than countries. Also, it is more common (although not universal, of
> course) for political disputants to agree on the name of a city even if
> they don't agree who should rule it or which country it should be in.
>

> > I also asked, and it didn't get answered, who is in charge of making a
> > decision on setting a policy?
>

[Mike Connor]

On criteria, let's not get too far into the weeds here. Hard cases
generally make bad law. I'll take good judgement (and reasonable
discussion over disagreements) over trying to introduce a finely-detailed
rule set.

So, as a way to move forward, I'd propose that we do the following:

1) Use the Mozillians API in all cases to apply a uniform standard across
all Mozilla sites.

2) Standardize on "Country or Region" or "Location" or similar for fields
to avoid sovereignty implications

3) Use ISO-3166 as a base, and put the Mozillians owner (or their delegate)
in charge of deciding on any variations (Taiwan, Kosovo, etc) from the base
spec.

4) Identify .governance as the point of escalation if someone wants to have
a wider discussion on an owner decision to include/exclude a proposed entry.

This feels like the least bad option, and provides an escalation path
towards a wider discussion on the merits of an individual situation, rather
than strawman arguments about where a theoretical line should go.

Thoughts?

-- Mike

[Ehsan Akhgari]

On 2015-05-25 10:49 AM, Eric Rescorla wrote:
>
>
> On Mon, May 25, 2015 at 7:44 AM, Ehsan Akhgari <ehsan....@gmail.com

> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2015-05-22 10:16 PM, Eric Rescorla wrote:
>
>
>
> On Fri, May 22, 2015 at 6:24 PM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>

I believe it should not be curated by Mozilla, or a third-party
organization that we hand this off to (as we currently do). The net
effect of any sort of vetting on the list by Mozilla, ISO, or another
organization is that in the cases where they get it wrong, we're making
it impossible for individuals to self-identify the territory they
consider themselves to be from.

> If curated, what should
> be the conditions? If not curated, what if I want to put in "Sealand",
> "Mars", or "People's Republic of Fuck You"?

I believe it's fine to ignore such cases when coming up with general
rules, and treat them as spam and deal with them as such.

Note that the users can already enter such unhelpful information in
other free-form (or pseduo-free-form) fields, such as the name field,
and we don't need to worry about such cases more than worrying about any
other spamming scenario.

[Eric Rescorla]

On Mon, May 25, 2015 at 8:10 AM, Mike Connor <mco...@mozilla.com> wrote:

> On criteria, let's not get too far into the weeds here. Hard cases
> generally make bad law.
>

But we already know that there are hard cases that we need to deal with.
Indeed one such case is the origin of this thread.

I'll take good judgement (and reasonable discussion over disagreements)
> over trying to introduce a finely-detailed rule set.
>
> So, as a way to move forward, I'd propose that we do the following:
>
> 1) Use the Mozillians API in all cases to apply a uniform standard across
> all Mozilla sites.
>
> 2) Standardize on "Country or Region" or "Location" or similar for fields
> to avoid sovereignty implications
>
> 3) Use ISO-3166 as a base, and put the Mozillians owner (or their
> delegate) in charge of deciding on any variations (Taiwan, Kosovo, etc)
> from the base spec.
>

I don't agree with this for the reasons Adam Roach so eloquently observed.

4) Identify .governance as the point of escalation if someone wants to have
> a wider discussion on an owner decision to include/exclude a proposed entry.
>

A big public discussion about whether X is a valid region. What could
possibly go wrong?

This feels like the least bad option, and provides an escalation path
> towards a wider discussion on the merits of an individual situation, rather
> than strawman arguments about where a theoretical line should go.
>
> Thoughts?
>

I think this is a bad idea. Much better would be to just use 3166 as the
entire prepopulated list and let people write in whatever they want, but
not add it to a list we ratify.

-Ekr


-- Mike

>
> On 25 May 2015 at 10:49, Eric Rescorla <e...@rtfm.com> wrote:
>
>>
>>
>> On Mon, May 25, 2015 at 7:44 AM, Ehsan Akhgari <ehsan....@gmail.com>

>> wrote:
>>
>>> On 2015-05-22 10:16 PM, Eric Rescorla wrote:
>>>
>>>>
>>>>
>>>> On Fri, May 22, 2015 at 6:24 PM, Ehsan Akhgari <ehsan....@gmail.com

>>>> <mailto:ehsan....@gmail.com>> wrote:
>>>>
>>>> On 2015-05-22 9:14 PM, Eric Rescorla wrote:
>>>>
>>>>
>>>>
>>>> On Fri, May 22, 2015 at 5:52 PM, Ehsan Akhgari
>>>> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>
>>>> <mailto:ehsan....@gmail.com
>>>>

>> merely record whatever people want to put there? If curated, what should be

>> the conditions? If not curated, what if I want to put in "Sealand", "Mars",
>> or "People's Republic of Fuck You"?
>>

>> -Ekr
>>
>>
>

[Eric Rescorla]

On Mon, May 25, 2015 at 8:12 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> On 2015-05-25 10:49 AM, Eric Rescorla wrote:
>
>>
>>
>> On Mon, May 25, 2015 at 7:44 AM, Ehsan Akhgari <ehsan....@gmail.com

>> <mailto:ehsan....@gmail.com>> wrote:
>>
>> On 2015-05-22 10:16 PM, Eric Rescorla wrote:
>>
>>
>>
>> On Fri, May 22, 2015 at 6:24 PM, Ehsan Akhgari
>> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>

> I believe it should not be curated by Mozilla, or a third-party
> organization that we hand this off to (as we currently do). The net effect
> of any sort of vetting on the list by Mozilla, ISO, or another organization
> is that in the cases where they get it wrong, we're making it impossible
> for individuals to self-identify the territory they consider themselves to
> be from.

OK, then you and I disagree here. I'd prefer to accommodate such people by
giving them a freeform field.

> If curated, what should
>
>> be the conditions? If not curated, what if I want to put in "Sealand",
>> "Mars", or "People's Republic of Fuck You"?
>>
>

> I believe it's fine to ignore such cases when coming up with general
> rules, and treat them as spam and deal with them as such.
>
> Note that the users can already enter such unhelpful information in other
> free-form (or pseduo-free-form) fields, such as the name field, and we
> don't need to worry about such cases more than worrying about any other
> spamming scenario.
>

Well, that's why I put in Sealand, since at least at one point there were
in fact people claiming it was a sovereign jurisdiction. The line between
"legitimate disagreement" and "spam" seems pretty fuzzy.


-Ekr

[Ehsan Akhgari]

On 2015-05-25 11:20 AM, Eric Rescorla wrote:
>
>
> On Mon, May 25, 2015 at 8:12 AM, Ehsan Akhgari <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2015-05-25 10:49 AM, Eric Rescorla wrote:
>
>
>
> On Mon, May 25, 2015 at 7:44 AM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>

> <mailto:ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>>> wrote:
>
> On 2015-05-22 10:16 PM, Eric Rescorla wrote:
>
>
>
> On Fri, May 22, 2015 at 6:24 PM, Ehsan Akhgari
> <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com> <mailto:ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>>

Do you disagree with a "free-form field + autocomplete for existing
entries", similar to the way tagging is typically done in web apps, for
example?

> > If curated, what should
>
> be the conditions? If not curated, what if I want to put in
> "Sealand",
> "Mars", or "People's Republic of Fuck You"?
>
>
> I believe it's fine to ignore such cases when coming up with general
> rules, and treat them as spam and deal with them as such.
>
> Note that the users can already enter such unhelpful information in
> other free-form (or pseduo-free-form) fields, such as the name
> field, and we don't need to worry about such cases more than
> worrying about any other spamming scenario.
>
>
> Well, that's why I put in Sealand, since at least at one point there
> were in fact people claiming it was a sovereign jurisdiction. The line
> between "legitimate disagreement" and "spam" seems pretty fuzzy.

I would be perfectly happy with trusting the module system to navigate
those fuzzy cases.

[Mike Connor]

On 25 May 2015 at 11:18, Eric Rescorla <e...@rtfm.com> wrote:

> On Mon, May 25, 2015 at 8:10 AM, Mike Connor <mco...@mozilla.com> wrote:
>
>> On criteria, let's not get too far into the weeds here. Hard cases
>> generally make bad law.
>>
>
> But we already know that there are hard cases that we need to deal with.
> Indeed one such case is the origin of this thread.
>

The origin of this thread was from a legacy entry that mis-identified
Kosovo as a part of Albania. I don't think that passes any reasonable
sniff test.

> I'll take good judgement (and reasonable discussion over disagreements)
>> over trying to introduce a finely-detailed rule set.
>>
>> So, as a way to move forward, I'd propose that we do the following:
>>
>> 1) Use the Mozillians API in all cases to apply a uniform standard across
>> all Mozilla sites.
>>
>> 2) Standardize on "Country or Region" or "Location" or similar for fields
>> to avoid sovereignty implications
>>
>> 3) Use ISO-3166 as a base, and put the Mozillians owner (or their
>> delegate) in charge of deciding on any variations (Taiwan, Kosovo, etc)
>> from the base spec.
>>
>
> I don't agree with this for the reasons Adam Roach so eloquently observed.
>

Adam's argument seems generally rooted in a desire to avoid making
decisions. I do not believe blame avoidance should be a primary goal here.

As Tim and others have pointed out, the list is flawed because of UN
politics, so all we really get is someone to blame. My goal here is to
maximize inclusiveness, and to let human judgement give us the flexibility
to decide what's right for Mozillians.

> 4) Identify .governance as the point of escalation if someone wants to
>> have a wider discussion on an owner decision to include/exclude a proposed
>> entry.
>>
>
> A big public discussion about whether X is a valid region. What could
> possibly go wrong?
>

We'll have it no matter what we choose as a policy.

> This feels like the least bad option, and provides an escalation path
>> towards a wider discussion on the merits of an individual situation, rather
>> than strawman arguments about where a theoretical line should go.
>>
>> Thoughts?
>>
>
> I think this is a bad idea. Much better would be to just use 3166 as the
> entire prepopulated list and let people write in whatever they want, but
> not add it to a list we ratify.
>

And that's not going to work for technical and abuse reasons. And leaves
the original, clearly wrong example on the table, except we'd get to point
the finger elsewhere.

Do we care more about inclusiveness or blame avoidance? That's where the
argument seems to hinge at this point.

-- Mike

[Eric Rescorla]

On Mon, May 25, 2015 at 8:34 AM, Mike Connor <mco...@mozilla.com> wrote:

>
>
> On 25 May 2015 at 11:18, Eric Rescorla <e...@rtfm.com> wrote:
>
>> On Mon, May 25, 2015 at 8:10 AM, Mike Connor <mco...@mozilla.com> wrote:
>>
>>> On criteria, let's not get too far into the weeds here. Hard cases
>>> generally make bad law.
>>>
>>
>> But we already know that there are hard cases that we need to deal with.
>> Indeed one such case is the origin of this thread.
>>
>
> The origin of this thread was from a legacy entry that mis-identified
> Kosovo as a part of Albania. I don't think that passes any reasonable
> sniff test.
>

And yet people clearly want to not change it. Long experience in other fora
shows how controversial this is.

> I'll take good judgement (and reasonable discussion over disagreements)
>>> over trying to introduce a finely-detailed rule set.
>>>
>>> So, as a way to move forward, I'd propose that we do the following:
>>>
>>> 1) Use the Mozillians API in all cases to apply a uniform standard
>>> across all Mozilla sites.
>>>
>>> 2) Standardize on "Country or Region" or "Location" or similar for
>>> fields to avoid sovereignty implications
>>>
>>> 3) Use ISO-3166 as a base, and put the Mozillians owner (or their
>>> delegate) in charge of deciding on any variations (Taiwan, Kosovo, etc)
>>> from the base spec.
>>>
>>
>> I don't agree with this for the reasons Adam Roach so eloquently observed.
>>
>
> Adam's argument seems generally rooted in a desire to avoid making
> decisions. I do not believe blame avoidance should be a primary goal here.
>

Avoidance of long divisive discussions on topics where we have no
particular expertise is not at all the same thing as blame avoidance.

> As Tim and others have pointed out, the list is flawed because of UN
> politics,
>

All lists will be flawed.

> so all we really get is someone to blame.
>

No, we get to rule these discussions out of scope. It's different.

4) Identify .governance as the point of escalation if someone wants to have
>>> a wider discussion on an owner decision to include/exclude a proposed entry.
>>>
>>
>> A big public discussion about whether X is a valid region. What could
>> possibly go wrong?
>>
>
> We'll have it no matter what we choose as a policy.
>

We don't actually need to have that if we defer to ISO. People can of
course argue, but since those arguments won't have an actionable result,
they can be safely ignored.

This feels like the least bad option, and provides an
>>>
>>


> escalation path towards a wider discussion on the merits of an individual
>>> situation, rather than strawman arguments about where a theoretical line
>>> should go.
>>>
>>> Thoughts?
>>>
>>
>> I think this is a bad idea. Much better would be to just use 3166 as the
>> entire prepopulated list and let people write in whatever they want, but
>> not add it to a list we ratify.
>>
>
> And that's not going to work for technical and abuse reasons.
>

I don't think that's at all obvious. The technical reason seems to be that
people won't be able to find each other, but that's just not true: people
can converge on the same value in the same way that write-in ballots in
elections work. As for abuse, in a writein field it's much easier because
we just need to filter for obviously objectionable content in the same way
we do in (say) people's names, not make political decisions.

> And leaves the original, clearly wrong example on the table, except we'd
> get to point the finger elsewhere.
>

Not having this be our problem seems to have a lot of merit

> Do we care more about inclusiveness or blame avoidance? That's where the
> argument seems to hinge at this point.
>

I don't think that's an accurate summary at all.

-Ekr

[Eric Rescorla]

On Mon, May 25, 2015 at 8:33 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> On 2015-05-25 11:20 AM, Eric Rescorla wrote:
>>
>>
>> OK, then you and I disagree here. I'd prefer to accommodate such people
>> by giving them a freeform field.
>>
>
> Do you disagree with a "free-form field + autocomplete for existing
> entries", similar to the way tagging is typically done in web apps, for
> example?

I could live with a list plus a free-form field of the type you indicate.

> If curated, what should
>>
>> be the conditions? If not curated, what if I want to put in
>> "Sealand",
>> "Mars", or "People's Republic of Fuck You"?
>>
>>
>> I believe it's fine to ignore such cases when coming up with general
>> rules, and treat them as spam and deal with them as such.
>>
>> Note that the users can already enter such unhelpful information in
>> other free-form (or pseduo-free-form) fields, such as the name
>> field, and we don't need to worry about such cases more than
>> worrying about any other spamming scenario.
>>
>>
>> Well, that's why I put in Sealand, since at least at one point there
>> were in fact people claiming it was a sovereign jurisdiction. The line
>> between "legitimate disagreement" and "spam" seems pretty fuzzy.
>>
>
> I would be perfectly happy with trusting the module system to navigate
> those fuzzy cases.
>

Yeah, I think that's unwise for the reasons I indicated.

-Ekr

[Majken Connor]

We need to agree on requirements before we can measure the value of any
proposed solution.

I don't think that's at all obvious. The technical reason seems to be that
people won't be able to find each other, but that's just not true: people
can converge on the same value in the same way that write-in ballots in
elections work. As for abuse, in a writein field it's much easier because
we just need to filter for obviously objectionable content in the same way
we do in (say) people's names, not make political decisions.

That depends entirely on the implementation. Early on in Mozillians it was
impossible to find everyone in the same reason with a single search because
of how the info was stored and how the search was performed. If you wanted
to find everyone in Utah for example, that depended on people filling in
their state information. Also it relied on the information not being stored
as Provo-Utah or Provo/Utah.

So it is a requirement that people be able to find each other, a good
solution will fulfill this requirement, but that doesn't mean it's not
possible to have a bad solution that would fail.

[Boris Zbarsky]

On 5/25/15 11:43 AM, Eric Rescorla wrote:
> On Mon, May 25, 2015 at 8:34 AM, Mike Connor <mco...@mozilla.com> wrote:
>> The origin of this thread was from a legacy entry that mis-identified
>> Kosovo as a part of Albania. I don't think that passes any reasonable
>> sniff test.
>
> And yet people clearly want to not change it.

That's because the only other remotely sensible choice we gave them is
to change to identifying Kosovo as a part of Serbia. If we gave them
the option of identifying Kosovo as part of neither, and _then_ they
continued to identify as part of Albania, then we could have a
discussion about how to handle that. But that's not the situation we're
in right now. Given the situation we _are_ in, I can totally understand
the reluctance to change. All this has been mentioned in this thread
before, so bringing up the "but they don't want to change" thing in this
context is odd.

Anyway, it seems to me like we have a proposal on the table (Ehsan's)
that you're happy with. For the record, I'm happy with it too.

-Boris

[Eric Rescorla]

On Mon, May 25, 2015 at 4:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 5/25/15 11:43 AM, Eric Rescorla wrote:
>
>> On Mon, May 25, 2015 at 8:34 AM, Mike Connor <mco...@mozilla.com> wrote:
>>
>>> The origin of this thread was from a legacy entry that mis-identified
>>> Kosovo as a part of Albania. I don't think that passes any reasonable
>>> sniff test.
>>>
>>
>> And yet people clearly want to not change it.
>>
>

> That's because the only other remotely sensible choice we gave them is to
> change to identifying Kosovo as a part of Serbia. If we gave them the
> option of identifying Kosovo as part of neither, and _then_ they continued
> to identify as part of Albania, then we could have a discussion about how
> to handle that. But that's not the situation we're in right now. Given
> the situation we _are_ in, I can totally understand the reluctance to
> change. All this has been mentioned in this thread before, so bringing up
> the "but they don't want to change" thing in this context is odd.
>

Sorry, it was like 50 messages back and I missed it when I skimmed to catch
up with the thread. With that said, I don't think it's at all hard to
anticipate that we will run into hard cases.

> Anyway, it seems to me like we have a proposal on the table (Ehsan's) that
> you're happy with. For the record, I'm happy with it too.

Yes, I can live with it.

-Ekr

[Mike Connor]

So, I'm a little lost on how this concept solves the original problem
here. A free-form field means these users could continue to identify as a
part of Albania. Isn't that more divisive and controversial than allowing
Kosovo into the list? I assume it's long-settled that we won't use ISO's
short name for Taiwan?

The only advantage I see is that we can point things elsewhere, potentially
at the expense of effectiveness (see comments about the problems with the
old free form entry).

-- Mike

On 25 May 2015 at 16:31, Eric Rescorla <e...@rtfm.com> wrote:

> On Mon, May 25, 2015 at 4:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>

> > On 5/25/15 11:43 AM, Eric Rescorla wrote:
> >
> >> On Mon, May 25, 2015 at 8:34 AM, Mike Connor <mco...@mozilla.com>
> wrote:
> >>
> >>> The origin of this thread was from a legacy entry that mis-identified
> >>> Kosovo as a part of Albania. I don't think that passes any reasonable
> >>> sniff test.
> >>>
> >>
> >> And yet people clearly want to not change it.
> >>
> >

> > That's because the only other remotely sensible choice we gave them is to
> > change to identifying Kosovo as a part of Serbia. If we gave them the
> > option of identifying Kosovo as part of neither, and _then_ they
> continued
> > to identify as part of Albania, then we could have a discussion about how
> > to handle that. But that's not the situation we're in right now. Given
> > the situation we _are_ in, I can totally understand the reluctance to
> > change. All this has been mentioned in this thread before, so bringing
> up
> > the "but they don't want to change" thing in this context is odd.
> >
>
> Sorry, it was like 50 messages back and I missed it when I skimmed to catch
> up with the thread. With that said, I don't think it's at all hard to
> anticipate that we will run into hard cases.
>
>
>
>
> > Anyway, it seems to me like we have a proposal on the table (Ehsan's)
> that
> > you're happy with. For the record, I'm happy with it too.
>
>
> Yes, I can live with it.
>
> -Ekr

[Boris Zbarsky]

On 5/26/15 2:52 PM, Mike Connor wrote:
> So, I'm a little lost on how this concept solves the original problem
> here. A free-form field means these users could continue to identify as a
> part of Albania.

It also means that we could then ask them to stop doing that without
forcing them to identify as being in Serbia.

That is, it would create a _mechanism_ for an accurate identification
here. Whether that mechanism is used is then a policy decision...

> Isn't that more divisive and controversial than allowing
> Kosovo into the list?

I'm not sure what you mean. Even if, today, we had Kosovo in the list,
people could still pick "Albania" from the list instead just like they
did already. What would be do in that situation? Presumably ask them
politely to change to "Kosovo" instead, yes?

-Boris

[Mike Connor]

It depends on what we

On 26 May 2015 at 15:08, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 5/26/15 2:52 PM, Mike Connor wrote:
>

>> So, I'm a little lost on how this concept solves the original problem
>> here. A free-form field means these users could continue to identify as a
>> part of Albania.
>>
>

> It also means that we could then ask them to stop doing that without
> forcing them to identify as being in Serbia.
>

Yep, that's a step forward. As long as the search mechanism is able to
work. I'm not sure that's a safe assumption. If it's not, it means those
users are stuck being difficult/impossible to find.

> That is, it would create a _mechanism_ for an accurate identification
> here. Whether that mechanism is used is then a policy decision...

Whether it's used isn't my concern. It's whether it's _effective_ if used.
If the choice is "be findable through search or identify your location
accurately" the system is not effective.

> Isn't that more divisive and controversial than allowing
>> Kosovo into the list?
>>
>

> I'm not sure what you mean. Even if, today, we had Kosovo in the list,
> people could still pick "Albania" from the list instead just like they did
> already. What would be do in that situation? Presumably ask them politely
> to change to "Kosovo" instead, yes?

If they do that, it's not really different from me listing my location as
New York state. Inaccurate, and it'll make it harder for others to find
me. As long as territories don't overlap, it's basically just a user
picking the wrong thing.

-- Mike

[Majken Connor]

This is so unproductive. Everyone seems more concerned with arguing their
opinions than in actually making some sort of progress and as far as I can
tell the people who are most active in this discussion aren't actually
stakeholders who could take next steps in creating a formal proposal for a
policy and getting it reviewed and approved.

First it needs to be decided if this is even a problem that needs a policy.
How much does Mozilla care if the ISO currently used is controvertial? If
Mozilla doesn't care, then the case needs to be made why Mozilla should
care. If Mozilla does care, then someone who would own this should step
forward and say "Mozilla cares, and I have the authority to drive this,
here are the problems we need to solve to have a good policy."

Y'all are arguing about what colour to paint the bikeshed and we don't even
have a shed yet. Someone has just complained that they don't like where
someone else's bike is parked.

On Tue, May 26, 2015 at 3:40 PM, Mike Connor <mco...@mozilla.com> wrote:

> It depends on what we
>
> On 26 May 2015 at 15:08, Boris Zbarsky <bzba...@mit.edu> wrote:
>
> > On 5/26/15 2:52 PM, Mike Connor wrote:
> >

> >> So, I'm a little lost on how this concept solves the original problem
> >> here. A free-form field means these users could continue to identify
> as a
> >> part of Albania.
> >>
> >

> > It also means that we could then ask them to stop doing that without
> > forcing them to identify as being in Serbia.
> >
>
> Yep, that's a step forward. As long as the search mechanism is able to
> work. I'm not sure that's a safe assumption. If it's not, it means those
> users are stuck being difficult/impossible to find.
>
>
> > That is, it would create a _mechanism_ for an accurate identification
> > here. Whether that mechanism is used is then a policy decision...
>
>
> Whether it's used isn't my concern. It's whether it's _effective_ if used.
> If the choice is "be findable through search or identify your location
> accurately" the system is not effective.
>
>

> > Isn't that more divisive and controversial than allowing
> >> Kosovo into the list?
> >>
> >

> > I'm not sure what you mean. Even if, today, we had Kosovo in the list,
> > people could still pick "Albania" from the list instead just like they
> did
> > already. What would be do in that situation? Presumably ask them
> politely
> > to change to "Kosovo" instead, yes?
>
>
> If they do that, it's not really different from me listing my location as
> New York state. Inaccurate, and it'll make it harder for others to find
> me. As long as territories don't overlap, it's basically just a user
> picking the wrong thing.
>
> -- Mike

[Boris Zbarsky]

On 5/26/15 3:40 PM, Mike Connor wrote:
> If they do that, it's not really different from me listing my location as
> New York state.

It's more like you listing your location as "Washington, VA". At which
point a Marylander would complain that the city of Washington is not
part of Virginia (let's ignore for the moment the one that actually is).

> As long as territories don't overlap

This is the crux of the matter, really. In practice what different
people consider to be these territories _do_ overlap. As in, there are
people who claim Kosovo is its own country, people who claim Kosovo is
part of Serbia, and people who claim Kosovo is part of Albania.

> it's basically just a user picking the wrong thing.

Well, picking the wrong thing to make a political statement.

Has someone actually asked the people involved whether they would switch
their "country or region" from Albania to Kosovo if the option existed?

-Boris

[David Ascher]

I suggest everyone (but in particular reps portal + mozillians.org) go back
to the actual use cases to determine the approach on a case by case basis.
In most social software (which I think reps + mozillians are),
jurisdictional affiliation is never actually a P1. "Finding people near
me" is; "finding people who think like me / talk like me / walk like me"
often is as well. Location (recognizing that people are in many locations
over time, and that "distance is non-linear") and language (recognizing
that many people speak many languages) are therefore often more useful.

There may be valid needs for know which legal authority someone is governed
by, but I don't see one here. Facebook is a better source of inspiration
than your local government IT system.

[Tim Guan-tin Chien]

One of the classical use case would be selecting UI language
("locale"). These labels are currently defined by the localization
community of the locales, so we have a definite list here:

https://wiki.mozilla.org/L10n:Teams

This shouldn't be controversial as the labels are given by the
community who is at stake, and take the responsibility of localizing
our products [1]. It's is also an bottom-up approach, not a
use-that-list-and-ignore-its-problem approach.

Things get ugly when you want to separate selections of language with
selections of country/region, since you need that to get to the full
namespace available in BCP47 [2]. Getting the full namespace also help
you describe people without an established Mozilla community listed
above. I assume that's the Reps site use case.

[1] Maybe not for some B2G phones in which the code goes through the vendors.
[2] http://www.w3.org/International/questions/qa-choosing-language-tags

[Tim Guan-tin Chien]

FWIW I think your proposal is more practical than a free form field.

On Wed, May 27, 2015 at 2:52 AM, Mike Connor <mco...@mozilla.com> wrote:
> So, I'm a little lost on how this concept solves the original problem

> here. A free-form field means these users could continue to identify as a
> part of Albania. Isn't that more divisive and controversial than allowing
> Kosovo into the list? I assume it's long-settled that we won't use ISO's
> short name for Taiwan?
>
> The only advantage I see is that we can point things elsewhere, potentially
> at the expense of effectiveness (see comments about the problems with the
> old free form entry).
>
> -- Mike
>
> On 25 May 2015 at 16:31, Eric Rescorla <e...@rtfm.com> wrote:
>
>> On Mon, May 25, 2015 at 4:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>>

>> > On 5/25/15 11:43 AM, Eric Rescorla wrote:
>> >
>> >> On Mon, May 25, 2015 at 8:34 AM, Mike Connor <mco...@mozilla.com>
>> wrote:
>> >>
>> >>> The origin of this thread was from a legacy entry that mis-identified
>> >>> Kosovo as a part of Albania. I don't think that passes any reasonable
>> >>> sniff test.
>> >>>
>> >>
>> >> And yet people clearly want to not change it.
>> >>
>> >

>> > That's because the only other remotely sensible choice we gave them is to
>> > change to identifying Kosovo as a part of Serbia. If we gave them the
>> > option of identifying Kosovo as part of neither, and _then_ they
>> continued
>> > to identify as part of Albania, then we could have a discussion about how
>> > to handle that. But that's not the situation we're in right now. Given
>> > the situation we _are_ in, I can totally understand the reluctance to
>> > change. All this has been mentioned in this thread before, so bringing
>> up
>> > the "but they don't want to change" thing in this context is odd.
>> >
>>
>> Sorry, it was like 50 messages back and I missed it when I skimmed to catch
>> up with the thread. With that said, I don't think it's at all hard to
>> anticipate that we will run into hard cases.
>>
>>
>>
>>
>> > Anyway, it seems to me like we have a proposal on the table (Ehsan's)
>> that
>> > you're happy with. For the record, I'm happy with it too.
>>
>>
>> Yes, I can live with it.
>>
>> -Ekr

[Gervase Markham]

On 23/05/15 21:40, Mike Hoye wrote:

> - Defer to the ISO spec. We wash our hands of the matter, in other
> words. This sends a very clear message to our community.

That's what we do now, right? This is the option with the disadvantage
that residents of Kosovo, if required to pick a country, must pick
either Serbia or Albania?

> - Use the ISO spec plus a bunch of extra rules we make up. Charitably, I
> will call this a very bad idea. We should absolutely not do this.

Would you put the FreeBSD policy into this category?
http://www.freebsd.org/internal/i18n.html

You may say there's a slippery slope, but if you start from the ISO
spec, changing "Taiwan, Province of China" to simply "Taiwan" seems like
an obvious and widely-adopted improvement, which removes offence from
one set of people and (combined with a "Country or Region" label) does
not offend anyone else.

Is it really beyond our capabilities to figure out which rules fall into
the category of "clear improvement" and which do not?

> - Make it a freeform text field and trust our people to exercise their
> best judgement as members of the Mozilla community.

(For completeness: I proposed a way to do this that wouldn't entirely
break geographic search.)

Gerv

[Tim Guan-tin Chien]

bump.....? any update on this? Should we move forward with an official
policy proposed here?

[Irvin Chen]

I'd notice that recently, more and more new Mozilla website came exist
with this problematic ISO3166 problem.

For example,

Mozilla Location Service
https://location.services.mozilla.com/stats/countries

Shape of the Web
https://shapeoftheweb.mozilla.org/access/speed


We Do Need to set a policy (similar to FreeBSD one *1) for Mozilla widely,
or we will have to face all the problem again and again,
once every new Mozilla website come alive.

Here is also a better list for country/region entity name to use along with
country code from ISO3166,
http://geonames.nga.mil/gns/html/namefiles.html

*1 https://www.freebsd.org/internal/i18n.html

--
@ irvinfly: community liaison
moztw.org Mozilla Taiwan community

[Irvin Chen]

Just learned that we have already a good list for Country/Region for
product.
Please use this instead of ISO3166 and make it into a L10n policy!

1) http://hg.mozilla.org/mozilla-central/file/tip/toolkit/locales/en-US/chrome/global/regionNames.properties
2) http://viewvc.svn.mozilla.org/vc/libs/product-details/regions/

[Gijs Kruitbosch]

Why is this a "good" list? This doesn't have an entry for Kosovo, nor
for South Sudan, nor for the most recent incarnation of the various
Netherlands Antilles (it still has "Netherlands Antilles" which is no
longer a nation state entity)

~ Gijs

[Irvin Chen]

Because it's what we currently used for our products.
And anyone can file a bug on bugzilla to fix those problem you mentioned,
in the mean time other project can adopt it without go through all hesitate
& resolving argues for ISO 3166 all again.

2015-06-09 17:52 GMT+08:00 Gijs Kruitbosch <gijskru...@gmail.com>:

> Why is this a "good" list? This doesn't have an entry for Kosovo, nor for
> South Sudan, nor for the most recent incarnation of the various Netherlands
> Antilles (it still has "Netherlands Antilles" which is no longer a nation
> state entity)
>
> ~ Gijs
>
> On 09/06/2015 10:02, Irvin Chen wrote:
>

[Tim Guan-tin Chien]

Instead of arguing what's missing from the current snapshot, we should
continue the discussion on framing a agreed policy.

Thanks.

On Tue, Jun 9, 2015 at 6:06 PM, Irvin Chen <ir...@mail.moztw.org> wrote:
> Because it's what we currently used for our products.
> And anyone can file a bug on bugzilla to fix those problem you mentioned,
> in the mean time other project can adopt it without go through all hesitate
> & resolving argues for ISO 3166 all again.
>
>
>
>
> 2015-06-09 17:52 GMT+08:00 Gijs Kruitbosch <gijskru...@gmail.com>:
>
>> Why is this a "good" list? This doesn't have an entry for Kosovo, nor for
>> South Sudan, nor for the most recent incarnation of the various Netherlands
>> Antilles (it still has "Netherlands Antilles" which is no longer a nation
>> state entity)
>>
>> ~ Gijs
>>
>> On 09/06/2015 10:02, Irvin Chen wrote:
>>

[Irvin Chen]

The list*1 had been inside Firefox for decades in
preference/content/language setting *2,
and you can see the L10n-ed version of the list directly inside Firefox *3,
So I believed it's a list get really good care by our L10n communities
worldwide,
qualify enough to be shipped with Firefox.

*1
https://dxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/regionNames.properties
*2
https://dxr.mozilla.org/mozilla-central/source/browser/components/preferences/languages.xul#45
*3 chrome://global/locale/regionNames.properties

We can simply set an i18n policy to adopt the list Mozilla-wide,
ensuring our website/product be kind to all of our users,
and left all the changing and maintaining hesitate to our best local/l10n
communities,
who is absolutely good in filing bug and patching.

(Vladimir Krstic: Here we need you to filing a bug for Kosovo please.)

Together with language name list *4 *5,
we can get a good and respectful list of locales and regions instead of ISO
3166,
and it's even better - the list had already been localization!

*4
http://hg.mozilla.org/mozilla-central/file/tip/toolkit/locales/en-US/chrome/global/regionNames.properties
*5 chrome://global/locale/regionNames.properties

Irvin
Taiwan

2015-06-09 18:10 GMT+08:00 Tim Guan-tin Chien <timd...@mozilla.com>:

> Instead of arguing what's missing from the current snapshot, we should
> continue the discussion on framing a agreed policy.
>
> Thanks.
>
> On Tue, Jun 9, 2015 at 6:06 PM, Irvin Chen <ir...@mail.moztw.org> wrote:
> > Because it's what we currently used for our products.
> > And anyone can file a bug on bugzilla to fix those problem you mentioned,
> > in the mean time other project can adopt it without go through all
> hesitate
> > & resolving argues for ISO 3166 all again.
> >
> >
> >
> >
> > 2015-06-09 17:52 GMT+08:00 Gijs Kruitbosch <gijskru...@gmail.com>:
> >
> >> Why is this a "good" list? This doesn't have an entry for Kosovo, nor
> for
> >> South Sudan, nor for the most recent incarnation of the various
> Netherlands
> >> Antilles (it still has "Netherlands Antilles" which is no longer a
> nation
> >> state entity)
> >>
> >> ~ Gijs
> >>
> >> On 09/06/2015 10:02, Irvin Chen wrote:
> >>

[Gijs Kruitbosch]

On 09/06/2015 12:28, Irvin Chen wrote:
> The list*1 had been inside Firefox for decades in
> preference/content/language setting *2,

Languages and countries/regions are not the same thing. The list in the
preferences has language names, and only uses the regionNames list for
identifying distinctions in language based on the region where that
language is spoken (en-US vs. en-GB being a well-known example).

The purpose seems different enough, and the number of regions we
actually use and display small enough, that it doesn't seem like a good
candidate for use for the projects identified upthread.

~ Gijs

[Irvin Chen]

Gijs,

We have 2 solution besides leave the issue raise again and again,

First, we use the regionName list and extend it to as complete as we need.
Second, we take GENC/ISO 3166 as base and we still need to set a procedure
for our worldwide communities able to patch the list.

Which ever we choose, we both need to set a i18n policy and make
acknowledge to all product manager follow the list to prevent further
problem and make our user happy and not feel offended.

Mozilla should be the best model of the OSS projects on i18n. We do well
respect to our user worldwide since 2002. And now we fall behind some other
projects but we can catch up.



Gijs Kruitbosch
gijskru...@gmail.com>於 2015年6月9日 週二，下午8:17寫道：

On 09/06/2015 12:28, Irvin Chen wrote:

> > The list*1 had been inside Firefox for decades in
> > preference/content/language setting *2,
>

> Languages and countries/regions are not the same thing. The list in the
> preferences has language names, and only uses the regionNames list for
> identifying distinctions in language based on the region where that
> language is spoken (en-US vs. en-GB being a well-known example).
>
> The purpose seems different enough, and the number of regions we
> actually use and display small enough, that it doesn't seem like a good
> candidate for use for the projects identified upthread.
>
> ~ Gijs
>

[Majken Connor]

Irvin,

I think it might help move this forward if someone started a proposal doc
somewhere. Otherwise we won't get out of the debate stage. What you just
said seems like a good start for one. It can also capture the questions we
need to answer before deciding on a policy.

On Tue, Jun 9, 2015 at 11:47 AM, Irvin Chen <ir...@mail.moztw.org> wrote:

> Gijs,
>
> We have 2 solution besides leave the issue raise again and again,
>
> First, we use the regionName list and extend it to as complete as we need.
> Second, we take GENC/ISO 3166 as base and we still need to set a procedure
> for our worldwide communities able to patch the list.
>
> Which ever we choose, we both need to set a i18n policy and make
> acknowledge to all product manager follow the list to prevent further
> problem and make our user happy and not feel offended.
>
> Mozilla should be the best model of the OSS projects on i18n. We do well
> respect to our user worldwide since 2002. And now we fall behind some other
> projects but we can catch up.
>
>
>
> Gijs Kruitbosch
> gijskru...@gmail.com>於 2015年6月9日 週二，下午8:17寫道：
>
> On 09/06/2015 12:28, Irvin Chen wrote:

> > > The list*1 had been inside Firefox for decades in
> > > preference/content/language setting *2,
> >

> > Languages and countries/regions are not the same thing. The list in the
> > preferences has language names, and only uses the regionNames list for
> > identifying distinctions in language based on the region where that
> > language is spoken (en-US vs. en-GB being a well-known example).
> >
> > The purpose seems different enough, and the number of regions we
> > actually use and display small enough, that it doesn't seem like a good
> > candidate for use for the projects identified upthread.
> >
> > ~ Gijs
> >

[Tim Guan-tin Chien]

It might be worthwhile to copy one of the propsals in this thread to a wiki
page and start from there.

But again, I am not sure of the process needed to make it a Mozilla-wide
policy.


Tim

Majken Connor <maj...@gmail.com> 於 2015年6月10日 星期三寫道：

> Irvin,
>
> I think it might help move this forward if someone started a proposal doc
> somewhere. Otherwise we won't get out of the debate stage. What you just
> said seems like a good start for one. It can also capture the questions we
> need to answer before deciding on a policy.
>
> On Tue, Jun 9, 2015 at 11:47 AM, Irvin Chen <ir...@mail.moztw.org
> <javascript:;>> wrote:
>
> > Gijs,
> >
> > We have 2 solution besides leave the issue raise again and again,
> >
> > First, we use the regionName list and extend it to as complete as we
> need.
> > Second, we take GENC/ISO 3166 as base and we still need to set a
> procedure
> > for our worldwide communities able to patch the list.
> >
> > Which ever we choose, we both need to set a i18n policy and make
> > acknowledge to all product manager follow the list to prevent further
> > problem and make our user happy and not feel offended.
> >
> > Mozilla should be the best model of the OSS projects on i18n. We do well
> > respect to our user worldwide since 2002. And now we fall behind some
> other
> > projects but we can catch up.
> >
> >
> >
> > Gijs Kruitbosch

> > gijskru...@gmail.com <javascript:;>>於 2015年6月9日 週二，下午8:17寫道：

> >
> > On 09/06/2015 12:28, Irvin Chen wrote:

> > > > The list*1 had been inside Firefox for decades in
> > > > preference/content/language setting *2,
> > >

> > > Languages and countries/regions are not the same thing. The list in the
> > > preferences has language names, and only uses the regionNames list for
> > > identifying distinctions in language based on the region where that
> > > language is spoken (en-US vs. en-GB being a well-known example).
> > >
> > > The purpose seems different enough, and the number of regions we
> > > actually use and display small enough, that it doesn't seem like a good
> > > candidate for use for the projects identified upthread.
> > >
> > > ~ Gijs
> > >

> > > _______________________________________________
> > > governance mailing list
> > > gover...@lists.mozilla.org <javascript:;>

> > > https://lists.mozilla.org/listinfo/governance
> > >
> > _______________________________________________
> > governance mailing list

> > gover...@lists.mozilla.org <javascript:;>

> > https://lists.mozilla.org/listinfo/governance
> >
> _______________________________________________
> governance mailing list

> gover...@lists.mozilla.org <javascript:;>
> https://lists.mozilla.org/listinfo/governance
>

[Fred Wenzel]

As for making it project-wide policy, I would reckon something like:

- Draft a policy that is reasonably well (not: unanimously) agreed upon
- Find a module owner (and maybe: peers)
- work with Mitchell for her nod of approval as project-wide policy
- create module, execute

FWIW: I've been shepherding the product-details code for years, so wouldn't
mind owning the module or being a peer.

That said, I don't see this discussion gravitate towards a superior
solution yet, so I'd most definitely need productive (!) help drafting a
policy here.

Fred


On Wed, Jun 10, 2015 at 2:22 AM, Tim Guan-tin Chien <timd...@mozilla.com>
wrote:

> > > > > The list*1 had been inside Firefox for decades in
> > > > > preference/content/language setting *2,
> > > >

> > > > Languages and countries/regions are not the same thing. The list in
> the
> > > > preferences has language names, and only uses the regionNames list
> for
> > > > identifying distinctions in language based on the region where that
> > > > language is spoken (en-US vs. en-GB being a well-known example).
> > > >
> > > > The purpose seems different enough, and the number of regions we
> > > > actually use and display small enough, that it doesn't seem like a
> good
> > > > candidate for use for the projects identified upthread.
> > > >
> > > > ~ Gijs
> > > >

> > > > _______________________________________________
> > > > governance mailing list
> > > > gover...@lists.mozilla.org <javascript:;>

> > > > https://lists.mozilla.org/listinfo/governance
> > > >
> > > _______________________________________________
> > > governance mailing list

> > > gover...@lists.mozilla.org <javascript:;>

> > > https://lists.mozilla.org/listinfo/governance
> > >
> > _______________________________________________
> > governance mailing list

> > gover...@lists.mozilla.org <javascript:;>

[Gervase Markham]

On 10/06/15 10:22, Tim Guan-tin Chien wrote:
> But again, I am not sure of the process needed to make it a Mozilla-wide
> policy.

I'd say the easiest route is via something like: consensus, written
support from key stakeholders and then a rubber-stamp from Mitchell. If
we can't get consensus, we should write up the majority stakeholder view
and get the minority to write a dissent, but that would make approval
take longer.

Gerv

[Gervase Markham]

On 10/05/15 17:31, Vladimir Krstic wrote:
> Please work this out, investigate why these people have there
> location set like so and fix it.

Thanks to everyone for their input on this. It's clear that none of the
options available to us here is without any problems. So, after
discussions with Mozilla legal, we've decided that we will work towards
standardizing Mozilla's websites on using the GENC list[0].

The GENC list is based on ISO3166 but modified by the US Government for
their purposes. As it so happens, it makes what seem to us like a very
sensible set of changes. Of particular relevance to this thread, it adds
an entry for Kosovo, but it also makes other changes which seem
sensible, such as calling Taiwan "Taiwan".

I will be contacting the relevant responsible people over the next
little while to encourage them to move their sites across to using this
data source. If you know of places where Mozilla is using a list of
countries on a website, please let me know by email.

If you can see some massive objection to this course of action, other
than "it's from the US Government", then please also let me know.
Otherwise, thanks to everyone for their participation in the discussion.

Gerv


[0] https://nsgreg.nga.mil/doc/view?i=2500 is the latest version,
version 3.0 - although unfortunately this website requires a security
exception in all Firefoxes and Chromes due to its cert chaining to the
untrusted DOD root, and also won't work in Nightly or Developer Edition
because their server is officially busted and won't negotiate anything
other than RC4 even though it advertises it. <shrug>