Here's a current list of "component" names. Each ticket belongs to one of them. The definitions are somewhat arbitrary and non-orthogonal, but represent what I (warner) have been using to classify various issues.

First, the non-code things.

• contrib: problems with non-core things that live in the source:contrib/ directory, like the various FUSE implementations.
• dev-infrastructure: things that help us build Tahoe, like the ci, docker, the automated speed/memory/code-coverage tests (and the web pages which display their results), the IRC channels and mailing lists, and this Trac bugtracker itself.
• operational: things involved in running a Tahoe grid, external tools used to monitor or maintain a grid, tools used to launch a tahoe node, issues with te allmydata.com grid.
• website: things about the allmydata.org website and its Trac instance
• unknown: not yet categorized. All tickets default to this component until someone updates it.

Now, the tickets that can be resolved by changing something in the Tahoe source code tree:

• code: catch-all for anything that isn't classified better. Having a lot of tickets here suggests that maybe we need to add a component or two.
  • code-dirnodes: anything involving tahoe directories
  • code-encoding: immutable-file encoding format/layout, cap format, encoding/decoding algorithms
  • frontend stuff
    • code-frontend: general frontend things: new user-facing interfaces, FTP/SFTP servers, FUSE-like interfaces
    • code-frontend-cli: CLI tools
    • code-frontend-w32: windows frontend stuff
    • code-frontend-web: webapi interfaces, user-facing "WUI" interfaces
  • code-mutable: anything involving mutable files: encoding/decoding, share format
  • code-network: introducer, locating storage servers, establishing/maintaining connections to them
  • code-nodeadmin: node startup/shutdown, tools to create nodes, logging tools, management/monitoring tools, manhole, disk-space-limiting tools
  • code-peerselection: server selection/sorting algorithm, rebalancing code, allocation policy, swarming-download
  • code-storage: storage server implementation, share-storage directory layout, client-to-server share transfer protocol
  • documentation: (deprecated, use docs keyword)
  • packaging: pyproject.toml file and the hatch back-end, library dependencies, creation of binary packages (deb/rpm/exe), licensing, installation instructions