Lift curation, remove versioning

[ngokevin]

@donmccurdy @fernandojsg

What I'm considering, since it's a lot of overhead to curate every component and tie each version to a component, and even when we do they're broken anyways. We don't have the time or manpower to act as full time code reviewers.

Have the Registry act as an index rather than a curated store, for a place for people to find every single component (perhaps showing the "good" ones up top). If they don't work, they can go file an issue, or copy/paste the code and modify it. And we can show application-specific components for inspiration (A-Blast, A-Painter). Then we can say "here's literally every single possible feature"

Showcased applications like A-Blast or A-Painter can have their own pages so people can see what components were used to make them.

I've heard Unity Store components are often broken as well, so there's precedent :)

[donmccurdy]

Curation overhead aside, it's also a burden on authors to manually send PRs to our YAML file every time they do a minor or major release, and every time A-Frame itself does a release. So, I agree with the need to loosen up manual work required here. But if it was just that problem, we could deal with it by scraping NPM APIs better, and just having an expectation that package.json be maintained correctly.

I have two questions about your proposal:

1. If we go in the direction of less curation, how do we deal with component decay? The awesome-aframe list suffers from that IMO, and a lot of the components there don't work on current versions of A-Frame. It might be reasonable to use a component's package.json to detect the version of A-Frame they declare as a peerDependency or dependency, and rank things lower if that's < stable. We could sort by github stars, or by downloads / month, or have some manually curated set of "featured" components, but still accept all submissions.
2. What's the primary purpose of the registry?
   • If it's a standalone destination for discovering components, then yes, the curation and versioning is probably overkill.
   • If the registry is meant to serve the inspector, then IMO there are stronger expectations that components should actually work. We can't do much to rank more reliable components here, because discovery in the inspector is primarily via search. If there are a bunch of unmaintained and broken components, the inspector itself is going to feel broken.

[dmarcos]

The purpose of the registry was:

1. Help separate signal from noise by having a place where people can find good components (something that a simple google search won't give you). We knew that manual curation would not scale over time. It would be great to find a way to automate. Anything we can think of? Is there anyone that might help with manual curation for a while and help find ways to automate?
2. Serve the inspector so it can be used as a playground to test and discover new components as @donmccurdy mentioned.

[ngokevin]

Adding @kfarr since I think we've chatted about this. Loose thoughts:

Even when I curated the components, which is maybe the best case scenario, it still didn't stop component decay. I've asked around, I don't think anyone would have time + knowledge to curate. Yeah, I would have a small set of featured components and then a looser list under it.

At least if the components are listed in a visual form (e.g., seeing how recently it was updated, maybe add some package.json fields), it would give an extra layer of indication to their quality than awesome-aframe. While A-Frame is moving fast and breaking, we could let things loose for now, and look at baking things later.

The Inspector integration was one of the original purposes and was a neat idea. In practice, I don't find it as useful. It's a Select Box that gives names of components with not much more information. Many components will not work under the context of a 2D visual Inspector (e.g., controls, backend components, event-based components). If you find one, you'll still need to search for the script tag and include it. How often do people use that feature? I personally use Inspector as a way to pause the scene and get a different view of the scene.

I think a smoother workflow is to find a component on the Registry, include it, and if you find it useful and it works, then you can fiddle with the Inspector values if it makes sense to for that component. So I would want to move it more towards a standalone page, that we can point to and say "here's literally every single feature that was ever made, here's some that are really, and here's some that may work but are at least a good reference or place to file issues".

[donmccurdy]

That's fine with me. I do think that better indicators/sorting are necessary. The current health of components listed, or at least their likelihood of working via the inspector, needs to improve and I don't see room to loosen that up. But agreed we can improve things by means other than manual curation.

[ngokevin]

OK, I'll think about it some more.