kaxil commented on issue #67515: URL: https://github.com/apache/airflow/issues/67515#issuecomment-4555440066
> The linked blog post from Armin is about people using AI to generate issues. Absolutely. AI has made people come up with issues & PR that they don't read. But what I said in previous comment was: "on why Committers are frustrated as well when people come in with an issue with a solution that might not be the best long-term solution.". You are one of hundreds of people that create GH issues on the Airflow repo. Look at the all the PRs I have closed in recent times, badly rewritten, overly confident. And it takes time to review (even with AI) all of them. At times there is slop, at times there is a bad issues, at times people directly comes with their solution which isn't good for longer-term. > involved AI is 100% disclosed. > My entire issue is human, I assure you. That doesn't matter to me. AI is a tool, if you use it or not that is up to an individual. Responsibility sits on the person taking the action. If it is accurate, kudos to the person. If it is wrong, the responsibility lies to that individual. How would disclosure help me? There are people who disclose and I have no issues with them at all, that's good. But for me that does not make any difference on how I would review a PR or look at issue. I would review it the same way: there are some quality checks of minimum standard, then if it is a valid issue/PR change and if that is good for the project or not. > My note of not contradicting was in reference to task execution related stuff. No, not really. You said "_isn't even saying **anything** that contradicts what I said._" Since you seem to be the one caring a lot about how things are written, worth double checking with a tool, maybe Pangram might have an offering for it. > Surely you can see some difference between me and someone who is writing an issue after having learned about Airflow 3 hours ago. 😂 You'd be surprised that someone learning Airflow 3 hours ago could sometimes write better issues without any assumptions. They don't need to be an "Airflow god" for it. > You just think moving some imports to be lazy makes things harder to maintain and spaghetti. No, "not think", I am sure of it. Take [this PR](https://github.com/apache/airflow/pull/62365) as an example. A new contributor add a top-level import since it is needed by the feature they are adding. They have 0 context of previous discussion or what you did -- and why will they. There are absolutely 0 code comments on why those imports are in-line, nothing preventing adding those. And the same applies to all providers and core airflow & Task SDK. Which is precisely why this is not maintainable for us. On the flip side, there is also [this](https://github.com/apache/airflow/blob/cd431eedcd062671c2aef9fa30422b9316fc8178/providers/celery/src/airflow/providers/celery/executors/celery_executor_utils.py#L167-L195) where we pre-import certain things (if packages are installed) for speed. So we need a balance and a long term maintainable solution. > It's a very valid opinion (although not the initial justification you gave -- again, I would have loved to just hear that up front over the weird arguments about it not mattering). Yeah, because imo the things I have already said were valid enough to not need the proposed solution. > That doesn't make my issue nonsense. Those are your words, not mine. > I do see that your most recent comment does not read as AI generated nor does Pangram accuse it of being AI. Good for you but those comments (and time) were absolutely not needed. It was a waste of time for me, this comment and the last one which would have been better used for the project. As I said above, AI-assisted/AI-generated does not matter -- the responsibility of what comes through my profile or anyone's GitHub profile lies on that person. AI is a tool. AI-generated isn't the question, accountability is. Even humans would make mistakes but accountability of owning and fixing things is a human thing. -- 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]
