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.
- Works with the Architecture Review Board 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 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.
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.
Set expectations with, and ensure Product and Delivery managers are aware of how much time is being taken up with InnerSource review
Keep the relevant documentation up to date
Keep feature request and bug reports up to date in Jira.
Communicate with contributors setting realistic expectations for timescales for review of Pull Requests
Conduct code reviews with contributors according the code of conduct defined in the
Participate and answer questions where appropriate (chat groups, Jira etc.)
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.
1.1. Organize workshops or meetups about the project
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.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.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.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.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
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