InnerSource Roles

On this page

The Owner Role

The Owner is the person that has overall ownership of the project and who can appoint Trusted Committers that have responsibility delegated to them to be allowed to approve pull requests.

  • The Owner sets the long term strategy and direction and has the final say in architecture and functional changes.
  • An Owner is also a Trusted Committer.

Expectations of Owner

  • Works with the relevant project stakeholders to ensure that this project’s architecture direction is in line with the overall strategy and doesn’t duplicate functionality available elsewhere
  • Ensures that the InnerSource guidelines are applied to the project correctly.
  • Provides high-level business requirements and works with product owners, if relevant for this project, to ensure these requirements meet expected business outcomes.
  • Demonstrate excellent judgment, teamwork and ability to uphold development principles.
  • Be already acting as an owner, providing high-quality reviews and design feedback.
  • Have the bandwidth to contribute to reviews in a timely manner. If the load is unsustainable, work to expand the number of TCs.
  • Serves as the principal escalation point.
  • Represents the project in business strategy discussions and provides strategic advice to the team.

The Trusted Committer Role

The Trusted Committer role belongs to a person or persons who have been nominated to manage, review and accept pull requests which have been submitted from an external source.

  • The Trusted Committer should have very good in-depth knowledge of the codebase for which they are responsible and should be nominated by the code owning team.
  • The Trusted Committer role is not necessarily permanent but can be rotated around the team at a suitable schedule.
  • It is important that the person nominated as TC is given the time during sprint planning to work on reviewing code which has been submitted.
  • Decide on whether the TC role is permanent or rotated between members of the team.

What a Trusted Committer needs to do to support an InnerSource project

  1. Make time to review pull requests.

    Do not keep contributors waiting too long - if there is an unavoidable delay in reviewing a pull request make sure contributors are aware of this as early as possible in the cycle so that they can plan for contingencies.

  2. Set expectations with, and ensure Product and Delivery managers are aware of how much time is being taken up with InnerSource review

  3. Keep the relevant documentation up to date

  4. Keep feature request and bug reports up to date in Jira or equivalent issue manager.

  5. Communicate with contributors setting realistic expectations for timescales for review of Pull Requests

  6. Conduct code reviews with contributors according the code of conduct defined in the CODE_OF_CONDUCT.md file

  7. Participate and answer questions where appropriate (chat groups, GitHub discussions, Jira etc.)

The Contributor Role

Developers, product managers, marketers, and other roles within the company that help drive software forward. Contributors are not necessarily part of the direct project team but help build software by contributing code, submitting bug fixes, and more.

Some ways to contribute to an InnerSource project

  1. Planning

    1.1. Organize workshops or meetups about the project

  2. Design

    2.1. Restructure layouts to improve the project’s usability

    2.2. Conduct user research to reorganize and refine the project’s navigation or menus

    2.3. Put together a style guide to help the project have a consistent visual design

  3. Document

    3.1. Write and improve the project’s documentation

    3.2. Curate a folder of examples showing how the project is used

    3.4. Write tutorials for the project

    3.5. Write a translation for the project’s documentation

  4. Organize

    4.1. Link to duplicate issues, and suggest new issue labels, to keep things organized

    4.2. Go through open issues and suggest closing old ones

    4.3. Ask clarifying questions on recently opened issues to move the discussion forward

  5. Code

    5.1. Find an open issue to tackle

    5.2. Ask if you can help write a new feature

    5.3. Automate project setup

    5.4. Improve tooling and testing

  6. Help

    6.1. Answer questions about the project

    6.2. Answer questions for people on open issues

    6.3. Help moderate the discussion boards or conversation channels

  7. Coach & Review

    7.1. Review code on other people’s submissions

    7.2. Write tutorials for how a project can be used

    7.3. Offer to mentor/coach another contributor

View on GitHub