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]
> >
> >
>

Reply via email to