Browse files

Added three new patterns to the README

Added Gig Marketplace, Trusted Committer and InnerSource Portal
  • Loading branch information...
NewMexicoKid committed Sep 14, 2018
1 parent fd71571 commit 95ad8b50a35d940f768728b2bab6b86e04fb80f4
Showing with 3 additions and 0 deletions.
  1. +3 −0
@@ -11,10 +11,13 @@ The below lists all known patterns. They are grouped into four stages of maturit
* [Common Requirements]( - *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]( - *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]( - *Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.*
* [Gig Marketplace]( - *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.*
* [InnerSource Portal]( - *Create an intranet website that indexes all available InnerSource project information. This will enable potential contributors to more easily learn about projects that might interest them and for InnerSource project owners to attract an outside audience.*
* [Praise Participants]( - *Thank contributors effectively to engender further engagement from them and to encourage others to contribute*
* [Review Committee]( - *A formal review committee is setup within an org to "officiate" particular inner source projects with resources, etc.*
* [Service vs. library: It's inner source, not inner deployment]( - *Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's
possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.*
* [Trusted Committer]( - *Many inner-source projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.*
#### Reviewed Pattern Ideas (not yet proven but reviewed)

0 comments on commit 95ad8b5

Please sign in to comment.