[Feature] Settle on a canonical name for the .yml files formerly known as schema.yml

[joellabes]

Is there an existing feature request for this?

• I have searched the existing issues

Describe the Feature

https://docs.getdbt.com/reference/configs-and-properties says:

But it doesn't say what we call them instead.

In practice, people continue to call them schema.yml files, or just .yml files which isn't specific enough given the other yaml files that a dbt project creates.

Can we pick a name and stop defining them by what they're not?

Describe alternatives you've considered

We could just leave it. It's not as good as it could be, but it's not awful.

Who will this benefit?

• Docs authors
• People describing functionality in the dbt Slack

Are you interested in contributing this feature?

I think this will only be documentation changes, right? Happy to make those once we pick a term

Anything else?

I have absolutely no idea what the term should be 😬 .

Question: let's say we call them banana files. It's likely that they'd still be called banana.yml files in conversation and documentation, which might still lead to people thinking they have to call them banana.yml. Are we OK with that? I.e. is the main issue the fact that schema is an overloaded term, as opposed to the implication that they must have a specific name? 🍌🍌🍌🍌🍌

[jtcohen6]

I so strongly agree with the thrust of this issue. When it comes to overloaded terms in our parlance, schema gives model a run for its money.

Where would these changes need to happen? I think documentation is the most important, since there isn't any user-facing functionality in dbt-core that depends on / exposes this nomenclature. That said, there are tons of internal uses of the term, even an entire module: schema.yml, meet schemas.py, and its friend the SchemaParser! If we could settle on a new name, I'd love to do parallel renaming within the guts of dbt Core as well.

What should the name be? I sometimes call these resources.yml, or (even more often) whatever.yml, as an attempt at indicating "they can be named whatever." Open to ideas!

[joellabes]

I don't hate whatever.yml, and I'm going to start using that in conversation for now. I think it lacks gravitas for the proper documentation though, and the thought of a WhateverParser breaks my heart.

I was mostly making this so it could be out in the open,🤞 for someone to have a good idea

[NiallRees]

I often refer to these as model yml files and source yml files. It accurately describes both their relationship and concern for 99% of users and aligns with the naming convention of <associated model/source name>.yml. Achieving simplicity for the 99% and then adding more advanced notes around how the yml files can configure models and sources simultaneously makes sense to me.

[joellabes]

I've been poking around in the docs today, and found that we're calling them Property Files in the tab pickers https://docs.getdbt.com/reference/test-configs

Is that new? I feel like I'm only seeing it now, but I'm seeing it everywhere which either means @runleonarun's team is super onto it, or it's been like that forever and I'm being Baader–Meinhof'd

[jtcohen6]

I remember making some of these changes with Claire back in the day :)

properties.yml? config.yml? Now that config: can also be a property, defined in those files...

[joellabes]

I see properties.yml appearing more and more in the wild (today's example)