Provide a user-friendly snapshot for CAMARA users and developers

[hdamker]

With the upcoming wiki.camaraproject.org we will get the opportunity to provide an overview across the CAMARA (sub) projects which is more user friendly and easier to maintain than the current APIBacklog.md.

Next steps (proposed by @jordonezlucena):

• Update current APIBacklog.md with information from AHC (@jordonezlucena)
• Wait for wiki.camaraproject.org being operational (planned for end of October)
• Decide which content will be migrated to Wiki (and being evolved therein) and which content will be kept in the API backlog.md file (discussion here within the issue, might depend on Consolidation Issue for open points release management ReleaseManagement#9)

This issue replaces camaraproject/WorkingGroups#307

[jordonezlucena]

Update current APIBacklog.md with information from AHC(@jordonezlucena)

Actioned through #331

[jordonezlucena]

@hdamker @MarkusKuemmerle: what is the status of the second step (Wait for wiki.camaraproject.org being operational)?

[hdamker]

@jordonezlucena wiki.camaraproject.org can in principle be used (we already use it for TSC meeting minutes). We just need to decide on which level we place the information and address the third task.

[jordonezlucena]

@jordonezlucena wiki.camaraproject.org can in principle be used (we already use it for TSC meeting minutes). We just need to decide on which level we place the information and address the third task.

@hdamker: as noted in the latest commit at #331, the proposal is to remove from APIbacklog table all the information related to actual API lifecycle management. This includes the following fields:

• API release: the list of versions of the API. Version follows the x.y.z conventionE.
• Link to API definition: (for a given API release) it specifies a pointer to the API definition.
• Link to API documentation: (for a given API release) it specifies a pointer to the API definition.
• Link to API code: (for a given API release) it specifies a pointer to the API YAML file
• API tested at: (for a given API release) list of operators which have tested the API functioning and behaviour.
• API deployed at company and country: (for a given API release) list of operators which have deployed API, and in which countries.

The reason is that these SIX fields capture information which is in scope and under supervision of corresponding Sub-Projects, and thus difficult for Backlog WG to maintain and evolve (and even more in a .md file).

Whether it makes sense for wiki.camaraproject.org to host all these fields, or only a subset of them, it is a decision I prefer to leave to TSC.

[jordonezlucena]

@jordonezlucena wiki.camaraproject.org can in principle be used (we already use it for TSC meeting minutes). We just need to decide on which level we place the information and address the third task.

@hdamker: as noted in the latest commit at #331, the proposal is to remove from APIbacklog table all the information related to actual API lifecycle management. This includes the following fields:

• API release: the list of versions of the API. Version follows the x.y.z conventionE.
• Link to API definition: (for a given API release) it specifies a pointer to the API definition.
• Link to API documentation: (for a given API release) it specifies a pointer to the API definition.
• Link to API code: (for a given API release) it specifies a pointer to the API YAML file
• API tested at: (for a given API release) list of operators which have tested the API functioning and behaviour.
• API deployed at company and country: (for a given API release) list of operators which have deployed API, and in which countries.

The reason is that these SIX fields capture information which is in scope and under supervision of corresponding Sub-Projects, and thus difficult for Backlog WG to maintain and evolve (and even more in a .md file).

Whether it makes sense for wiki.camaraproject.org to host all these fields, or only a subset of them, it is a decision I prefer to leave to TSC.

New PR available in #360