4 ms·

I'm not sure if you read the article, but literally every one of your points is clearly addressed Open source contributors self-select. > Yes, and if the enviro

I'm not sure if you read the article, but literally every one of your points is clearly addressed Open source contributors self-select. > Yes, and if the environment is hostile to people of colour, or specific genders, they obviously won't contribute. They have to put time in, usually for $0 and often without thanks > Right. As the author states in a comment below the piece: "Open source work should be paid work, and, until it is, it shouldn't be a requirement to getting a job -- that only increases inequity when so much of the unpaid care work falls on those already minoritized by tech and open source." I don't know of any FOSS project who asks, or cares, about race or sex or anything else except code, or if the project is ill-maintained, at least your patch will get just as ignored regardless of your background. > So how do you explain all the research that tells you this isn't true? Such as this piece - https://peerj.com/preprints/1733/ https://peerj.com/preprints/1733/ - cited in the article.

raxxorrax 5y ago
The data of the study doesn't reflect these conclusions to be honest. The most simple one, that women engage in far fewer numbers explains all observable effects in my opinion. Also the users the data observes are found on Github and Google+. This is a insufficient data if you write about the open source community in general. The implicit bias test the authors used to certify themselves have problems justifying their relevance.
- chhum 5y ago
  "The most simple one, that women engage in far fewer numbers explains all observable effects in my opinion." > Well yes. But why do you think that is? If OSS is, in general, hostile to woman (and I would suggest that it is) than obviously fewer of them engage with it. Of course that same problem is reflected all the way up the chain - fewer woman become programmers because computing is hostile to them - a trend which starts at school and has been the case since about the 1980s.
fivelessminutes 5y ago
> I'm not sure if you read the article > As the author states in a comment Ie, not in the article. Can you elaborate on how that paper 'tells me' my own lived experience the last 20 years maintaining FOSS projects and offering patches 'isn't true'? That sounds arrogant on your part. The paper tries to guess gender from github nyms and profile pics, and looking for google + integration, this seems like a red flag to me. I couldn't guess gender or sex from that, especially considering regional differences, like anime pictures for profile pics, unless it was explicitly telling me in the name. What they may instead be partitioning is the aggressiveness / confidence of the nym and its presentation, which corrolates later to what happens at the first hurdle for their patches. For simple bug fixes, patches are typically acceptable right away. For more complex fixes and new features, some negotiation is needed with the maintainer as to how it should be done, there are often several ways that are reasonable, but eg, only one or two that align with future plans for the code. If the maintainer asks for a redo, a good proportion of contributors give up, they have exhausted their initial energy. Similarly, when asked for tests, or presented with considerations for other supported platforms the contributor doesn't care about, more give up. It requires extra confidence to approach the maintainer about preferred ways to do the patch before just starting on it. The maintainers are sometimes assholes (I am pretty sure, to everyone). I think it's very hard to unpick why patches didn't go anywhere unless you follow the story of each, certainly you need abnormal energy and confidence to get started and get over the hurdles for anything nontrivial.

raxxorrax 5y ago

The data of the study doesn't reflect these conclusions to be honest. The most simple one, that women engage in far fewer numbers explains all observable effects in my opinion. Also the users the data observes are found on Github and Google+. This is a insufficient data if you write about the open source community in general. The implicit bias test the authors used to certify themselves have problems justifying their relevance.

chhum 5y ago
"The most simple one, that women engage in far fewer numbers explains all observable effects in my opinion." > Well yes. But why do you think that is? If OSS is, in general, hostile to woman (and I would suggest that it is) than obviously fewer of them engage with it. Of course that same problem is reflected all the way up the chain - fewer woman become programmers because computing is hostile to them - a trend which starts at school and has been the case since about the 1980s.

fivelessminutes 5y ago

> I'm not sure if you read the article > As the author states in a comment Ie, not in the article. Can you elaborate on how that paper 'tells me' my own lived experience the last 20 years maintaining FOSS projects and offering patches 'isn't true'? That sounds arrogant on your part. The paper tries to guess gender from github nyms and profile pics, and looking for google + integration, this seems like a red flag to me. I couldn't guess gender or sex from that, especially considering regional differences, like anime pictures for profile pics, unless it was explicitly telling me in the name. What they may instead be partitioning is the aggressiveness / confidence of the nym and its presentation, which corrolates later to what happens at the first hurdle for their patches. For simple bug fixes, patches are typically acceptable right away. For more complex fixes and new features, some negotiation is needed with the maintainer as to how it should be done, there are often several ways that are reasonable, but eg, only one or two that align with future plans for the code. If the maintainer asks for a redo, a good proportion of contributors give up, they have exhausted their initial energy. Similarly, when asked for tests, or presented with considerations for other supported platforms the contributor doesn't care about, more give up. It requires extra confidence to approach the maintainer about preferred ways to do the patch before just starting on it. The maintainers are sometimes assholes (I am pretty sure, to everyone). I think it's very hard to unpick why patches didn't go anywhere unless you follow the story of each, certainly you need abnormal energy and confidence to get started and get over the hurdles for anything nontrivial.