Hello everyone, Following the last dev call, I'd like to open a discussion around documentation first approach.
My key observations around Airflow 3.2 development cycle is that in order to do affective testing I need to understand how a feature designed to work. While it is listed and explained in AIP page, dev discussions and possibly in PR description it is not reasonable to expect community users to go through all of these data points. We have multiple features that are being developed in parallel so it's huge effort for community members. By having documentation ready early we help community members to be able to efficiently test the feature in a real production-like scenario. It will also help us to gain valuable and early information about if users understand the feature as we intended. This avoid cases where documentation lands around/after beta release is cut leaving little time to testing. Given the AI era, it might even be easier to create and update documentation as development of the feature progress - it can even make PR review easier. The Proposal: 1. The default AIP draft will include a specific entry if the author thinks it should be under the Documentation first policy. I think it's better to let authors choose while the community review the choice. It will also mention by what part of the development documentation should be ready (before development. by date, by specific milestone, etc...) 2. Community will review it as part of the AIP review. 3. Request to include a feature / AIP under the policy may also come after AIP was approved if circumstances justify it. This means that any community member can raise the request. If the AIP author agrees then the AIP page will be updated accordingly. In the cases where AIP author disagree, the community member can raise mailing list discussion. Thanks, Elad
