Standardise issue lifecycle

[moritzsommer]

Current Situation

It seems like we are currently collecting old legacy issues in this repository that will be forgotten until the end of time. And since I missed the last few years of active implementation, I don't know which issues are still important and which are just outdated.

From what I understand, there are several reasons for that:

1. Auto-close: If the keywords for auto-close are missing, issues are left open and forgotten. Later, someone has to manually check which issues have already been solved. This could be a huge problem when the main SDK developers change. Examples:
   1.1 Referable.update_from() doesn't update parent namespace #215 (comment)
   1.2 aasx: Add failsafe for writing and reading AASX files #228 (comment)
2. Discussion: Sometimes, discussions are held about the IDTA specification or compatibility in general. If no updates or clear results are provided, the status of the issues stagnates. Examples:
   2.1 Allow uppercase dataTypes and set them to lowercase #98
   2.2 Fix LangStringSet._check_language_tag_constraints after the spec has been clarified #157
3. Priority: The issues are not prioritised. Some seem less important and are therefore overlooked. After being ignored for quite some time, they may no longer be relevant. Examples:
   3.1 Problem of Customized child classes due to AAS Constraint 108 in SEList #47
   3.2 ModelReference type deserialization #169

Moreover, the automatic closure of issues does not really work for our workflow. When we merge an issue into the develop branch, we consider it solved. However, GitHub's auto-close feature only works when merging into the main branch, our default.

Proposed Change

Since outdated legacy issues cause major problems when devs join or especially leave the project, we should agree on a standard procedure for dealing with (open) issues. The following points could be discussed during our next dev meeting:

• Manual sorting and closing of existing issues
• Agreement on regular backlog (every 2/3/4 months?) for future issues
• Auto-close of issues merged into a non-default branch
• Auto-close of inactive issues
• Introduction of priority labels (interesting read)
• Documentation of issue labels and lifecycle in CONTRIBUTING.md
• Introduction of a template for new issues