Mentoring roles

Concept

In the past we've mostly leaned on community volunteers to sign up to be a "primary mentor" that could pretty much be paraphrased to the mythical "full-stack developer" as they'd be responsible for all the things and might even have to stand up and volunteer for that not yet knowing what project they might pick.

This new idea splits apart the responsibilities into smaller roles that are more well-defined and allow multiple individuals to instead become a mentor team that combined can form the Voltron of mentorship. The main roles also neatly line up with our specialized teams (forum badges) which could allow for better organizing in the future

An old school "primary mentor" would fill all 4 primary roles (A, B, D, E) which is still possible, but in most cases a lot of work. Breaking it apart allows more flexibility in putting together mentor teams that check all the boxes together and makes volunteering a less intimidating affair.

Roles

The six roles form a nice A-F listing.

An absolutely minimal team (very easy item, very solid student) would be one Bureaucrat and one Engineer, who would also be the backup, However, such low role coverage should be avoided if possible (likely either/both mentors would also be architect or designer, or there may not be enough expertise)

A regular team (moderate item & student) would be 3+ mentors spread across roles A, B, D, E, any one person likely checking more than one box. 2+ Engineers is ideal for better time and effort coverage for PR review and testing.

A "party over here!" team (flock of mentors on a popular item) should focus on excess capacity in Engineers, keeping a primary Architect and/or Designer to avoid divergent architecture/design. Good opportunity for Es to learn more about A & D and take on such a role in a future project themselves.

• Architect - moderate time requirements, moderate importance. Person knows the related code well enough to be an authority on the topic (or is the closet thing we have to one) and helps with planning. Helps the student and others arrive at a solid architecture (following solid coding practices, good performance, etc) through planning sessions and light PR review, focusing on structure, not necessarily testing. Not required for a project but highly recommended. PR reviews along the lines of "Yeah that design looks good, although I haven't tested it".

• Bureaucrat - low time, highly critical. Knows how GSOC works. Responsible for filling out student evaluations (which means you need to follow closely enough to know how the project is going), organizing and attend the weekly meeting, keeping the GitHub project board accurate, and make sure the whole group is engaged (student is active, mentors are helping out the best they can). Special: every project should have a secondary Bureaucrat or a follower with the ability to step in if needed (if the primary goes MIA)

• Consultant - low time but high skill. Has been identified as valuable on one of more topics that may come up. Won't necessarily engage on own initiative. Anybody on the team can poke a consultant to please help out when relevant, and especially Bureaucrats should keep Consultants in mind. Typically Consultants would be longer term experts with limited time who are reluctant to commit to an entire project (scope and/or duration)

• Designer - moderate time, moderate importance. Understands the end user functionality desired by the project, and helps make sure the project is outputting functionality that actually does what it is supposed to do, leading to a good user experience. Helps refine the students proposal through planning sessions, focusing on the end user experience. Performs some usage testing, with a focus on stuff working as intended, not just as written. Compares to the Architect and is likewise optional but highly recommended (in theory the student is the default Designer and their proposal the initial design). PR reviews along the line of "I haven't reviewed the code in detail but the game works and does what it should!"

• Engineer - high time, high importance. Does main PR review and logical testing (stuff works as written, but not necessarily as intended). Assists student with implementation questions, helping with research if needed. Is the "main tank" of the team, with the highest time requirements, but lowest skill requirements. One required, multiple desired (better time coverage and more perspectives). Sort of an in-between role where you can say you assume it is both architected right and designed correctly, where you mostly focus on making sure all the code passes builds, quality checks, the game runs, and it seemingly does what it says it should.

• Follower - low time, low importance. Simply somebody curious enough to follow the project closely to maybe help out, but probably not. May be learning alongside the student. Higher skill individuals could be staying in touch to potentially step in as an emergency backup if needed, but be reluctant to commit to a larger time demand up front otherwise.

When to check the boxes?

On our Trello board where we organize possible student projects each student card (which eventually defines a project) has a set of checkboxes for the Mentor Roles. Idea is that mentors signing on to a role adds their name to that role's line. An org administrator should verify with that mentor that they understand what they're committing to and "sign off" on that role by checking the checkbox.

If more mentors join the same role the process should be followed again to double check that all mentors are committed and happy to work on the project together.

Note that the Trello board mentioned here is a private mentor-only board. We also have a public Trello board listing GSOC ideas

Relation to project departments

Maybe "Department" is a better word than "teams" to think of the badges in the forum, should we get more serious about them. Then those departments map neatly to the mentor roles, providing additional indicators or who to maybe recruit to fill a given role.

• Architect == Architect. No surprise there
• Bureaucrat == Logistics. Support crew / Operations
• Designer == Designer. Yep
• Engineer == Contributor and maybe the most interesting link

This allows for a nice flow from general contributor to stepping up to provide more engineering capacity in mentoring contexts. As more is learned architecture or design might be a next step. Not as much is expected from "plain" engineers than from architects or designers.