2023/2024 Contributor Hospitality Ideas

[BigLep]

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.".

[whizzzkid]

Summarizing Tasks:

• Reference helia-unixfs, helia-ipns, etc.
  - docs: ✨ Mapping unixFS and IPNS packages #76
• Reference helia-examples
  - docs: create a list of examples ipfs-examples/helia-examples#27
• Reference demo-slides, recordings, etc
  - docs: added link to helia demos #80
• Fix API docs links
  - fix(readme): Fixing Links aegir#1228
• Fix Code coverage
  - fix: re-enable test coverage aegir#1195
• Fix NPM docs and link backs.
  - fix(readme): Fixing Links aegir#1228
• Fix roadmap items with current items (@achingbrain)
• Fix manifest language (@achingbrain)
• Add benchmark comparisons against js-ipfs or other implementations (@achingbrain)
• Add CODEOWNERS
  - chore: Adds codeowners #78

[achingbrain]

NPM docs like don't link back to the top-level helia REAME which has all the info (see npmjs.com/package/helia ). The API links from within are broken.

I think a more fleshed out Documentation section in each package would be good here? Something similar to the version in the helia examples.

[BigLep]

I'm going to finetune this but here are some things coming to mind when looking at this again with fresh eyes. I know I need to check in on the other comments above. I'm still working here but wanted to get out some initial notes that was seeing.

• What runtimes do we support (node versions, browser distributions/versions including mobile/desktop)
• Document the release process / expectations #81
• Document our development and contributing guide #82
• It would be great to 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".
• 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.
• 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?
• 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.".
• Have the bare minimum text under each of the packages under https://github.com/ipfs/helia/tree/main/packages aggressively link back to https://github.com/ipfs/helia. (I assume we still need to keep the licensing text copy/pasted, but stuff about contributing should all be one place.). This prevents copy/paste and helps extract more value out of the work we're putting into the top-level project readme.
• Project status section needs to be updated.

[BigLep]

@achingbrain :

NPM docs like don't link back to the top-level helia REAME which has all the info (see npmjs.com/package/helia ). The API links from within are broken.

The point I'm trying to make is that we're going to invest a lot in https://github.com/ipfs/helia. That is the landing page. I think we should have the bare minimum text under each of the packages under https://github.com/ipfs/helia/tree/main/packages by provide a big/bold link back to https://github.com/ipfs/helia. (I assume we still need to keep the licensing text copy/pasted, but stuff about contributing, docs, support, etc. should all be in one place.). This prevents copy/paste and helps extract more value out of the work we're putting into the top-level project readme. Does that make sense?

[BigLep]

I did some more readme updates for some of the items above: #83

[BigLep]

Thanks @whizzzkid for your contributions here and getting more task tracking going. I know I piled some more tasks on with some of my comments. I have gone through and attempted to coalese all the tasks in the top-level issue description. Feel free to modify. We can let that be our source of truth for how this endeavor is progressing.

[BigLep]

I think there are two tiers of work. There are easier things that can be completed pretty independently. Thanks for seeing and jumping on those @whizzzkid. Please keep plugging away as able.

Then there are the bigger items around the project's relationship to other projects and direction. I think this is the most important area to focus on @achingbrain . This is items like the manifest updates and describing how the project relates to js-ipfs. I want someone to come to the project and after a quick read to get why we're building Helia and where it fits. I would then role to the developer/contributor guide stuff. Let me know if it's helpful to talk more specifically on priorities here.