CHAOSS CHAOSScon EU 2020, 23 Feb 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Language barriers for open source contributors | Isabella Vieira Ferreira | CHAOSScon EU 2020

Description

Language barriers for open source contributors

While open source development is common across the world, projects from countries outside North America and Europe, such as China, have difficulties attracting international contributors. One major reason for this is language differences. Thus, there is a lack of understanding of whether there are problems with attraction and retention of contributors due to language differences. To address the aforementioned issue, the proposed presentation will provide an overview of the diversity of non-native English speakers in different open source ecosystems. Furthermore, we will provide results about whether or not those contributors face a language barrier when contributing to open source projects. This will include a survey and a discussion with the audience to understand their motivations when contributing to open source projects, if they have ever faced any communication problems due to language differences, if the non-native English speakers feel welcomed in open source communities, and if they have ever felt that there is a language barrier when contributing to open source projects. The presentation will conclude with a discussion on how we can create metrics to assess the spoken language diversity in open source communities and how to include those people in the community more easily.

Slides: https://chaoss.github.io/website/CHAOSScon/2020EU/slides/language_barriers.pdf

-----
Isabella Vieira Ferreira
PhD Student - Polytechnique Montréal
@isaferreira_57

Isabella Ferreira is currently a PhD student at Polytechnique Montréal working under the supervision of Dr. Bram Adams. As part of her degree, she is working with cross-cultural contributions in open source projects, civil communication in open source projects, and on how to link review e-mails to Git commits. Her main research interests are mining software repositories, software maintenance and evolution, and human affect in Software Engineering.

-----
About CHAOSScon

Learn about open source project health metrics and tools used by open source projects, communities, and engineering teams to track and analyze their community work. This conference will provide a venue for discussing open source project health, CHAOSS updates, use cases, and hands-on workshops for developers, community managers, project managers, and anyone interested in measuring open source project health. We will also share insights from the CHAOSS working groups on Diversity and Inclusion, Evolution, Risk, Value, and Common Metrics.

https://chaoss.community/chaosscon-2020-eu/

A

Hello, everyone does anyone recognize this image, you know what it is about.

A

So this is a tower of babel and they, the history behind it, is that people wanted to build the tallest tall tower and to reach god and at that time that was kind of easy because they were speaking the same languages and they wrote from the same place right so because they wanted to do that without God, so God they started to punish them and make them speak different languages. So at some point they couldn't communicate anymore and the tower work was never finished.

A

And apparently this is the first time in history that people could not finish a project due to a language barrier.

A

That's what my talking about my new Isabela I'm, a PhD student at free technique, mantra and I'm gonna talk about the language barriers for open-source contributors, so the topic Bible is like a open source project right. So we have people that want to build a software and nowadays with open-source they come from different places and they speak different languages. So communication is very important and if they cannot understand each other, so we would say that maybe the quality will not be good or you're, not gonna.

A

Attract and retain those developers- and it seems that non-native English speakers they might not be confident enough when they're in a very technical environment, for example. Here someone was asking a question and then he said I'm, not a native English speaker. So please forgive me and I'm glad to receive any feedback and to answer your question or your questions for what qualification and someone also said in the first line of his post. First of all, sorry for my english, I'm not a non-native english speaker and I'm not sure about the vocabulary regarding typing.

A

So what am I writing? Might not be clear to you and even if you are a native english speaker, that might be different if you are come from different countries right so, for example, here they were talking about package manager from Emacs straight and someone said: oh I'm, not a native English speaker the title. It seems that this is not a good package manager, but I think you mean the opposite, and then someone shall need a speaker but I'm British.

B

A

Be hard to catch those things right and in our context here, a language by year is when developers can not contribute to a source code or they have difficulties in communication to different languages, and we want to analyze its non-native english-speakers. They actually face a language barrier and you can source projects and for that we need to identify someone's language right and that's kind of a bit trickier.

A

So we started from translation so in mind, translation projects that we can somehow identify someone's first language, and we do that because translation is one of the common ways to start contributing to open source projects and because with that, we can somehow estimate the first language of someone based on the language that they contribute the most so in mind. Two ecosystems, genome and OpenStack 14 projects from each other, and we analyzed about 10 years of data.

A

As a result, we found 549 translation contributors that did translation to 122 languages, so we got those translation contributors, and that was not enough for us to know if they are native or non-native English speakers. So we did a may know, validation by googling their names and going through social media github their web page to try to find where they are from or based on their location or in their name.

A

So, for example, if someone has a Chinese name is that is not unknown in the speaker or if he's in the US, we say that is a English speaker. So, as a result, we found that we have more non-native, English speakers than made of English speakers, and we want to compare both groups to see whether is easier or more difficult for someone to go on translation to source code right. But since those numbers they are very different.

A

It's not a fair comparison, so we decided to split the group of non-native contributors based on how this similar is the language that they contribute the most to English and based on that, we calculated something called genetic proximity, which is how close how similar to English are the words in that language.

A

So if the genetic genetic proximity score is close to zero, it means that the language is very close to English and if it's 100 means is very different from English and as we can see here, we have three clear Peaks for both ecosystems, which means that we can split our dataset for non-native English speakers into three different categories right, the first time we call it almost native speakers and those people here they contribute mostly two languages close to English, in other words German Dutch and language. That are very similar to that.

A

Here we had remotely native speakers, basically Romance languages like French, Spanish and Portuguese, and here we have absolutely no native speakers, which are people that speak Chinese, Hebrew or Hindi. So as a result, we had four different groups made of almost native remoted native and absolutely non-native speakers, and we want to see how easy it is for people that are in those categories to go from translation to co-development.

A

So here we split people by different types of contributions, so we have people that did translation and they changed the source code and we also have people that just did translation and their native category for it alone. We found that most of the contributors. They just do translation, so it means that the project somehow does not retain those contributors to do more technical change. But we don't know.

A

What's the go of those people right, and we also found that most of the people that do just translation, they are either remote in native or absorbed absolutely non native, and most people that are native speakers. They do translation and coaching's and for OpenStack we found out so that it's later and absolutely no native English speakers, they do translation coaching's while remote in native speakers.

A

They just do translation and other stuff, and we want to just calculate the success rate of someone going from translation to source code and the success rate is basically we get the number of someone that the translation and code change, for example in the native category, and we divide by the total number of natives because we have- and here we can see, fergan on that made up English speakers.

A

They have more than 50%, which is the threshold we define to see if it's easier or difficult for someone to change the source code, so apparently for those non-native, English speakers, somehow it's hard for them to go from translation to source code and for openstax for remoting native speakers.

A

So as a result, we found that it is easier for native speakers to go from translation to source code, and then we want to channelize which factors could explain those differences and why those need non-native speakers, they won't change the source code. So we did two type of analysis. The first one was analyzing the github activity of those contributors that did translation, & Co chains. We analyzed the number of repositories and the number commits in their github account. So for the number number of public repositories. We can see that we made up English speakers.

A

They have more repositories analyzing here. The medium compared to don't know, native English speakers and for OpenStack is the opposite. However, we only found statistical difference per genome, which means that Indian or made-up English speakers. They have more public repositories than non-native English English speakers, and when we analyze the number of commits do those repositories. We also found that made of English speakers.

A

They have more comments than non-native English speakers for both ecosystems, but we are only found statistical difference for genome, and that means that if they have more commits- and they have more public repositories, somehow they are more experienced with other projects. It might be easier for them to contribute, since they have a more technical knowledge and then we analyzed the pull requests.

A

So you wanted to see if you are a native or non-native english-speakers, if you have more rejected, pull requests and how many comments you had and how easy or hard is to read the commit messages. So forgiven we found that almost nearly speakers, they submit most of the pull requests and they have more urgent to request and for OpenStack its I was the same but native speakers. They have more pull requests here. We have the number of comments in each pool request analyzed for genome.

A

They only have a few comments in their pull requests, so we were not vote analyze it and for openstack we saw that made of English speakers. They receive more comments in their pull requests than non-native English speakers, and we also found a statistical difference in that result, and then we wanted to see is the way you write your commit message for a pull request. If it's easier or hard to read for someone, so we calculated, we call it a fresh readability score when it's close to 100. It means the message is very easy.

A

To read and close to tear is very difficult to read so for native English speakers. We see that they have a higher readability score for both our systems and we found the statistical difference, and this result means that it's easier that the message is written by native English speakers, it's easier to be read their non-native, English speakers. So, as a result, we found that native English speakers.

A

They have more convinced more github repositories, which means they have more experience in other projects, and they also have more comments and that committee messages are easier to read, which might explain why they receive more comments.

A

So we have some practical implications. We recommend that core project members should look in why those contributors are not promising to coaching's things. For example, in genome we have most people doing just translation, also, maybe not native speakers. An experienced developer should team up with an experienced and non-native English speaker speakers, as we see them here to see how they could incorporate tools, for example, during pull requests to check the clarity and correctness of the English messages.

A

And for researchers, we could build tools to assess the committee members to assess how someone is progressing and what are their face. No language barrier or not, and one thing that might be a start pointing is to do what OpenStack nowadays. So they have a documentation saying that well, our documentation is written in American English, and we know that this might be a challenge for non-native English speakers. So here we provide some guidelines, so they show how new contributors should work if they have English as a second language.

A

Also how native English speakers should work with non-native English speakers and they also provide some cultural and things to remember. For example, they mention that Americans and Australians. They are more direct to the point why Chinese and Portuguese speakers they first list the the facts, and then they make the request.

A

So with that right, you put my top. So we talked about the language barrier, whether non-native speakers placed on language by year or not. We saw that it's easier for native English speakers to progress from translation to coaching's and that they are more experienced. Their messages are easier to read and that they receive more comments in their poorest past and also we provide some practical implications.

A

This was the start pointing to analyze the language barrier, so I would be happy if you have another idea how to measure it and some how to incorporate it into cups. Thank you.

C

So you have five minutes to answer questions if you could repeat the questions for the camera.

D

A

Means that they did translation and afterwards they leave the coaching's.

D

A

And someone that did just translation taking never did anything for change.

C

So I was the: were you able to do in your study like prior projects that were dominated by non-english speakers and see if the event was the same?

C

If it was another language, besides English members coming in, or was there enough of a sample size to make that happen? Yeah.

A

For now, we externalize English projects we intended to analyze, for example, Chinese projects to see how hard it is for them to attract ER people. But we could not find enough data since we start with translation projects with other languages, but that we've been to the data.

E

Show slide 24.

E

Yeah, so Dara is wondering for know why so sweet something that scenes for me counterintuitive. Is that the absolutely non-native speakers in genome they are closer to the native ones than the almost and remotely native ones.

A

E

A

It might be that they have, for example, short messages or they just write a title people request and that somehow they might, you cannot capture it.

A

E

The beginning there was justification, which is that the way in which you define whether a language is closer to the other. So this kind of.

E

A

E

How do you define all this genetic.

E

A

It's a based on linguistics, they have some metrics, so they compare if the words are similar and yeah.

A

The body English house party for me in French, the genetic.

B

Related to this so wearing you plastic, because they.

B

Native English and a lot of open-source contributors actually.

B

A

This is actually the language that they contribute the most. So if you now remain a classification, we say that they are non-native people, but the language that they contribute. The most is Hindi, so they will be here but they'll if their language they contribute their boss is English. They will be here.

B

I think it's really nice that people, if and also for check, aware that the language they used to do something very simple and don't use a lot of abbreviation. That is an important to have somebody who contribute generation to transfer into a contribution, because the whole idea of helping and includes communities, so people play different products to grow the project since 11.8 is also important to have people do documentation, so I want to spend the whole idea to transfer. Oh yeah.

A

We don't know for now it's their goal to do coaching. So that's something we should look into, but it might be also that they don't have the technical knowledge or the experience to go for if they want to.

D

A

Mean if they come to put more to discussions.

D

A

It depends on the person in the community and if they are familiar with each other, they might use different languages and if they don't know each other, they might be more formal or they do not use sarcasm and those things are really very hard to identify. So nowadays, for example, for sarcasm, we don't have a lot of tools for them, but though we have tools for sentiment and motion politeness that might help to identify those keys.

A

C

Thank you very much.