+- Effort: variable, depending on the chosen listers/loaders (4PM ?)
+- Priority: Medium
+
+Deploy at least 2 additional loaders (of currently unsupported VCS/package formats) and 2 additional listers (of currently unsupported hosting platforms), expanding the coverage of the Software Heritage archive. Listers and loaders can be developed in house or contributed by external partners, e.g., via dedicated grants.
+
+KPIs:
+
+- Number of new loaders/listers deployed
+- Number of origins archived/listed
+
+Minimize archival lag w.r.t. upstream code hosting platforms
+Make it user-driven, simple, and efficient to fully and recurrently archive a new instance of an already supported code hosting platform.
+
+- User-facing web form allowing any user to *propose* the archival of a new forge instance, and moderation web UI to validate archival requests before ingestion. `T4047 <https://forge.softwareheritage.org/T4047>`__
+- Admin tooling and UI to deal with received submissions. `T4058 <https://forge.softwareheritage.org/T4058>`__
+- Include free-from box suggestion form for forges that are not supported yet (to replace the currently poorly maintained `wiki page <https://wiki.softwareheritage.org/wiki/Suggestion_box:_source_code_to_add>`__). Possibly to be integrated with the user support system elsewhere in the roadmap.
+Complete on paper specification for SWHID version 2, including migrating to a stronger hash than SHA1.
+
+- Complete on paper spec
+- Aligned with work done on new git hashes
+- Migration plan from/cohabitation with v1 (N.B.: we need to maintain SWHID v1 support forever anyway)
+- Understand impact on internal microservice architecture (related to `T1805 <https://forge.softwareheritage.org/T1805>`__, in particular use SWHIDs everywhere (core SWHIDs, without qualifiers))
+- Keep correspondence with v1 (there may be multiple v2 for one v1)
+Layer 1: show intrinsic and extrinsic metadata for artifact on web UI (design, implementation and deployment) Layer 2: add linked data capabilities (Semantic Web solutions)
+
+- Design metadata view for Web UI
+- Allow export of metadata (in multiple formats - APA/ BibTeX/ CodeMeta/ CFF)
+- Make the textual search language of archive.s.o a first-class citizen, including:
+- Simplify syntax
+- Conduct UX audits and user-testing of the web search UI
+- Note: this does *not* include extending the type of data currently indexed and used for search (e.g., no filenames, no file content, etc.; they can come later/separately).
+
+KPIs:
+
+- SWH search using QL available in production
+- Default user experience for archive.s.o textual searches
+The currently available user documentation only provides a FAQ. It should contain at least:
+
+- An overall non-technical description of the archive and the core elements of its architecture
+- A set of howto/getting started pages on main subjects (search, browse, push code in the archive, retrieve code and artifacts from the archive, metadata)
+- Link to existing documentation on the main w.s.o. site as appropriate.
+Publish a web page (under docs.s.o somewhere) providing a high-level overview of which listers/loaders are available (implemented, deployed, running, etc.) with pointers to the corresponding modules/implementations.
+- Priority: n/a (one 2-day sprint every 2 months)
+
+Includes work:
+
+We currently have a lot of `open Sentry issues <https://sentry.softwareheritage.org/organizations/swh/issues/>`__, but this is very raw data that isn’t very usable or visible. They should be cleaned up so that under normal conditions, the number of reported issues stays “minimal”.
+- Create a user-facing ticket system to support user requests and bug reports (e.g., a support@ address that automatically create support tasks that we can triage and follow)
+- Define the process to:
+
+ - Ensure some basic quality of service (e.g., time to first answer)