[Pattern Draft] Contributor journey optimization

[spier]

Closes #786

See rendered preview here.

The pattern was mostly generated with this ChatGPT prompt.

Would be great to get feedback especially about "the concept" part of the prompt.

Describe the concept of "Contributor Journey Optimization" in the format of an InnerSource Pattern. Use the template for an InnerSource Pattern provided below.

# The concept:

With "Contributor Journey" we mean the progression of a user of an InnerSource project through various staging. Let's assume the following stages of a user:

- does not know the project
- knows the project
- uses the project
- makes non-code contributions to the project
- makes code contributions to the project
- becomes a trusted committer

These stages are meant as a progression from top to bottom.

With "Contributor Journey Optimization" we mean:

A method for evaluating a project's (potential) Contributor Journey, document impediments for a contributor to move from one stage to the next, and derive and prioritize concrete tasks to reduce the friction in the journey to a minimum. The goal is to maximize the value added by stakeholders to the project and taken by stakeholders from the project.

The idea is that this method can be applied as a workshop with project members (and maybe stakeholders), facilitated by a "coach", or in a self service manner by project maintainers.


# Template

## Title

Short Title Here

## Patlet

A two sentence description of the problem and solution.
The first sentence describes the problem you are looking to solve, while the second sentence describes the solution.
The first sentence of the Patlet should not mention anything about the solution.

Readers may quickly review dozens of these patlets to discover and browse the larger library of patterns.

## Problem

What is the problem - crisp definition of the problem.

Short description, usually not more than a couple sentences, that describes what the issues and challenges are.

Be careful not to morph into information found in other sections below.

## Story (optional)

Sometimes there is a story that helps people understand the pattern better.

## Context

Where does the problem exist?

What are the pre-conditions?

**Unchangeable** before the solution goes into place.

The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"

Use bullet points for this section, so that readers can quickly check if this applies to them.

## Forces

What makes the problem difficult?

What are the trade-offs?

These are constraints that **can be changed** at a cost.

The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.

Use bullet points for this section.

## Sketch (optional)

visual illustration

## Solutions

Verified resolutions and possible resolutions to the problem.

## Resulting Context

What is the situation after the problem has been solved?

The original context is changed indirectly by way of the solution.

Often this section can include discussion of the next possible Patterns/problems introduced.

This section can be short in content - the solution may not introduce new problems or change much context.

## Rationale (optional)

Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem.

Can expand on what-if's or theories.

## Known Instances (optional)

Where has this been seen before?

Helps to reinforce that this is a REAL pattern and that you match the context.

May mention:

* A particular business

* Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".

## Status (optional until merging)

General pattern status is stored in GitHub's Label tagging - see any pull request.

Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.

You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."

## Author(s) (optional)

Often, this is yourself.

If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To).

Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution).

## Acknowledgments (optional)

Include those who assisted in helping with this pattern - both for attribution and for possible future follow up.

Though optional, most patterns should list who helped in their creation.

## Alias (optional)

If this pattern is also known under a different name than what is listed unter **Title**, please list those alternative titles here.

e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.

[spier]

@dellagustin-sap would love to get your feedback on this, as this is your idea after all :)

[spier]

@dellagustin-sap hope you recovered from all the input during FOSS Backstage :)

Any feedback that you got during the event, that you would like to work into this pattern draft?

I would love to push "a version" of this pattern out into our repo, so that we can more easily point other people to it and gather more feedback.

[dellagustin-sap]

Hi @spier , there was quite some discussion after the presentation, which was very nice. The problem is, I'm having trouble remembering it...

I remember:

1. There was some debate about the name, whether it should be just Contributor Journey or Contributor Journey Optimization (I'm still on the latter)
2. The feedback that there should be a step where the person looks at the code, I'm thinking about expanding the "Participate" step to Observe and Participate, or Learn and Participate, to keep the number of "journey steps" short. I''m not sure I'm ok with using the term Learn at this particular stage of the journey, at least no just "Learn", because there is learning also before that, but at this stage it is a different type of learning, it is a bit like learning to use the software vs learning the insides of the software and the project

[MaineC]

Concerning 1.)

Count me in the "likes contributor journey optimization" bucket.

Maybe there's two sides this pattern that belong together:

• The definition of the steps of the contributor journey. Those could be very similar across organisations and even to many open source projects.
• The steps taken to make it easier for contributors to move from one stage to stage. I would imagine that there's a bit of variety depeding on the exact nature of the InnerSource project, company culture etc. My hunch would be that one might even see a link to our crossing the chasm pattern. As is that one talks about things to do to make the InnerSource program itself successful. I would imagine that some of the steps described in there might also help move users of an InnerSource project along the contributor journey.

[spier]

@MaineC many open source maintainers must have the same issue. i.e. how to turn users into contributors, contributors into maintainers, etc.

Have you come across any writeups about this? There must be some, just I don't know how to best search for it.

Here some places that I did find. How to find more?

• https://un.curl.dev/people.html
• https://producingoss.com/en/producingoss.html#community-and-motivation
• https://producingoss.com/en/producingoss.html#transitions

[Update]:
I just found the other references that @dellagustin-sap posted here:
InnerSourceCommons/ispo-working-group#157

I guess that should give us enough reading material for a first version of this pattern.

[MaineC]

https://blog.isabel-drost.de/building-online-communities-from-the-0mq-trenches130/ adds some more links and background

(I specifically shared the Apache Beam blogpost on slack that Guilherme included because I remember them trying to outgrow their seed community towards ppl from other orgs, the thing I liked and didn't know before was the concept where contributors are invited to review Pars by committers)

[sallydeering1]

curious what "knows the project" adds. Is this 'they know of it and aren't contributing to or using it'? maybe a different word than "knows" needed here?
Also, between making contributions and being a trusted committer, should we add 2 stages - reviews and comments on non-code contributions and reviews and comments on code contributions or just reviews and comments on contributions.

[dellagustin]

Hi @sallydeering1 , this Miro Board could help understanding the background of the pattern: https://miro.com/app/board/uXjVL4Wk-Os=/
I also have this slides, that I used to present the concept on the InnerSource Gathering in Berlin: https://dam.sap.com/mac/u/a/jtmWHNd?rc=10&doi=SAP1193221

I'll try to address your comment later. I need to do some thinking.