potiuk commented on issue #4846: [AIRFLOW-4030] adding start to singularity for airflow URL: https://github.com/apache/airflow/pull/4846#issuecomment-575337231 Just to make sure we understand each other - I am not defensive, I really try to understand and put in actions some of the things that can make our community more welcoming. I understand your experience is not good with this PR, so I really want to find out and get some ideas on what we can do better (or maybe give you some information you missed that we already changed). As you will see below - we are really open to that and I particularly am very interested in that. > Also understandable, and in this case, as a new contributor, it would be helpful to have someone give guidance about what needs to be done, tested, etc. I perfectly understand that part. Actually you might want to take a look at the thread I started recently titled "Being even more welcoming community?" at our devlist: https://lists.apache.org/thread.html/aa6006ae051a406b0dfe20297407efd2ddf1337293b33fdda4c8f5fd%40%3Cdev.airflow.apache.org%3E We specifically talked there about need for some mentorship approach where more experienced community members could mentor the new ones and answer the questions. We also have slack where people ask questions (and other people - often committers are responding) and devlist in general. So what do you think in general we could do better here? What would help you as a new committer? I would really encourage you to join the devlist thread about "Being more welcoming") and voice your concerns there. I really want to understand what your expectations are for that other than what is currently there. Any ideas are welcome. > 30-40 times seems a big excessive, but I don't want to judge. Well. Few years ago I've learned (from a person I value a lot) one of the best quotes: "If there is something that is painful - start doing it more often". It is a counter-intuitive but brilliant advice in many things in IT - doing builds, releasing etc. This is very same thing with rebases - the more often you do them, the less painful they are and the better you learn how to do them in least painful way. That's why for me 30-40 is not a lot because I sometimes do it daily And it works beautifully because at most I have one-two-conflicts to solve that are easy/obvious. > It seems like there should be better organization around at least setting expectations for contribution. In my case, I neither knew what to do, I didn't feel empowered to do anything, and I didn't understand the architecture well enough or have enough experience with the community to know what I was supposed to do. I have a feeling that you are referring to Airflow as it was 10 months ago when you started it. And gee how we've changed since. Let me just ask you a few questions: - Do you know we have updated "Pull Request guidelines" which describe the requirements for contribution in fairly short but comprehensive way? https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#pull-request-guidelines ? - Do you know that we have a detailed "new contributor's" workflow in our CONTRIBUTING.rst documentation where we graphically describe how the process look like, where we explain that you should involve and discuss with community, be persistent: https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#contribution-workflow-example ? - Do you know that we have "First time contributor's workshops" - https://cwiki.apache.org/confluence/display/AIRFLOW/First+time+contributor%27s+workshop where we encourage people to work together with commiters and learn how to contribute, what are the requirements and they have a chance to do so. We've already run 3 of those and we are discussing 5 more. - Do you know that we have a "Breeze" development environment that aims to be up-and-running in less than 10 minutes and allows you to quickly run any of the tests without a hassle of configure your local environment? https://github.com/apache/airflow/blob/master/BREEZE.rst - Do you know that we have a detailed "Testing" document that describes how to test Airflow - including integration tests, Kubernetes tests, backend-specific tests: https://github.com/apache/airflow/blob/master/TESTING.rst I would really love to understand it - whether you simply had your knowledge about our guides/processes back from 10 months ago, or maybe you knew all those resources and they were not helpful? And ideally - if you know what exactly could help you - I would love if you write it in the devlist thread: https://lists.apache.org/thread.html/aa6006ae051a406b0dfe20297407efd2ddf1337293b33fdda4c8f5fd%40%3Cdev.airflow.apache.org%3E > Yes, and to this point I'd say touche - there are people on the other side that aren't bitter, but need guidance. I've been an open source developer for over a decade and I'm well aware about rebasing, but more importantly, people and communities feel very differently about it. The sentiment here seems to be that it's in favor, but the communication was poor so the final result is a mess. I would really love to hear what could be improved in the communication. For now I hear there were delays and stalling (which is unfortunate, but hard for me to apologise for others who participated in that). On the other hand - it's really responsibility of the author to remind and call out if they feel their job is stalled. This might happen simply by overlook and just a friendly "ping", "can you please take a look - I am waiting for your feedback" is the best way to ping committers. We are usually busy and have not only yours but 10s of other commits to look after. We also wrote it in the CONTRIBUTIBUTING.rst "Ping @ #development slack, comment @people. Be annoying. Be considerate.". > Yes, and I would also need guidance from somewhere about what needs to be fixed, how to update the PR, otherwise it's just confusing. I think once you rebase it - you will get it - simply make a comment and @ people that commented your request and then "Be annoying, be considerate". Just be empathetic as well and understand that we get 100s of emails a day and we look through 10s of PRs, so we really look only at the PRs that have no conflicts and are "travis green". The main reason for all the automation we've implemented recently is to decrease the burden on reviewers. Now when we see "green" checkmark on PR is a sign for us that "basic requirements" are met - and then we can proceed to review. > I feel like you are taking the defense here, and I certainly didn't do anything wrong, so I want to offer a clean slate and suggest that discussion stop being focused around who is at fault and why, and how we can move forward to fix this. Currently there is a publication out with misleading / incorrect information and I'd suggest that effort is put into fixing that. I never pointed out any faults in my message and never said or suggested you were wrong. I just tried to be informative. As mentioned in my "Being even more welcoming community?" I specifically asked for concrete feedback and information 0 on what we can improve and how. In this context - What publication exactly you mean? I am not sure what exactly you refer to. > I will take the initiative and re-open the PR against the current version, and I look forward to better interactions with the _individuals_ in your community. Thanks! yes I think it's really good idea.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
