Skip to content

Cleanup for explicit-innersource-principles pattern #333

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 30, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -69,6 +69,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
* [Unified Source Code Inventory](patterns/1-initial/source-code-inventory.md) - *In a large organization with different legal entities is often hard to get full visibility into all software assets, in particular all source code. This situation reduces the opportunities to increase business value and keep liability costs, such as software maintenance, under control across the organization as a whole. An organization-level source code inventory addresses these issues while exploiting opportunities to identify and support valuable InnerSource assets.*
* [Explicit Shared Ownership](patterns/1-initial/explicit-shared-ownership.md) - *A software component that several teams depend on has grown to the point where owners are no longer capable of taking full ownership. There is confusion who to involve for changes. Sharing ownership explicitly and making expected behaviour visible removes ambiguity. Writing a contributions document creates a natural way to evolve ownership.*
* [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.*
* [Explicit InnerSource Principles](patterns/1-initial/explicit-innersource-principles.md) - *The usual InnerSource explanation of "applying open source best practices inside an organisation" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get published widely.*

<!--
NOTE: The 'Initial' Patterns below don't even have a Patlet yet, which is essential for readers to quickly browse our patterns.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,9 @@ Explicit InnerSource Principles

## Patlet

The usual InnerSource explanation of "applying open source best practices
inside an organisation" does not work well with people lacking an
open source background. As a remedy the most important principles of
The usual InnerSource explanation of "applying open source best practices
inside an organisation" does not work well with people lacking an
open source background. As a remedy the most important principles of
InnerSource get published widely.

## Problem
Expand All @@ -33,7 +33,7 @@ as well as a clear path towards achieving these goals.
## Context

* InnerSource as a term is circulating among employees.
* The initiative started among open source enthusiasts.
* The initiative started among open source enthusiasts.

## Forces

Expand All @@ -55,7 +55,7 @@ Clarity should be provided around these two areas:
### Why does the organisation want to adopt InnerSource?

In the past InnerSource has proven to be successful to solve several issues
commonly found in organisations.
commonly found in organisations.

However which organizational challenges does your organization hope to improve
upon using InnerSource?
Expand Down