Does anyone know what is happening with HACS and new submissions?
It seems the backlog is growing significantly, but not really decreasing.
There’s a closed issue that @frenck replied to stating it was due to the influx of AI-coded custom components, which makes sense (especially as I’ve contributed some myself, and have more to come). And in reality, it’s going to continue becoming a bigger issue.
But the radio silence isn’t helping as to whether a strategy around reviewing them and clearing the backlog is being worked out.
It seems it’s quite a bottleneck for a community-powered feature, that the community can’t do anything about helping with it.
@MissyQ perhaps a blog post with an update could be useful? Even if to say that there’s an awareness of the issue and it’s being looked at, but no resolution yet? Or if there are some thoughts or plans?
Or, perhaps get some community input on how it can be addressed?
For example, I’d love it if part of the submission process included things like:
Author statement on how much AI was involved in the creation
Author attestation around testing (for example, I now have two separate dedicated test environments to help ensure quality)
Some form of quality of life / user experience scanning & rating (e.g. if it’s has a visual editor / config UI or is pure YAML)
Similarity scanning (e.g. does something like this exist already)
Maybe a requirement that it be installed on several other users instances (and some form of validation from their HA instance, to reduce the chance of bot involvement to BS the system)
A statement from the author about why they felt it was necessary
Additionally, HACS is a third-party integration & is not part of HA Core, so the chances of a blog post to address the backlog are slim. There was only one notable exception to this, where a blog post was made for reasons explained here.
I get your point, really. Backlogs of 1.5-2 years were already an issue back when the thread above was made, and that was before AI was as popular as it is today. It must be frustrating to work on something then having to wait years before being able to share it via HACS.
However, you’re addressing the wrong issue and the wrong people. While AI is part of the issue, the fact that this has always been a problem means that your suggestions won’t necessarily speed things up. It might be a better idea to reach out to the dev in charge of HACS and ask if you can help with the review process in general.
The wait for HACS default is a pain but if you add a MyHA link it is fairly painless for users to add a HACS custom integration and rely on your preferred social media audience to publicise it. Users still get update notifications and when it get’s into default there’s nothing to switch over.
If you look at the HACS discord server there is a steady stream of approvals, and at least they’re auto closing ones where the submission is totally AI generated with no user following even the most basic instructions.
Sometimes there’s good reason for similar components to appear, HACS is all about giving choice and allowing experimentation so I’m not sure how I feel about gate keeping more than on basic quality/operability. I always check issues, stars, install counts, recent commits on anything I come across and I think the disclaimer installer beware really applies here.
On the tagging of people: I get the guidance, but I also work in plenty of platforms where people appreciate knowing that they have been mentioned as a first-hand reference, instead of third hand. So, I try to be reasonable there and targeted with if/when/who I tag.
As to what I'm addressing - I'm calling out frenck's point that AI has resulted in an increase in submissions. Is it his problem? No, but he chimed in on a thread with AI being the reason for the delay.
So then, should I continue the conversation in that thread? Sure, except that the issue on the repo is closed already.
As for tagging Missy - again, I was being targeted. She looks after the community. HACS is by virtual of it's name community, therefore I was hoping she might be able to take it up with the relevant folks and share some clarity with the community.
And as for reaching out to the dev in charge of HACS - it goes to one of the points in the article you suggested about tagging. I don't want to DM someone I don't know and/or haven't spoken to before on this topic. As an Autistic person I sometimes find DMs confrontational, so don't want to come across that way to someone else.
Also, I'd rather have the conversation in an open space, so that instead of just me getting the response - everyone can gain from it.
Yeah I get the point about the MyHA link, however it's more about discoverability.
Not everyone shares stuff in the community here.
I personally look forward to seeing new stuff appear in the default repo, and it's been fairly quiet for a while now.
As for the additional gatekeeping - to be honest, I'm not sure why there's any gatekeeping at the moment. Given it's a community store, it's up to everyone to be responsible for what they install. So as long as people do the needful, then their stuff should appear in the store - slop or not.
But, I'm not here to argue for the removal of the gatekeeping. I was just calling out that if AI created components are resulting in a larger volume of items to be processed, and that is the reason for the bottleneck - then I offered some suggestions that might help ease that.
There's a whole bunch of really cool solutions in the backlog that I'd love to see published. I've got one in there and a few more to add.
So, I'm just wanting to see if there are plans for it to be resolved, as I'm sure it's been a discussion item.
If the repo is clearly tagged with attributions to contributors (including AI contributors) that helps things along. Contributions that are vibe coded and there is little or no support available from the author are worthless IMO, as I can vibe code that myself. That is using AI to help others IMO.
Cases where AI is used to help the author form stuff and the author can support issues as they arrise, that's fine.
I agree. It sets the expectation for the user who is choosing to install the component that the code may not be the best or more secure, and that the developer may not be able to support it.