From 11decd39e4e79ba44357531871d0de653badada7 Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Thu, 26 Aug 2021 04:48:26 -0500 Subject: [PATCH] New Pattern: Core Team (#345) Create core-team.md Co-authored-by: Sebastian Spier --- patterns/2-structured/core-team.md | 106 +++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 patterns/2-structured/core-team.md diff --git a/patterns/2-structured/core-team.md b/patterns/2-structured/core-team.md new file mode 100644 index 000000000..16c3133c6 --- /dev/null +++ b/patterns/2-structured/core-team.md @@ -0,0 +1,106 @@ +## Title + +Core Team + +## Patlet + +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. + +## Problem + +* It is difficult to contribute to the project. +This could be due to things like: + * Can't run the project locally. + * Poor documentation. + * Convoluted code. + * Inadequate testing. +* It is difficult to use the project. +Some possible causes: + * Poor documentation (again). + * Frequent bugs. + * Unintuitive setup. + +## Story + +There's a central project that everyone depends on. +What a great candidate for InnerSource! +Unfortunately, the project has grown organically, with various contributions and additions slapped on haphazardly. +Now it's an icky, thick morass of code that no one understands and everyone is afraid to touch. +It's clearly due for an overhaul (e.g. refactoring, testing, documentation, etc.), but even though everyone needs and wants that work to happen, no one takes the time to do it. + +## Context + +* Many teams need the project. +* The project has significant tech debt. +* Slow adoption and iteration on the project. +* There is not a owner or maintainer who takes reponsibility for the project and contribution ecosystem as a whole. + +## Forces + +* Every contributing team is busy, and therefore prioritizes work that results in an immediate payoff for themselves. +* As the project grows the natural trend is for it to become more difficult to use and to modify. + +## Solution + +Form a core team whose job it is to maintain this project in a state so that others can easily onboard and contribute to it. +This core team does the work that is necessary for a healthy usage and contribution ecosystem. +This critical work tends to not be prioritized as a contribution. +Categories of this type of work include communication, local environment, and DevOps infrastructure. + +Here are some specific examples: + +* Production bugs +* Documentation +* Onboarding tutorials and examples +* Automated testing +* CI/CD +* Local environment +* Modularization +* Versioning +* Monitoring +* Trailblazing new classes/categories of features + +Each of these items is very important to a healthy product ecosystem, yet is unlikely to be prioritized as a contribution. + +The core team may be composed of a small number of people on a full-time or a part-time basis. +The choice depends on the amount of work needed, the availability of resources, and the culture of the organization. +The most important consideration is to form the team in a way that allows the organization to empower and hold them accountable in the same way as any other team. + +Due to their central role, core team members should nearly always fill the role of [Trusted Committers][tc] as well. +While the [Trusted Committer][tc] role focuses mostly on facilitating others' contribution and use of the project, a core team member regularly contributes to the project as well. +The core team doesn't have its own business agenda that determines its contributions. +They decide what to work on based on what will help others most to use and contribute to the project. + +A good way to continually remind the core team of this goal is to have them report regularly on: + +* number of active teams using the project +* number of off-team contributions to the project. + +Continual focus on these metrics will naturally drive the core team to prioritize generally the right work to create a thriving InnerSource ecosystem around the project. + +## Resulting Context + +* It is easy to use and contribute to the project. +* Many teams use and contribute to the project. +* Core team has their success defined in terms of others' interaction with and response to their project. + +## Rationale + +Separating out a core team and tasking them in this way helps to fill the gaps that a successful project needs yet are left behind by contributors that are pursuing their own agenda only. +The core team fills those gaps and greases the wheels so that the contribution ecosystem remains healthy. + +## Known Instances + +Nike implemented this pattern to manage the InnerSource effort around its reusable CI/CD pipelines. + +## Status + +Structured + +## Author + +[Russell R. Rutledge](https://github.com/rrrutledge) + +[tc]: https://innersourcecommons.org/learn/learning-path/trusted-committer/