blag commented on PR #23335: URL: https://github.com/apache/airflow/pull/23335#issuecomment-1112602307
Case 1. Agree. Double check with the user before doing anything dangerous or destructive that we can't easily undo. _Acquire the user's informed consent_ before doing anything irreversible. There should be no timeout in this case. :+1: Case 2. Not asking questions when a user has explicitly asked for a long-running command or an otherwise disruptive operation: :+1:. At that point the user is likely aware of the implications and has _explicitly consented to them_. In the case of an unexpected condition, a timeout is (IMO) the wrong way to handle that. If the timeout default answer is "quit", then we should not bother asking the user anything, just emit a message, (this next part is really important:) let the user know all of the ways to force the command to run, and then quit, all without waiting for a timeout. We should support using environment variables to set the timeout default answer (similar to Apt's `DEBIAN_FRONTEND` or how Homebrew handles this), as well as utilizing some sort of `--yes` or `--force` flag (similar to Docker's `docker build --no-cache`). Case 3: Prompting for a decision when auxiliary actions should maybe be taken. :-1: No, this is bad UX. Power users should be able to set behavior using environment variables or flags (see case 2) - this is exactly how `docker build --no-cache` works, and they shouldn't be delayed by a timeout with a default answer - that just adds needless delay to their day. If we are confident enough to take action after a timeout, then we should be confident enough to just emit an info or warning message (and use Rich's colors for that! 😄) and carry on with that action without any delay. Something like: > Airflow images haven't been rebuilt in awhile. If you run into issues, update your branch against `main` and rebuild images with `...`. Given all of these use cases, I don't really see much of any benefit to using timeouts anywhere. And if something is important enough to ask the user for input, we should at least give **all** users, even those with reading/literacy difficulties, users with disabilities, and new users, enough time to read, think about, and respond to our prompts. IMO, timeouts are mostly an anti-pattern <sup>1</sup>. <sup>1</sup> There are exceptions to this. (1) On macOS' and Ubuntu's GUIs if you go to logout or shutdown your computer, the confirmation screen will show you a 60 second timeout. This is a security improvement, because it helps when people click everything but the confirmation button. And it's not disruptive, because it both takes multiple, deliberate clicks to get to that screen in the first place, and if a user reaches that screen by accidentally mis-clicking, it's visually very obvious that it's not what they were actually trying to do. (2) When asking your phone to navigate somewhere via voice command, both Google Maps and Apple Maps will pull up an interstitial page to confirm your destination, and that page has a timeout and will automatically begin navigating there if you do not cancel it. This is useful because voice commands are usually done when people are driving, and throwing a timeout in there allows the user to drive their car and simply wait for (IIRC, 10 seconds) instead of directing their attention to hunt for the "GO" button on their phone. Neither of these cases apply to Airflow, but they are exceptions to the rule, hopefully they give a better idea of how timeouts can be used in non-anti-pattern ways. -- 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]
