You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 30-day-warranty.md
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,18 @@
1
-
# Title
1
+
##Title
2
2
3
3
30 Day Warranty
4
4
5
-
# Context
5
+
##Context
6
6
7
7
Teams depend on another team accepting their contributions so that a component produced by the receiving team can be used by the contributing team. The receiving team does not have the resources, knowledge, permission, and/or inclination to write the contributed component.
8
8
9
9
- TBD: link to pattern "setting clear expectations for contributing code"
10
10
11
-
# Problem
11
+
##Problem
12
12
13
13
A team develops a component which is used throughout an organization. This team resists accepting or outright rejects contributions (feature requests). This behavior blocks progress and leads to frequent disruption from escalations.
14
14
15
-
# Forces
15
+
##Forces
16
16
17
17
- There is distrust of contributions due to a past history of cheating: teams
18
18
submitted half finished contributions and subsequently filed requests for
@@ -38,7 +38,7 @@ A team develops a component which is used throughout an organization. This team
38
38
they are mitigated in a contribution; the system itself is somewhat brittle
39
39
(may not be ways to fully test and catch all problems).
40
40
41
-
# Solution
41
+
##Solution
42
42
43
43
Address the fears of both the receiving and the contributing teams by establishing a 30 day period starting with the time the contributed code goes into production, during which the contributing team consents to provide bug fixes to the receiving team.
44
44
@@ -48,35 +48,35 @@ Note that the warranty period could be 45, 60, or 100 days too. The duration may
48
48
49
49
<imgalt="30 Day Warranty"src="/assets/img/thirtydaywarranty.jpg"width="70%">
50
50
51
-
# Resulting Context
51
+
##Resulting Context
52
52
53
53
- The receiving team is willing to accept contributions and able to share the
54
54
workload of initial adaptations/fixes.
55
55
- Increased transparency and fairness.
56
56
- Keeps escalations from becoming too heavyweight.
57
57
58
-
# Known Instances
58
+
##Known Instances
59
59
60
60
This was tried and proven successful at PayPal.
61
61
62
-
# Authors
62
+
##Authors
63
63
64
64
- Cedric Williams
65
65
66
-
# Acknowledgement
66
+
##Acknowledgement
67
67
68
68
- Dirk-Willem van Gulik
69
69
- Padma Sudarsan
70
70
- Klaas-Jan Stol
71
71
- Georg Grütter
72
72
73
-
# Status
73
+
##Status
74
74
75
75
Proven
76
76
77
77
Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
78
78
79
-
# Variants
79
+
##Variants
80
80
81
81
- Ensure cooperation of dependent teams by making them a community by having
82
82
more than one, meritocratically appointed "[Trusted Committers](project-roles/trusted-committer.md)" (TCs) take responsibility.
Copy file name to clipboardExpand all lines: crossteam-project-valuation.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,8 @@
1
-
# Title
1
+
##Title
2
2
3
3
Cross Team Valuation
4
4
5
-
# Patlet
5
+
##Patlet
6
6
7
7
It's hard to sell the value of cross-team, inner sourced projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.
0 commit comments