Avoid infinite activity score orders
Items with a zero activity score were getting an activity sorting score
of -infinity, because we base the value on log2(score). Adjusting the
calculation avoids this edge case, by always basing the sorting score on
a non-zero number.
---------
Co-authored-by: Kevin McConnell <kevin@37signals.com>
This introduces a more dynamic system of activity scoring, to improve
the way bubbles "bubble up" due to their activity. There are a few
different parts we can tune here, and it's likely we'll need to make
adjustments once we get a feel for how this works in practice.
The basic idea here is:
- We assign points for certain types of event that happen on a bubble. A
boost gets 1 point, a comment gets 10 points, and so on.
- These points decay over time, at a rate of 50% per day. So old
activity is worth much less than new activity. Bubbles should rise up
quickly when acted upon, bit will float back down if left idle.
- Some comments can score higher than others: the first comment from
each person on a bubble is worth more (20) because it signals that
more people are getting involved; and comments that follow a comment
by a different author are also worth more (15) because that signals
there's ongoing conversation between people, not just a series of
notes being left by one individual.
In terms of implementation, we persist the score on the bubble
whenever it changes, but we handle the decay on the client side. That
allows us to cache the bubble representation without having to
continually change it while its activity decays.
We also keep a separate `activity_score_order` attribute on the model.
This can be used to sort the bubbles in order of "most active", without
having to think about the decay.
When displaying a bubble in the `creating` state, we were wrongly using
the plaintext version of the draft comment. This has the effect of
losing formatting whenever the page is saved and reloaded.
We're already sending everyone the "published" notification, and for
assignees that will include the assignment message. Tracking the event
again here would just duplicate that.
We use a true/false preference so we can tell the difference between
disabling the watch vs never having the watch. This is so we can toggle
off and on the preferences for a container (like the bucket) without
losing any bubble-specific preferences.
* main: (27 commits)
Leave some space for the tray
Let's not assume it's a due date
Avoid overlap
Let's try without the big drag button, extend beyond the column a touch
Tighten labels
Match notification dot
Spacing
Add more context
Avoid leaving the tray open
This shouldn't be here
Paginate the read notifications
Add a test case
Split up a big view
Allow filtering by stage
Send beacon request on disconnect as well
Wire up notifications "Mark all as read" button
Add unread dot
Set state for when there are no new notifications
Move to right side, smooth transition
Open tray on click, stub mark-as-read button
...
Previously when an item was `created`, we'd track the event, update the
summary text, and broadcast the notifications. But now that we have a
draft state, we shold do all of this when it's published instead.
Kevin McConnell