mcjaeger
commented
7 years ago (from discussion) there is a similar functionality in the vulnerabilities where multiple status updates in an attribute are preserved. The rating shall be similar / the same approach to that.
Input from discussion
- mainline status shall be a kind of history field
- no separate service for multiple documents
- because, accessing the release for getting its mainline status (which is aggregated) will happen 100x more than accessing mainline status entries for other criteria, ie. all mainline status statements by one user
- so it better to have the data structure at the release document rather than having it at a separate location
- values are: user id, date of creation, comment string, generic field
This above is generic, for this issue:
- key is named
mainlineStatus - value is list of struct
- struct is user id, date of creation, comment string, generic field
- generic field is enum of mainline status
- mainline status is [mainline (3), specific (2), open (1), do not use (0)] (which could be translated to recommended, if you really want to, we do not know, do not)
Display:
- Aggregated display should use four numbers: one for each status, just like the product clearing role.
- In the release detail view, there should be a full listing ("Mainline Details") which lists all given mainline status input as data table (user can sort).
- A user overwrites his mainline status input if he adds a new one.
This feature requires user feedback.
It is about having an overview and some UI controls to manage components / releases by their life cycle status. Currently, this status is displayed, however, as flat attribute
Life cycle status (long "u") could be "specific", "mainline", "end-of-life". It is proposed that before starting the feature, a user feedback is really important here.
One major aspect is how to get such status value: voting for example? Special role assignment? Scores / metrics? that is where user feedback is required.