mirror of
https://github.com/discourse/discourse.git
synced 2026-08-06 06:24:48 +08:00
bf0128fa86The engagement dashboard's "Trust level pipeline" showed each level's
membership
plus direction-blind "moves in / moves out" counts, colored by
**position**
(in vs. out). That mislabeled healthy movement: a member graduating
*out* of Tiers, especially New,
rendered as a red ↓, reading as negative when it's the best possible
outcome.
This PR reframes the widget as a **directional arrivals funnel** with a
focus on the flow, and specifically looks at promoted/demoted-in
## Design thinking
- **Direction, not position.** Trust-level movement has a meaningful
axis —
up (promotion) is good, down (demotion) is not. We split every move into
`promoted_in` and `demoted_in`, drop the double bars, and colour by
direction: if more promotions => green, if more demotions => red.
Leaving New is now correctly green.
- **An "arrivals" funnel.** Each rung answers one consistent question:
*how many
members arrived here this period?* For every bar it's tracked the same
way + we add an extra label for the tier that is set as the `Default
trust level`.
- **Sign-ups ≠ promotions.** Signups are excluded from both the trend
and the bar scale. It's volume would otherwise often dwarf the other
bars.
## Backend — `reports/trust_level_pipeline.rb`
- **Snapshot** per level: `User.real.group(:trust_level).count` + share.
No date
filter — it's the current distribution, not a period metric.
- **Directional arrivals** from `user_histories` (`change_trust_level` +
`auto_trust_level_change`) within the period: `promoted_in`,
`demoted_in` per level.
- **Sign-ups**: real users created in the period, attributed to the
entry level
(`SiteSetting.default_trust_level`). Not counted as trust-level moves.
- **Trend** (`prev_period`): net = promotions − demotions across the
ladder
(sign-ups excluded) → `climbing` / `dropping` / `stable`.
## Known limitation
The `Default invitee trust level` is not taken into account, which means
invitees can be counted at the wrong rung.
However, accounting for it correctly means distinguishing invited from
organic sign-ups (joining through invites, and handling that a user's
trust level may have moved since they joined), which introduces a second
entry point. That breaks the widget's core simplification and adds
complexity. Overall I'm expecting the % of invitees to usually not
meaningfully muddle the representation of the pipeline flow.
|
||
|---|---|---|
| .. | ||
| reports | ||
| acl_target.rb | ||
| anon_cache_invalidator.rb | ||
| cached_counting.rb | ||
| category_hashtag.rb | ||
| custom_field.rb | ||
| has_custom_fields.rb | ||
| has_deprecated_columns.rb | ||
| has_destroyed_web_hook.rb | ||
| has_nested_reply_stats.rb | ||
| has_post_upload_references.rb | ||
| has_sanitizable_fields.rb | ||
| has_search_data.rb | ||
| has_url.rb | ||
| limited_edit.rb | ||
| locale_matchable.rb | ||
| localizable.rb | ||
| positionable.rb | ||
| reviewable_action_builder.rb | ||
| roleable.rb | ||
| searchable.rb | ||
| second_factor_manager.rb | ||
| stats_cacheable.rb | ||
| topic_tracking_state_publishable.rb | ||
| trashable.rb | ||
