From 8110c2186662bdcfacce4ebffa2749ad160c483e Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Mon, 13 Feb 2023 13:46:33 -0500 Subject: [PATCH 01/26] Move Release Process to structured --- pattern-categorization/innersource-program-mind-map.md | 4 ++++ patterns/{1-initial => 2-structured}/release-process.md | 6 ++++-- 2 files changed, 8 insertions(+), 2 deletions(-) rename patterns/{1-initial => 2-structured}/release-process.md (85%) diff --git a/pattern-categorization/innersource-program-mind-map.md b/pattern-categorization/innersource-program-mind-map.md index 008bd6adf..b55de88a0 100644 --- a/pattern-categorization/innersource-program-mind-map.md +++ b/pattern-categorization/innersource-program-mind-map.md @@ -38,6 +38,10 @@ ##### [Cross-Team Project Valuation](https://patterns.innersourcecommons.org/p/crossteam-project-valuation) +#### How to determine a project's release process and cadence + +##### [Standard Release Process and Published Artifacts](https://patterns.innersourcecommons.org/p/release-process) + ### Cultural Challenges #### Unrecognized effort diff --git a/patterns/1-initial/release-process.md b/patterns/2-structured/release-process.md similarity index 85% rename from patterns/1-initial/release-process.md rename to patterns/2-structured/release-process.md index e98a02f8a..04901c6bd 100644 --- a/patterns/1-initial/release-process.md +++ b/patterns/2-structured/release-process.md @@ -38,9 +38,11 @@ A good example of quality Release notes can be found [here](https://github.com/j 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. +Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with you project. Praising outside teammates for contributions, including documentation and release notes is a great way to foster community and grow your user base. + ## Known Instances -Comcast +Comcast (multiple projects) ## Authors @@ -48,4 +50,4 @@ David Grizzanti ## Status -**Initial** - FYI we are considering splitting "Published Artifacts" into its own pattern +**Structured** From c978ac067d333dd64da1f78f50b3b327ea23b0e6 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Fri, 17 Feb 2023 10:10:15 -0500 Subject: [PATCH 02/26] Update title --- pattern-categorization/innersource-program-mind-map.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pattern-categorization/innersource-program-mind-map.md b/pattern-categorization/innersource-program-mind-map.md index b55de88a0..16eb14a7e 100644 --- a/pattern-categorization/innersource-program-mind-map.md +++ b/pattern-categorization/innersource-program-mind-map.md @@ -40,7 +40,7 @@ #### How to determine a project's release process and cadence -##### [Standard Release Process and Published Artifacts](https://patterns.innersourcecommons.org/p/release-process) +##### [Standard Release Process](https://patterns.innersourcecommons.org/p/release-process) ### Cultural Challenges From 198eafdfb4ea3f03133ee559262bf6ce6e1f5af0 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Fri, 17 Feb 2023 10:10:51 -0500 Subject: [PATCH 03/26] Update title --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index 04901c6bd..b8c8e6ced 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -1,6 +1,6 @@ ## Title -Standard Release Process and Published Artifacts +Standard Release Process ## Patlet From 667272a8668174542e59f695660b5fd863b9e9f6 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Wed, 22 Feb 2023 08:33:44 -0500 Subject: [PATCH 04/26] Update patterns/2-structured/release-process.md Co-authored-by: Sebastian Spier --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index b8c8e6ced..f8f4623cc 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -42,7 +42,7 @@ Release notes are also a great opportunity to [praise participants](praise-parti ## Known Instances -Comcast (multiple projects) +* Comcast (multiple projects) ## Authors From 3c7fabe2d9c4e30ae9a1cf04f7616cb67ce32e94 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Thu, 23 Feb 2023 09:52:35 -0500 Subject: [PATCH 05/26] Update problem category for release process Also added Standard Base Documentation to this new problem category --- pattern-categorization/innersource-program-mind-map.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pattern-categorization/innersource-program-mind-map.md b/pattern-categorization/innersource-program-mind-map.md index 16eb14a7e..458176aea 100644 --- a/pattern-categorization/innersource-program-mind-map.md +++ b/pattern-categorization/innersource-program-mind-map.md @@ -38,10 +38,12 @@ ##### [Cross-Team Project Valuation](https://patterns.innersourcecommons.org/p/crossteam-project-valuation) -#### How to determine a project's release process and cadence +#### Can we trust the project for an extended period? ##### [Standard Release Process](https://patterns.innersourcecommons.org/p/release-process) +##### [Standard Base Documentation](https://patterns.innersourcecommons.org/p/base-documentation) + ### Cultural Challenges #### Unrecognized effort From 91a648dcb10a51a3891e510ccd4238e0b533f8ac Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Thu, 23 Feb 2023 10:25:04 -0500 Subject: [PATCH 06/26] Updates to Context and Force Plus a few grammar clean ups --- patterns/2-structured/release-process.md | 29 +++++++++++++++--------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index f8f4623cc..eca71e95d 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -4,27 +4,34 @@ Standard Release Process ## 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. +Teams may be reluctant to use InnerSource projects that they are unfamiliar with when there is no clear release process 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. +When a team is deciding whether to use an InnerSource project, 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. +Innersource projects that don't have a published artifact or release process reduces trust. Teams won't know when they can expect the next release, when breaking changes are introduced, 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. +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 documented and visible release process builds trust and confidence in your project. + +A lack of release notes and versioned, released binaries is very often an issue for internal projects. Teams get comfortable with the build process and internalize what goes into a release without showing the details. Any internal project with no pre-built binary or docker image available for external users fits this pattern. Without releasing often, providing clear documentation of what is included in the release, and providing an easy way to use the software, folks may shy away from using and contributing to your application or tool. ## 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 +### Difficult for organizations that don't have a central CI/CD system + +For organizations that don't provide engineers a centralized CI/CD system, automating a build and release process can be challenging. The team may need to stand up their own tool (Jenkins, Drone, etc). Without a CI/CD system, builds and release notes can still be produced, however, it may require a local build of the software and manual upload to whichever tool is hosting build artifacts. + +### Added burden of publishing release notes + +In addition to building your source code, writing release notes can be tedious without the ability to auto-generate a list of git commits. This would be left for someone to do manually, in addition to writing more high level details on a release. + +### Increased difficulty without a location to host artifacts + +If a company does not provide a centralized location for storing build artifacts (jars, npm modules, etc.) and docker images, engineers may be left deciding for themselves where is appropriate to store versioned software. Tools like GitHub provide this for you, however, if a company is not using one of these popular tools, this could pose a burden. ## Solution @@ -38,7 +45,7 @@ A good example of quality Release notes can be found [here](https://github.com/j 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. -Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with you project. Praising outside teammates for contributions, including documentation and release notes is a great way to foster community and grow your user base. +Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes is a great way to foster community and grow your user base. ## Known Instances From ecd71f6466d2f8a7b0e50390c5992e4c1832a372 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Mon, 27 Feb 2023 06:26:01 -0500 Subject: [PATCH 07/26] Remove trailing whitespace --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index eca71e95d..e11237708 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -23,7 +23,7 @@ A lack of release notes and versioned, released binaries is very often an issue ### Difficult for organizations that don't have a central CI/CD system -For organizations that don't provide engineers a centralized CI/CD system, automating a build and release process can be challenging. The team may need to stand up their own tool (Jenkins, Drone, etc). Without a CI/CD system, builds and release notes can still be produced, however, it may require a local build of the software and manual upload to whichever tool is hosting build artifacts. +For organizations that don't provide engineers a centralized CI/CD system, automating a build and release process can be challenging. The team may need to stand up their own tool (Jenkins, Drone, etc). Without a CI/CD system, builds and release notes can still be produced, however, it may require a local build of the software and manual upload to whichever tool is hosting build artifacts. ### Added burden of publishing release notes From c7c86234ac43c2e1068756b7ca757a23610828d5 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Mon, 27 Feb 2023 06:33:07 -0500 Subject: [PATCH 08/26] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 2bc2fe42f..113a2b5b7 100644 --- a/README.md +++ b/README.md @@ -56,6 +56,7 @@ Our mission * [Core Team](patterns/2-structured/core-team.md) - *Even when an InnerSource project is widely needed, contributions and usage may be hindered because the project is difficult to work with. Establish a core team that is dedicated to take care of the project's fundamental items. Their work enables contributors to add and use the features that provide value to their scenarios.* * [Document your Guiding Principles](patterns/2-structured/document-your-guiding-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 documented and published widely.* * [Extensions for Sustainable Growth](/patterns/2-structured/extensions-for-sustainable-growth.md) - *An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.* +* [Standardized Release Process](patterns/2-structured/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.* ### Maturity Level 1: Initial @@ -75,7 +76,6 @@ Our mission * [InnerSource Guidance Group](patterns/1-initial/innersource-guidance-group.md) - *A highly divergent set of development standards in different teams can slow down collaboration betweens these teams. A InnerSource Guidance Group that establishes broad governance and behavioral guidelines can help to reduce these frictions.* * [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.* * [Overcoming the Not-Invented-Here Mindset](/patterns/1-initial/not-invented-here.md) - *Perfectly good solutions are being rejected because of "Not Invented Here" (NIH). Engineers and their managers will choose to implement functionality themselves first, even if an alternative exists. A shift towards a culture of "Proudly Found Elsewhere" can help reduce the negative impact of NIH.* * [Balancing Openness and Security](/patterns/1-initial/balancing-openness-and-security.md) - *While InnerSource flourishes in environments with a high degree of shared code, Security/Legal prefers the limitation of source code access to only those that need it. By making Security/Legal part of the team, introducing explicit sharing levels and security policies for shared repositories, as well as defining what qualifies as sensitive information, code sharing can be facilitated while minimizing the associated risks.* * [Crossing the InnerSource Chasm](/patterns/1-initial/crossing-chasm.md) - *Early InnerSource experiments have been successful. Methods that were successful convincing early teams stop working though when scaling the initiative. This chasm can be crossed by using different methods to reach people at different stages of the innovation curve.* From 400fb3cce4dbf26fc7544bcfeb8283846a8a3eb8 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 8 Mar 2023 19:23:59 +0100 Subject: [PATCH 09/26] Fix InnerSource spelling --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index e11237708..2d2447a1c 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -11,7 +11,7 @@ Providing clear release notes and a published artifact (binary, docker image, ja When a team is deciding whether to use an InnerSource project, 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. -Innersource projects that don't have a published artifact or release process reduces trust. Teams won't know when they can expect the next release, when breaking changes are introduced, etc. +InnerSource projects that don't have a published artifact or release process reduces trust. Teams won't know when they can expect the next release, when breaking changes are introduced, etc. ## Context From 79cd6ccdeee34852ec079ad9690f8a9b6386a17a Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 8 Mar 2023 19:24:13 +0100 Subject: [PATCH 10/26] Formatting --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index 2d2447a1c..bc5c201a2 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -57,4 +57,4 @@ David Grizzanti ## Status -**Structured** +Structured From a4191bc44ed6efc2c5f45d229a338484f9bc78b1 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 8 Mar 2023 19:24:32 +0100 Subject: [PATCH 11/26] Spelling --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index bc5c201a2..1dc2362d9 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -39,7 +39,7 @@ If a company does not provide a centralized location for storing build artifacts - 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) +A good example of quality release notes can be found [here](https://github.com/jaegertracing/jaeger/releases). ## Resulting Context From 317e86a0cc135f9d7a92599c0195ef4a25c04c21 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Wed, 8 Mar 2023 15:45:21 -0500 Subject: [PATCH 12/26] Update patterns/2-structured/release-process.md Co-authored-by: Sebastian Spier --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index 1dc2362d9..e5a679e0f 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -4,7 +4,7 @@ Standard Release Process ## Patlet -Teams may be reluctant to use InnerSource projects that they are unfamiliar with when there is no clear release process in the repository. +Teams are reluctant to use InnerSource projects that they are unfamiliar with when they are unclear about the release process. Providing clear release notes and a published artifact (binary, docker image, jar, etc) gives people confidence you are publishing a quality product. ## Problem From ca0442f4a20581345136c48d94b294d308078851 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Wed, 8 Mar 2023 15:45:48 -0500 Subject: [PATCH 13/26] Update patterns/2-structured/release-process.md Co-authored-by: Sebastian Spier --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index e5a679e0f..e96582f03 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -45,7 +45,7 @@ A good example of quality release notes can be found [here](https://github.com/j 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. -Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes is a great way to foster community and grow your user base. +Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base. ## Known Instances From 7453c9adee46666411d7146fb06a6a664eb45c26 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Wed, 8 Mar 2023 15:48:46 -0500 Subject: [PATCH 14/26] Update patterns/2-structured/release-process.md Co-authored-by: Sebastian Spier --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index e96582f03..765ae77f3 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -5,7 +5,7 @@ Standard Release Process ## Patlet Teams are reluctant to use InnerSource projects that they are unfamiliar with when they are unclear about the release process. -Providing clear release notes and a published artifact (binary, docker image, jar, etc) gives people confidence you are publishing a quality product. +Providing clear release notes and a published artifact gives people confidence you are publishing a quality product. ## Problem From fc233f12162662162d9f3f9653c45e9a0c101482 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Wed, 8 Mar 2023 16:00:21 -0500 Subject: [PATCH 15/26] Update Patlet --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 113a2b5b7..2477765fc 100644 --- a/README.md +++ b/README.md @@ -56,7 +56,7 @@ Our mission * [Core Team](patterns/2-structured/core-team.md) - *Even when an InnerSource project is widely needed, contributions and usage may be hindered because the project is difficult to work with. Establish a core team that is dedicated to take care of the project's fundamental items. Their work enables contributors to add and use the features that provide value to their scenarios.* * [Document your Guiding Principles](patterns/2-structured/document-your-guiding-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 documented and published widely.* * [Extensions for Sustainable Growth](/patterns/2-structured/extensions-for-sustainable-growth.md) - *An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.* -* [Standardized Release Process](patterns/2-structured/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.* +* [Standardized Release Process](patterns/2-structured/release-process.md) - *Teams are reluctant to use InnerSource projects that they are unfamiliar with when they are unclear about the release process. Providing clear release notes and a published artifact gives people confidence you are publishing a quality product.* ### Maturity Level 1: Initial From b63edfa0c43ed567d03e44a6f7803f98d7caf68b Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Fri, 24 Mar 2023 10:41:54 -0400 Subject: [PATCH 16/26] Restructure Problem and Context --- patterns/2-structured/release-process.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index 765ae77f3..1703e05f0 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -9,15 +9,19 @@ Providing clear release notes and a published artifact gives people confidence y ## Problem -When a team is deciding whether to use an InnerSource project, 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. +When a team is deciding whether to use an InnerSource project, 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 when necessary and has tangible benefits. + +It is common practice for Open Source projects to have versioned releases, with notes documenting breaking changes, and new features 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. InnerSource projects that don't have a published artifact or release process reduces trust. Teams won't know when they can expect the next release, when breaking changes are introduced, 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 documented and visible release process builds trust and confidence in your project. +Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and Infrastructure as a Service modules are all examples of this. Most large organizations don't publish internal software to be consumed by other teams in the company, however. This can occur either because they are too busy provide documentation or don't realize it's value to others. + +An internal or public source repository should be available where source code is stored, but teams lack a process for making software consumable by outside teams. -A lack of release notes and versioned, released binaries is very often an issue for internal projects. Teams get comfortable with the build process and internalize what goes into a release without showing the details. Any internal project with no pre-built binary or docker image available for external users fits this pattern. Without releasing often, providing clear documentation of what is included in the release, and providing an easy way to use the software, folks may shy away from using and contributing to your application or tool. +As an organization grows and more internal software is written, the value of this pattern grows. ## Forces @@ -36,7 +40,7 @@ If a company does not provide a centralized location for storing build 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 +- Releases and accompanying build artifacts are generated by the CI system - 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). From aa3d24cf989017318be1a4b50633898655ae5e87 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Mon, 5 Jun 2023 09:39:37 -0400 Subject: [PATCH 17/26] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index baabd3a9d..9dfb71c98 100644 --- a/README.md +++ b/README.md @@ -76,7 +76,7 @@ Our mission * [Good First Project](patterns/1-initial/good-first-project.md) - *An InnerSource program has been launched at an organization, and to get off to a successful start it requires some good first projects that lend themselves to InnerSource-style development. Assessing the InnerSource-readiness (fitness) of the candidate projects can help in selecting projects that have the potential to help demonstrate the power of InnerSource.* * [InnerSource Guidance Group](patterns/1-initial/innersource-guidance-group.md) - *A highly divergent set of development standards in different teams can slow down collaboration between these teams. A InnerSource Guidance Group that establishes broad governance and behavioral guidelines can help to reduce these frictions.* * [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.* +* [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 behavior visible removes ambiguity. Writing a contributions document creates a natural way to evolve ownership.* * [Standard Release Process and Published Artifacts](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.* * [Overcoming the Not-Invented-Here Mindset](/patterns/1-initial/not-invented-here.md) - *Perfectly good solutions are being rejected because of "Not Invented Here" (NIH). Engineers and their managers will choose to implement functionality themselves first, even if an alternative exists. A shift towards a culture of "Proudly Found Elsewhere" can help reduce the negative impact of NIH.* * [Balancing Openness and Security](/patterns/1-initial/balancing-openness-and-security.md) - *While InnerSource flourishes in environments with a high degree of shared code, Security/Legal prefers the limitation of source code access to only those that need it. By making Security/Legal part of the team, introducing explicit sharing levels and security policies for shared repositories, as well as defining what qualifies as sensitive information, code sharing can be facilitated while minimizing the associated risks.* From 3083c96cb4453388e9f0aecd3adf8975f5e2b61a Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Mon, 7 Aug 2023 13:45:03 -0400 Subject: [PATCH 18/26] Update patterns/2-structured/release-process.md Co-authored-by: Sebastian Spier --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index 1703e05f0..1afe0cfe8 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -41,7 +41,7 @@ If a company does not provide a centralized location for storing build artifacts - CI/Delivery Pipeline is located within your repo to build artifacts (binary, docker image, jar, etc) - Releases and accompanying build artifacts are generated by the CI system -- Release includes notes on New Features, Bug Fixes, and any "Breaking Changes" specifically called out +- Release includes notes on New Features, Bug Fixes, and any "Breaking Changes" are called out specifically A good example of quality release notes can be found [here](https://github.com/jaegertracing/jaeger/releases). From 818885325d56846db3ceef7d1de480cde78b8096 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Mon, 7 Aug 2023 13:57:36 -0400 Subject: [PATCH 19/26] Update pattern-categorization/innersource-program-mind-map.md Co-authored-by: Sebastian Spier --- pattern-categorization/innersource-program-mind-map.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pattern-categorization/innersource-program-mind-map.md b/pattern-categorization/innersource-program-mind-map.md index fb0933911..9bccd8332 100644 --- a/pattern-categorization/innersource-program-mind-map.md +++ b/pattern-categorization/innersource-program-mind-map.md @@ -38,7 +38,7 @@ ##### [Cross-Team Project Valuation](https://patterns.innersourcecommons.org/p/crossteam-project-valuation) -#### Can we trust the project for an extended period? +#### Can we rely on the project for an extended period? ##### [Standard Release Process](https://patterns.innersourcecommons.org/p/release-process) From 93a24b51649fa172f9dc6b374d6e5f6d15daba95 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Mon, 7 Aug 2023 13:58:25 -0400 Subject: [PATCH 20/26] Update patterns/2-structured/release-process.md Co-authored-by: Sebastian Spier --- patterns/2-structured/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index 1afe0cfe8..c76bc1359 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -9,7 +9,7 @@ Providing clear release notes and a published artifact gives people confidence y ## Problem -When a team is deciding whether to use an InnerSource project, 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 when necessary and has tangible benefits. +When a team is deciding whether to use an InnerSource project, one of their considerations is whether 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 when necessary and has tangible benefits. It is common practice for Open Source projects to have versioned releases, with notes documenting breaking changes, and new features 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. From c7abae261f8e0437c614e053d43f3c820965f367 Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Tue, 8 Aug 2023 09:32:41 -0400 Subject: [PATCH 21/26] Update Patlet text --- patterns/2-structured/release-process.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index c76bc1359..ebb04c7df 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -4,8 +4,7 @@ Standard Release Process ## Patlet -Teams are reluctant to use InnerSource projects that they are unfamiliar with when they are unclear about the release process. -Providing clear release notes and a published artifact gives people confidence you are publishing a quality product. +Teams may hesitate to adopt an InnerSource project if they're unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software. ## Problem From 5abbd9960e326c7bacdb913a5b6350f6aeb6524e Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Tue, 8 Aug 2023 09:38:15 -0400 Subject: [PATCH 22/26] Update patterns/2-structured/release-process.md Co-authored-by: Sebastian Spier --- patterns/2-structured/release-process.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index ebb04c7df..f4c61cd84 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -37,6 +37,9 @@ In addition to building your source code, writing release notes can be tedious w If a company does not provide a centralized location for storing build artifacts (jars, npm modules, etc.) and docker images, engineers may be left deciding for themselves where is appropriate to store versioned software. Tools like GitHub provide this for you, however, if a company is not using one of these popular tools, this could pose a burden. ## Solution +By providing clear **release notes** and a published artifact you increase people's confidence that you are publishing a quality product that they can rely on. + +The following are key elements to achieve this: - CI/Delivery Pipeline is located within your repo to build artifacts (binary, docker image, jar, etc) - Releases and accompanying build artifacts are generated by the CI system From 906c167fe2a10914cc2491ca4d499b65b03f319d Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Tue, 8 Aug 2023 09:44:48 -0400 Subject: [PATCH 23/26] Clean up Context section --- patterns/2-structured/release-process.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index f4c61cd84..d943c24e9 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -16,7 +16,7 @@ InnerSource projects that don't have a published artifact or release process red ## Context -Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and Infrastructure as a Service modules are all examples of this. Most large organizations don't publish internal software to be consumed by other teams in the company, however. This can occur either because they are too busy provide documentation or don't realize it's value to others. +Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy to publish software artifacts or don't realize the projects value to others. An internal or public source repository should be available where source code is stored, but teams lack a process for making software consumable by outside teams. @@ -37,6 +37,7 @@ In addition to building your source code, writing release notes can be tedious w If a company does not provide a centralized location for storing build artifacts (jars, npm modules, etc.) and docker images, engineers may be left deciding for themselves where is appropriate to store versioned software. Tools like GitHub provide this for you, however, if a company is not using one of these popular tools, this could pose a burden. ## Solution + By providing clear **release notes** and a published artifact you increase people's confidence that you are publishing a quality product that they can rely on. The following are key elements to achieve this: From 2e9b370324bc70c7181ea63f364d02e6f9dc2a2f Mon Sep 17 00:00:00 2001 From: David Grizzanti Date: Tue, 8 Aug 2023 09:54:41 -0400 Subject: [PATCH 24/26] Clean up solution section --- patterns/2-structured/release-process.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index d943c24e9..fbfd4b34a 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -16,7 +16,7 @@ InnerSource projects that don't have a published artifact or release process red ## Context -Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy to publish software artifacts or don't realize the projects value to others. +Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy provide documentation or don't realize the projects value to others. An internal or public source repository should be available where source code is stored, but teams lack a process for making software consumable by outside teams. @@ -42,9 +42,10 @@ By providing clear **release notes** and a published artifact you increase peopl The following are key elements to achieve this: -- CI/Delivery Pipeline is located within your repo to build artifacts (binary, docker image, jar, etc) -- Releases and accompanying build artifacts are generated by the CI system -- Release includes notes on New Features, Bug Fixes, and any "Breaking Changes" are called out specifically +- A CI/CD pipeline is located within your repository that [automates the release process](https://opensource.guide/best-practices/#use-tools-to-automate-basic-maintenance-tasks) +- Build artifacts are generated by the CI/CD system (binary, docker image, jar, etc) +- Releases are clearly labeled and tagged with [semantic versioning](https://github.com/semantic-release/semantic-release) +- Releases include notes on New Features, Bug Fixes, and any "Breaking Changes" A good example of quality release notes can be found [here](https://github.com/jaegertracing/jaeger/releases). From 27c759eccade7d068b9589644facf485adfbdf6e Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 9 Aug 2023 14:03:35 +0200 Subject: [PATCH 25/26] Fix some spelling --- patterns/2-structured/release-process.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md index fbfd4b34a..0c09a017f 100644 --- a/patterns/2-structured/release-process.md +++ b/patterns/2-structured/release-process.md @@ -4,7 +4,7 @@ Standard Release Process ## Patlet -Teams may hesitate to adopt an InnerSource project if they're unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software. +Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software. ## Problem @@ -16,7 +16,7 @@ InnerSource projects that don't have a published artifact or release process red ## Context -Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy provide documentation or don't realize the projects value to others. +Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of this type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy to provide documentation or don't realize the projects value to others. An internal or public source repository should be available where source code is stored, but teams lack a process for making software consumable by outside teams. From 01e4a7683a3c76f857939d0a5b2153dbe9433006 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 9 Aug 2023 14:05:01 +0200 Subject: [PATCH 26/26] Copy updated title+patlet into the README --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9dfb71c98..b68946eed 100644 --- a/README.md +++ b/README.md @@ -56,7 +56,7 @@ Our mission * [Core Team](patterns/2-structured/core-team.md) - *Even when an InnerSource project is widely needed, contributions and usage may be hindered because the project is difficult to work with. Establish a core team that is dedicated to take care of the project's fundamental items. Their work enables contributors to add and use the features that provide value to their scenarios.* * [Document your Guiding Principles](patterns/2-structured/document-your-guiding-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 documented and published widely.* * [Extensions for Sustainable Growth](/patterns/2-structured/extensions-for-sustainable-growth.md) - *An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.* -* [Standardized Release Process](patterns/2-structured/release-process.md) - *Teams are reluctant to use InnerSource projects that they are unfamiliar with when they are unclear about the release process. Providing clear release notes and a published artifact gives people confidence you are publishing a quality product.* +* [Standard Release Process](patterns/2-structured/release-process.md) - *Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software.* * [Group Support](patterns/2-structured/group-support.md) - *What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.* ### Maturity Level 1: Initial