Jens, I am so sorry! I double checked and am not sure how I missed that. Thank you for catching my mistake!
Doesn't change the outcome but official updated tally: - Option A: +1.5 - Option B: +8.4 - Option C: +5 - Option D: +3.5 On Tue, Oct 28, 2025 at 5:17 PM Jens Scheffler <[email protected]> wrote: > Thanks Constance for driving this. > > Looking at the Google Sheet it seems my (binding) vote is missing but no > big problem as I also voted for Option B > > On 28.10.25 18:32, Constance Martineau via dev wrote: > > Thanks Daniel. Not sure how to make them show up, so made the google > sheets > > public: > > > https://docs.google.com/spreadsheets/d/1sNhlNM2YqgTDvWOXp7o0zFF-VquddWANxx7S02G3lXM/edit?gid=0#gid=0 > > > > > > > > On Tue, Oct 28, 2025 at 1:18 PM Daniel Standish via dev < > > [email protected]> wrote: > > > >> Images did not work > >> > >> On Tue, Oct 28, 2025 at 10:12 AM Constance Martineau via dev < > >> [email protected]> wrote: > >> > >>> Hi all, > >>> > >>> Thank you for your patience while I tallied the votes! For reference > >>> purposes, here > >>> <https://lists.apache.org/thread/7mbztc6dchh73c7cnn7sjm1qtt6gj5zw> is > a > >>> link to the vote thread. > >>> > >>> As a reminder the options were: > >>> > >>> > >>> - Option A: Prefer dag in docs; use DAG only when referring to the > >>> class/import > >>> - Option B: Prefer Dag in docs; use DAG only for the class/import > >>> - Option C: Keep DAG as the standard everywhere (status quo) > >>> - Option D: Prefer Dag in docs, use Dag for class/import and alias > DAG > >>> (for backcompat reasons) > >>> > >>> > >>> *Results (Binding Votes Only)* > >>> > >>> Based on the results, and following the rules that only binding votes > are > >>> counted, with voters able to submit a fractional vote between -1 and +1 > >> per > >>> option, Option B (Dag) won. > >>> > >>> We will therefore prefer "Dag" in docs, and use DAG only when referring > >> to > >>> the class or import itself. > >>> > >>> [image: image.png] > >>> > >>> *Additional Context* > >>> > >>> Because this vote was about convention (not code or architecture), and > >>> because the discussion around voting method itself was interesting, I > >> ran a > >>> few "what-if" tallies to see how the outcome might vary: > >>> > >>> - If all votes (binding + non-binding) were counted, including > >> multiple > >>> options per person, Option B (Dag) still wins, but by a much closer > >>> margin. > >>> > >>> [image: image.png] > >>> > >>> - If only the main binding vote (single strongest +1 per voter) > were > >>> considered, Option B (Dag) and Option C (DAG) would have been tied. > >>> > >>> [image: image.png] > >>> > >>> - If the main vote from both binding and non-binding voters were > >>> included, Option C (DAG) would have narrowly won) > >>> > >>> [image: image.png] > >>> > >>> (For transparency, Ryan Hatter submitted two +1s, so I pinged him to > >>> clarify why should be considered in the single-vote scenario) > >>> > >>> *Observation* > >>> It's interesting that the outcome differs slightly between binding and > >>> non-binding voters, with contributors leaning toward Dag and the > broader > >>> community favouring DAG. > >>> > >>> It's a nice reminder that Airflow serves two audiences: Contributors > >>> leaning toward a cleaner, more readable style, and the wider community > >>> still attached to the familiar "DAG" identity. Both are valid, and it's > >>> interesting to see how the project's voice is shifting as we grow. > >>> > >>> *Next Steps* > >>> Since we'd already started shifting documentation toward Dag when it > >> seemed > >>> to be the general preference, the vote results essentially confirms > that > >>> direction. > >>> > >>> We'll continue using Dag in docs going forward, keeping DAG only when > >>> referring to the class/import itself. No changes are needed for > existing > >>> references unless a doc is being actively updated. > >>> > >>> If anybody would like to call a separate vote to create a Dag alias for > >>> DAG, they are more than welcome to. I don't think the results of this > >> vote > >>> should preclude us from doing that at a later date if the community > >> agrees. > >>> If anyone has strong objections or follow-ups, please share them by EOD > >>> Friday, otherwise we'll consider this settled. > >>> > >>> Constance > >>> > >>> -- > >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
