Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What are stay-alive conditions? #195

Open
10 tasks
shereefb opened this issue Feb 29, 2016 · 3 comments
Open
10 tasks

What are stay-alive conditions? #195

shereefb opened this issue Feb 29, 2016 · 3 comments
Milestone

Comments

@shereefb
Copy link
Contributor

Context

What mechanics / stats keep a player in the game

Criteria

  • Make clear and objective processes / metrics / stats
  • Determine the thresholds for how a player stays in the game / gets kicked out in terms of processes / metrics / stats (doesn't always need to be a number)

Principles razor

  • Cultivate a learning community.
  • Prioritize scale over quality
  • Align incentives
  • Build a team game
  • Trust people's intentions and potential
  • Enable self-organization & self-determination
  • Map feedback loops
  • Optimize for agility
  • Simulation not preparation
  • Sustain the tension between individual and collective gain
@tannerwelsh
Copy link
Contributor

A few thoughts on principles for designing the conditions.

  1. State of “aliveness” is always transparent (feedback is clear)
  2. Focus only on their ability to integrate feedback
  3. No ex-post-facto laws/conditions
  4. Assessment/audit timeline is predictable

Deriving from these, here are some proposed stay-alive conditions, expressed as the terms of the learner-investor contract and the stats and processes that back them up:

Learner-Investor Contract: Terms

  1. LEARNER agrees to adhere to the schedule and to be on-site every workday.
  2. LEARNER agrees to set, work on, and review both team and individual relevant stretch goals (RSGs) on a weekly basis.
  3. LEARNER agrees to “pair left” and “pair right”* with team members, team leads, and other learners.
  4. LEARNER agrees to give kind, contextualized, and actionable feedback to other learners.
  5. LEARNER agrees to relate to themselves, their team, and other learners with integrity, dignity, and kindness.

Learner-Investor Contract: Assessment Method

The terms of the contract will be assessed as such:

  1. Review weekly hours engaged (HE). Contract is void if WHE < 30 for 3 consecutive weeks or a total of 5 weeks, whichever comes sooner.
  2. Review RSG velocity. Contract is void if velocity increases by < 10% week over week for 3 consecutive weeks or a total of 5 weeks, whichever comes sooner.
  3. Review hours engaged in pairing sessions (HE-Pairing) per phase. Contract is void if learner completes < 40 hours for 3 consecutive phases or a total of 4 phases, whichever comes sooner.
  4. Review feedback score (FS). Contract is void if score is below 60% for 3 consecutive weeks or a total of 5 weeks, whichever comes sooner.
  5. Review feedback integration ratio (FIR) per phase. Contract is void if ratio is < 1:1 for integrity, dignity, and kindness feedback for 3 consecutive phases or a total of 4 phases, whichever comes sooner.

Game Stats

  • Hours engaged (HE)
  • RSG velocity: value/weight of goals achieved / week
  • Hours engaged in pairing sessions (HE-Pairing)
  • Feedback score (FS): feedback quality
  • Feedback integration ratio (FIR): feedback integrated / feedback unintegrated

Game Processes

Logging hours engaged

Learners log their daily activities, including the type of activity and duration (increments of 15 min).

Setting RSGs

TBD

Logging pairing sessions

TBD

Giving feedback

TBD

Integrating feedback

TBD

* “pair left” and “pair right” use the driver/navigator analogy with a driver assumed to be sitting in the left seat. Therefore, to “pair left” is to drive a pair with a less experienced navigator/observer, and to “pair right” is to navigate/observe a pair with a more experienced driver.

@tannerwelsh
Copy link
Contributor

Proposed solution in #273.

In brief:

  • There are no game stats that determine how a player "stays alive"; stats are always for player's benefit to help them learn, but do not put them at risk of "failing"
  • Learners can only get kicked out for breaching a Code of Conduct (set of behaviors/agreements)

@shereefb
Copy link
Contributor Author

I really like this as a start.

Only red flag is that now stats don't have teeth. But maybe that's ok.
Feels safe enough to try.

On Thu, Apr 14, 2016 at 8:59 AM Tanner Welsh notifications@github.com
wrote:

Proposed solution in #273
#273.

In brief:

  • There are no game stats that determine how a player "stays alive";
    stats are always for player's benefit to help them learn, but do not put
    them at risk of "failing"
  • Learners can only get kicked out for breaching a Code of Conduct
    (set of behaviors/agreements)


You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
#195 (comment)

"When they tell you to grow up, they mean stop growing.” ~Tom Robbins

@tannerwelsh tannerwelsh removed their assignment Mar 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants