Repository navigation
Pattern describing enterprise InnerSource Guidance Group #106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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. | ||
|
|
||
| ## 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
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. | ||
|
spier marked this conversation as resolved.
Resolved
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
|
||
|
|
||
| - 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for jumping in to comment, @MaineC ❗️
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Reworded this as such:
|
||
| - 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 | ||
|
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 | ||
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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):