Hi all, (sorry if this is a duplicate post, I always have trouble posting to this list)
On Fri, Jun 19, 2020 at 5:54 PM Todd Hendricks <hendricks...@gmail.com> wrote: > > I'm a black data scientist. For whatever it's worth, I have never taken > offense to the term "Master" branch, as I have never interpreted it to have > a derogatory connotation. It's literally never crossed my mind. As an Indian person, I would concur with what Todd said. That said, I would like to highlight a few things. Since the community is spending time to discuss how to be more welcoming to a diverse group of contributors, instead of default branch names, there are many practically relevant issues that could be addressed. I've been trying to contribute to this project for about 2 yrs, rather unsuccessfully. I come from the perspective of analysis rather than engineering. But I'm no stranger to technical nitty gritties (particle physicist at CERN, data scientist at non-technical startups, scientific software dev). I started by filing bug reports for my needs (pyarrow and parquet). Most bug reports are still open, they received a bit of discussion, but mostly they have been assigned and reassigned to releases for over a yr. On day one I had offered to do the work myself, but with some guidance, I didn't receive any. So I gave up. Some months later, after Gandiva was released, I came back with the goal of using it from pyarrow. While after some help I could do simple tests in C++, getting it to work with pyarrow proved difficult. I don't remember the exact hurdle, but I decided I would package it for my distro (Fedora) for simpler compilation. So I contributed a few patches to the build system to build against system libraries instead of the vendored versions, including the ability to switch LLVM versions. I think around this time Kou was overhauling the build system. My patches were not accepted, but some of the ground work I did hopefully help Kou. Eventually though, I gave up. Soon after, I tried to build a wheel for ARM; I was gathering some data on an RPi. That didn't go so well either, again, the reason was lack of guidance. At the time, it was also expressed that wheels are disfavoured by the community, and not worth maintaining. I see that position has changed now. There is a clear pattern here, if the community is really serious about addressing diversity and being inclusive, time would be better spent by addressing issues like contribution guidelines for beginners (not saying absolute beginners), mentoring, or triaging of open issues in terms of ease of contribution, and other concrete hurdles for new comers. I realise people's time is scarce, but you have to start somewhere. At the least, if someone guides me, I can pick up these tasks and the maintainers can focus on the more involved roles. If the issues I have highlighted cannot be prioritised, then wasting time on superficial issues like default branch names should also be avoided. I hope my comments are accepted as constructive criticism. Cheers, PS: whitelist/blacklist -> accept/reject seems quite reasonable; personally, colour based terminology has always been very unclear to me -- Suvayu Open source is the future. It sets us free.
