Adding pattern as outlined in gdoc. minor formatting fixes

Author: spier

patterns/1-initial/reluctance-to-accept-contributions.md

@@ -0,0 +1,58 @@
+## Title
+
+Reluctance to accept contributions
+
+## Problem
+
+The core team that owns a shared asset is reluctant to adopt contributions of contributing business divisions, because this implies adoption of the maintenance responsibility for the contributed software as well, a burden the core team does not want to adopt.
+
+## Context
+
+An organizational unit (e.g. a business division or development team) is using an inner source product (a ‘shared asset’), and finds it is missing a certain feature that they need and would like to integrate into the shared asset. The core team that owns the shared asset is responsible for its design and maintenance. The potentially contributing organizational unit has no champion on the core team. 
+
+## Forces
+
+* The core team is responsible for maintenance, and therefore accepting contributions implies accepting the maintenance burden of new contributions. The core team is reluctant to take on this burden.
+* The unit that uses the asset requires the feature to be implemented for their product, but it is not clear where or how the feature “fits”--and thus they have difficulty implementing it because they lack knowledge of the shared asset.
+* Contributors that are not part of the core team do not have the same knowledge as the core team has about the shared asset.
+* The core team is offered a contribution that doesn’t fit with their vision of the shared asset--the contributor doesn’t understand all the intricacies that the core team needs to consider.
+* Contributions are not suitable for the core team to handle, either because of quality problems (e.g. lack of architectural compliance) or that the contribution is too large--the contributor isn’t aware of how to contribute.
+
+## Solution
+
+Define a clear contribution process for potential contributors.
+
+* Implement a “support warranty” of limited time duration (e.g. 30 days) during which the contributor fixes any issues that the core team finds.
+* Define clear contribution guidelines that define a set of expectations of contributions.
+* Define a contribution workflow that describes submission, review, and acceptance steps, and which specifies how contributions can be tested.
+* Provide training through tutorials, documentation, and one-on-one guidance.
+
+## Resulting Context
+
+Potential contributors have clear guidance available and process to follow so they know what to consider when preparing contributions. The core team is better able to handle incoming contributions.
+
+## See Also
+
+Support Warranty, Negotiate Contributions, Architecture for Participation, Feature Advocate (Note: these patterns are currently under construction)
+
+## Known Instances
+
+Philips Healthcare, “Feature Advocate” described in: VK Gurbani et al. (2010) Managing a corporate open source software asset, Communications of the ACM vol. 53(2)
+
+## Status
+
+11 Oct 2016 - First draft
+13 Apr - Reviewed & Revised
+
+## Author
+
+Klaas-Jan Stol
+
+## Acknowledgments
+
+* Georg Grütter
+* Bob Hanmer
+* Udo Preiss
+* Padma Sudarsan
+* Tim Yao
+* Nick Yeates