Hello team! Could you please help me to understand the DataHub contribution Process? My customers require many changes related to the frontend and backend. But I would not like to make a fork because backward compatibility support will become more complicated then. At the same time, we would like to understand in advance which of our improvements can be possibly merged in Master, and which ones cannot. Is it possible to discuss suggestions in advance in this Slack channel? Examples of our suggestions I'll provide in the thread.

Hi @faint-tiger-13525, let me respond in order: • Example 1: Many companies have dependencies on the current ownership types, we’d be really interested to know why the current types don’t satisfy your client- could you share some background

Hi @astonishing-answer-96712 and @faint-tiger-13525, please note that Example 4 is very close to our previous intention raised by me in this channel at first and then attempted for follow-up in #advice-metadata-modeling (you were involved in at least one of them), but it didn't lead anywhere and we had to resolve the requirement in a different way (leading to a hard-wired solution specific to the particular DataHub deployment instead of a more general solution)... Also note that it's related to the discussion of incomplete support for automated displaying newly added aspects (the autoRender annotation)...

@gentle-portugal-21014, I’m sorry about any frustration there, I think the best approach would be to submit a PR that we could review, we get a lot of requests in these channels that are hard to act on without the code in question there to discuss!

Hi @astonishing-answer-96712, sorry, but the added aspects are not for general use, thus a PR containing these extensions makes no sense, and we don't have a solution which would fill the existing gaps in the current implementation of autoRender support. In the meantime, I discovered that the completely blank screen (appearing after one of my attempts to add a new Dataset aspect with renderSpec.DisplayType set to "tabular") was probably due to an uncaught exception in the front-end code, but I don't want to invest additional time in this part due to the other issues/gaps of the autoRender support. But anyway, it's open source, I'm not frustrated, I just wanted to warn others to be aware of the existing limitations rather than spending time to discover them again on their own...

I’ll capture the autorender support as an issue and talk to the team about it, thank you so much for giving back, I’m sure the knowledge will help future contributors 🙂

Hi @astonishing-answer-96712, as a minor follow-up to the autorender topic - as of now, docs building fails on aspects having this annotation included, so this should be fixed as well once the autorender limitations are being looked on...

Hi @gentle-portugal-21014, I’ll note that! CC: @bulky-soccer-26729

Hello! I found the feature request for Example № 3 created by someone. Does it mean that the product team is deciding about implementing or not implementing this feature now? Are you open to a contribution from our side for this feature?

Hi, we still need more context- i think we’d be open to a contribution depending on how this interacts with the metadata model.

As far as I understand the idea described above, plain copy suggested in the referenced Example Nr. 3 shouldn't have any implications on the metadata model by itself, although I wonder which parts of the original Glossary Term would be copied and which not (e.g. which aspects and/or which attributes in those aspects would be involved). The assumed use case described above makes it a workaround rather than anything else though (however, the potential feature may be useful for some other use cases as well).

@gentle-portugal-21014 are you interested in this feature too?

@big-postman-38407 Not that much and not now. We intended to implement something very similar to Example 4 listed above as a generic solution using the Custom Properties feature, but we didn't reach agreement with the product team on how it should work (actually, we didn't get much response to this apart from a statement that there are areas for which impact needs to be assessed; I tried to cover the raised concerns, but got no reaction). Since we had a limited timeframe (we had to deliver a working solution to our customer until defined deadline), we had to choose the fork route and added the additional attributes as a local fork (we succeeded with that thanks to the help provided by the product team members 🙂 ). Although it's not the best solution from the support point of view, synchronization of our fork with changes from the base repository is still quite feasible.

@astonishing-answer-96712 , hello! I will continue the discussion about the requests @faint-tiger-13525 provided. Example 1. Justification: We consider this terminology better cover the responsibilities of the people involved in the data governance procedure. No single standard covers all the terms and definitions of data owner types, as different organisations and industries may use different terminology or define these roles slightly differently. However, the DMBOK includes a section on data governance that describes the roles and responsibilities of various stakeholders, including data owners, stewards, and custodians. Also, COBIT and HIPAA have these roles too. That is why we want to adopt these approaches when working with data governance in our company. Your primary objection was that lots of your users adopted the existing terminology. That is okay. We can implement changes, but we can leave the existing ones as pre-defined, just with the possibility to change their names if we want. In that case, we won’t break the logic for anyone after the update. What do you think? ------ Example 3. Justification: We don’t have templates to create a new term using the fields where we must put the information. Inside the description field, we have markdown formatting for text; for the end users, it can be challenging to create terms and fill them with the explanation each time. That is why copying can be good here; it can boost the users and still be an excellent additional feature to the templating. I believe we can improve user experience as we have business users who are not familiar with the technical aspects of the system. ------- Example 2. Justification: We consistently utilise this terminology throughout the company as it is more familiar to our top management. Our company culture strongly emphasises clear and concise communication, and we believe this specific terminology suits us better. The change of terminology can be confusing for our management. We tried subtypes instead, but it didn’t work how we wanted. Moreover, the title “Sub Type” caused more confusion. I understand that the names of the entities are supposed to be unified for everyone, but I still meet the differences between companies when talking about the same things. Using a term that accurately conveys the intended meaning to your audience is essential. I think we can add a possibility to rename them if it works better for the particular user of your system and leave default names for the others who are used to them, with the possibility to change the name in the future if needed.

I think you should be good to submit a PR on #3, for #2 I think if you are just editing the display name but not changing any of the actual values behind the scenes we’d be open to accepting a PR (just for UI configurability) If you try to change the actual names of the fields, the PR will likely be rejected as there is a lot of code that expects them to have those names, and the change would touch too many independent parts. For #1 I would take the same approach of UI configurability without editing the backend name. I think this should be possible by setting global vars and reading from the user or org config rather than changing the actual base model. In general, I think it’s going to be a hard sell to change the actual names of any fields, as the project’s structure is too reliant on them, and the backend changes would have to be too sweeping to not cause major regressions

I got it. Thank you very much for your response!

I think a lot of these would end up falling into #i18n-community-contribution