Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions src/assets/YAML/meta.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -21,16 +21,16 @@ strings:
label: ISO 27001:2022
description: |-
ISO 27001:2022
labels: ['Very Low', 'Low', 'Medium', 'High', 'Very High']
labels: ['Very Low', 'Low', 'Medium', 'High', 'Critical']
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that ToDo tasks could have a 'Critical' label. But these labels are displayed for 'Time', 'Resources' and 'Usefullness'.

I don't think it makes sense to have 'Critical time' as a label for something that takes a long time. Same for 'Critical resouces'. As for 'Critical usfullness', it makes more sense. But then again, 'Very high usefullness' is also fine, and does not require us to split the lables into several arrays.

KnowledgeLabels:
[
'Very Low (one discipline)',
'Low (one discipline)',
'Medium (two disciplines)',
'High (two disciplines)',
'Very High (three or more disciplines)',
'Critical (three or more disciplines)',
]
hardness: ['Very soft', 'Soft', 'Medium', 'High', 'Very high']
hardness: ['Very soft', 'Soft', 'Medium', 'High', 'Critical']
maturity_levels:
[
'Level 1: Basic understanding of security practices',
Expand All @@ -40,8 +40,8 @@ strings:
'Level 5: Advanced deployment of security practices at scale',
]
# Default team
teams: ['Default', 'B', 'C']
teams: ['DevOps', 'Security', 'Applications']
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is interesting. I was on a very different planet. This changeis suggesting the each team is different type of team. That can definitely also be the case.

In my head, all teams were development teams. (Or different applications in an organisation.) And I just named them Team A, Team B, Team C and Team D.

Then I was splitting these into the groups:

  • Customer related
  • Internal focus
  • Cloud
  • On-premise

Just to illustrate situations where a team/application naturally may have more than one parent.

The teams in the default meta.yaml will only be an initial suggestion, that users can change.
(And @Whiteends, some time this year, we might publish an update where users can manually change the team names in the browser. Feel free to comment and have a sneak peak at https://dsomm.pages.dev/teams)

I have no strong feelings about what specific names we choose to be the inital default values. But I think it should be an example than makes sense for most people in many situations, and that is easy to understand.

So please share your thoughts @Whiteends. There are no rights or wrongs here, just shades of grey 😊

teamGroups:
GroupA: ['Default', 'B']
GroupB: ['B', 'C']
GroupC: ['Default', 'C']
GroupA: ['DevOps', 'Security']
GroupB: ['DevOps', 'Applications']
GroupC: ['Applications', 'Security']