...
Project Name (common abbreviation of the project or subcommittee) Responsibility: | Repository Name (contains documentation to be published with the upcoming release) Responsibility: | ReadTheDocs Link (link pointing to RTD 'latest' main index.rst; main title used in index.rst)
| Repository Status (new | maintained changed | remove ; needed to e.g. identify changes in the intersphinx linking)
| Documentation Owner(s) (responsible for documentation in this repo; please use @ notation for the name)
| Documentation available: o repo 'master' exists
| Documentation available: o repo 'branch' exists Responsibility: |
|---|---|---|---|---|---|---|
| M2 | M2 | M2 | M2 | M2 | M4 | RC0 |
...
To create a release-specific set of documentation it is essential for the doc team to know, which components are part of the upcoming ONAP release. To be more concrete: We need to know which components are deployed when ONAP is installed via OOM. And we need to know this on repository level - not on project or container level because documentation files are found in the repositories for the deployed ONAP components.
As of now (April November 2021) an ONAP release deployed via OOM consists of components whose underlying repositories include documentation and where the repositories ...
...
But with the tables on this page and a little help from the projects and release management it will be possible to identify all relevant files and related actions. Only the first table must (partly) be maintained by the projects!
To reduce complexity and to avoid confusion and misunderstanding for the reader we decided to remove documentation for unmaintained projects/repositories.
Our target on mid- / longterm is to ged rid of manually filling out this table. Any good idea and your feedback is welcome here! Do not hesitate to contact the documentation team.
...