Note: there is an overlap with INFRA/ics-doc activities, but this appears to be the only one.

Also note: an alternative of creating components for existing projects is not feasible, as activities such as tracking SM1-specific documentation can span more than one existing project.

Note: this is just to make things clear.
Is this project "planned" to cover all area of PFS software development, meaning all of DRP/ICS/SPT/etc. in the sole place...?
Example seems not well reasoned or described, if SM1-specific means documentation for ICS/SM1 (or its operation) these are still within the ICS project which shall remain to the end of PFS.

Yes, this is intended to cover all areas of PFS software development, with the exception of the documentation already available in the ics_doc repo, for which a JIRA INFRA component has already been defined.

The SM1 example here was mentioned as activities up to SM1 acceptance already span multiple projects (PIPE2D, SIM2D as well as INSTRM). But I am happy to raise tickets on the INSTRM project, component=ics_doc if this is correct.

My worry is that we will be writing PFS documentation that does not alway suit being placed in INSTRM/ics_doc. What do we do with these documents? Users would then have to waste valuable time contacting the jifa@pfs support to get help, or raise issues in the incorrect places. Raising issues should be as simple and as convenient as possible for the user, and having a single project to encompass all PFS documentation activities helps to active that.