Very valid points from both of you! I am all in on this as well, I think it's been all cylinders firing for a little while now with making airflow 3 feature rich. Taking some time to clean up the features would be great!
-- Regards, Aritra Basu On Mon, 6 Oct 2025, 10:23 am Jarek Potiuk, <[email protected]> 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/> > > >
