"I prefer D, but it won't pass" I think we are all pretty honest and transparent here. If someone **wants** to cast a vote to D - they absolutely can. If they decided not to - no matter what their motivation is - they decided not to. It's their decision and what counts is an actual vote not the motivation. This is a vote, not a discussion - at this stage only the actual vote counts.
And again - if someone decides to change their vote - they still can. J, On Wed, Oct 22, 2025 at 8:24 PM Jarek Potiuk <[email protected]> wrote: > And if someone did not understand that they can vote on multiple options - > there is still 24 hrs to change the vote BTW. This is absolutely no problem > to change the vote until the end of the vote. > > On Wed, Oct 22, 2025 at 8:23 PM Jarek Potiuk <[email protected]> wrote: > >> I think Constance described it well in the announcement. >> >> > You can vote any fractional between -1 and +1 for any of the options, >> and >> the option with the highest sum (even if it's a negative) wins. This is a >> procedural vote, meaning that -1 is not considered a veto. Everyone is >> encouraged to vote, but only PMC members and Committer's votes are >> considered binding. >> >> And yes I think it's OK to vote on multiple options. For example (+1 D) >> means +1 on D, 0 all others - I.e. I have no opinions on other options. >> At least this is what my +1 B meant. >> If one thinks that one (or more) of those options are unacceptable - >> they can vote with -1 on all those. >> >> Note that this is precisely what Constance described - that there might >> be an option with negative total sum. >> >> And it's perfectly fine for people to vote +1 or +0.9 on multiple options >> - it's not "who wins" but "which option wins". I don't absolutely care who >> "wins" here, but which option has the most support. >> >> J. >> >> >> >> On Wed, Oct 22, 2025 at 8:09 PM Daniel Standish via dev < >> [email protected]> wrote: >> >>> Interestingly it seems a lot of people were like "I prefer D, but it >>> won't >>> pass" >>> >>> Maybe it would actually... >>> >>> On Wed, Oct 22, 2025 at 11:08 AM Daniel Standish < >>> [email protected]> wrote: >>> >>> > So far, this is my tally: >>> > >>> > A >>> > TP (binding) >>> > (.5) sumit >>> > >>> > B >>> > jarek (binding) >>> > vincent (binding) >>> > niko (binding) >>> > jens (binding) >>> > ankit >>> > pankaj (binding) >>> > tamara >>> > (0.5) collin >>> > (0.9) wei (binding) >>> > (0.5) brent (binding) >>> > >>> > C >>> > kaxil (binding) >>> > pavankumar (binding) >>> > sumit (binding) >>> > josh (binding) >>> > bas (binding) >>> > pierre (binding) >>> > >>> > D >>> > ramit >>> > collin >>> > ryan (binding) >>> > wei (binding) >>> > brent >>> > >>> > By my count it is >>> > >>> > B - 6.4 >>> > C - 6 >>> > D - 3 >>> > A - 1.5 >>> > >>> > If you only include the bindings and if the bindings are correct >>> > >>> > I have not voted yet. >>> > >>> > >>> > >>> > >>> > On Wed, Oct 22, 2025 at 11:04 AM Daniel Standish < >>> > [email protected]> wrote: >>> > >>> >> Question: >>> >> >>> >> whose votes are binding on this vote? committers? PMC members? >>> everyone? >>> >> >>> >> Also, many have voted for 2 options and with fractions. >>> >> >>> >> To me the fractional voting makes sense with a binary up-or-down vote. >>> >> It's meant to signal strength of support for a motion. But with >>> multiple >>> >> choice, I'm not sure it makes as much sense. >>> >> >>> >> E.g. I could vote +1 for C and -1 for B -- then in effect my vote >>> counts >>> >> 2 times! But that doesn't sound right to me. >>> >> >>> >> For multiple choice votes, ranked choice voting probably makes the >>> most >>> >> sense. >>> >> >>> >> >>> >> >>> >> On Wed, Oct 22, 2025 at 10:52 AM Brent Bovenzi via dev < >>> >> [email protected]> wrote: >>> >> >>> >>> +1 Option D >>> >>> +0.5 Option B >>> >>> (binding) >>> >>> >>> >>> On Wed, Oct 22, 2025 at 1:42 PM Pierre Jeambrun < >>> [email protected]> >>> >>> wrote: >>> >>> >>> >>> > Option C (binding) >>> >>> > >>> >>> > On Wed, Oct 22, 2025 at 6:07 PM Bas Harenslak via dev < >>> >>> > [email protected]> wrote: >>> >>> > >>> >>> > > Option C (binding) >>> >>> > > >>> >>> > > >>> >>> > > On 22 Oct 2025, at 16:10, Josh Fell via dev < >>> [email protected]> >>> >>> > > wrote: >>> >>> > > >>> >>> > > +1 for option C (binding) >>> >>> > > >>> >>> > > On Tue, Oct 21, 2025 at 9:39 PM Sumit Maheshwari < >>> >>> [email protected] >>> >>> > > >>> >>> > > wrote: >>> >>> > > >>> >>> > > +1 for Option C (binding) >>> >>> > > +0.5 for Option A (binding) >>> >>> > > >>> >>> > > On Wed, Oct 22, 2025 at 6:32 AM Tzu-ping Chung via dev < >>> >>> > > [email protected]> wrote: >>> >>> > > >>> >>> > > My ideal scenario would be dag when we describe an object (using >>> “a >>> >>> dag” >>> >>> > > or “the dag” etc), and Dag as the class name, like any ordinary >>> noun. >>> >>> > > >>> >>> > > Since that would probably too much work for no real value (as >>> many >>> >>> > > >>> >>> > > already >>> >>> > > >>> >>> > > suggested), I’m going to put +1 on option A since it matches best >>> >>> how my >>> >>> > > mind wants to perceive the noun. >>> >>> > > >>> >>> > > TP >>> >>> > > >>> >>> > > >>> >>> > > On 21 Oct 2025, at 03:02, Constance Martineau via dev < >>> >>> > > >>> >>> > > [email protected]> wrote: >>> >>> > > >>> >>> > > >>> >>> > > Hi everyone, >>> >>> > > >>> >>> > > As discussed in this email thread >>> >>> > > < >>> https://lists.apache.org/thread/h4b0vjfr4dkbyhrkoxpfjo67s38yr0hh>, >>> >>> I >>> >>> > > >>> >>> > > am >>> >>> > > >>> >>> > > formally calling a vote to finalize how we refer to Airflow >>> workflows >>> >>> > > >>> >>> > > in >>> >>> > > >>> >>> > > writing. The vote will run for roughly 72 hours, and last until >>> >>> > > >>> >>> > > Thursday >>> >>> > > >>> >>> > > October 23rd at 7:00 pm UTC (countdown link >>> >>> > > <https://countingdownto.com/?c=6656693>) >>> >>> > > >>> >>> > > The options are: >>> >>> > > >>> >>> > > - 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) >>> >>> > > >>> >>> > > You can vote any fractional between -1 and +1 for any of the >>> options, >>> >>> > > >>> >>> > > and >>> >>> > > >>> >>> > > the option with the highest sum (even if it's a negative) wins. >>> This >>> >>> > > >>> >>> > > is a >>> >>> > > >>> >>> > > procedural vote, meaning that -1 is not considered a veto. >>> Everyone >>> >>> is >>> >>> > > encouraged to vote, but only PMC members and Committer's votes >>> are >>> >>> > > considered binding. >>> >>> > > >>> >>> > > Please see email thread >>> >>> > > < >>> https://lists.apache.org/thread/h4b0vjfr4dkbyhrkoxpfjo67s38yr0hh> >>> >>> for >>> >>> > > additional context. >>> >>> > > >>> >>> > > Why this matters: We’ve had inconsistent terminology across docs >>> and >>> >>> > > repeated PR debates over capitalization. Standardizing will make >>> our >>> >>> > > writing clearer, strengthen the Airflow brand, and give external >>> >>> > > stakeholders a single reference to follow. >>> >>> > > >>> >>> > > Best, >>> >>> > > Constance >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> --------------------------------------------------------------------- >>> >>> > > To unsubscribe, e-mail: [email protected] >>> >>> > > For additional commands, e-mail: [email protected] >>> >>> > > >>> >>> > >>> >>> >>> >> >>> >>
