Thanks Vikram, Jarek for pushing this idea. I am also in for it!
Looking forward also on meeting a lot of users at the Summit to listen for their migration blockers or feedback if already on Airflow 3.x - I assume there are a couple of things to be improved. Some minor gaps also blocking us in our deployment and looking forward to focus on.
(Assuming that the "partial" features like deadline alerts and things that are marked as experimental of course continue to complete)
On 06.10.25 06:52, Jarek Potiuk wrote:
I am very much for it! And I would even add a little - it would be great that pretty much all of us got involved - even (and especially) in the areas that they have not been involved so far. There are a number of areas - both new, and "changed old" that I think there is a small number of "experts" (basically those who worked on it) - but others have limited visibility of understanding of a) new areas b) scope of changes (I am speaking from my own experience here as well). And we are somewhat shying away not even in attempting to fix things, but also even in triaging and responding and interacting with users who are raising issues. Thus many issues are untriaged. I think we got a bit more "siloed" in our part with Airflow 3 development and we need to break the silos a bit. There might be few reasons: - we feel not competent enough to help - somehow we feel "the others who implemented it" are responsible for fixing those - we have "our" parts that we are looking at and focusing on (this is I think the biggest part especially for those "experts" who might feel overwhelmed - if we look elsewhere, we might have a feeling that "our" part will be lagging behind) - those "experts" on the other hand might feel overloaded with a number of issues in their specific area and have hard time in getting someone to help them I think ideally, we need more of the community engagement here - and likely "experts" taking more of a role of brainstorming and guiding other contributors, committers, PMC members to help following their advice and oversight in solving the issues. That would not only be opportunity to efix things potentially faster (after initial ramp-up time) but also turn such "polishing" period into a knowledge transfer. Ultimately it's not one or two person who is responsible for some "areas" in Airflow, but whole community is. And those "experts" might even find time to help in "other" areas if they are less burdened with working on solutions down to a green PR in their area of expertise. And also I think that "help" thing comes to the users who raised their issues (some of them undoubtedly listening here) - we will need their help in at least testing solutions and commenting on hypotheses. Maybe we can figure out a way of working (commenting on issues, triaging approach, issue solving attempt, way of asking for help)? that will "catalyse" such knowledge transfer. But I also might be wrong in my assesment - so I'd love to hear what others might say here - maybe also have some proposals how we could reorganise to handle open issues better (and to handle some of the challenges involved). Undoubtedly such knowledge transfer has some risks that solving issues will slow down - at least initially, so we have to be rather careful with this approach and have clear boundary of trust from the experts that things will be solved when they are guiding somoene. J. On Sun, Oct 5, 2025 at 8:13 PM Vikram Koka via dev <[email protected]> wrote:Dear Airflowers, I am looking forward to meeting many of you this coming week at the Airflow Summit. It will be wonderful to connect in person after a year of online collaboration since the last Summit. I’d like to put a proposal in front of all of you. We’re sure to hear valuable feedback from users who have adopted or are adopting Airflow 3. My proposal is that we dedicate October, the four weeks following the Summit, to polishing work rather than new feature development. This would mean focusing on smoothing out any rough edges in the adoption journey and making it easier for users to take full advantage of the new capabilities we’ve released. Depending on the aggregated feedback, we can also consider multiple patch releases during this period to quickly incorporate improvements. As part of this, let's make sure feedback is easy to track: - System of record: Use Github issues <https://github.com/apache/airflow/issues> as the source of truth, even if there is a conversation over slack or on the dev list. - Version labelling: Include the Airflow version so it can be labeled appropriated (label:affected_version either 3.0 or 3.1), easily reproduced and resolved. - Upgrade blockers: Indicate if this affects upgrades from 2.x. We have been labeling and tracking these separately. - Documentation vs. code: Indicate if this is a documentation gap, rather than a code problem. - Context: Airflow's flexibility allows for a wide range of behavior. With Airflow 3's architectural changes, especially the new TaskSDK model, some implicit behaviors may now need to be explicitly specified. If you found anything confusing or frustrating, please let us know if a documentation update, upgrade script change, or a clarifying example would be helpful. We are looking for active participation from everyone, including those who haven't contributed before. Even a small contribution such as a clear reproduction scenario, a documentation improvement, or a simple upgrade script update can make a big difference. Thank you and best regards, Vikram -- Vikram Koka Chief Strategy Officer Email: [email protected] <https://www.astronomer.io/>
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
