Please free to complete or comment specific parts of this overview:

An idea for a strategy:
a "features" page on the website (which can be under About or under Archive)

• list of services (similar or identical to the list of services in the left menu on the web-app)
  • browse, => https://archive.softwareheritage.org
  • search, => https://archive.softwareheritage.org/browse/search/
  • save code now, => https://archive.softwareheritage.org/save/
  • deposit, => https://deposit.softwareheritage.org/
  • download-vault, => https://archive.softwareheritage.org/browse/vault/
  • SWHID resolve and reference =>https://archive.softwareheritage.org/browse/search/ , =>docs: https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html
  • archive mirrors?
  • FUSE?

Just saw this search page on Zenodo: https://help.zenodo.org/guides/search/

I'm renaming the task to an actionable item.

Thank you @zack for the quick response. I agree with you and do prefer archiving metadata for only existing SWHIDs.

Yeah let's go with option 3!

Thank you for your patience @douardda
You are right changing the deposited metadata should not be "acceptable", but this information is lost between a regular de posit and a metadata-only deposit, since we do not have a revision for it.
This task was the result of the discussion "do we create an origin-snapshot- revision for metadata-only deposit" which we concluded with NO due to the upcoming ERMDS.

@zack very good video!
Here is a short summary from the video (Daniele Procida) and from Divio's documentation website:
https://documentation.divio.com/
Four different functions:

• tutorials: allow the newcomer to get started (see https://docs.divio.com/en/latest/introduction/#django-tab)
• how-to guides: show how to solve a specific problem (see https://documentation.divio.com/how-to-guides/)
• technical reference: describe the machinery (see https://docs.divio.com/en/latest/reference/divio-cli/)
• explanation (discussions/background): understanding oriented (clarifying with a wider view) (see

https://www.uxmatters.com/mt/archives/2010/10/using-personas-during-design-and-documentation.php
Create persona documentation. When writing personas, include the following information:

Here is the stakeholder landscape that was created for the SCID WG output (RDA & FORCE11)

A summary of the following article:
https://blog.prototypr.io/software-documentation-types-and-best-practices-1726ca595c7f

Product documentation
Process documentation

Looks good!
I have a couple of questions:

1. What should be in the status receipt deposit_external_id (in a normal deposit)?
2. The SWHID given is returned in the receipt, but the SWHID doesn't give access to the deposit in the archive, should we add a url or identifier to the entry in the ERMDS? (@vlorentz)

see T2753

Closing this with the recent changes in the protocol:
https://docs.softwareheritage.org/devel/swh-deposit/specs/protocol-reference.html

One part is done on: D4607
But we still need to provide a way to give a parameter create_origin without deprecating the slug swh-deposit client cli.

server side done and deployed with v0.6.0

Did you push your updates to the swh-deposit documentation? is the user manual done?
Can I resolve this task?

1. verify if creating a lot of origins for checks is ok and verify if there is a problem having link rots
2. if yes, use add_to_origin to an existing origin that will redirect to https://forge.softwareheritage.org/source/jesuisgpl/

very good description.

History of FORTRAN and FORTRAN II

History of FORTRAN and FORTRAN II

For a next version with content we can't use the same deposit_id with an EM_IRI because it will mean we need to keep for the same deposit_id a list of different SWHIDs.
This is why we need a new deposit for each new content and link between deposits with a parent property.

of course we will but the client will see only one SWHID to one deposit_id

I just realized that new content = new SWHID
so if we accept a EM-IRI with new content it needs to capture the new SWHID and "delete" the old SWHID
this is not a good idea unless we keep all history of content modification
hence there is a need of a new deposit with each new content and to each will be attached only one SWHID core

After today's call with @ardumont, @douardda and @vlorentz we have reviewed the question of depositing the next version vs updating the same version.
With this in mind,
when updating the same version using EM-IRI: the object created on SWH should be a revision
when depositing a new version we are not sure if we do an edit of the precedent deposit or create a new deposit.

Looks good.
I have only a couple of naming remarks.

Great! This was super quick.

Possible option (discussion might be needed)
discovery_date from ERMDS = reception_date of the first deposit_request
swh:date = completed_date

In T2751#52450, @ardumont wrote:

I wonder if it would not make more sense to put spec-meta-deposit.rst and spec-sparse-deposit.rst within blueprint.rst since these are other "use cases"

Personally, I like the documentation files separation. I kinda don't want to have to deal with only one file to edit and scroll like a mad man when i want to edit something.

I'm fine with rendering the documentation as one page though and do as you propose (which i think is possible (?) without having to merge all files into 1).

In T2751#52343, @douardda wrote:

I also think that if we use the "blueprint" terminology, then the blueprint section should list all the specifications, implemented or not, but make it very clear what's done, in-progress or only planned.

I need to reflect on this.
There were two major reasons for which we use the slug:

1. create an origin
2. versions and deposit's paternity - the slug is the property letting us know that a deposit is another version of the same slug

First major question: do we prefer to have deposits with cli?
and do we need to have a preference, or should both mechanisms be equal

Reviewed even if already closed.
The changes are good.
Thanks David for this diff. it can partly address T2391.

good catch with the v2 precision.
I also agree that the statuses should be higher in the document.
I don't know if the status diagram is in here or somewhere else, it might be relevant to show it or put a link in.

Thank you for doing this important review of the deposit documentation.
I started commenting, and get back to this later.

Can you verify if there is a check related to the coherence between the slug and external_identifier?