### 👉 For the latest updates, jump down to [this comment](https://github.com/or…bit-love/orbit-model/issues/29#issuecomment-665024630)
We first published the Orbit Model as a blog post way back in March 2019. Since then, lots of folks have adopted it, many of you have helped improve it, and we've even built an app based on it 🎉
As the model has matured from a high-level idea in a blog post to a framework that community folks use every day, it’s become clear that it’s time for a “refactoring” to reach its full potential.
Orbit Model 2.0 is our proposal to streamline the model, help it scale to all community types, and become a complete framework for community building.
With that, I'm pleased to share with you this RFC - request for comments - that outlines a set of changes that I and the Orbit team would like to propose and get your feedback on. The changes are sweeping enough that I feel it's appropropriate to call it a full 2.0. So, let's dig in!
### Motivations
Here are some key themes from feedback and long-term goals of the model.
**Some are fairly specific:**
- Orbit level names like Ambassador/Fan/User/Observer don't work for everyone;
- It's unclear who belongs in what Orbit Level;
- It's unclear what role _time_ plays: how does activity/inactivity factor into a member’s Orbit level?
- It's unclear what score I should assign to each activity
**Others are more general:**
- The connection between Orbit metrics and traditional marketing or business metrics should be clearer;
- The model should work for communities of different sizes & shapes (new, established, et al.)
## Proposed changes
To address the feedback and motivations, I am proposing the following 3 changes.
### [outdated] Change 1: Base Orbit Level purely on activity within a recent period
This is the biggest change and is a conceptual leap from how the model works today. New Orbit level definitions would look like this:
| Level | Description |
|---------|----------------------------|
| Orbit 1 | Active in the last month |
| Orbit 2 | Active in the last 90 days |
| Orbit 3 | Active in the last year |
| Orbit 4 | Inactive |
By consequence, when a member does any activity, they pop into Orbit 1 for at least 1 month, or longer if they keep doing activities frequently. If not, each day that passes causes them to slowly drift away.
Previous contribution history doesn't impact a member’s Orbit Level. If even a long-term contributor is inactive for a month, they drop down to Orbit 2, and eventually 3 and 4 if they don't re-engage.
Time becomes an essential quality of the model, addressing one of the key questions about the model mentioned above. The suggested Orbit Level thresholds above are reasonable defaults based on the data we have about developer communities, but the number of days for each level can be configured by each community
So why is time important?
The great thing about time is that it's the same for everybody, and whether a member has or has not done something in a given time period is fully deterministic, given that you're tracking the activity. It either happened or it didn't, so it's a reliable abstraction to build on.
In this approach, Orbit levels would equate with the popular MAU (monthly active users) family of metrics. Reporting your community MAU is easy, it's the current size of Orbit 1. YAU (yearly active) is the size of Orbit 3 (both examples assume the default values above).
Time also provides clear moments to engage & retain your community members. You can know precisely when a member will fall to the next orbit level, just by looking at the date of their last activity. No fancy formula needed. For example, if an O1 (Orbit 1) member has been inactive for 29 days, that's a good time to re-engage them, especially if they're a historically high-Love (highly engaged) member and normally in O1 most of the time.
Finally, a time-based approach to Orbit Levels means we can remove the prescriptive labels like Ambassador, Fan, User, Observer which, unsurprising, have different meanings for different communities.
This approach simplifies the abstractions such that two community managers could have a meaningful conversation about their Orbit One, and each would know exactly what the other meant by those terms.
### Change 2: Remove the concept of activity scores
The original intention of activity scores (weighting some activities higher than others, like counting a blog post more than a newsletter signup), was to be able to aggregate them together to give members a total points score, called Love. Such a score is then useful to compare the relative engagement of members.
This also proves hard to scale. The choice of what score to give an activity is arbitrary, dependent on the community, and never has a correct answer. Is a Twitter mention by a member with 20k followers “worth more” than the same mention by a member with 100 followers? Is a 5k word, in-depth blog post “worth more” than a 300 word superficial one?
Small changes in activity scores can cascade to big changes in the relative engagement of members, which feels wrong. Changing "Twitter mention" from 2 to 3 points shouldn't reconfigure my community metrics to heavily favor Twitter users, but it might because that’s a 50% increase.
This leads us to the next change: how do we calculate Love without activity scores?
### Change 3: Update how Love is calculated
Love is the Orbit Model's relative community engagement score. Love is also the "currency that drives community" (h/t to Erin Frey). I say "relative" because comparing the Love score for two members should tell you, at a glance, which one is more engaged. An absolute value of Love (e.g. 16.2) doesn't have a meaning on its own, except to compare with another.
The current Orbit Model lacks guidance on how to factor in the role of time when calculating Love. That is a problem because time is so important in determining engagement. A member whose activities are more recent should be assigned a higher Love than a member who did the same activities a year (or a month) ago.
There is no one "right way" to calculate Love. It's an equation with many inputs. The member's activity timeline is central, but each community could also apply other signals & data they have too.
Given that, I propose that we lay out some general guidelines and a basic formula for calculating love, but leave the exact implementations open.
Here's one I've that works pretty well when I applied it to some real-life community data. I'll spare you the mathematical formula and describe it in pseudocode. This is one way to calculate the love for one member, based on just the number of activities they did, factoring in depreciation due to time.
```
value(month) = (number of activities) * (0.9 ^ number of months ago)
love = sum of value(month) for the last 12 months
```
Example: I am a community member and did 1 activity in March and 2 in June. Today is July. My love is:
```
love(josh) = 2 * (0.9 ^ 1) + 1 * (0.9 ^ 4) = 2.4561
```
There are many ways to enhance and customize the equation to fit your needs best, which can be a topic of future conversation.
## Supporting visuals
*Heatmap-style visualizations are useful for showing engagement over time, without scores or complicated formulas.*
*Equations like Love above can produce useful trendlines for member engagement:*
# You've reached the end!
That's amazing. I want to give you a hug just for that. But this also means that you're dangerously close to the box where you can add your comments and reactions to anything that you've seen in here. Please do and let's discuss 👇
ℹ️ If you can add your first comments by July 31, or as soon as possible, that’d be of great help. Thank you!
