New folder structure for Patterns about innersourcepatterns

[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.

[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.

[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 🎈

[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]

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 #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 #155 proposes.

[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