Leveling Up

Moving from Open Source Contributor to Doer

Motivation

On the Web Team, we lacked a framework for making decisions about who should be in linear.app, when someone should join standup, what groups do we add them to and what are our expectations, etc.

This is a set of guidelines to help us frame this conversation. It’s expected that this will evolve over time based on things we see working really well, and also problems we run into.

Anytime the team has a disagreement about when or how to bring someone in deeper, the outcome of that discussion will be updates to these guidelines.

Web Team - Open Source Contributor Levels

wOSC I -> wOSC II

To move to OSC II

• At least two individual sponsors of OSC III or higher
• Completed at least one issue of significant size and complexity
• Or, have completed multiple issues showing a pattern of quality and thoughtfulness
• It takes less time to ask the person to do the work and review their work, than it does for you to do the work yourself
• Demonstration of quality code

Questions to Ask

• Will they add value to the conversation in YFI Web?
• Will they respect coordinape and opt-out when they’re not contributing?
• Is their work at least the quality level of a promising junior engineer?
• Has any of their completed work caused regressions or serious bugs?
• If so, do we believe they’ve learned from this experience? Or is this a recurring behavior?

Who asks these questions & who makes this decision?

• Web team
• It’s not required for the team to vote on this, but they should be made aware the person’s being elevated

​

Web Team

wOSC II -> wOSC III

To move to OSC III

• At least two individual sponsors from doers
• They’ve been given privileged information and haven’t leaked it
• They complete 1-2 issues per week (on average)
• They opt-out of coordinape when not working
• They assign all their gives in coordinape every epoch (soft requirement)
• They are an asset to engineering
• Either contributing strong technical thinking
• Or contributing quality work that frees the team up to focus on more critical items
• They self-structure their work and can succeed even with minimal requirements, reaching out to the right teams as needed
• The team trusts them
• At this point, the person is effectively being evaluated for becoming a doer
• This is not a guarantee
• Some people may not move past this point due to personal considerations, job circumstance, etc.
• We should not promote anyone to this level we don’t think could be doer material

Questions to Ask

• Do they regularly participate in YFI Web Telegram?
• Do they improve the quality of the conversation?
• Could I assign an area of responsibility to this person? (e.g. fix any bugs that come into GitHub on the v2 site)
• Do they follow process?
• Are their tech design tickets of good quality?
• Do they display exemplary attitude in peer review? (i.e. do they take feedback well?)
• Do I have to structure their work or can they self-structure?
• Have they come up with issues to suggest?
• Do they review others work?

Who asks these questions & makes this decision?

• Web team
• Sponsors submit a proposal internal to the web team for teammates to weigh in on / vote on
• A brief summary of the person and poll are submitted to ‘Yearn Web Team Personnel’ telegram
• The summary should touch on ‘questions to ask’, above

​

Web Team

wOSC III -> Doer

To move to Doer

• At least three sponsors from doers, from more than one team
• Will I bleed for this person?
• Do I trust them with my livelihood and my freedom?

​

Questions to Ask

• Have they driven significant technical scope?
• Have they contributed significantly to technical design thinking?
• Do they regularly file quality issues and complete tech design reviews and code reviews?
• Does the team breathe a sigh of relief at locking them in as a full-time doer?
• Have they had constructive, positive interactions with other teams?

Who asks these questions and makes this decision?

• Web team submits a proposal to doers with the sponsors sign-off
• Treasury says if we can afford the headcount
• Ops reviews & approves/disapproves

Web Team

Offboarding Steps

Offboarding Steps for OSC I

• None, just don’t accept their PRs

Offboarding Steps for OSC II

• A brief summary of the person and the reason for offboarding are submitted in a poll to ‘Yearn Web Team Personnel’ telegram
• Consequence
• Ejection from Linear, Coordinape

Offboarding Steps for OSC III/IV

• Offboarding Process
• Trach’s conflict resolution process is followed for one-off incidents. If there’s a pattern of problematic behavior, then the offboarding process is considered.
• A brief summary of the person and the concerns are submitted in a poll to ‘Yearn Web Team Personnel’ telegram
• Outcome of this vote is whether or not the person requires a performance improvement plan
• If performance improvement plan is required, a conflict mediator coaches the individual and shares the performance improvement plan, including steps for the individual to take, and the expected timeline in which the team needs to see the behavior change for them to continue as part of the team.
• The coach meets with this person at least weekly to discuss issues and assist in their performance improvement coaching.
• Once the performance improvement window has passed, a brief summary of the person and the reason for offboarding are submitted in a poll to ‘Yearn Web Team Personnel’ telegram
• This should include details from the performance improvement plan, did they follow it, to what degree, do we have confidence outstanding issues will be addressed, etc.
• Outcome of this vote is whether or not they’re ejected
• Consequence
• Ejection from Linear, Coordinape, Standup

Offboarding Steps for doer

• Similar to steps for OSC III

Invitation

If these sorts of guidelines would be useful for other teams, please feel free to add your own slides! Your levels obviously may be different than ours or have different names, and we’ll look forward to learning from your example!

The pyramid graphic is just a Google diagram (Insert -> Chart -> Process).

Strategists

Note: It seems that the web team’s pyramid can be generalized for most teams (e.g. protocol, subgraph, maybe yMechanics, etc.), however the strategists are different enough in their levels and responsibilities that a new pyramid has been created.

It is currently a very rough draft.

Strategists - Open Source Contributor Levels

Strategists

Coming in from the cold -> sOSC I

• Forums don’t currently work for this
• People reach out to Facu, Sam, Poolpi
• We need some kind of blind drop for strategists
• Yearn can see it, the person can see it, nobody else can
• Keeps people comfortable about sharing
• What’s the strategy starter kit?
• What’s the strategy spec if they don’t know how to code yet?
• Provide a template

sOSC I -> sOSC II

To move to OSC II

• ​

Questions to Ask

• ​

Who asks these questions & who makes this decision?

• Strategist Team

sOSC II -> sOSC III

To move to OSC III

• At least one sponsor from sOSC IV or doer.

sOSC III -> sOSC IV

​

To move to OSC IV

• At least one sponsor from sOSC IV or doer.
• Some kind of selfless activities
• Reviewing strategies from other people
• Being active in the YFI Strategist group
• Helping manage the vaults
• Contributing to evolving the protocol
• Vaults releases
• Creating bugs, raising issues, giving feedback
• Monitoring their strategy in ganache fork and doing harvests
• Letting the group know when something’s off
• Proactively raising issues, preventing stuff from breaking
• Plugging in monitoring and altering
• Updating dashboards with scorecards for their strategies, making sure the thresholds are accurate and up-to-date
• Monitoring underlying protocols
• If you have a strategy using a protocol, you’re effectively the ‘account manager’ for that protocol
• In close communication
• Understanding behavior changes, flagging to yearn team, etc.

Note

• At level III maybe give 50% of strategy profits, the rest go to IV and doers?
• At level IV maybe 100% or whatever is reasonable, the remainder to BRAIN coordinape?

sOSC IV -> Doer

​

​