vsoch commented on issue #4846: [AIRFLOW-4030] adding start to singularity for 
airflow
URL: https://github.com/apache/airflow/pull/4846#issuecomment-575240752
 
 
   > Hello @vsoch -> I am sorry you have this extra work, but unfortunately it 
happens and this is part of our normal process. This is how - deeply 
asynchronous - the process of community-driven project is. There is no "your 
team" here - there are individual contributors and committers and even 
individual PMC members that are working mostly in their spare time and find the 
time outside of their normal work, at the expense of their families and 
personal time to review and comment on other's code and make it "ready" to 
submit. So there is no "your team" here. There are individual people. And 
sometimes they have other obligations and are simply swamped with their regular 
job so things usually take longer than in a "commercial" setting.
   
   This is completely understandable, and the norm for most open source 
projects that don't have some company (or similar) backing. The feedback I'd 
give is that regardless of an individual being a maintainer or an actual team, 
a new contributor should be welcomed and supported throughout the process. It's 
the individuals of any project doing the reviewing that really make or break 
the culture.
   
   > Yet we have much higher requirements (tests, documentation, quality of 
code, good architecture) precisely because we have no formal structure and no 
way to divide responsibilities - we have to make sure the code can be picked up 
by anyone, anytime and it is fully covered by automated tests.
   
   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 often have PRs opened for weeks or even months until I have time and got 
enough feedback and buy-in from others to be ready to merge - especially if a 
commit is big. And sometimes my idea is ahead of its time and it has to wait 
for months (even years) to be finally implemented (happened to me!). And I am 
humble enough and persistent enough to continue rebasing my code - because I 
understand others cannot just stop their work while the iterations happen. 
Sometimes rebasing 30-40 times. 
   
   30-40 times seems a big excessive, but I don't want to judge. 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.
   
   > And I am trying to not be bitter about it - I try to be empathic about it 
and understand that there are people - not machines on the other side. Actually 
the strategy I use - is to rebase often to avoid one big rebase. It makes it so 
much easier. And rebasing is usually easy - especially that you get conflicts 
ONLY about the files that you touched as well. You do not need to understand 
the whole codebase. I can really recommend tools lik IntelliJ/PyCharm - they 
have fantastic support for solving conflicts and usually it is very easy. And 
only you can do it I am afraid. And it will happen - because other people work 
in parallel. That's just a reality of the project.
   
   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 think a lot of people would like to see singularity support and after 
initial slow uptick it seems that it's time came. This also means that you will 
get a lot of comments, and you will have to meet the quality bar to get merged 
and sometimes people will have different opinion and you will have to find 
consensus.
   
   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 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 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.

----------------------------------------------------------------
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:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to