Updated patterns in block "Reviewed Pattern Ideas (not yet proven but reviewed)"

=> Maturity: Unproven

Author: spier

improve-findability.md

@@ -1,43 +1,47 @@
 ## Title
 
-Improve Findability 
+Improve Findability
 
 ## Also Known As
 
 - Badly Named Piles
 - Poor Naming Conventions
 
-## Context
+## Patlet
 
-Reusable software component(s) are available internally but users can't easily find them.
-This problem is more likely to occur in large, federated companies where different organizational units operate as silos.
-Historically, the company does not have a culture of sharing code across silos.
+TBD
 
 ## Problem
 
 People can't find the internally developed solutions that they need due to poor naming conventions.
 
+## Context
+
+Reusable software component(s) are available internally but users can't easily find them.
+This problem is more likely to occur in large, federated companies where different organizational units operate as silos.
+Historically, the company does not have a culture of sharing code across silos.
+
 ## Forces
 
 - The volume of contributions to inner source is impacting the ability to find components.
 - The internal search engine is not robust, or is not connected to git repositories (it can be difficult to make this change happen)
 - Cryptic naming conventions for projects and lack of keywords contribute to reduced findability.
 - People may lose confidence in the integrity of inner source and become discouraged from engaging when they search and don't find what they need.
 
-
 ## Solution
+
 To help improve findability for inner source projects:
 - Provide guidelines for applying clear, meaningful naming conventions to projects, and reinforce the importance of avoiding cryptic code names.
 - Include keywords in project descriptions.
 - Apply tagging to repositories (validated).
 - Use labels where possible.
 - If possible, pull repository names, descriptions, and README.md files into the search engine (not the code itself).
-- Instate a concierge service (guide) to help product people find stuff. (This approach might not scale, but could be helpful at the beginning of a program.) 
-
+- Instate a concierge service (guide) to help product people find stuff. (This approach might not scale, but could be helpful at the beginning of a program.)
 
 <img alt="Poor naming conventions" src="/assets/img/poornamingconventions.jpg" width="70%">
 
-## Known instances
+## Known Instances
+
 None known as of yet---this is a pattern idea until it is proven.
 
 ## Desired Resulting Context
@@ -52,6 +56,8 @@ None known as of yet---this is a pattern idea until it is proven.
 
 ## Status
 
+Unproven
+
 Brainstormed pattern idea reviewed 2017-03-11.
 
 ## Authors
@@ -61,4 +67,3 @@ Brainstormed pattern idea reviewed 2017-03-11.
 - Erin Bank (CA Technologies)
 - Padma Sudarsan (Nokia)
 - Tim Yao (Nokia)
-

modular-code.md

@@ -1,32 +1,42 @@
-**Title:** Modular Code
+## Title
+
+Modular Code
+
+## Patlet
+
+TBD
+
+## Problem
 
-**Statement of Problem:** 
 Development does not want to spend the extra resources needed to develop modular components. As a result, shared components are not reused.  
 
-**Context:** 
+## Context
+
 * There is no corporate mandate for modularized code.
-* This is a new product/new code, not a legacy product/code. 
+* This is a new product/new code, not a legacy product/code.
 * There is an available repository for sharing code.
 * Making code modular takes extra effort and time to develop.
 * Time commitments might already have been made for customer deliveries (not changeable).
 
-**Forces:**
+## Forces
+
 * There is a learning curve to writing code that can be reused.
 * Extra documentation is required for reusable code.
 * Some companies have a common components group that develops reusable code, but others feel that such components should be developed by those business lines that are using the components and a library of common components could be established.
-* Developers might not know how to write modular code. Education might be needed. 
+* Developers might not know how to write modular code. Education might be needed.
 * Might be a fear that if not done properly, quality might be impacted.
 * Developers might not have incentive to write modular code (due to their tight schedules and lack of a mandate).
 * You might be dealing with legacy systems (can't be simply refactored or rewritten).
 * Requirements might be different for writing modular code.
 * Architectural constraints might impact modularity.
 * Developers who develop monolithic code bases might lack the perspective of how modularity might improve how they work.
 
-**Resolution:** 
+## Solutions
+
 * Provide incentives to teams to invest in modular code. Modular code is far more reusable. This could work well for large teams when working on modularized projects; team members can focus on their smaller assigned tasks.
     - Developers could get an opportunity to increase their influence in the organization.
 * Select certain "success projects," teams that will develop reusable code and demonstrate the long term success. This can help motivate others (they see what is possible and what is in it for them). Transparency is critical.
-* Offer education. Modular code is well-understood; there is a lot of literature in favor of this. 
+* Offer education. Modular code is well-understood; there is a lot of literature in favor of this.
 * Accept the cost of modularization, build time into the release schedule.
 * Companies moving to use more open source code will appreciate modularity more over time.
 * Modular code is easier to work with, especially for larger teams.
@@ -35,12 +45,12 @@ Development does not want to spend the extra resources needed to develop modular
     - There could be requirements on tests, tools and documentation before considering a component as reusable
 * Establish standards on testing methodology, labeling of repos.
 
-**Resulting Context:** 
-Time is spent making the shared code modular so it can be reused.  
+## Resulting Context
 
-**Author:**  
+Time is spent making the shared code modular so it can be reused.  
 
-**Status:** 
-Donut
+## Status
 
+Unproven
 
+## Author