contributing new feature owner pattern to innersourcecommons patterns

Signed-off-by: Gawande, Manoj <[email protected]>

Author: magawande

README.md

@@ -38,6 +38,7 @@ Our mission
 * [Common Requirements](patterns/2-structured/common-requirements.md) - *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.*
 * [Contracted Contributor](patterns/2-structured/contracted-contributor.md) - *Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.*
 * [Dedicated Community Leader](patterns/2-structured/dedicated-community-leader.md) - *Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.*
+* [Feature Owners](patterns/2-structured/feature-owners.md) - *This pattern is for scaling inner source project contributions and for aspirant associates who are looking for more accountability, develop their soft skills and be successful at work.*
 * [Gig Marketplace](patterns/2-structured/gig-marketplace.md) - *Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.*
 * [Maturity Model](patterns/2-structured/maturity-model.md) - *Teams have started adopting InnerSource. The practice is spreading to multiple departments. Understanding of what constitutes an InnerSource project are wide spread though. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.*
 * [InnerSource License](patterns/2-structured/innersource-license.md) - *Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An InnerSource License provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit.*

assets/img/feature-owner.png

@@ -0,0 +1,75 @@
+## Title
+
+Feature Owners
+
+## Patlet
+
+This pattern is for scaling inner source project contributions aligned with business initiatives and for aspirant associates who are looking for stretch assignments, more accountability, develop their soft skills and be successful at work.
+
+## Problem
+
+Contributions in innersource projects mostly are all volunteer based. Below are the challenges we see in day-to-day life:
+- How to increase more contributions in the project.
+- How to create opportunities for associates who want to play more than an individual contributor role and are looking for:
+    - Elevating leadership skills.
+    - More visibility at work.
+    - More accountability.
+    - Developing their soft skills. 
+    - Motivations and inspiring others. 
+
+## Story
+
+A single project which is on high demand and consumption is increasing every month. We need to expand the contributions and add new functionalities. But associates have a concern on how they can play more than an individual contributor role and which will motivate them to contribute more.
+
+## Context
+
+Business & [Community leader](patterns/2-structured/core-team.md) looking for scaling inner source contributions and to drive engaging associate experiences by maximizing their development and growth. 
+
+
+
+## Forces
+
+- [Community core team](patterns/2-structured/dedicated-community-leader.md) is composed of small number of people. They have core responsibilities and are not always available for guidance.
+- As project grows, we need more subject matter experts in the space to scale the development and maintain the project.
+
+
+## Solution
+
+Define all the features needed in the project. Per definition, <em>"A feature is the product's service/function that provides business value, meets customer needs and must be able to be done in 2-3 months".</em> 
+
+Invite all contributors for open participation. Empower associates to pick the features which they would be interested in and become feature owners. There can be more than one owner for any given feature.
+
+Feature owners responsibilities:
+- Analyze the work. 
+- Complete the end to end development.
+- Document & provide guidelines.
+- Educate community core team & community members.
+- Demo the feature work at the appropriate venues.
+- Support feature critical issues. Refer [30-day-warranty Pattern]((patterns/2-structured/30-day-warranty.md)).
+- Maintain feature work based on bandwidth OR find additional feature owners.
+- Review contributions to the feature.
+- Become SMEs on that feature.
+
+
+![Feature Owner Responsibilities](../../assets/img/feature-owner.PNG)
+
+
+
+<!-- ![30 Day Warranty](../../assets/img/thirtydaywarranty.jpg) -->
+
+
+## Authors
+
+- Manoj Gawande
+
+## Acknowledgement
+
+- Dinesh Ramadoss
+- Amit Chauhan
+- Adrian Prezioso
+
+## Status
+
+* Structured
+
+