Agree upon a unified "configuration" terminology

[astrojuanlu]

Maybe we could use 3 different words for 3 different things:

• "Configuration"/"config": everything under conf/
• "Settings": settings.py
• "Metadata"/"Project metadata": pyproject.toml (since eventually we're moving all project metadata there, see Make all starters use pyproject.toml #2280 (comment)

I'm not a native speaker but, even though understanding that "configuration" and "settings" are mostly the same, and that pyproject.toml does indeed contain some "Kedro settings", by at least striving for internal consistency in the terminology we can hopefully minimize confusion.

Originally posted by @astrojuanlu in #2427 (review)

On the other hand, @datajoely proposed a different taxonomy:

Originally posted by @datajoely in #2427 (comment)

• Data config
• App config
• Build config

I really like this.

---

And last but not least, let's not forget config.yml that can be used to programatically call kedro new. I've been advocating internally to move to a CLI flags approach, but I didn't want to pursue the issue further after #1692 is addressed.

[datajoely]

The most important element is the lifecycle piece:

Data config - Runtime (env, parameters, catalog)
App config - Library component init (Catalog location, ConfigLoader, Pipelines, hooks)
Build config - Project start up (bootstrap, src location etc)

[astrojuanlu]

Using this "data config", "build config", "app config" terminology now, I'm quite happy with it. In the absence of a better idea, I think we should codify it in the documentation. @datajoely do you have a higher resolution version of the image by any chance?

[datajoely]

@astrojuanlu can yo usee this?
https://miro.com/app/board/o9J_llzgzfk=/?share_link_id=245109814687

[stichbury]

@astrojuanlu and @datajoely

Please can you clarify the documentation tasks here as it's not totally clear what is needed? That is, can you give a set of "rules" for how to use the terminology that you decide upon and where you think the main sections are that need updating? Until I have that kind of checklist to follow, it's a risk to update the text as it could make it more messy rather than less.

I think agreement on terminology is the first issue, and at that point only, does it become a docs ticket. So I'm revising the title of this one and moving it out of docs...you can create a subtask when you have the rubric for docs changes to follow.

[astrojuanlu]

There's a concrete proposal on #2434 (comment), whenever this becomes a priority let's collect upvotes and/or arguments against it. I personally like it.

[astrojuanlu]

The task here is to agree on the terminology. After we've done that, we can close the issue and open a new one with specific actions for the docs.

[astrojuanlu]

Nobody posed any objections to the terminology so I'm considering this done. For the record:

• Data config - Runtime (env, parameters, catalog)
• App config - Library component init (Catalog location, ConfigLoader, Pipelines, hooks)
• Build config - Project start up (bootstrap, src location etc)

Will be opening new tickets with specific tasks (trying to stay away from catch-all "review docs").