Renaming file to .md + Fixing some spacing

Author: spier

…itial/innersource-contractor-model-terms …al/innersource-contractor-model-terms.mdpatterns/1-initial/innersource-contractor-model-terms renamed to patterns/1-initial/innersource-contractor-model-terms.md patterns/1-initial/innersource-contractor-model-terms renamed to patterns/1-initial/innersource-contractor-model-terms.md

@@ -1,37 +1,47 @@
 ## Title
+
 InnerSource Contractor Model Terms
 
 ## Patlet
+
 Contract developers are often not motivated to engage in InnerSource activities. This patlet includes some terms which could be included in their initial contract to ensure engagement in the InnerSource process.
 
 ## Problem
+
 Contractor developers are often not motivated (through forces described below) to not engage in InnerSource activities. Once delivered, and even if the code is made visible, their projects are often less likely to be part of successful InnerSourced engagements.
 
 ## Context
+
 This problem exists where an organization either:
+
 - Out-sources the development of a well defined project or 
 - Engagages external firms for staff augmentation and has mixed teams of permanent employees with a large percentage of contract staff. 
 
 ## Forces
-Contractor Motivation and Constraints:- 
+
+Contractor Motivation and Constraints: 
+
 - Often contracts with third party developers are very focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third party PRs) are considered to be distractions or something that will “slow down” ultimate delivery. 
 - There is also often a concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team.
 - Above and beyond the idea that InnerSource may slow down the project, there is often an additional concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. 
 
 All of the above can mean that even if an individual contract developer wants to engage in InnerSource, there may be system-level constraints pushing them not to.
 
 It should be noted that the above scenario is indirectly impacted by:
+
 - The norms around defining Statements of Work for third party contractors
 - Pressures to reduce contractor costs during procurement
 - Ability to tie contributions to payment at a granular level. 
 
 It could also be noted that the Contractor's motivations in this instance is almost like a more extreme instance of the oft-reported organizational/budgetary constraints that might exist for some internal business units. (Not sure if this is relevant, but it does seem to be an extreme case of what is reported as common objections even in internal teams). 
 
 ## Solutions
+
 At the outset of any new project, ensure terms of the contract and Statement of Work reference InnerSource goals and the expected roles that can be played by individual contractors. 
 
 Specific examples include:
-- Role Definitions :- At the beginning of every project, contractors are explicitly assigned roles such as Admin, Contributor, Reader or InnerSource roles such Trusted Committer / Contributor.
+
+- Role Definitions:- At the beginning of every project, contractors are explicitly assigned roles such as Admin, Contributor, Reader or InnerSource roles such Trusted Committer / Contributor.
 - Specific InnerSource Goals and/or time to be allocated to InnerSource initiative:- e.g. Allocated time to reviewing PRs from outside the team; response time goals to respond to PRs from others. 
 - Specific guidelines on decision-making processes to decide how SOW may change as a result of PRs that come during the implementation of the project.
 
@@ -40,19 +50,24 @@ Specific examples include:
 Implicit in these new terms is a move away from a rigid SOW with a hard deadline and set of deliverables. 
 
 ## Resulting Context
+
 This patlet can help re-define standard contract terms with software development vendors. When implemented, it gives individual contractors permission and guarantees reward for engaging in the InnerSource process. 
 The end result should also be more sustainable code for the contracting organization. 
 
 ## Known Instances (optional)
+
 Some community participants have seen this approach work with their clients. Derek Murawsky  can add details as appropriate.
 
 ## Status (optional until merging)
+
 TBD
 
 ## Author(s) (optional)
+
 Clare Dillon (v.0 assuming others will add themselves in this section as we flesh it out).
 
 ## Acknowledgements (optional)
+
 Particular thanks to Gil Yehuda for raising the issue  in the InnerSource Slack channel and Derek Murawsky for sharing his approach.
 
 This pattern was extracted from a conversation on the topic held with the following folks: