Trusted committers are the ones responsible not only for software development but also for mentoring, for pulling new people into the project, for helping and supporting downstream users with the goal of adding them to the Trusted Committer team. But how do you go about adding new Trusted Committers?
The way this works in the InnerSource project at Europace is that for people showing obvious commitment, one of the existing Trusted Committers will step forward, nominating them as a potential new Trusted Committer - giving a short explanation of why. This nomination happens in an otherwise silent slack channel that is marked as private and accessible only for existing Trusted Committers, for the sake of brevity called slack#innersource-private going forward.
Each nomination is left open for a couple days so others can add their praise or raise concerns. Silence in this case is considered as approval.
Typically no concerns are being raised. Knowing that the future Trusted Committer will be added to this very channel and will be able to read what was written leads to greater focus on strengths, potentials and mentoring instead of people trying to shut others out.
If no objections are received an invitation to the potential committer is being sent out in private by the person who nominated them.
On acceptance the new Trusted Committer is added to the list of Trusted Committers in the project’s README.md and CODEOWNERS files as well as to slack#innersource-private, so that they can see the praise received. Furthermore an announcement is sent to a public channel where colleagues can see the achievement - see also praise participants pattern.
- Introduction to series
- Checklist for internal meetups … internal meetups should be as remote friendly as possible. What do we need for that?
- Checklist for base documentation … which base documentation should we think about when starting a project?
- Issues - for brainstorming … issues not only as digital versions of sticky notes, but also for brainstorming
- Issues - for tracking work and asking questions … tracking work, asking questions, further use cases for issues
- Lazy consensus … avoid waiting endlessly by adopting lazy consensus for non-controversial changes
- Templates to drive standards … pilot recommendations locally, derive a template from the successful pilot, only then roll that pilot out as a standard to others
- External tools? … GitHub only? By far not - if appropriate switch to another tool, but link your content together for better findability. Careful: Search gets harder the more tools you introduce.