New folder structure for Patterns

[spier]

I propose a folder structure that reflects the maturity that a given pattern as reached.

Specific proposal:

patterns
├── donut
├── proven
└── unproven

What happens to the existing patterns:

• We would move all existing patterns into the respective subfolder.
• We would also keep the "Status" field in the pattern file itself.

Why is this useful? (purpose)

• easier to autogenerate an ebook of only the proven patterns (i.e. all files in new folder patterns/proven
• ability to merge PRs more quickly, even if they are not fully reviewed (see conversation in Slack) - also see Questions below
• clears up the root directory of the GitHub repo, leading to a clear separation between patterns and other meta data files that we only need for managing the repo, or for the book generation etc
• opportunity for further automation - e.g. autogenerate an index page of all patterns and their patlet, similar to what we have in the main README.md today.

Concerns

• We have some open PRs that work on edits to the existing patterns. Changing the folder structure now would lead to merge conflicts. I suspect all PRs would have to rebase to master. Also whenever we merge those PRs in, we would always have to make sure that the patterns end up in the correct folder.

Questions

• in addition to the existing Pattern Maturity, there seems to be the desire to flag any pattern as Draft, indicating that it has not been fully reviewed by anybody. This should allow us to merge faster. => I get confused by this, as there then are two different taxonomies: One indicating how proven a pattern is, and one indicating the level of review that a pattern has experienced.

[NewMexicoKid]

There are indeed (at least) two separate dimensions for assessing a pattern:

• its maturity level (level of review) - this has, for instance, how well a pattern has been documented
• whether it has been proven in real life; i.e., some patterns start as donuts, people contribute solutions to try but until they have been tried, that "pattern" is just a proposed solution in a pattern form (in general, patterns reflect proven solutions)

Is there a way to avoid the rebasing problem by putting in a clear metadata field in the pattern with the proven/unproven tag? Then auto-generation of an e-book can still be done without causing rebasing problems for outstanding PRs.

[maxcapraro]

I feel we overly simplify if we treat the validation status as binary (proven, unproven).

My suggestion (see #155) would be: Use maturity levels as the primary dimension to process and edit the patterns and funnel them towards the e-book.

[maxcapraro]

On topic: I think moving the patterns /contributions lifecycle to the folder structure is a good thing :)

[lenucksi]

• I agree with both @spier and @maxcapraro that using folders as a state indicator is a nice idea, and one that we should strive to adopt.
• I also agree with @NewMexicoKid on the multidimensionality and especially on the use of meta-data for selection and generation of rendered artifacts.
• In the conference's break-out session the idea for additional indexing axis's came up, which I also think could be useful and likely be adressed using metada.

Regarding the rebasing problem:

• I think we should strive to merge or close the existing PRs in a near time horizon, idealy with added classification according to Contribution process including Maturity Levels #155.
• After this is done, the rebasing problem will not exist any longer.
• Once this is done we can start re-arranging the content and hence deal with what this issue and Contribution process including Maturity Levels #155 proposes.

[spier]

Ok. We can wait for a couple of more PRs to be merged.

However I doubt that we will ever can to a clean slate (i.e. 0 PRs), so sooner or later we will have to deal with a couple of merge conflicts when introducing this patterns folder structure.

But anyhow, I am happy to wait with this for a bit longer.

[lenucksi]

However I doubt that we will ever can to a clean slate (i.e. 0 PRs), so sooner or later we will have to deal with a couple of merge conflicts when introducing this patterns folder structure.

If we can reduce this to ~5 PRs having to be rebased / merged / ... that would already be a bit nicer than having to do this for ~20 PRs.

[spier]

Makes sense. Let's try :)

[spier]

@lenucksi I got curious which of the open PRs are introducing new patterns vs how many are modifying existing ones. My assumption is that we would only see merge conflicts for modifications.

tl;dr

I went through all open PRS and classified them. Only #63, #101 and #102 represent changes to existing patterns. So if we could get them merged or closed, then all other PRs are just new patterns that won't lead to merge conflicts.

Details

2019

• 124 - new pattern - project-setup/communication-tooling.md
• 123 - new pattern - project-setup/issue-tracker.md
• 121 - new pattern - maturity-model.md
• 120 - new pattern - innersource-portal-hygiene.md
• 112 - new pattern - who-is-using-my-code.md

2018

• 106 - new pattern - innersource-guidance-group.md
• 102 - modification/duplication - gig-marketplace.md / innersource-portal.md (already merged?)
• 101 - modification/duplication - gig-marketplace.md (already merged?)
• 95 - modification - modular-code.md
• 87 - modification - crossteam-project-valuation.md (PR turns this into a real pattern. should be merged asap)

2017

• 84 - new pattern - contained-innersource.md
• 82 - new pattern - cultural-change-through-hiring.md
• 78 - new pattern - change-the-middle-management-mindset.md
• 74 - new pattern - assisted_compliance.md
• 71 - new pattern - include-product-owners.md
• 64 - new pattern - not-invented-here.md
• 63 - modification/duplication - change-developers-mindset.md / duplicate of change-developers-mindset.md
• 47 - new pattern - overcoming-project-management-time-pressures.md
• 46 - new pattern - open-source-trumps-innersource.md
• 38 - new pattern - donut-get-contributor-despite-silo.md → get-contributor-despite-silo.md

[spier]

We didn't end up with the folder structure originally proposed in this issue, but rather one that follows the new maturity levels:

• 1-initial
• 2-structured
• 3-validated

Still we can close this issue as the purposes that this issue was after has been achieved 🎈