Hi Joan,
IMO, unless there will be a "MUST" or "SHOULD" and some request for action by
leadership, it might be more inviting to simply describe the two approaches
with some pros and cons and some data and opinions on why it worked and let
other communities decide for themselves. Unless we know for a fact that all
"big communities" will tend to benefit more from separate lists, I'm not sure
we should predispose big communities towards separate lists.
My 2 cents,
-Alex
On 5/14/19, 1:08 PM, "Joan Touzet" <woh...@apache.org> wrote:
Both of these approaches are interesting.
Since this goes past what we want to do for just ourselves, I've renamed
the thread. I just want to remind everyone in this discussion that the
D&I group (in whatever official form it takes) can't set policy for the
ASF - we can only provide recommendations to be acted upon by leadership.
Even within that framework, I am a big fan of RFC 2119 terminology[1]
for our recommendations (that end up in front of the BoD/officers and
may eventually become policy, procedure, or general recommendations).
You'll recognize this as the "MUST," "SHOULD," "COULD," etc. approach to
standards and requirements.
I see the two options being presented (on-list, separate-list) both as
"COULD"s - I don't yet see a convincing argument for making either a
"SHOULD" over the other. But that doesn't mean we couldn't provide
guidance, such as:
"Big communities, or those with a substantial non-English membership
(such as our projects heavily active and originating in China like
CarbonData, Eagle, Griffin, HAWQ, Kylin, ROcketMQ, ServiceComb and
Skywalking) may opt for the Debian-like approach of a separate ML, where
critical discussion is diverted back to dev@ for English. Smaller
projects with less traffic on their dev@ lists, or who tend to use only
a single list for communication, may prefer to keep all threads, English
or not, on the same list."
Thoughts?
I'm finally excited about this initiative again. This discussion is
already bearing fruit that goes past the context of a FAQ and into what
could become part of the first preliminary report back to the Board.
-Joan "yay" Touzet
[1]:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2119&data=02%7C01%7Caharui%40adobe.com%7Cdc1f83c5db3244143ce408d6d8a7fb19%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636934613329838955&sdata=JJ%2FqRowSK%2B7YWdf9CZXiAtxNhSqYtclKSMebCVGJar0%3D&reserved=0
On 2019-05-14 1:14 p.m., Jose Miguel Parrella Romero wrote:
> In Debian, there are non-English mailing lists for user support,
developer discussions, i18n/l10n and news (think press)
>
> The volume is rather small and threads that can potentially change the
direction of the project are invariably in English (whether in the bug tracking
system, mailing lists, IRC, etc.), but the infrastructure exists and at least
for i18n/l10n and news I can say there's an operational dependency on it. Of
course outside of Debian-hosted infrastructure, there are local Debian user
groups, meetups, conferences, etc.
>
> I recently heard an anecdote from Chris Lamb (former Debian Project
Leader) where he mentioned that after a non-English speaker was repeatedly
using the word "abysmal" to describe the performance of a service (creating
friction with the developers and operators) they chose what I would describe as
a probing/educational communication style, where regardless of whether the
performance of the service was underwhelming or not, the nuances of the concept
were written back to the original poster to the point where either it was a
personal attack (rare) or a different word emanated as alternative.
>
> PS: also sharing some resources from Debian's Anti-Harrassment team Wiki
page [1]
>
> [1]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FAntiHarassment&data=02%7C01%7Caharui%40adobe.com%7Cdc1f83c5db3244143ce408d6d8a7fb19%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636934613329848952&sdata=oCyzofhBdkgB0G1vPwYvya7ErMDEiSuyG38ex2m3zWs%3D&reserved=0
>
> ________________________________________
> From: Alex Harui <aha...@adobe.com.INVALID>
> Sent: Tuesday, May 14, 2019 9:46 AM
> To: diversity@apache.org
> Subject: Re: [FAQ] Proto-FAQ question 1
>
> IMO, we can come up with a way to support non-English official
communication channels. We have to try to make it clear to as many people as
possible that it is ok to write an email in your native language on dev@ and
users@. We could decide that private@ is the air-traffic-controller channel
and must be English. Hopefully the kinds of discussions on private@ are
limited enough that people on that list can learn enough functional English to
participate. Most are coders using English keywords in programming languages.
>
> When I see a post in non-English on the lists of the projects I
participate in, I shove it into Google Translate. It works well enough to give
me an idea of what the post is about. If I thought it was important, I would
copy the English translation as a reply to the post saying "Google Translate
said you are saying: ". Sometimes, another person on the lists who is fluent
in the original poster's language will offer a translation as well as discuss
with the OP in that OP's language. And that's all good to me.
>
> I do not think we want to have language-specific channels any more than
we would tell some group they must use English when having a conversation in a
public space. That's one analogy I use for the ASF: that we are basically
working from a bench in the town square where everyone can listen in on our
conversations and I can listen in on others. We should not start from the fear
that some conversation that we cannot understand is going to have negative
consequences. Some will, for sure, but it should be ok to ask for a short
summary in English. We can make it a recommended or required practice for the
PMC members to try to provide those short summaries, even if it is via Google
Translate.
>
> Again, a restaurant analogy. If some tourists come into your restaurant,
use their limited English to order food, then have a conversation in their
native language while eating, that should be allowed, and the astute restaurant
worker will still try to pick up on whether they are enjoying the food and the
restaurant in general. IMO, Google Translate has worked well enough for me to
pick up on non-English conversations on the lists and participate. I would not
want to have to monitor other language specific lists. I would encourage
everyone on our lists to use Google Translate to get a sense of the
conversations in other languages. I will be super happy if my project's users@
lists are a mix of languages.
>
> My 2 cents,
> -Alex
>
> On 5/14/19, 9:19 AM, "Joan Touzet" <woh...@apache.org> wrote:
>
> This is something that's been on my mind a lot recently.
>
> We can't come up with a way to support non-English official
> communication channels for the Foundation as Bertrand mentions, but
if
> we don't allow non-official channels in other languages, as the
saying
> goes, "the Internet will route around us" and just create them
outside
> of the ASF.
>
> I, for one, would rather see those discussions happening on ASF
lists if
> at all possible. Maybe we can't have a dev-chinese@project.a.o, but
> couldn't we at least support a users-chinese@project.a.o?
>
> I think it's equally important to consider the i18n and l10n of the
> software projects that we shepherd. This is something I want to ask
the
> assembled minds in the board/officers at the face-to-face meeting
this week.
>
> I know there are some woefully under-recognized solutions within the
ASF
> (such as our Pootle instance,
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftranslate.apache.org%2F&data=02%7C01%7Caharui%40adobe.com%7Cdc1f83c5db3244143ce408d6d8a7fb19%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636934613329848952&sdata=99hQRfqfyrWqqaAY81jUj9fY1xV2y83K5m95H2G2ktk%3D&reserved=0).
Look how
> few projects even try to use it. This is tragic. And doing what we
can
> to improve things here I feel does fall under D&I. It even meshes
with
> the US non-profit mission of software for/in the public good, since
the
> US does not have an official national language, and has a large
> percentage of citizens and residents who speak other languages.
>
> On the intake side, we should consider translation of the FAQ and
other
> documents into a few languages, with reverse translations back to
> English to ensure nuance is not lost (especially for critical
documents
> like the CoC, general project bylaws, and maybe some of "The Apache
Way"
> stuff.) These documents can clearly be marked as "not official" so
as to
> not overburden our thin legal resources to date.
>
> -Joan
>
> On 2019-05-14 12:03 p.m., Alex Harui wrote:
> > It has been interesting to me how important words are in these
discussions. In this case, the word "fix". We may not be able to "fix" as in
"eliminate" the requirement to communicate in English, but I believe we can and
should encourage communities to choose their words more carefully so that
"fluency" is not perceived as a requirement. I already do filter my choice of
words to try to avoid word patterns that non-US citizens may not understand
since all but one of the most active committers on my project live outside the
US.
> >
> > We might come up with other social suggestions like allowing posts
in other languages on users@ lists, allowing posts in other languages on dev@
but recommending translation of the original post to English and requiring
posts in English on private@. That's sort of how Flex and Royale operate today
without any official documentation of this approach.
> >
> > My observation is that restaurant workers in the US in popular
tourist areas are generally trained to be patient with non-English-speaking
customers and also choose their words carefully. Why shouldn't we all take
that approach at Apache? Another observation is that airline pilots fly to
the US from all over the world and communicate in English to flight controllers
in the US (and other countries too, iIRC). I'm fairly certain the US-based
flight controllers choose their words carefully. I do not think all of those
pilots from other countries are fluent in English. They have learned enough
functional English to communicate on how to navigate and land an airplane.
Does/should software development at the ASF require an even larger English
vocabulary than navigating air-space?
> >
> > My 2 cents,
> > -Alex
> >
> > On 5/14/19, 6:27 AM, "Bertrand Delacretaz"
<bdelacre...@apache.org> wrote:
> >
> > On Tue, May 14, 2019 at 3:09 PM Daniel Gruno
<humbed...@apache.org> wrote:
> > > ...It's like democracy - while not perfect, it is (I would
say) the least
> > > sucky way of ensuring fairness, openness and proper
governance, as it is
> > > the most universal (and de facto standard) language we
have..
> >
> > +1
> >
> > > I do not see the need for or lack of English skills as a
thing *we* can fix...
> >
> > Same here, I was mentioning as one invariant that does affect
who
> > joins our communities - or more precisely the way people
contribute.
> >
> > -Bertrand
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> > For additional commands, e-mail: diversity-h...@apache.org
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> > For additional commands, e-mail: diversity-h...@apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> For additional commands, e-mail: diversity-h...@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> For additional commands, e-mail: diversity-h...@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> For additional commands, e-mail: diversity-h...@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org
