search

LearnersGuild / echo

learning management system
MIT License
3 stars 31 forks source link

Players have Experience Points #500

Closed jeffreywescott closed 7 years ago

jeffreywescott commented 7 years ago

@jeffreywescott commented on Tue Aug 09 2016

(depends on #501)

Strategic Goals this issues impacts

Experience Points (XP) are how we measure productivity and duration of practice. They are roughly equivalent to "effective hours worked", but with more nuance.

XP are measured in hours, up to two decimal places. They can grow indefinitely, but will never recede. In this sense, they are different from a "health" stat that fluctuates.

Eventually, we'll likely introduce gating or leveling mechanisms around XP, to create semantic distinctions between a player with 50 XP and one with 5000 XP.

Data Sources

For each project, use the following data from retro (note: depends on #68):

To calculate XP earned for a single project, use the formula:

XP = total hours contributed * relative contribution * mean internal project completeness * mean internal project quality

Where:

For example, given the values:

player 1 hours contributed = 40
player 2 hours contributed = 45
player 3 hours contributed = 10
player 1 actual contribution = 0.14
mean internal project completeness = 0.89
mean internal project quality = 0.94

Then XP player 1 for working on this project for this cycle is 11.12

XP = ( (40+45+10) * 0.14 * 0.89 * 0.94) = 11.12.

Addenda:

Update the post-project DM to each team member to include XP: 

**RETROSPECTIVE RESULTS:** #${project.name}

**Internal project reviews:**
Completeness: ${project.avgInternalCompleteness} (avg of: ${project.internalCompletenessReviews.join(', ')})
Quality: ${project.avgInternalQuality} (avg of: ${project.internalQualityReviews.join(', ')})

**Feedback from your team:**
${teamFeedbackList.join('  \n\n')}

**Hours contributed:**
Team size: ${team.length}
Your hours: ${stats.hours || 0}
All team hours: ${stats.teamHours || 0}

${teamHoursList.join('  \n')}

**Contribution to the project:**
Self-assessed: ${stats.rcSelf || 0}%
Team-assessed: ${stats.rcOther || 0}%

Your estimated contribution to the project: ${stats.rc || 0}%
Expected contribution for # of hours: ${stats.ec || 0}%
Contribution difference: ${stats.ecd || 0}%

**Stats earned for this project:**
Experience Points (XP): ${stats.xp || 0}
  = (${stats.teamHours} team hours * ${project.avgInternalCompleteness} completeness * ${project.avgInternalQuality} quality * ${stats.rc} contribution)
Culture Contribution: ${stats.cc || 0}%
Team Play: ${stats.tp || 0}%

Original issue: https://github.com/LearnersGuild/game/issues/150

@tannerwelsh commented on Wed Sep 14 2016

update language and then move to RFI

@tannerwelsh commented on Thu Sep 22 2016

Builds towards goal: !Learner stats match our subjective reality, elicit honest feedback, and promote self-directed, collaborative growth

@shereefb commented on Thu Sep 22 2016

related #501

@tannerwelsh commented on Thu Sep 22 2016

updated description

@tannerwelsh commented on Thu Sep 22 2016

ready for review @shereefb + @LearnersGuild/software

@shereefb commented on Fri Sep 23 2016

Love it. One suggestion is to show the math behind how XP was calculated. Which contributes to: - !Players know how to increase low stats

**Stats earned for this project:**
Experience Points (XP): 11.12 ( (40+45+10) * 0.14 * 0.89 * 0.94)
Culture Contribution: ${stats.cc || 0}%
Team Play: ${stats.tp || 0}%

@tannerwelsh commented on Fri Sep 23 2016

incorporated @shereefb's suggestion

@jeffreywescott commented on Tue Oct 04 2016

For each project, use the following data from retro (note: depends on #68):

  • Actual Contribution
    • % of project completed by learner (mean of all teammate's evaluations, incl. self)
  • Internal project review scores (i.e. those submitted by the team members)
    • Project Completeness
    • Project Quality
  • Hours contributed to project per team member

I thought we had moved away from project reviews being used as part of XP? Is the description out of date?

Moving back to Review.

@tannerwelsh commented on Wed Oct 05 2016

@jeffreywescott it depends on having https://github.com/LearnersGuild/game-prototype/issues/68 complete, which is why it specifies internal reviews (i.e. those submitted with the team retros).

@jeffreywescott commented on Wed Oct 05 2016

Got it. Thanks for the clarification, @tannerwelsh.

@jeffreywescott commented on Thu Oct 06 2016

Cannot move this over to implementation because it depends on #68.

@tannerwelsh commented on Tue Oct 18 2016

@jeffreywescott I'm not sure I understand why the inter-issue dependency is blocking movement of this card. Does every issue that gets moved to RFI need to have zero dependencies on other issues?

@jeffreywescott commented on Wed Oct 19 2016

@tannerwelsh how can something be "ready for implementation" if another issue is not yet "ready for implementation" and it is a dependency? I look at "ready for implementation" as a signal that it can move to the implementation board and be prioritized, but if it is dependent on issues that aren't also ready ... that's not the case, right?

How do you look at RFI?

@tannerwelsh commented on Thu Oct 20 2016

@jeffreywescott yes I see it as the same, but in this case its dependency is in RFI also, so they could both be moved over at the same time. Might just be a case of review-lag. When you wrote that it couldn't be moved to implementation, the dependency was still in review. But now it's not. :)

@jeffreywescott commented on Thu Oct 20 2016

Ah -- okay. Thanks ... planning to review the RFI column sometime today.

jeffreywescott commented 7 years ago

@shereefb / @tannerwelsh: opinions on whether this is critical for Q1 2017?

tannerwelsh commented 7 years ago

Part of "in the red", so yes

jeffreywescott commented 7 years ago

Tracked here, closing.