Open C0DK opened 1 year ago
I am a bit skeptical about this personally, because I think it'll get hard to track when we should be communicating using the display name and when we should be using the "real name". For example, a user might interact with a job solely using dagit, and only understand it via it's display name. But then, they get an error in said job, should that error be surfaced using the display name or the "real name"? Additionally, do we force uniqueness constraints onto the display name?
I'd be curious to know how other systems handle stuff like this.
Personally, I don't understand why you've chosen to use the concept of a "name" for something that is clearly an identifier. On any other service, this differentiation seems obvious and possible. I mean when you reference an issue on GitHub, you wouldn't write a clear text Optional display name on nodes
, but rather write #10868
. Any actual log should probably use the identifier, but for displaying, I'd use the display name. I can only think of very few services I interact with where there isn't such a distinction. Even on twitter, a service for non-technical people, users understand the differentiation between a handle and a "name".
It's not to dismiss your concerns - there are certain considerations that need to be made, and discussions to be had, but these discussions have happened on most other services you and I interact with.
Has this issue gone anywhere? I have to agree with @C0DK - As a user, I tend to use the Dagster UI (fmr Dagit) to document/communicate when assets are built and how they tie together. Having a dedicated display name helps people understand what's going on without much thought. Key information could still be provided in the modal that contains all of the asset related metadata
@magreenberg1 it has not, to my knowledge.
What's the use case?
For groups (and other things), it seems intuitive to me to include spaces; however, as the id of (for instance) an asset group is displayed, this is not possible. We would love to show our graphs etc to our non-technical colleagues but the lack of human-readable names is a negative impact. We also try to group the different assets into
ingress
(ingestion/input etc) andegress
(output/reverse ETL etc). Here, it'd be nice to include an emoji to improve the visual indicators.Ideas of implementation
Have an optional str field on assets, graphs, etc etc (afaik they all inherit from something i.e a
Node
) which could be calleddisplay_name
Additional information
No response
Message from the maintainers
Impacted by this issue? Give it a 👍! We factor engagement into prioritization.