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/> >
