more process questions

[AlexanderLanin]

see "parent_has_problem" at https://eclipse-score.github.io/docs-as-code/main/product/requirements.html

[MaximilianSoerenPollak]

The links underneath link to the 'Docs-as-code' Documentation.
These tool requirements we have written there link to specific parents (via satisfies).
THESE PARENTS are the requirements / things that have problems.
So the comments you see under each link are meant for the PROCESS_ parents of the tool requirement, not the tool_req itself.

• parents not aligned
  Contents are not the same requirements even though they talk about the same thing
• parents not aligned
  One exempts process from the rule the other doesn't.
• parents not aligned
  One exempts process from the rule the other doesn't.
• parents not aligned
  Process has 'valid|draft' as possible statuses (not described in the req). Also architecture talks about requirements
• unclear
  Which need type we should use for this 'document header'.
• unclear
  How the contribution % is counted. How to accumulate %. As well we noticed that Committer is used, but that is a reserved role in S-Core.
• tool specific
  Process talks about CODEOWNERS which is Github specific.
• parent not up to date
  As aligned tool_req should be exempt here. Process is excempt (in the metamodel) but not mentioned here as exempt.
• not understood
  This requirement is not yet specified. The corresponding parent requirement is unclear and must be clarified before a precise tool requirement can be defined.
• unclear
  Is this mandatory for all needs types? Especially 'tool_req' does not always have a process requirement to link to
• unclear
  We already made a ticket for this. See here
• unclear
  Does not mention which attribute to use. Link direction unclear. Linked Figure does not mention 'fulfils' attribute
• unclear
• unclear
  What is the difference between safety relevance and safety affected?

[AlexanderLanin]

Meeting Minutes

Participants:

• @masc2023
• @pahmann
• @PandaeDo
• @AlexanderLanin

Clarified:

• tool_req__docs_req_link_satisfies_allowed -> having a link is mandatory
• tool_req__docs_tvr_safety, tool_req__docs_tvr_security -> it's safety_affected, but basically we need to come up with a way to do/document tool classifications in infrastructure team

Postponed:

• tool_req__docs_common_attr_id_scheme -> we'll wait for examples from the pilots, e.g. persistency
• tool_req__docs_doc_attr_author_autofill -> postponed as it's not relevant at the moment. A more clever strategy must be used, as e.g. it's easy to achieve 50% at the beginning, but not once the document is mature.
• tool_req__docs_req_attr_reqcov -> later

Adapt process --> @masc2023:

• tool_req__docs_common_attr_status -> Add "(apart from proccess req)" to gd_req__req__attr_status
• tool_req__docs_doc_types -> check for missing requirement in process
• tool_req__docs_doc_attr_approver_autofill -> drop reference to CODEOWNERS as we don't know yet what tool/mechanism we will use
• tool_req__docs_req_attr_reqtype -> Add "(apart from proccess req)" to gd_req__req__attr_type

Architecture questions to be moved to #34 for discussion with @hoe-jo:

• tool_req__docs_common_attr_safety
• tool_req__docs_common_attr_security
• tool_req__docs_arch_link_fulfils

New points:

• According to the first "clarified" point a link from process requirements to workflows is mandatory.

[AlexanderLanin]

Let's focus this issue on the process adaption:

Adapt process --> @masc2023:

• tool_req__docs_common_attr_status -> Add "(apart from proccess req)" to gd_req__req__attr_status
• tool_req__docs_doc_types -> check for missing requirement in process
• tool_req__docs_doc_attr_approver_autofill -> drop reference to CODEOWNERS as we don't know yet what tool/mechanism we will use
• tool_req__docs_req_attr_reqtype -> Add "(apart from proccess req)" to gd_req__req__attr_type