[WIP] porting a first set of wiki pages to .md files

30-day-warranty.md

@@ -15,27 +15,27 @@ A team develops a component which is used throughout an organization.  This team
 # Forces
 
 - There is distrust of contributions due to a past history of cheating: teams
-  submitted half finished contributions and subsequently filed requests for 
+  submitted half finished contributions and subsequently filed requests for
   fixes that make it ready for use in production.
-- If code is contributed from outside the team, the team has the natural 
+- If code is contributed from outside the team, the team has the natural
   suspicion that the other team does not know how to write code that would
   meet the teams expectations.
-- Each team looks first to help its own leaders achieve their own goals. This direction 
+- Each team looks first to help its own leaders achieve their own goals. This direction
   of loyalty can complicate resolution of this problem.
 - There is a natural aversion to taking responsibility for code not written
   by oneself.
 - Contributed needs to be heavily rewritten before being accepted into the
   codebase.
 - There is the fear of the contributors not being available for support with
   fixing bugs after the time on contribution.
-- Teams fear contributed code will lead to high(er) maintenance costs but do 
+- Teams fear contributed code will lead to high(er) maintenance costs but do
   not know how to control for that.
-- Receiving teams may fear that teaching others how to contribute code will 
+- Receiving teams may fear that teaching others how to contribute code will
   expose technical debt in their system and that visibility may be damaging.
-- Receiving teams may not believe that they will get acceptable code no 
+- Receiving teams may not believe that they will get acceptable code no
   matter how much mentoring they provide.
-- Either team may not feel confident in measuring risks or certifying that 
-  they are mitigated in a contribution; the system itself is somewhat brittle 
+- Either team may not feel confident in measuring risks or certifying that
+  they are mitigated in a contribution; the system itself is somewhat brittle
   (may not be ways to fully test and catch all problems).
 
 # Solution
@@ -70,7 +70,9 @@ This was tried and proven successful at PayPal.
 - Klaas-Jan Stol
 - Georg Grütter
 
-# State
+# Status
+
+Proven
 
 Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
 

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,10 +41,10 @@ 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](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/61)
-* [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)
 
 #### Pattern Donuts (needing a solution)
 
@@ -76,7 +76,7 @@ The pattern form is useful for describing proven patterns but it can also be use
 
 [See our CONTRIBUTING.md for details on getting involved](CONTRIBUTING.md)
 
-We encourage beginners seeking answers to jump in by creating ''donuts'' (problems without solutions). We encourage experts to pad their experience - these are hoped to become part of a book one day. Anyone can offer reviews and comments for [in-progress patterns](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls). 
+We encourage beginners seeking answers to jump in by creating ''donuts'' (problems without solutions). We encourage experts to pad their experience - these are hoped to become part of a book one day. Anyone can offer reviews and comments for [in-progress patterns](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls).
 
 We work together via Github, Webex, Slack, etc. Do not hesitate to join the [#innersourcecommons](https://isc-inviter.herokuapp.com/) or #innersource-patterns slack channels and ask to be included in the [patterns meetings](/meta/meetings.md) (there is an email list).
 
@@ -102,4 +102,3 @@ The topics below cover information about how we define, operate, and upkeep this
 ![Creative Commons License](https://i.creativecommons.org/l/by-sa/4.0/88x31.png)
 
 InnerSourcePatterns by [InnerSourceCommons.org](http://innersourcecommons.org) is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/) License.
-

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

common-requirements.md

@@ -1,22 +1,22 @@
 ## Title
 Common Requirements
 
-## Context
-Many projects are trying to use common code.  There is a shared repository that all the projects access.  This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects.  Each project has its own delivery schedule, set of deliverables and customers.
-
 ## Patlet
 Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.
 
-## Problem Statement
+## Problem
 The common code in the shared repository isn't meeting the needs of all the projects that want to use it.  
 
+## Context
+Many projects are trying to use common code.  There is a shared repository that all the projects access.  This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects.  Each project has its own delivery schedule, set of deliverables and customers.
+
 ## Forces
-The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same. 
+The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same.
 Requirements on code should be derivable from real customer needs.  
 
 The needs of different customers are generally quite similar; however they might be expressed differently or weighted differently between customers. An example might be how some customers want some result presented in one way while others want it presented in the reverse order---it's simple to do the translation between them, but requires additional coding for one of the cases and the as a result the module that computes the result can't be reused by both customers.
 
-Many customers want the supplier to help them know what they need. The company has many “Systems Engineers” writing requirements for the products.  These requirements are supposed to be a distillation of customer needs to guide development of the product. 
+Many customers want the supplier to help them know what they need. The company has many “Systems Engineers” writing requirements for the products.  These requirements are supposed to be a distillation of customer needs to guide development of the product.
 Reusing code is an important goal to save the company time and money.  
 
 ## Solution
@@ -38,8 +38,8 @@ The developers write a story to solve a problem in one way.
 
 The program managers rewrite the story to better express their needs---keeping the essence the same. By the time it returns to developers though they don't recognize it as what they wanted to do in the first place and so balk at implementing it.  The solution to this pattern is to have more seats around the planning table so that story modifications are understood across the project not just in the developer or program manager camps.
 
+## Status
+Proven
+
 ## Author
 Robert Hanmer, 22 Aug 2016, 20 Sept 2016  
-
-## Status
-Shepherded pattern

contracted-contributor.md

@@ -1,10 +1,19 @@
 ## Title
 
-_Contracted Contributor_ 
+_Contracted Contributor_
 
 ## Patlet
 Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.
 
+## Problem
+
+Without support by middle management, the total number of contributors and, as
+a result, the amount of contributions made and value generated by the
+InnerSource initiative will likely fall below expectation of top level
+management. This will likely be amplified if there is no adequate funding for
+and empowerment of [Dedicated Community Leaders](dedicated-community-leader.md).
+This runs the risk of top level management abandoning the InnerSource idea.
+
 ## Context
 
 A large corporation has started an InnerSource initiative. Major goals for the
@@ -31,15 +40,6 @@ line managers usually do not have targets outside of their own organisation.
 Contributions to InnerSource projects are expected to be made during working
 hours, not during free time.
 
-## Problem
-
-Without support by middle management, the total number of contributors and, as
-a result, the amount of contributions made and value generated by the
-InnerSource initiative will likely fall below expectation of top level
-management. This will likely be amplified if there is no adequate funding for
-and empowerment of [Dedicated Community Leaders](dedicated-community-leader.md).
-This runs the risk of top level management abandoning the InnerSource idea.
-
 ## Forces
 
 - Managers are held responsible for the results of their business units.
@@ -49,32 +49,32 @@ This runs the risk of top level management abandoning the InnerSource idea.
   managers to reach or exceed their goals.
 - Line managers and HR will, by default, judge the performance of their
   subordinates against their business units goals, which might not be aligned
-  with the goals of the InnerSource community. 
+  with the goals of the InnerSource community.
 - The less executive air cover a line manager perceives he has, the less likely
   is he or she to have his or her staff participate in InnerSource activities
   which contribute to another business unit.
 - The less transparency and control a line manager has of work done by one of
-  her subordinates, the less likely is she to allow her to contribute. 
+  her subordinates, the less likely is she to allow her to contribute.
 - The less formally work in InnerSource is managed and organised, the less
   likely a line manager who is accustomed to formal processes is to sign off on
   one of her employees contributing to InnerSource.
 - The more time an associate spends on contributions to an InnerSource project
   which does not benefit his day-to-day work, the more will the workload for
   his teammates in his business unit increase.
 - Individual contributors will likely consider participating in InnerSource
-  as an opportunity to enhance their professional netowrk within the company 
-  and to gain knowledege and experience in the technical area of her 
+  as an opportunity to enhance their professional netowrk within the company
+  and to gain knowledege and experience in the technical area of her
   contributions.
 
 ## Solution
 
 Set up a formal contracting between the contributor, their line manager and a
 centrally funded and steered InnerSource governance office (ISGO). Have the
 ISGO reimburse business units who contracted contributors for the contracted
-time. 
+time.
 
 - The contracting specifies a maximum percentage of the associates work time in
-  InnerSource. 
+  InnerSource.
 - The contracting clearly states that work in the contributor's business unit
   takes precendence over work in InnerSource.
 - The contracting states that it is not required to work in InnerSource for the
@@ -94,14 +94,14 @@ time.
 ## Resulting Context
 
 A formal contracting and centrally funded reimbursements convincingly
-communicating the organizations support for the InnerSource initiative, thus 
+communicating the organizations support for the InnerSource initiative, thus
 empowering middle management to sign off on it:
 
 - Allocation of corporate funds to business units for reimbursement of
   development capacity signals to line managers that InnerSource is deemed
   valuable by the organization, that it has executive air cover and that they
   are expected to support it, too.
-- A formal contracting signals that work in InnerSource is managed 
+- A formal contracting signals that work in InnerSource is managed
   professionally and inspires trust.
 - A formal contracting increases transparency and provides a better overview
   about the associate's available capacity for his business unit and
@@ -118,11 +118,11 @@ A formal contracting is also beneficial for contributors and communities:
 
 ## Known Instances
 
-- _BIOS at Robert Bosch GmbH_. 
+- _BIOS at Robert Bosch GmbH_.
 
 ## Status
 
-_Proven Pattern_
+Proven
 
 ## Author