Below are items that stuck out when coming to https://github.com/ipfs/helia with fresh eyes imagining what it's like for someone who hears about Helia, wants to learn more, and wants to contribute potentially:

README Items

• Reference helia-unixfs, helia-ipns, etc. We don't give pointers to these important modules. docs: ✨ Mapping unixFS and IPNS packages #76
• How do I get started as a consumer? Reference https://github.com/ipfs-examples/helia-examples
• Reference demo-slides, recordings, etc: docs: added link to helia demos #80
• Remove erroneous verbiage: "The core of IPFS is the Files API, which will likewise be implemented in Helia. These initial building blocks are in development now; have a look at this repo's PR(s)." Is this true. Isn't this in helia-unixfs?
• @whizzzkid : Fix API docs links: fix(readme): Fixing Links aegir#1228
• Link to code coverage. The badge lists it as unknown. This is a new endeavor. We should be able to show off good numbers to start. fix: re-enable test coverage aegir#1195
• @BigLep Have a section about who some of our users are. I expect we don't have any currently. That's ok, but lets solicit for people to share us. We want a "your logo here": docs: readme tidyup (status, organization, etc.) #83
• @BigLep Update project status section: docs: readme tidyup (status, organization, etc.) #83
• Answer "Where should a user ask questions?"
• @achingbrain Answer "What is the relationship of this project to js-ipfs?"
• @achingbrain Answer "How do we prove interoperability with other IPFS implementations like Kubo?"
• @achingbrain Answer "How does it perform compared to other implementations including js-ipfs?"
• Answer "What runtimes do we support (node versions, browser distributions/versions including mobile/desktop)"
• I think we could use more visuals on the readme. I think having something visual showing the relationship between ipfs/helia, js-libp2p, and the other Helia repos. I think seeing this helps drive home the point that Helia is modular.

Manifesto Items

• @achingbrain "The core of Helia will be very focused on use as a library: just js-libp2p, a blockstore, js-bitswap and a POSIX-like API which will be extendable to add additional features such as IPNS, an RPC-API, etc." and " instead it will present an abstraction of posix filesystem operations (ls, cat, etc) as an API but the underlying filesystem(s) will be configurable." The POSIX-like API is no longer part of it right?
• @achingbrain Permissions discussion should probably have a callout that this is for when Helia is run as a daemon, but that isn't the primary usecase.

Other specific things to do

• @whizzzkid: Add CODEOWNERS to the helia repos (helia, helia-unixfs, hela-ipns, helia-examples) to make it clear who is responsible for reviewing: chore: Adds codeowners #78
• @whizzzkid: Have helia-examples provide a landing page of an overview of the options: docs: create a list of examples ipfs-examples/helia-examples#27
• @whizzzkid: helia/packages READMEs should have minimal text but instead drive back to https://github.com/ipfs/helia which has a lot more content.
• (similar to previous) helia-ipns and helia-unixfs READMEs should be as minimal as possible and drive to https://github.com/ipfs/helia to learn about contributing, etc.
• @achingbrain : Have a tracking issue of what needs to specifically be done before we can shut down js-ipfs from a maintenance regard.
• @achingbrain / @BigLep : I know we have the roadmap doc (https://github.com/ipfs/helia/blob/main/ROADMAP.md ).
  Given it's been a few months, we should update with current understanding.
• Document the release process / expectations #81
• Document our development and contributing guide #82

General thoughts

1. Provide more bite-size chunks for would-be contributors to pick off. As of 2023-02-20, we basically have a really large contribution in Pinning and Garbage Collection #28 or we have smaller things in examples which is great but it could be clarified with a prioritized list of examples. It would be useful to get other work items scoped out with clear done criteria and likely some labeling to make clear the sizing.
2. I'm curious how useful people find the Helia API docs we link to. It seems like to do much, need to the unixfs repo for example. Does it make sense to generate all the Helia-related projects docs together so it's clearer to a user what are all the Helia APIs are exposed?
3. I think our tagline needs to be more than "An implementation of IPFS in JavaScript". I think the statement down below is more compelling "A lean, modular, and modern implementation of IPFS for the prolific JS and browser environments.".