pattern draft: Incubator Pipeline

[gyehuda]

This is the first draft.

[Update]:
Quick link to rendered markdown

[spier]

In the first round of review I am just making some fixes to the markdown.
I will commit them straight away, as they won't be controversial.

Then I will run other CI checks (via GitHub Actions), just to confirm that there aren't any other issues with the formatting.

Once that is done, I will add some suggestions for content changes for you to review. This last step might take me a couple of days.

[spier]

This is a fantastic pattern already @gyehuda!

Great work following along the template and filling out all sections.

I left some specific comments inline in the review.

Some general ideas to improve the pattern:

• can you expand on the problem that the contributing team is solving for themselves, and their motivation to enter the incubator rather than rolling their own project outside of the UI component?
• in conversations you mentioned that using the UI components library might be a policy in the company. In that case this would belong into the Context, as it allows readers of the pattern to check if they have this situation.
• consolidating terminology
  • I noticed that there were various words used for the different teams (shared library team | customer team | central team | user teams). It might be worth consolidating these terms, so that it is always clear which team is meant.
  • A similar consolidation could be done on other terms e.g. "top-level unit vs first-class citizen". While always using the same term for the same concept will make the text a bit more boring to read, it will make it more clear to the readers what is wht.
  • As an intermediary step prior to consolidation one could also create a little glossary at the end, just to double check which essential terms are used interchangeably.

I know that this is a lot of feedback and I don't want this PR review to become too long. I would much rather merge this pattern as Initial relatively quickly, so that it becomes easier for others to discover the pattern and contribute.

We could achieve this by time-boxing the remaining review period.
e.g. "We will continue the improve/review cycle until August 15th. After that we merge what we have and continue further feedback in subsequent PRs."

What do you think about that approach?

[spier]

Some ideas for helpful visualizations:

a) different stages of incorporation of a contributed UI component

The Solutions section describes different stages of maturity, with quality gates separating one stage from the next. This could e.g. be visualized similar to this (source file):

b) sample visualization of how the incubating components look like for consumers

When a consumer of the central UI components want to figure out whether a given component is a first-class or a second-class (incubating) component, how would they do that?

e.g. will incubating component be listed differently in the documentation, or flagged somehow, so that it is clear that the support for these components is different than the one for the first-class component?

[spier]

Your blog post mentions:

This approach is, in some way, a blend of existing InnerSource patterns: the Contracted-Contributor (an agreement), Gig-Marketplace (if the UIC team invites incubees), and the Review-Committee (acceptance after incubation) pattern.

Those are great observations in the blog post that would be good to translate into the pattern somehow.

Maybe they could be integrated in to the Rationale like this:
a) Which other patterns is the Incubator Pipeline related to (or even taking inspiration from)?
b) How and why is the Incubator Pipeline a pattern in its own right?

One could add a link to the 30 Day Warranty pattern as well, as that sounds similar to the support agreement in the incubator.

[spier]

@gyehuda I just had one other thought:
Is it essential for this pattern to work that the library in question is modular, so that contributions from an out-group that are under incubation can be kept "separate" from the rest of the code?

If so, then this would belong into the Context as it would help readers to understand "do I have this situation?".

[spier]

In the meantime we have this new plugin that talks about extensions/plugins to enable InnerSource. Could be worth linking to. https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/extensions-to-manage-contributions-at-scale.md

[spier]

@gyehuda one thought about this PR:
PRs that are open for extended periods run the risk of becoming stale, and eventually unmergable. Typically because author or reviewer have moved on, or the context in which the pattern was first created has changed too much.

Another disadvantage particular to new patterns in PRs (rather than improvements of existing patterns) is, that many readers won't find these new patterns when they are hidden in PRs, as they mostly view the patterns in the main brach of our repo.

Therefore I am wondering what the smallest possible increment on this PR would be that allows us to merge it, so that the new Incubator Pipeline pattern becomes available in the main branch for everybody to read?

One proposal from me:

• merge this branch as is but keep all review comments in this PR open. Add a link from the pattern to this PR, so that we can work in the feedback from the open comments in future improvements to this pattern.

Would that work? Or would you favor another approach?

[robtuley]

One proposal from me:

merge this branch as is but keep all review comments in this PR open. Add a link from the pattern to this PR, so that we
can work in the feedback from the open comments in future improvements to this pattern.
Would that work? Or would you favor another approach?

I'm going to action this. I can raise another PR to add some of the comments content in.

[robtuley]

Updates for this pattern are now continued in #489