Skip to content

Commit 0981855

Browse files
authored
Merge pull request #100 from dogonthehorizon/master
Add pattern for trusted committer
2 parents d7d672c + 533039e commit 0981855

File tree

1 file changed

+167
-0
lines changed

1 file changed

+167
-0
lines changed

project-roles/trusted-committer.md

Lines changed: 167 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,167 @@
1+
# Title
2+
3+
Trusted Comitter
4+
5+
# Patlet
6+
7+
Many inner-source projects will find themselves in a situation where
8+
they consistently receive feedback, features, and bug-fixes from contributors.
9+
In these situations project maintainers seek ways to recognize and reward the
10+
work of the contributor above and beyond single contributions.
11+
12+
# Context
13+
14+
- You are the maintainer of a cross-team library, service, or shared resource
15+
- You receive regular contributions
16+
- There are motivated contributors looking to build expertise through
17+
inner-sourced projects
18+
19+
# Problem
20+
21+
- Project maintainers want to find ways to scale their ability to support a
22+
project
23+
- Project maintainers want to find ways to lengthen the value delivered by a
24+
project
25+
- Project maintainers want to visibly reward frequent contributors and
26+
empower them to amplify their value contribution.
27+
- Lack of language for recognizing contributions across teams within an
28+
organization
29+
30+
# Forces
31+
32+
- Over the lifecycle of a project the focus of the maintainers may shift away
33+
to accomodate changing business priorities
34+
- Contributors seek visible artifacts of their contributions demonstrating
35+
value
36+
- Maintaining a project of reasonable complexity is taxing for a small team
37+
38+
# Solution
39+
40+
## Defining the Trusted Committer Role for a Project
41+
42+
What a Trusted Committer handles is up to each project and its maintainers.
43+
Whatever shape your Trusted Committer role takes, make sure it's clearly
44+
documented somewhere in your project. This sets expectations for new community
45+
members and outlines the role for future candidates.
46+
47+
Below we've provided a few guidelines for what Trusted Committers can be
48+
invited to do:
49+
50+
* If a candidate participates often in community channels (e.g. Slack, JIRA
51+
issue triaging, etc.) then becoming a Trusted Committer formalizes their role
52+
in community support.
53+
54+
* A good candidate for a Trusted Committer, is someone who frequently submits
55+
code, documentation, or other repository changes. Start by including this
56+
person on pull requests. If they are actively engaging in pull requests,
57+
consider approaching them about opportunities for further collaboration on the
58+
project.
59+
60+
## Formalizing Trusted Committers
61+
62+
The first step is to approach candidates about becoming a Trusted Committer.
63+
Maintainers should make sure candidates understand the role. To be clear:
64+
there is no expectation that candidates will accept the role. Each candidate
65+
should figure out if they have the bandwidth to get involved.
66+
67+
When a candidate accepts the role it is up to the project maintainers to
68+
publicly recognize the transition from user to Trusted Committer. It is also a
69+
good idea to add their name to a Trusted Committers section in your project's
70+
README. As an example:
71+
72+
```markdown
73+
# project-name
74+
75+
... your project's readme ...
76+
77+
## Project Leaders
78+
79+
### Maintainers
80+
81+
- Your team
82+
83+
### [Trusted Committers]
84+
85+
- The name of the new trusted committer
86+
87+
[Trusted Committers]: https://example.com/link/to/your/trusted/committer/documentation.md
88+
```
89+
90+
## Maintaining Trusted Committer Relationships
91+
92+
When a new Trusted Committer is minted it’s a good idea to keep them in the
93+
loop as you continue to iterate on your project. This can be as simple as
94+
inviting them to your project channel or as involved as including them in your
95+
planning sessions. More opportunities for involvement gives Trusted Committers
96+
a path to Maintainer if they so desire.
97+
98+
Besides keeping Trusted Committers informed it’s a good idea to check in on a
99+
regular basis. A good cadence is every week, but as the Trusted Committer
100+
settles in this can drop to every few weeks or so. The purpose of these
101+
check-ins is to make sure the Trusted Committer feels supported in their new
102+
role, like a 1:1 with your manager. If things aren’t going well, listen and
103+
try to understand what is preventing the Trusted Comitter from being successful.
104+
If things are going well, [thank the Trusted Committer for their continued
105+
effort][praise] in making the project successful and set a new date to check-in.
106+
107+
## Sunsetting a Trusted Committer
108+
109+
There comes a time when removal of a Trusted Committer is necessary, for
110+
example:
111+
112+
* No longer willing to take part
113+
* No longer able to perform their duties
114+
* No longer employed by the company
115+
116+
In each of the above cases a plan for removing access to project resources
117+
should be agreed upon by both parties. This includes transitioning their entry in
118+
a project's **Trusted Committer** section to a list of past contributors.
119+
120+
After access is removed it is courteous to [thank the Trusted Committer for
121+
their participation in a public way][praise]. This ensures clear communication
122+
and continuity within the community.
123+
124+
# Resulting Context
125+
126+
## For Contributors
127+
128+
Achieving Trusted Committer status for a project is a sign that the contributor
129+
has demonstrated an improvement to a community project. Recognition for these
130+
efforts can be used during annual reviews with managers.
131+
132+
## For Maintainers
133+
134+
As a project matures, maintainers can become less familiar with key aspects
135+
of a project. Trusted Committers fill in these gaps. This ensures that all
136+
aspects of the project are better served over time.
137+
138+
A healthy set of Trusted Committers ensures that if project maintainers move on
139+
there is a plan for responsible stewardship.
140+
141+
# Known Instances
142+
143+
This has been tried and proven successful at Nike and PayPal.
144+
145+
# Authors
146+
147+
- [Fernando Freire]
148+
149+
# Acknowledgements
150+
151+
- [Russell Rutledge]
152+
- [Loren Sanz]
153+
- [Noah Cawley]
154+
- [Jeremy Hicks]
155+
156+
# State
157+
158+
Published internally at Nike; drafted via pull-request in June of 2018.
159+
160+
# Variants
161+
162+
[Russell Rutledge]: https://github.com/rrrutledge
163+
[Loren Sanz]: https://github.com/mrsanz
164+
[Jeremy Hicks]: https://github.com/greatestusername
165+
[Noah Cawley]: https://github.com/utanapishtim
166+
[praise]: https://github.com/paypal/InnerSourcePatterns/blob/master/praise-participants.md
167+
[Fernando Freire]: https://github.com/dogonthehorizon

0 commit comments

Comments
 (0)