|
| 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