Roles are given to group members according to the jobs they do in the community, or that we need them to do. Roles can be acquired by doing certain activities or assigned by community leaders. Roles are a good way to increase love, as they provide clear paths up the commitment curve and often come with expectations around the frequency of participation. Plus, people just like to know what they are supposed to do and how often.
Roles are not required to use the Orbit Model. In smaller communities, roles and orbit levels may be the same thing. In more complex communities, there may be many roles, and levels may make sense to use within each role, not globally. Use roles to the extent it helps you make sense of what groups of members are doing or need to do to help the community achieve its goals.
The mission of an open source project may be to make high-quality software freely available to a large number of people. Given that mission, we can infer that we'll need Core Team Members and Maintainers to build and guide the project, Developer Advocates and Documentarians to help it be understood and adopted, and finally the end Users to use it, report bugs, and suggest enhancements. Some end Users may also become Code Contributors if they submit changes themselves.
| Roles in an open source community | |
|---|---|
| Maintainer | User |
| Core Team Member | Code Contributor |
| Developer Advocate | Documentarian |
| Financial Backer | Project Manager |
Roles in this community are not mutually exclusive. A member may be a Maintainer, a User, and a Documentarian at the same time.
Once a community's roles have been defined, the next step is to determine how to assign roles to each member.
Some roles are like titles and should be explicitly bestowed by leadership. That's usually for a small portion of the membership. Appointed roles in an open source community may include Core Team Member or Project Manager.
Members acquire roles by doing a certain amount or type of activity. In our open source example, the User role could be given to anyone who clones or downloads the project. The Developer Advocate role could be given to any member who has written a blog post or given a talk. It's up to each community to make their own roles and rules.
Here's a larger set of acquired roles for our open source community:
| Roles | Activity Types |
|---|---|
| Core Team Member | Merge Code, Organize Meetings, Give Keynotes |
| Maintainer | Merge Code, Attend Meetings |
| Developer Advocate | Give Talks, Write Blog Posts, Fix Issues |
| Code Contributor | Submit Pull Requests |
| Documentation | Write Documentation |
| User | Sign up, Download, Open Issues |
| Financial Backer | Donate Money |
Defining clear roles in the community is a good way to increase love and the community's overall impact. Members like to know what they should do and how often they should do it.
The following table outlines a set of expectations for different roles in our example open source community.
| Role (Who) | Activity Type (What) | Frequency |
|---|---|---|
| Maintainer | Attend Meetings | Monthly |
| Code Contributor | Submit Pull Requests | Weekly |
| Developer Advocate | Write Blog Posts | Monthly |
| Financial Backer | Donate Money | Monthly |
| User | Attend Conference | Yearly |
| User | Open Issues | As needed |
In complex communities with many roles and subcommunities, it's possible to combine roles and orbit levels. Each role, like Code Contributor or Financial Backer can have its own love and orbit levels, each capturing a level of commitment that is unique to the member's contributions in a specific area, e.g. code or monetary donations.