Move patterns from wiki to markdown

README.md

@@ -30,8 +30,8 @@ possible to either deploy the same service in independent environments with sepa
 * [Cross-Team Project Valuation](crossteam-project-valuation.md) - *It's hard to sell the value of cross-team, inner sourced projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.*
 * [Reluctance to Receive Contributions](https://docs.google.com/document/d/13QDN-BpE_BixRFVGjao32n4Ctim0ROXAHbBWMBOijb4/edit) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them.*
 * [What Before How or Services Documentation](https://docs.google.com/document/d/1_N1wsQeDusfIcNy-O2ZXenY3PL7ZbvkUDRZxGUuegZw/edit?usp=drive_web) - *A lack of common understanding between different management tiers creates funding barriers and increases the risk that solutions will not deliver required business outcomes.*
-* [Overcome Acquisition Based Silos - Developers](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Overcome-Acquisition-based-Silos)
-* [Overcome Acquisition Based Silos - Managers](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Overcome-Acquisition-based-Silos)
+* [Overcome Acquisition Based Silos - Developers](overcome-acquisition-based-silos-developer.md)
+* [Overcome Acquisition Based Silos - Managers](overcome-acquisition-based-silos-manager.md)
 * [Open Source Trumps InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/46) - *People find the InnerSource project but, after all things are considered, even if the InnerSource component meets their needs, they still go with the open source component.*
 * [Overcoming Project Management Time Pressures](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/47) - *Project management believes timeline pressure and commitments on feature content does not allow for developers to spend the time needed to develop shareable code and provide support.*
 * [Start as Experiment](start-as-experiment.md) - *An inner source initiative is considered but not started, because management is unsure about its outcome and therefore unwilling to commit to the investment.*
@@ -41,19 +41,19 @@ possible to either deploy the same service in independent environments with sepa
 
 * [Don't Bother Looking](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/60)
 * [Junkyard Styled Inner Sourcing](junkyard-styled-innersourcing.md)
-* [Shared Code Repo Different from Build Repo](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Shared-Code-Repo-Different-from-Build-Repo) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.*
-* [Incentive Alignment](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Creating-Developer-Incentive-Alignment-for-InnerSource-Contribution)
-* [Change the Developers Mindset](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-change-the-developers-mindset)
-* [Share Your Code to Get More Done - Likely Contributors Variant](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-Share-Your-Code-to-Get-More-Done---Likely-Contributors-Variant)
+* [Shared Code Repo Different from Build Repo](shared-code-repo-different-from-build-repo.md) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.*
+* [Incentive Alignment](developer-incentive-alignment-for-innersource-contribution.md)
+* [Change the Developers Mindset](change-the-developers-mindset.md)
+* [Share Your Code to Get More Done - Likely Contributors Variant](share-your-code-to-get-more-done.md)
 * [Introducing Metrics in InnerSource](introducing-metrics-in-innersource.md) - *Involve all stakeholders in designing and interpreting metrics to measure the current status in terms of health and performance of the InnerSource initiative.*
 
 #### Pattern Donuts (needing a solution)
 
-* [Donut 3: How to Defeat the Hierarchical Constraints](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-3%3A-how-to-defeat-the-hierarchical-constraints)
-* [Donut 5: Project Management Time Pressures](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-5:-project-management-time-pressures)
-* [Donut 6: Organizational Mindset Change](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-6:-organizational-mindset-change)
+* [How to Defeat the Hierarchical Constraints](defeat-hierarchical-constraints.md)
+* [Project Management Time Pressures](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/47)
+* [Organizational Mindset Change](organizational-mindset-change.md)
 * [Donut 8: Not Invented Here](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-8:-Not-invented-here)
-* [Donut: Bad Weather For Liftoff](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Bad-weather-for-liftoff)
+* [Bad Weather For Liftoff](bad-weather-for-liftoff.md)
 * [Get Contributions Despite Silo Thinking](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/38)
 
 
@@ -97,6 +97,7 @@ The topics below cover information about how we define, operate, and upkeep this
   * [Meetings](meta/meetings.md) - Become involved with the people and communications of the Inner Source Patterns group
 
 # Related References
+
 * [A pattern language for pattern writing](http://hillside.net/index.php/a-pattern-language-for-pattern-writing), Meszaros and Doble
 
 # Licensing

bad-weather-for-liftoff.md

@@ -0,0 +1,52 @@
+## Title
+
+Bad weather for liftoff
+
+## Patlet
+
+TBD
+
+## Problem
+
+- The team is not able to demonstrate any increases in quality or speed, because they did not adopt any of the principles of OSS development.
+- As a result, the InnerSource approach is discredited.
+
+## Context
+
+- Company A would like to start an InnerSource initiative in order to increase development speed and quality of software artifacts.
+- There are not many developers in company A, which are experienced in OSS development practices.
+- The company was not able to contract or hire an experienced InnerSourcerer.
+- Company A has put together a small team of software developers to work on a single project InnerSource style. The project has tight deadlines to meet.
+
+## Forces
+
+- By default, humans will be resistant to change if they have no compelling reason to change.
+- Pressure (in this case induced by the project being a pilot and also induced by the deadline) reduces the ability to change and explore new ways of working.
+- There is a natural tendency to pick low hanging fruits (e. g. tooling) and stop there.
+- For InnerSource to blossom, a critical mass of experienced developers which can walk the talk is required.
+
+## Sketch (optional)
+
+## Solution
+
+TBD
+
+## Resulting Context
+
+## Rationale (optional)
+
+## Known Instances (optional)
+
+## Status
+
+Donut
+
+## Author(s)  
+
+* Georg Grütter, Wyane DuPont, Michael Dorner
+
+## See Also
+
+This pattern was originally created in this wiki and then ported here.
+Original wiki page:
+https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Bad-weather-for-liftoff

change-the-developers-mindset.md

@@ -0,0 +1,64 @@
+## Title
+
+Change the developers mindset
+
+## Patlet
+
+TBD
+
+## Problem  
+
+* Change developer mindset, it's difficult to push developers to do things.
+* Developers are resisting the change, they are in their comfort zone and it's hard to go out.
+* Developer organizations maturity is high, so people are used to being in some hierarchy/rules
+* Developers are formed in agile, the shift from agile is difficult
+
+## Context
+
+* Top-down inner source support
+* 3k population of developers
+* Middle Management  is not supporting inner source
+* There's already a successful group in the early stages
+* Code visibility is product dependent
+
+## Forces  
+
+* Manager are previous developers, so they like the way they were promoted and they want to proceed in similar ways
+* Manager restrict where developers can spend time on
+* Top-down approach to the inner source
+* Different teams within the company have to decide to proceed with inner source
+* No formal training
+* Processes are not clear
+
+## Sketch (optional)
+
+## Solution  
+
+* Showing reward/recognition of the developer team
+* Formalize training
+* Clarify more processes
+* Give middle management specific objectives to make inner source successful
+* Listen to manager complaints and fears and count on them
+
+## Resulting Context
+
+* Use of the several projects across the several development teams
+* Collaboration within the same developer team (mentorship and so on)
+
+## Rationale (optional)
+
+## Known Instances (optional)
+
+## Status
+
+Unproven
+
+Old status: Pattern Idea
+
+## See Also
+
+This pattern has been moved for discussion at https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/39
+
+This pattern was originally created in this wiki and then ported here.
+Original wiki page:
+https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-change-the-developers-mindset

defeat-hierarchical-constraints.md

@@ -0,0 +1,41 @@
+## Title
+
+Defeat Hierarchical Constraints
+
+## Patlet
+
+TBD
+
+## Problem
+
+Corporate culture constrains people to hierarchical goals.  
+
+## Context
+
+In strongly hierarchical organizations, developers want to please their managers. Their managers may not support their people spending time on inner sourcing even if someone higher up does. In some countries, there is a strong cultural force to respect and obey authority.  
+
+## Forces
+
+To make inner sourcing work, you need to allow some developers outside your org to participate in your development.
+Managers have deadlines and they don’t see how having their people will help them achieve *their* goals and objectives. They may feel it slows them down.
+Even if there is nominal higher support for the goals, developers may still feel afraid to take that step.  
+
+## Solutions
+
+TBD
+
+## Resulting Context
+
+Developers feel empowered to spend at least 20% of their time on inner sourcing  
+
+## Status
+
+Donut
+
+## Author(s)
+
+## See Also
+
+This pattern was originally created in this wiki and then ported here.
+Original wiki page:
+https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-3%3A-how-to-defeat-the-hierarchical-constraints

developer-incentive-alignment-for-innersource-contribution.md

@@ -0,0 +1,84 @@
+## Title
+
+Developer Incentive Alignment for InnerSource Contribution
+
+## Patlet
+
+TBD
+
+## Problem
+
+* The organization needs to adopt a more collaborative, open-source like workstyle, but its developers are not properly incentivized or extrinsically motivated to participate in the company’s InnerSource processes.
+* There is a prevailing attitude in the developer culture that helping or contributing to others' success and learning is a “time sink” or "not my job."
+* Credit and kudos are not consistently shared with developers who help or contribute to others' success.
+* Prevailing developer culture is such that many believe the way up the organizational ladder - via increases in title or compensation - depends on one’s performance on quantitative metrics such as lines of code output, deadlines met, ownership of product releases or updates, and so forth.  
+* Developers aren’t moving up the ‘organizational ladder’ because it is perceived as a path toward people management and direct reports, rather than a path of deepened respect or capabilities in engineering.
+
+## Context  
+
+* There is a need to foster team-centric behaviour and limit instances of [ego-driven development](http://deliberate-software.com/ego-driven-development/) or idolizing a 'star developer.'
+* There are multiple developers within the organization or business unit with the same or related areas of expertise, such as front-end development, devops, testing, etc.
+* Mid-to-top level management either do not have a technical background or their technical backgrounds and experiences are many years out of date; organizational emphasis is therefore on quantitative output of development team.
+* The organization wants to create more alignment between work efforts and external motivation without relying directly on financial rewards or quotas.  
+* The organization is comfortable with a personnel management and/or professional development style that is organic or “bottom-up” as opposed to traditional training or development programs run through HR (even as task management or velocity is managed in a more top-down fashion).
+
+## Forces   
+
+1. Existing attitudes and developer culture
+ * Team-centric behaviour is not evident. Developers of all levels tend to focus mostly on their own contributions. When stories are assigned, work is often done ‘locally’ and not pushed up or checked in until the end of the sprint.
+ * Asking developers to push code early and often is met with extreme resistance, accusations of micro-management, or claims that such a practice would slow velocity.
+ * Existing practice commonly leads to duplicated work, missed requirements, or frequent gaps in the software or process.
+
+2. Need to retain developer talent
+ * Managers focus heavily on tasks or velocity for developers rather than providing mentorship. Developers view helping or mentoring others as the job of Management, or something “I don’t get paid to do.” Career progression, or other ‘upward mobility paths’ (to receive a raise, for example) are not clearly identified in the organization.
+ * Existing job descriptions, promotion tracks or compensation bands are opaque or hard to get from the organization’s HR department, resulting in a mixed understanding of job responsibilities. This puts additional pressure on performance review or improvement plans because HR, developers and managers don’t have shared a shared understanding of roles or expectations.
+ * 'Home growing' developer talent - encouraging career growth within the company - is far cheaper for organizations in the long run than hiring from outside. Studies show employee retention increases as new opportunities, challenges, and paths for learning are introduced.
+
+3. Maintaining the product development lifecycle
+ * Keeping the status quo is encouraged or reinforced with existing product/project management processes and expectations. Developers and managers are reticent to make changes for fear of putting deadlines or product/business unit goals at risk (note that these often have financial implications for the company and individual). Working on one’s own individual contributions is seen as doing one’s part to protect this lifecycle; efforts outside one’s own individual contributions is seen as disruptive.
+ * Product/Business unit pressures
+ * HR - existing resource allocation plans & patterns
+
+## Sketch (optional)  
+
+![Table of roles goes here]
+![or maybe the pyramid]
+
+## Solution  
+
+***Resolution to the problem***
+
+* Job Descriptions/Roles on the engineering title ladder are allocated mentorship and "Open Source Time" as fits their level (i.e. 0% expectation for jrs, 100% expectation for Principals)
+* Moving up the ladder requires taking on more responsibility for mentoring, reviewing code, and bringing in contributions
+* Developers may choose not to move up the ladder because of a preference for certain types of contributions ("I like just writing code" vs "I want to have a bigger impact on the team")
+* relevant Skills & experience are associated with advancing titles/roles - Moving up the ladder also requires developing the social skills necessary for mentorship
+* Job Descriptions/Roles can be easily associated/assimilated into employee review systems or other HR programs (comp/bonus structures, etc)     
+
+## Resulting Context    
+
+* culture has been shifted from contribution culture to learning culture
+* devs & pms believe time spent mentoring and reviewing is equally, if not more so, valuable to time spent coding
+* job descriptions include mentorship & contribution language to set expectations up front & make it easier to assess if candidates have requisite skills/experience required
+* org is retaining and better utilizing existing talent
+* devs take on professional mentorship responsibilities for their peers rather than leaving it to non-technical management
+* career progression clearly identified & understood by engs and management
+
+## Rationale (optional)  
+
+## Known Instances (optional)  
+
+## Status  
+
+Unproven
+
+Old status: brainstormed solution
+
+## Author   
+
+Jory Burson
+
+## See Also
+
+This pattern was originally created in this wiki and then ported here.
+Original wiki page:
+https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Creating-Developer-Incentive-Alignment-for-InnerSource-Contribution

organizational-mindset-change.md

@@ -0,0 +1,43 @@
+## Title
+
+Organizational Mindset Change
+
+## Patlet
+
+TBD
+
+## Problem
+
+How do you effect an organizational mindset change to support inner sourcing?  
+
+## Context
+
+Upper management, middle management and developers are not convinced to fully support inner sourcing. They are used to doing software development in the old way.  
+
+## Forces
+
+Changing an organizational mindset takes time and effort, which most organizations (feel they) cannot afford.
+Inner sourcing could bring about a lot of desirable benefits, but it takes time to ramp up to deliver them.
+Changing executive mindsets usually requires hype which then is hard deliver on.
+KPIs to prove the benefits are often required early but choosing the wrong KPIs can severely warp the program.
+Pressure from competitors and the market place makes management less willing to try significant change (deemed too risky).  
+
+## Solutions
+
+TBD
+
+## Resulting Context
+
+All of the company heartily adopts inner sourcing! Cake for everyone!  
+
+## Status
+
+Donut
+
+## Author(s)  
+
+## See Also
+
+This pattern was originally created in this wiki and then ported here.
+Original wiki page:
+https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-6:-organizational-mindset-change