IPFS Gui & Tools ownership

[SgtPooki]

I want to discuss defining and reducing the surface area of ownership of the GUI & Tools team.

Currently, there are a few areas where we define what the IPFS GUI / IPFS Gui & Tools / IPFS GUI Tools / @ipfs-gui team owns:

1. https://github.com/protocol/w3dt-stewards/blob/main/scripts/create-triage-links/src/repos.js
2. https://github.com/ipfs/ipfs-gui#all-projects
3. https://www.notion.so/pl-strflt/IPFS-GUI-3bc1c1bf54d74f928bf11ef59c876b74#3271edf4345e4a95b163066d5a9f5da6 (points to item 2 above)

Questions

1. Can we drop support for any of the listed packages? Can any gui&tools packages/repos be archived/deprecated?
   • We have already reduced triage-work to what is listed at https://github.com/protocol/w3dt-stewards/blob/main/scripts/create-triage-links/src/repos.js. Is that sufficient?
2. We know that ipfs-desktop, ipfs-webui, and ipfs-companion are our priorities, but what are our priorities beyond those three?
   • What support priority do the main three have?
   • What are the priorities of the other packages?
   • What support do we need from @achingbrain , i.e. what packages from https://github.com/ipfs/js-ipfs/tree/master/packages do we need tier 1 support on?
   • What are our other dependencies? What support do we need from other orgs/teams? (ipld, multiformats, etc..)
3. Should we keep a list of unmaintained, yet useful packages? If so, where?
4. Decide whether this repo (ipfs/ipfs-gui) should be the home of all IPFS GUI related efforts across teams, or the centralized repo for the IPFS GUI & Tools team

Proposal

1. Support changes
   1. Drop support for the following packages:
      • ipfs-share-files - https://github.com/ipfs-shipyard/ipfs-share-files#maintainers is already asking for official maintainers
      • ipfs/in-web-browsers - https://github.com/ipfs/in-web-browsers should be owned by browsers-WG team
      • https://github.com/ipfs/kubo/tree/master/assets/dir-index-html - drop support, we're already not including those in triage efforts and I'm not familiar with it.
   2. Debateable
      • ipld/explore.ipld.io - https://github.com/ipld/explore.ipld.io should be owned by ipld, but we essentially have this entire page inside of webui/desktop via https://webui.ipfs.io/#/explore
      • awesome-ipfs - there is already discussion about moving support for this repo into [ecosystems dashboard]. could drop official support if we automate more of the repo(https://ecosystem.ipfs.tech/) so PRs get automerged. Needs better stewards for curation than what IPFS GUI & Tools team can offer
2. I propose the following order of support priorities:
   • ipfs-webui (consumed by kubo & desktop)
   • ipfs-desktop (unique user sessions over lifetime: 33k Linux, 131k Windows, 39k macOS)
   • ipfs-companion (chrome store says 60k+ users)
   • ipfs/ipld-explorer-components - consumed by explore.ipld.io & webui
   • public-gateway-checker - somewhat useful and popular repo for checking status of ipfs gateways. Lots of opportunity here without a large burden
   • ipfs-shipyard/pinning-service-compliance - useful for ensuring pinning providers are compliant, and helpful as a pre-req for adding pinning-service providers to webui pinning provider defaults
   • ipld/explore.ipld.io
   • ipfs-shipyard/i18n - documentation only, small burden, but required by desktop and webui or other gui&tools projects that need i18n.
   • ipfs-shipyard/js-pinning-service-http-client - used only by ipfs-shipyard/pinning-service-compliance currently
   • multiformats/cid-utils-website
   • ipfs-shipyard/ipfs-css
   • awesome-ipfs - lists a lot of ipfs related projects/tools/datasets,
3. I propose we keep a list of packages in this repo's README that include unmaintained & useful repos so they're not lost and can be taken up if the need arises.
4. I think it makes sense to keep this repo as the home for GUI projects, but we may want a similar ipfs/ipfs-tools repo for things that aren't necessarily GUI.

cc @BigLep @lidel @tinytb

[SgtPooki]

@autonome @lidel https://github.com/ipfs/in-web-browsers/issues/195 is an example of something that makes more sense for the browsers WG to own rather than IPFS GUI & Tools. Do either of you have an opinion on IPFS GUI & Tools team's ownership of the in-web-browsers repo.

cc @tinytb @BigLep

[lidel]

• :+1: for removing dir-index-html , Kubo team is maintaining that
• :+1: for removing in-web-browsers from GUI triage links. It was never a GUI project – was included it in triage links because there was no GUI team and i was doing them together in one session in my spare time :)
• If you want to cut things, I'd argue awesome-ipfs should also be removed
  • this is more an ecosystem / community resource than a GUI app
  • a sibling website https://ecosystem.ipfs.tech/ is not on the list
  • other websites like https://js.ipfs.tech/ are also not GUI responsibility
• list is missing utility website https://dag.ipfs.tech – https://github.com/ipfs-shipyard/ipfs-dag-builder-vis

[SgtPooki]

Action items i'm going to take based on lidel's review so I can close this out.

• [x] Remove from ipfs-gui readme "ownership" section
  • [x] dir-index-html
  • [x] in-web-browser
  • [x] awesome-ipfs
• [x] Remove from triage links
  • [x] dir-index-html
  • [x] in-web-browser
  • [x] awesome-ipfs
    • [x] update awesome-ipfs description / banner to include a call for maintainer
• [x] Add to readme "ownership" section and triage links
  • [x] https://dag.ipfs.tech/ – https://github.com/ipfs-shipyard/ipfs-dag-builder-vis

[SgtPooki]

Closing this for now. We can come back to this later if necessary, but there hasn't been much activity so I'm just proceeding with what we've got for now.