First we must arrive at something approaching consensus, which it seems we have not ;)
On Wed, Sep 3, 2025 at 4:14 PM Ferruzzi, Dennis <[email protected]> wrote: > > I believe we should better document the decision this time. > > Hate to be That Guy, but what about (yet another) prek rule to enforce it? > > > - ferruzzi > > > ________________________________ > From: Kyungjun Lee <[email protected]> > Sent: Tuesday, September 2, 2025 5:46 PM > To: [email protected] > Subject: RE: [EXT] [DISCUSS] dag vs DAG vs Dag > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. > Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez > pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que > le contenu ne présente aucun risque. > > > > This may be a slightly different topic from the current discussion, but I > hope it’s okay to ask here. Are there any ongoing or planned discussions > within the community about extending the concept of DAGs beyond the > traditional “task dependency graph” definition — for example, toward > dataflow graphs, event-driven DAGs, or asset-based workflows? > > > > 2025년 9월 2일 (화) 오후 8:53, Jarek Potiuk <[email protected]>님이 작성: > > > > “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] > > > > > > > > >
