Add new pattern for Release Process/Published Artifacts

README.md

@@ -77,6 +77,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Share Your Code to Get More Done - Likely Contributors Variant](patterns/1-initial/share-your-code-to-get-more-done.md)
 * [Code Consumers](patterns/1-initial/code-consumers.md)
 * [Explaining InnerSource to Management by anchoring it to Agile / DevOps / Lean](patterns/1-initial/concept-anchor.md)
+* [Standarized Release Process](patterns/1-initial/release-process.md) - *Teams may be reluctant to use InnerSource projects that they are unfamiliar with when there is no clear release process apparent in the repository. Providing clear release notes and a published artifact (binary, docker image, jar, etc) gives people confidence you are publishing a quality product.*
 
 #### Donuts (needing a solution)
 

patterns/1-initial/release-process.md

@@ -0,0 +1,51 @@
+## Title
+
+Standard Release Process and Published Artifacts
+
+## Patlet
+
+Teams may be reluctant to use InnerSource projects that they are unfamiliar with when there is no clear release process apparent in the repository.
+Providing clear release notes and a published artifact (binary, docker image, jar, etc) gives people confidence you are publishing a quality product.
+
+## Problem
+
+When a team is deciding whether or not to use an InnerSource projects, one of their considerations is whether they trust that they can rely on the given project for an extended period. Switching the tools/projects that they are using has a cost, so they only want to make those investments sporadically.
+
+It reduces trust if the given InnerSource projects doesn't have a published artifact or publicly viewable release process, as the team won't know when they can expect new features or the next release, how breaking changes are handled, etc.
+
+## Context
+
+It is common practice in Open Source projects to have releases, with release notes documenting breaking changes,
+new features, etc along with either a published binary or link to a Docker image. This practice may not be as
+transparent or well documented/visible for InnerSource projects, modules, etc. Providing robust release notes
+along with a published artifact that is the result of a clearly documented and visible release process builds trust and confidence in your project.
+
+## Forces
+
+- Difficult for organizations that don't have a central CI/CD system
+- Adds the burden of publishing release notes
+- Becomes more difficult if the organization does not provide an internal location to host artifacts
+
+## Solution
+
+- CI/Delivery Pipeline is located within your repo to build artifacts (binary, docker image, jar, etc)
+- Releases and accompanying build artifacts are generated by CI system at build time
+- Release includes notes on New Features, Bug Fixes, and any "Breaking Changes" specifically called out
+
+A good example of quality Release notes can be found [here](https://github.com/jaegertracing/jaeger/releases)
+
+## Resulting Context
+
+Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
+
+## Known Instances
+
+Comcast
+
+## Authors
+
+David Grizzanti
+
+## Status
+
+**Initial** - FYI we are considering splitting "Published Artifacts" into its own pattern