potiuk commented on PR #55894: URL: https://github.com/apache/airflow/pull/55894#issuecomment-3424639521
> @potiuk good to go and update? WDYT? Go ahead. But I think some clarity is needed here. In fact, I think in Airflow we prefer to "do" stuff rather than make sure that what we "do" is not going to be commented on and asked to be changed. While it might seem like over-burdening of contributors with potential re-work, this is in fact targeted to optimise the committer's time (which is far more scarce of a resource). That also includes committers proposing changes that other committers review. I often redo and rewrite my PRs multiple times and that's OK. It's OK to get later comments that were not received before, and also it's not **guaranteed** that if you got a "go ahed" it means that no more changes will be requested (by the same maintainer or other maintainers). This is simply because a) things change, b) people have more time to think c) before ideas are materialized in a PR, you might not realise somethign d) new evidences show up ... or e) the comments are suggestion were unclear, ambiguous or misuderstood or e) simply committer changes their mind seeing the proposed PR. So - just to be very clear about expectations here - if you (or anyone else - it's not you in particular) get a "go ahead" after comments where you were asked to make a change, it does not automatically mean it will be merged if you follow the comments. This is not "given". It might well be when you rework your change proposal, you will get other comments or even that maintainers who will see it will tell you "no, after seeing it, the original proposal was actually better with that simple thing" - or that you won't get conflicting comments and proposals from another maintainer (even someone who had not been involved so far). This all **might** happen and is even expected to happen quite often. That's why I suggest to anyone reacting to comment - just do. Make the changes, and then ask to re-review, rather than wait for review, try to get 100% clarity on the changes and only after that - do it. This is far more efficient, optimizes maintainer's time, energy and focus way better, even if it might be that the contributor's individual time is not optimally used. Yes - it's not, and it's ok and pretty much conscious choice of maintainers here on what we are (even without thinking) optimising for, also often that contributor's time / energy and focus is often not "lost" - resulting discussions, learnings, conflicts of opinions are often way better result for the 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
