Evolving the patterns catalog to 2.0

[jawache]

@greenhsu123 / @bengurney1 / @markus-ntt-seidl / @Oleg-Zhymolokhov

So there have been several threads around this topic namely these:

#217
#213
#220

I think to summarize the conversation there are a few issues.

1. We've been building the patterns atomically, each pattern is evaluated individually and not as part of a collection of patterns. This results in a lot of duplication and confusing results like multiple very similar patterns.
2. Evaluating a set of patterns as a whole would help resolve these issues, we'd be able to compare and contrast, merge duplicates, identify inconsistencies etc...
3. The grouping of patterns is by domain, but there is a lot of similar patterns across domains - e.g. coding for low CPU is the same in multiple domains.
4. There is a tension between what's practical in terms of getting a group of people together to agree and what's ideal in terms of structure.
5. There is a feeling that there are probably a much smaller set of top level patterns with sub patterns.

One approach we discussed was to:

1. Gather a cohort of SMEs for one domain (probably Cloud).
2. Over the course of limited period with a target end date focus on identifying 10/12 top-level patterns for that domain.
3. There can be top-level patterns and sub-patterns.
4. We won't define any structure or hierarchy or anything, just focus on deciding the patterns - structure/tagging/categorization can come later.

Limiting the number of patterns will act as a forcing function to get consensus on the core/common patterns, having unlimited patterns means there is less pressure to have the challenging conversations and express disagreement, disagreement is good since only though disagreement do we get to agreement.

Limiting the time will also act as a forcing function, the right people will engage if they know they have limited time to engage.

@bengurney1 suggested an approach where we use a series of Design Thinking workshops to get to a result here. We used a very similar approach to generate our Theory of Change. Over a 6 week period a set of people met every week for 1 hour and collectively came up with our ToC. https://greensoftware.foundation/articles/theory-of-change-defining-strategy-gsf / https://www.figma.com/file/9xjePKRWrLU0fGyUwHpMEF/GSF-Diagram?node-id=21%3A759

[jawache]

Cam: What will this mean for future contributors who want to contribute to patterns when they are all decided through a workshop.
Oleg: Cloud is composed of Serverless, so if there are 12 Cloud patterns does that include Serverless or does Serverless have 12 patterns. How do we categorize domains that are mutually exclusive. Remove the limiting factor on the number of patterns.
Tammy: Some even more top level patterns cross domain patterns.
Oleg: What's the reasoning for creating a pattern?
Tammy: Some are obvious and related, once you get into the weeds like Kubernetes, 12 Kubernetes patterns would be very specific.
Tammy: Can we re-use this meeting for the workshops?
Asim: Perhaps 1 person per org.
Tammy: Encourage people who've actually tried to apply patterns/calculate SCI scores to join.
Oleg: Ask people to pre-read patterns, ask orgs to send experts.