Doug Guthrie

Internal slack feedback for the first attempt in the related [PR](https://github.com/dbt-labs/dbt-core/pull/5885) > Things that this makes me start thinking about: > - Does this work if the upstream model has...

> Does this work if the upstream model has the same name as a model in the current project? What would need to change (https://github.com/dbt-labs/dbt-core/pull/3053)? My first inclination is that...

> How should the upstream project specify which models are public / ref'able? I really like @christineberger's [suggestion](https://github.com/dbt-labs/dbt-core/discussions/5244#discussioncomment-3595589) in the original discussion where the developer explicitly defines what models to...

> What sort of error should the downstream project see when trying to ref a private model? I think the same compilation error that you would get today if `ref`ing...

Another implementation thought I had is to add some more properties to our `NodeConfig` (or something in a higher parent class). The idea being that these `nodes` that we're pulling...

Don't plan on adding this feature at this time. Would love a PR if it's something you'd like to add.

Closed with #118

Happy to accept a PR to fix this but not something I'm going to fix.

I think this is out of scope for this library. I can see the case for both wanting this data and excluding it. Closing as not planned to fix.

Most likely a rate limiting issue on the YF side (not much I can do here).