> “If you name it, you can own it Yep. 100%. Precisely what Ash wrote. I am actually quite happy that many people say "this is something that is not correct". In a way it makes it a perfect candidate to pick someone we can "own" - because nobody owns it yet in the minds of people. The fact that we feel uncomfortable about it "now" is exactly the reason why we should choose it. Mostly because this is something that we claim "ownership" of - and (as with everything) we will get used to it over time and we will start treating it as ours if we accept it as "our" term.
J. On Tue, Sep 2, 2025 at 11:38 AM Ash Berlin-Taylor <[email protected]> wrote: > “If you name it, you can own it” > > +1 for Dag, it can be an airflow term, much more so than DAG as an acronym > can be. > > > On 2 Sep 2025, at 08:03, Ankit Chaurasia <[email protected]> wrote: > > > > I totally agree that "Dag" - it is neither a proper class nor a proper > > variable naming pattern. > > > > "DAG" can be used when referring directly to the class. > > > > "dag" makes the most sense as it aligns with Python’s snake_case for > > identifiers. > > > > *Ankit Chaurasia* > > > > > > > > > > > > > > On Mon, Sep 1, 2025 at 11:23 PM Sumit Maheshwari <[email protected] > > > > wrote: > > > >> 100% agree with Daniel. "Dag" seems to be the worst choice out of all > >> options. > >> > >> > >> On Mon, Sep 1, 2025 at 10:54 PM Daniel Standish > >> <[email protected]> wrote: > >> > >>> I sort of don't really understand why we would write Dag. It seems > >>> kindof the worst of both worlds. That's not what the class is. And it > >>> doesn't really make sense as a proper noun. > >>> > >>> I would just use dag most of the time and DAG when you need to refer > >>> unambiguously to the actual class. > >>> > >>> > >>> On Sun, Aug 31, 2025 at 3:46 PM Jarek Potiuk <[email protected]> wrote: > >>> > >>>> I don't think we concluded whether we should use "Dag" or "dag" - but > >> I > >>>> think the important goal of why we decided on dropping the "DAG" as > >>> acronym > >>>> was that we want to really start "owning" the "Dag" term - "Dag" > really > >>>> meaning "Airflow Workflow". > >>>> I think using capitalized form "Dag" fulfills that goal better than > >>> "dag". > >>>> > >>>> J. > >>>> > >>>> > >>>> On Sun, Aug 31, 2025 at 5:09 PM Pierre Jeambrun < > [email protected] > >>> > >>>> wrote: > >>>> > >>>>> Response thread there. Can’t remember the full outcome from the top > >> of > >>> my > >>>>> head but “Dag, dag, dags” seems fine, preferably for doc, new code, > >>> user > >>>>> facing, but not worth the trouble going through the whole codebase > >> for > >>>>> refactoring. > >>>>> > >>>>> > >>>>> https://lists.apache.org/thread/8k338stlkkp07ko3no70p2nng757kd1w > >>>>> > >>>>> On Sun 31 Aug 2025 at 17:01, Wei Lee <[email protected]> wrote: > >>>>> > >>>>>> I think our previous consensus was “dag" or “dags", but recent PRs, > >>>>>> including mine, have changed them to "Dag". I’m fine with "Dag" or > >>>> “dag” > >>>>>> (like “dag” a bit more) as long as it’s not “DAG”. > >>>>>> > >>>>>> I believe we should better document the decision this time. I can > >>>> create > >>>>>> that PR once we finalize it again here. > >>>>>> > >>>>>> Best, > >>>>>> Wei > >>>>>> > >>>>>>> On Aug 31, 2025, at 9:13 PM, Daniel Standish > >>>>>> <[email protected]> wrote: > >>>>>>> > >>>>>>> Saw this PR https://github.com/apache/airflow/pull/55097 > >>>>>>> > >>>>>>> I thought we discussed this at some point that using just "dag" > >> or > >>>>> "dags" > >>>>>>> is perfectly fine. De-emphasizing the mathy origin of the "DAG" > >>>>> concept. > >>>>>>> > >>>>>>> Personally I believe we should leave instances of "dag" or "dags" > >>> in > >>>>> the > >>>>>>> docs alone. > >>>>>>> > >>>>>>> Is the consensus I recall just an invention of my mind? > >>>>>>> > >>>>>>> Thanks > >>>>>> > >>>>>> > >>>>>> > >> --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: [email protected] > >>>>>> For additional commands, e-mail: [email protected] > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
