Skip to content
Closed
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
43 changes: 43 additions & 0 deletions innersource-guidance-group.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
## Title
InnerSource Guidance Group

## Patlet
A company may require a mechanism to set broad governance and behavioral guidelines as part of the rollout and sustaining needs of an InnerSource initiative.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patlet should summarize the solution (in addition to the problem).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the pattern like this (a bit more liberally):

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.


## Problem
Without a set of organizational standards Trusted Committers, and individual teams, are free to set their own standards, which is a step in the right direction. However, team standards could be highly variant and further diverge over time as they evolve and adapt to new needs and forces. This can lead to confusion and frustration as contributors submit code across team and functional boundaries. The business is interested establishing a set of agreed-upon standard operating procedures that guide teams while still providing sufficient autonomy to meet the parochial needs of individual teams.

## Context

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general suggest revising this section to think through what are the points of context that are essential for this pattern, specifically, as opposed to what is your own personal context, currently.

A company is planning to introduce InnerSource as a strategic initiative. They are faced with reforming and steering the behavior of developers and engineers toward a common goal. In general functional groups and teams within the company adhere to a broad spectrum of standards regarding tools, development languages, collaboration models, engagement models, documentation models, etc. The company recognizes the value of the Trusted Committer role as a situational leader for a team that sets and enforces team standards, code contribution standards, contribution agreements, PR management, etc. however the company is interested in establishing organizational guidelines as well that steer and focus Trusted Committers and the teams they represent.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A company is planning to introduce InnerSource

Is this point an essential point of context for using this pattern? Seems like the pattern would apply even to those that have already introduced inner source, for example.


As an example, the breadth of languages used within an engineering and operations organization could include, powershell, bash shell, perl, tcl, python, golang, java, shell augmented with sed and awk and jq, etc. and the organization wants to standardize as much as possible on a subset of these languages so that the ability to collaborate between teams is maximized.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the document suggest standardizing on inner source process, but this paragraph suggests standardizing on technology. Which standardization is the goal of this pattern? Both?


## Forces
Comment thread
spier marked this conversation as resolved.
Resolved
- Separate engineering and development teams establish development standards that may be highly divergent from other teams which limits the ability to collaborate.
- As people move between teams, or responsibility for specific initiatives change over time, the ability of the organization to adapt to variant team norms results in decreased development velocity.

## Solutions
Recognize that Trusted Committers are both situational leaders and subject matter experts representing their team and establish a governance model with a “committee” attended and chaired by Trusted Committers chartered with establishing company and/or organizational guidelines.
Comment thread
spier marked this conversation as resolved.
Resolved

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that governance model is a loaded term, and maybe too strong for what you actually describe this group as doing (establish organization guidelines).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, governance might be too strong.

I have reworded this like this:

Recognize that Trusted Committers are both situational leaders and subject matter experts representing their team. Establish an InnerSource Guidance Group as a “committee” attended and chaired by Trusted Committers. Charter this InnerSource Guidance Group with establishing company and/or organizational guidelines.


- The “committee” is scheduled periodically as necessary by the TC’s – twice a week, once a month, quarterly, etc.
- The goal is to establish general direction, or a highway, while leaving freedom for individual teams to adapt to local needs, or side streets
- Trusted Committers establish organization guidelines that become templates for Contribution Agreements
- Trusted Committers collaborate on and refine guidelines asynchronously via passive documentation and the establishmentment of organizational patterns

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I, personally, see this as an inner source project, whose contributors and community are those at the company who are interested in inner source.

This project should live and run itself by its own advice that it gives to others. It just happens to be a collaborative documentation project as opposed to a collaborative code project.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to what @rrrutledge said. This is also something that has worked very well for us at Europace: Our very first InnerSource project was one tasked with bringing people interested in InnerSource together, documenting best practices along the way and helping out with advice for others.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for jumping in to comment, @MaineC ❗️

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reworded this as such:

  • Trusted Committers collaborate on and refine guidelines asynchronously via passive documentation and the establishment of organizational patterns.
    • This guideline definition project itself can be run as an InnerSource project, accepting contributions from anywhere in the organization.
    • By running this as a collaborative documentation project, it can role-model and verify the behaviors that they want to promote for other InnerSource projects as well.

- The TC “committee” is responsible for communicating general guidelines to upper management
- This also ensures that teams and functional groups have a recurring touchpoint with other team and functional groups – establishing trust and insight into the overall organizational needs and requirements

## Resulting Context
Comment thread
spier marked this conversation as resolved.
Resolved

## Rationale (optional)
Empowering TC's as representatives on behalf of their teams propagates ownership of the overall InnerSource strategy as it deploys and evolves in an organization and ensures that a baseline level of governance and standardization occurs.

May mention:
- A large, highly regulated, financial organization is planning to implment a TC Steering Group to provide broad guidlelines and guard rails as part of their InnerSource initiative.

## Author(s)
- Tim Tyler <ttyler01@gmail.com>

## Acknowledgements
- Tim Yao

## Changelog