de-emphasizing curation from the registry

[ngokevin]

@dmarcos and @donmccurdy and I met for roadmap and priorities. Generally, we don't want to have a curation bar, and just show everything. With or without extra/scraped metadata. There are also currently multiple ways to find components (npm, awesome, Google, docs), so there is duplicated effort here. Options:

1. Discontinue the Registry, link to npm search instead (or other search engines).
2. Automate and index npm to do a pretty display of components with images and search.

Feedback needed! Does your life depend on the Registry? Let us know.

[cvan]

/cc @larsbergstrom - in case you missed it from #153.

Is there a solution to emphasise scenes over components? How does this improve the ease of creating new content? Is there intention of getting folks to create and remix more Glitches?

[ngokevin]

That's a bit unrelated to curated components...If you're trying to highlight a problem with developer engagement, I believe A-Frame is doing okay in onboarding developers. There are instant remixable Glitches featured in the documentation and we continually feature case study articles. If you'd like to jump in, people can directly help by creating Glitches and sharing them.

[cvan]

Digression on my part. I’ll follow up with that elsewhere.

I like the two options for forgoing manual curation of components.

What are your thoughts on some type of simple JSON file for each most recent version of A-Frame with known, tested components?

That’s a bit similar to the YAML format. I don’t think they’re bad ideas.

Can you think of a simple way to expose compatibility information? Perhaps components could throw warnings about possible version mismatches or incompatible between versions of A-Frame or peer dependencies?

You’ve thought a lot about this. What do you think is the biggest friction point with components (discovery or compatibility or composability)? And what’s the smallest incremental win that could improve one of those?

[ngokevin]

There's not much friction. Many components being made, and they're adopted and used. Compatibility metadata is near impossible to capture reliably for all components, especially as A-Frame moves quickly with three.js bumps. It should be 100% reliable or not at all.

It's not much work to quickly try a component, see if it doesn't work anymore, then file an issue / find an existing issue on GitHub. It's just how it is when having packages and add-ons/extensions that plug into a platform/framework.

Here's the npm link. We already have a Where to Find Components page in the docs we can update. We can point to Google also, that works as well. My plan is to:

1. Add a header to the Registry pointing to that section in the docs.
2. Improve that section however we can.
3. Discontinue the Registry (leaving it around for a while)
4. If anyone ever gets around to scraping npm, we can release that.

[donmccurdy]

Automate and index npm to do a pretty display of components with images and search.

As @ngokevin mentioned it does depend on someone doing the work, but I'd hope (long-term, anyway) we can make something with better search and filtering than npm's results. Maybe recommending a "aframe": {...} section in package.json to assist with that, indicating whether the published thing is a component, or tooling like aframe-react, etc. Sorting by GitHub stars would probably be an improvement to whatever NPM is doing, too.

Scenes seem like a larger issue, probably need a dedicated discussion explaining some background elsewhere?