Skip to content

Commit d88e23a

Browse files
spierspier
committed
Moving wiki pages to repo. Block: "Pattern Ideas (not yet proven; brainstormed)"
1 parent 782ede2 commit d88e23a

5 files changed

+258
-4
lines changed

‎README.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -41,10 +41,10 @@ possible to either deploy the same service in independent environments with sepa
4141

4242
* [Don't Bother Looking](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/60)
4343
* [Junkyard Styled Inner Sourcing](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/61)
44-
* [Shared Code Repo Different from Build Repo](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Shared-Code-Repo-Different-from-Build-Repo) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.*
45-
* [Incentive Alignment](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Creating-Developer-Incentive-Alignment-for-InnerSource-Contribution)
46-
* [Change the Developers Mindset](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-change-the-developers-mindset)
47-
* [Share Your Code to Get More Done - Likely Contributors Variant](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-Share-Your-Code-to-Get-More-Done---Likely-Contributors-Variant)
44+
* [Shared Code Repo Different from Build Repo](shared-code-repo-different-from-build-repo.md) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.*
45+
* [Incentive Alignment](developer-incentive-alignment-for-innersource-contribution.md)
46+
* [Change the Developers Mindset](change-the-developers-mindset.md)
47+
* [Share Your Code to Get More Done - Likely Contributors Variant](share-your-code-to-get-more-done.md)
4848

4949
#### Pattern Donuts (needing a solution)
5050

‎change-the-developers-mindset.md

Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
## Title
2+
3+
Change the developers mindset
4+
5+
## Patlet
6+
7+
TBD
8+
9+
## Problem
10+
11+
* Change developer mindset, it's difficult to push developers to do things.
12+
* Developers are resisting the change, they are in their comfort zone and it's hard to go out.
13+
* Developer organizations maturity is high, so people are used to being in some hierarchy/rules
14+
* Developers are formed in agile, the shift from agile is difficult
15+
16+
## Context
17+
18+
* Top-down inner source support
19+
* 3k population of developers
20+
* Middle Management is not supporting inner source
21+
* There's already a successful group in the early stages
22+
* Code visibility is product dependent
23+
24+
## Forces
25+
26+
* Manager are previous developers, so they like the way they were promoted and they want to proceed in similar ways
27+
* Manager restrict where developers can spend time on
28+
* Top-down approach to the inner source
29+
* Different teams within the company have to decide to proceed with inner source
30+
* No formal training
31+
* Processes are not clear
32+
33+
## Sketch (optional)
34+
35+
## Solution
36+
37+
* Showing reward/recognition of the developer team
38+
* Formalize training
39+
* Clarify more processes
40+
* Give middle management specific objectives to make inner source successful
41+
* Listen to manager complaints and fears and count on them
42+
43+
## Resulting Context
44+
45+
* Use of the several projects across the several development teams
46+
* Collaboration within the same developer team (mentorship and so on)
47+
48+
## Rationale (optional)
49+
50+
## Known Instances (optional)
51+
52+
## Status
53+
54+
Unproven
55+
56+
Old status: Pattern Idea
57+
58+
## See Also
59+
60+
This pattern has been moved for discussion at https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/39
61+
62+
This pattern was originally created in this wiki and then ported here.
63+
Original wiki page:
64+
https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-change-the-developers-mindset

‎developer-incentive-alignment-for-innersource-contribution.md

Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
## Title
2+
3+
Developer Incentive Alignment for InnerSource Contribution
4+
5+
## Patlet
6+
7+
TBD
8+
9+
## Problem
10+
11+
* The organization needs to adopt a more collaborative, open-source like workstyle, but its developers are not properly incentivized or extrinsically motivated to participate in the company’s InnerSource processes.
12+
* There is a prevailing attitude in the developer culture that helping or contributing to others' success and learning is a “time sink” or "not my job."
13+
* Credit and kudos are not consistently shared with developers who help or contribute to others' success.
14+
* Prevailing developer culture is such that many believe the way up the organizational ladder - via increases in title or compensation - depends on one’s performance on quantitative metrics such as lines of code output, deadlines met, ownership of product releases or updates, and so forth.
15+
* Developers aren’t moving up the ‘organizational ladder’ because it is perceived as a path toward people management and direct reports, rather than a path of deepened respect or capabilities in engineering.
16+
17+
## Context
18+
19+
* There is a need to foster team-centric behaviour and limit instances of [ego-driven development](http://deliberate-software.com/ego-driven-development/) or idolizing a 'star developer.'
20+
* There are multiple developers within the organization or business unit with the same or related areas of expertise, such as front-end development, devops, testing, etc.
21+
* Mid-to-top level management either do not have a technical background or their technical backgrounds and experiences are many years out of date; organizational emphasis is therefore on quantitative output of development team.
22+
* The organization wants to create more alignment between work efforts and external motivation without relying directly on financial rewards or quotas.
23+
* The organization is comfortable with a personnel management and/or professional development style that is organic or “bottom-up” as opposed to traditional training or development programs run through HR (even as task management or velocity is managed in a more top-down fashion).
24+
25+
## Forces
26+
27+
1. Existing attitudes and developer culture
28+
* Team-centric behaviour is not evident. Developers of all levels tend to focus mostly on their own contributions. When stories are assigned, work is often done ‘locally’ and not pushed up or checked in until the end of the sprint.
29+
* Asking developers to push code early and often is met with extreme resistance, accusations of micro-management, or claims that such a practice would slow velocity.
30+
* Existing practice commonly leads to duplicated work, missed requirements, or frequent gaps in the software or process.
31+
32+
2. Need to retain developer talent
33+
* Managers focus heavily on tasks or velocity for developers rather than providing mentorship. Developers view helping or mentoring others as the job of Management, or something “I don’t get paid to do.” Career progression, or other ‘upward mobility paths’ (to receive a raise, for example) are not clearly identified in the organization.
34+
* Existing job descriptions, promotion tracks or compensation bands are opaque or hard to get from the organization’s HR department, resulting in a mixed understanding of job responsibilities. This puts additional pressure on performance review or improvement plans because HR, developers and managers don’t have shared a shared understanding of roles or expectations.
35+
* 'Home growing' developer talent - encouraging career growth within the company - is far cheaper for organizations in the long run than hiring from outside. Studies show employee retention increases as new opportunities, challenges, and paths for learning are introduced.
36+
37+
3. Maintaining the product development lifecycle
38+
* Keeping the status quo is encouraged or reinforced with existing product/project management processes and expectations. Developers and managers are reticent to make changes for fear of putting deadlines or product/business unit goals at risk (note that these often have financial implications for the company and individual). Working on one’s own individual contributions is seen as doing one’s part to protect this lifecycle; efforts outside one’s own individual contributions is seen as disruptive.
39+
* Product/Business unit pressures
40+
* HR - existing resource allocation plans & patterns
41+
42+
## Sketch (optional)
43+
44+
![Table of roles goes here]
45+
![or maybe the pyramid]
46+
47+
## Solution
48+
49+
***Resolution to the problem***
50+
51+
* Job Descriptions/Roles on the engineering title ladder are allocated mentorship and "Open Source Time" as fits their level (i.e. 0% expectation for jrs, 100% expectation for Principals)
52+
* Moving up the ladder requires taking on more responsibility for mentoring, reviewing code, and bringing in contributions
53+
* Developers may choose not to move up the ladder because of a preference for certain types of contributions ("I like just writing code" vs "I want to have a bigger impact on the team")
54+
* relevant Skills & experience are associated with advancing titles/roles - Moving up the ladder also requires developing the social skills necessary for mentorship
55+
* Job Descriptions/Roles can be easily associated/assimilated into employee review systems or other HR programs (comp/bonus structures, etc)
56+
57+
## Resulting Context
58+
59+
* culture has been shifted from contribution culture to learning culture
60+
* devs & pms believe time spent mentoring and reviewing is equally, if not more so, valuable to time spent coding
61+
* job descriptions include mentorship & contribution language to set expectations up front & make it easier to assess if candidates have requisite skills/experience required
62+
* org is retaining and better utilizing existing talent
63+
* devs take on professional mentorship responsibilities for their peers rather than leaving it to non-technical management
64+
* career progression clearly identified & understood by engs and management
65+
66+
## Rationale (optional)
67+
68+
## Known Instances (optional)
69+
70+
## Status
71+
72+
Unproven
73+
74+
Old status: brainstormed solution
75+
76+
## Author
77+
78+
Jory Burson
79+
80+
## See Also
81+
82+
This pattern was originally created in this wiki and then ported here.
83+
Original wiki page:
84+
https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Creating-Developer-Incentive-Alignment-for-InnerSource-Contribution

‎share-your-code-to-get-more-done.md

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
## Title
2+
3+
Share Your Code to Get More Done
4+
5+
Old title: Share Your Code to Get More Done - Likely Contributors Variant
6+
7+
## Patlet
8+
9+
TBD
10+
11+
## Problem
12+
13+
* Developers do not realize that they can get more done by taking advantage of Inner Sourcing
14+
* Developers continue to work in their silo or alone and never take the time invest in moving to Inner Sourcing
15+
* Project Teams need a compelling reason to invest some time to make the change
16+
17+
## Context
18+
19+
* Development on a specific product is siloed and a finite number of developers are involved in development activity
20+
* Development progress is not moving fast enough
21+
* Developers are being asked to do more work than they can accomplish
22+
* Other developers are likely to work on the product if the opportunity to participate existed
23+
* Current developers are working near maximum efficiency
24+
25+
## Forces
26+
27+
* Developers have no extra time to shift to Inner Sourcing
28+
* Management has not prioritized a shift to Inner Sourcing
29+
* Adding staff to get the work done using traditional methods is not possible
30+
* The value of Inner Sourcing is not included in the project plan
31+
32+
## Sketch (optional)
33+
34+
## Solution
35+
36+
* Leverage existing case studies and collateral from Inner Source Commons to educate management on the value of investing in Inner Sourcing.
37+
* Work with planning team to document an alternative project plan with some inner sourcing activities and estimated benefits from realistic expected participation
38+
* Move the product code to an Inner Source compatible solution and open the code
39+
* Assign a portion of the developers time to work as reviewers to ensure inner sourcing activities are successful
40+
* Recruit potential contributors and inform them of the availability of the opportunity to participate
41+
* Align incentives to participation for both existing developers and contributors to encourage behavior
42+
43+
## Resulting Context
44+
45+
* Development previously done in a silo is on the inner source system
46+
* People from outside the traditional silo are contributing successfully
47+
* More development is getting done per period (sprint)
48+
49+
## Rationale (optional)
50+
51+
## Known instances (optional)
52+
53+
## Status
54+
55+
Unproven
56+
57+
Old status: Idea
58+
59+
## Author
60+
61+
David Marcucci
62+
63+
## See Also
64+
65+
This pattern was originally created in this wiki and then ported here.
66+
Original wiki page:
67+
https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Shared-Code-Repo-Different-from-Build-Repo

‎shared-code-repo-different-from-build-repo.md

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
## Title
2+
3+
Repo for Shared Code Different from Repo the Product Org Uses in its Build
4+
5+
## Patlet
6+
7+
TBD
8+
9+
## Problem
10+
11+
Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.
12+
13+
## Context
14+
15+
Shared code is kept in an accessible repository that is different from SCMs used by the products that use the shared code. Integration, testing and builds might be automated with the product SCM but not the shared code repo.
16+
17+
## Forces
18+
19+
When the shared code is in a separate repository, any use of it could result in forking modifications, leading to complications later when the source is changed by the owning organization. When starting an inner sourcing program, it is possible there are many SCM systems in use; and, frequently, a new SCM is used for the inner sourcing program. Migrating from one SCM to another is not trivial. Since the using organization has a copy, they might not be aware of changes to the shared code. It is difficult and expensive for the using organization to change their automated build process to use a foreign repo.
20+
21+
## Solution
22+
23+
Continuous integration, not only to with testing but also in production (aligns with DevOps). Known marker that shows the code hasn't been modified. Improved communication between teams. Accountability when you screw up; hold people accountable. Publish good stats about the negative implications of errors and processes for making this everyone's problem.
24+
25+
## Resulting Context
26+
27+
Ideally, overhead is minimized or eliminated. Or integrate the shared code repository in the production build.
28+
29+
## Status
30+
31+
Unproven
32+
33+
## Author
34+
35+
## See Also
36+
37+
This pattern was originally created in this wiki and then ported here.
38+
Original wiki page:
39+
https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Shared-Code-Repo-Different-from-Build-Repo

0 commit comments

Comments
 (0)