hi Suvayu, Changing the subject so we can have a discussion about this separately. It sounds to me a bit like you may be airing grievances but I will offer my opinion and we can see what other people think.
>From a purely factual view, the project is successfully attracting and supporting contributors. Over 500 different people have contributed to the project (more than the "420" printed on GitHub because many people use e-mail addresses not associated with their GitHub user names) and that number is increasing steadily over time. We have invested greatly in providing systems to support developers of the project. We have a large and complex CI setup and nowadays it works pretty much like clockwork which is a huge change compared with a year or two ago. In general, I will say: if you wish for significant volunteer mentorship especially in an early stage open source project you are likely going to be disappointed. I associate these patterns with later stage projects (think: the Python programming language or the Linux kernel). I personally do not have the time -- I direct a team of people working on the project working towards specific development goals, and we are in turn accountable to the people who are sponsoring our work. In addition, I do a large amount of individual contributions. If you are looking for individualized "mentorship and guidance" _beyond_ pointers toward what part of the project you should be looking at to solve a problem, feedback on issues about whether or not something is deemed useful or high priority or not, and feedback on your PRs whether you are on the right track or not, I think your expectations -- at this stage of the project -- may not be reasonable. The number of regularly active developers in this project for the parts that you have looked at is actually quite small. So you're talking about some of the 10 people at the top of the GitHub contributor list. It would be different if we were talking about an older project with an order of magnitude more regularly active developers. The area where I think we could improve the most is developer documentation, which in a sense is "self-service guidance" in understanding the codebases. Antoine and others have taken initiative on this but it often goes by the way side since the number of people with requisite knowledge to write it is small (countable on fingers and toes if you include all the programming languages) and very short of free cycles. Thanks, Wes On Fri, Jun 19, 2020 at 9:44 PM Suvayu Ali <fatkasuv...@gmail.com> wrote: > > 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.
