On Sat, Jun 20, 2020 at 1:52 PM Neal Richardson <neal.p.richard...@gmail.com> wrote: > > Hi Suvayu, > Thanks for your feedback. I'm sorry to hear that you feel that you haven't > had the best experiences trying to contribute to the project. For what it's > worth, I believe that raising concerns like this _is_ itself a valuable > contribution. So even if you haven't gotten to the point of having a pull > request merged, I don't think it's accurate to say that you've been trying > unsuccessfully to contribute--you're contributing right now. > > As it turns out, just the other day I opened a JIRA issue about improving > the contributor guide (https://issues.apache.org/jira/browse/ARROW-9189), > and I'll be taking that up next week as part of our 1.0 website overhaul. I > agree that we can do a better job in helping new contributors participate, > and that many of those forms of contribution need not require lots of time > from Arrow core developers. Wes's point about the limited bandwidth to > provide mentorship is valid; that said, I've seen many successful cases of > first-time contributors getting the support they need. While there's > certainly room for improvement, I'm optimistic that we're on the right > track.
Yes — to be clear, the core developers in my experience (myself included) are spending a lot of time responding to questions on JIRA, clarifying issues with issue reporters, and offering advice about how to proceed. Additionally, we spend a lot of time reviewing code and helping people get their patches ready to be merged. There's no way we would have 500+ contributors if we were not doing these things. As far as getting the help that's needed from core developers, the thing that helps someone like me the most is to have the "request" be as specific and direct as possible. In any given day I might look at 50-100 different issues and so if it's not clear what I need to do I will often move on to the next thing. Example direct requests: * Do you think $PROPOSED_APPROACH is the right one? * In which file(s) should I be looking to make changes? * Is there anything related in the codebase I can look at to learn? I'm sure we can put this advice in our contributor guide. If you ask these questions and do not get an answer, it is OK to ask again. I see six JIRA issues from Suvayu in the project * https://issues.apache.org/jira/browse/ARROW-1956 * https://issues.apache.org/jira/browse/ARROW-3806 * https://issues.apache.org/jira/browse/ARROW-4930 * https://issues.apache.org/jira/browse/ARROW-3792 * https://issues.apache.org/jira/browse/ARROW-3874 * https://issues.apache.org/jira/browse/ARROW-6577 There are comments in all cases and the issues were resolved in 4 out of 6 cases. I see one example of you asking for guidance (https://issues.apache.org/jira/browse/ARROW-1956) on December 29, 2017 while I (and presumably others) were on vacation for the New Year. In the future, it is OK to be more persistent. Thanks > Neal > > > On Sat, Jun 20, 2020 at 11:25 AM Suvayu Ali <fatkasuv...@gmail.com> wrote: > > > Hi Wes, others, > > > > Thank you for taking the time to draft a long response. > > > > On Sat, Jun 20, 2020 at 3:57 PM Wes McKinney <wesmck...@gmail.com> wrote: > > > > > > 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. > > > > This response reinforces one of my points, all this branch name change > > business then has nothing to do with actually getting new > > contributors. > > > > > 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. > > > > Agreed, and I have learned a lot from it just by observing. > > > > > 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. > > > > If pointers to you are: look at the serialisation code, then yes, I > > was hoping for more along the lines of look at class XYZ in file bla. > > I completely understand if that's not possible. That is why I never > > said anything before. You may not remember, during the "whether to > > support wheels" discussion, as I was impacted, I offered a compromise > > of releasing a reduced feature-set wheel with simpler dependencies, > > which was rejected with this exact argument. I did not counter, > > because it is a very reasonable position to take, and I'm in no > > position to "demand" anything. > > > > I only wrote today because I felt maybe now there is a willingness for > > newer, diverse contributors, because that's how this thread was > > motivated. So I stated the hurdles I have faced, and hoped instead of > > wasting scarce resources on superficial changes the community could > > address actual hurdles for new contributors like me. Obviously I > > misunderstood. > > > > > 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. > > > > I'm guessing you mean the Sphinx docs? Whatever I have managed to use > > Arrow for, it's thanks to those. Maybe that is my cue, when hitting a > > dead-end, "I should ask which source file do I look in?" > > > > Anyway, I don't want to waste anyone's time anymore. I felt there's > > room for feedback, I was wrong, and I withdraw from this discussion. > > I'll continue to lurk on the mailing list, and try to contribute when > > I can. > > > > Cheers and thanks for your time, > > > > -- > > Suvayu > > > > Open source is the future. It sets us free. > >
