#There's an open PR adding the [Diyanet
native frost
Requiring a developer account to get access to an integration is quite common among our integrations. I think that's fine. But requiring sending an email with a signed PDF sounds very user unfriendly. I think that's not a good fit for an integration in core.
On the other hand, it's hard to draw the lines about what is reasonable for what work the user has to do to get access to an API.
If the process to get access to an API works well and is predictable, I think we should allow it, even if it's unconventional.
azure wigeon
I agree with Erik, I think integrations that require developer accounts shouldn't be in core as that is very user unfriendly. With the current quality score rules, an integration like this could even become Platinum, which probably signals the wrong thing.
The integration quality scale is a framework for Home Assistant to grade integrations based on user experience, features, code quality and developer experience.
So at a minimum, we should probably add a new rule to our scale.
Generally, I think we could discuss requirements that integrations need to meet in order to become a core integration.
rough flicker
I strongly disagree, there is nothing inherently wrong with developer accounts. Limiting options like that seems antithetical to the OHF value of choice.
azure wigeon
I don't think it would infringe on the values of the OHF - they can still exist as custom integrations. We wouldn't prevent anyone from using this integration. We support custom integrations for this reason no?
But this definetly would need to be discussed outside of this issue
fluid venture
I think it's completely wrong to allow core integrations to require developer accounts, not just because it's a terrible user experience, but also because the purpose of the developer accounts is for developers to develop an application which they then make an agreement with the API vendor to publish. We are completely circumventing that.
I don't have a problem with custom integrations doing it of course.
But that's not what I wanted to ask here, we do allow requring developer accounts and I'm not trying to change that here. My question was if the manual steps requested by diyanet are too cumbersome. Martin said he thinks it's not much worse than any other developer account - I actually agree with that, because some of them are outright horrible.
For an example of a horrible user experience, look at the manual steps required to set up google assistant, filling out a PDF and emailing it is nothing compared to that.
rough flicker
I'm familiar with that. And I'm sure that taking away the possibility of doing that from people, requiring them to use HA Cloud, is going to be great publicity.
Maybe let's not discuss it here further, like you said that discussion is not directly relevant for the PR.
broken latch
I think using developer accounts is fine. If possible we should try to avoid it and offer account linking. However in the case of a manual process where we also would be a party which causes a party that does not have any automated system in place to take care of it, I think having people emailing a PDF to humans to get access to an API is not sustainable for them
fluid venture
Sure, it's fine for hobbyists developing their own integration, and perhaps publishing it as a custom integration for other hobbyists to tinker with. But core integrations should not require that any tinkering, they should just work.
If possible we should try to avoid it and offer account linking
Exactly