jaklan commented on PR #43453: URL: https://github.com/apache/airflow/pull/43453#issuecomment-2458421570
@potiuk > Yes. You trade the time of contributors with time of maintainers. And no. It's not a general "truth" that things start from design. There is an idea of "emerging design" that comes from discussion on a code implemented and tests showing how it work. There is even "test driven development" so statement suggesting that there is the only way of doing things starting with design is totally unfounded. And here we prefer to see the code and tests to be able to assess the impact - that saves precious time of maitainers who (I am sure you can attempt to empathise wiht them) sometimes review 10s of PRs a day and do it in their free, voluntary time. We don't trade the time of contributors with time of maintainers - it's beneficial for both sides to agree on the direction before you go deep into code changes. Neither "emerging design" nor TDD means you start without the expected goal. Although you want to say you first write tests, then you write logic, and only after that you start defining the outcome in issues / user stories, but that would be, well, very unique approach. > So the best thing you can do is to follow the way we do it here. If we follow things each of 3000+ contributors think is "better" , that would make it impossible to manage the flow of incoming contributions. So if you would like to join 3000 contributors, I think it makes sense that you adapt to the way how they work, not the other way round. Or at least that seems more reasonable from common sense point of view. Yes, we will follow the "PR requirements", but that's not the point. In that case we can do the full implementation and be blocked at the very last stage because of something aimed to be discussed at the beginning, or we can implement something very opinionated which will be accepted just because "code and tests look fine". Neither outcome is good. > So ultimately it's actually your responsibility as an author to test and "convince" maintainers that the change is tested enough and to test it when release candidate is sent for voting . This is why also we ask you to add unit tests, to get more confidence that you understand the process and you are going to follow it - including testing the release. We are back to the beginning again. The whole discussion is not about "convincing" anyone if the implementation is correct, that part is quite obvious, but about the common agreement which approach makes sense. We would change the logic, someone else would say they prefer the another one and create a new PR, and we will go back-and-forth indefinitely? If you say there's no one within Airflow contributors to make such decision (which I really don't get - someone has to be a reviewer and someone has to accept the PR anyway - not only, I hope, by reviewing the quality of code - so such person could provide a feedback already now as well), then we can just reach out to dbt Labs folks to find the "decision maker" there. With a hope that their agreement would be a sufficient argument for reviewers to accept the agreed solution (once implementation is finalised, of course). -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
