I'm working to implement a contrib-friendly Radioactivity value per-group at #1710724: Default Radioactivity integration and provide listings such as "Most active groups" based on Radioactivity.

It seems there are two main ways of implementing this. It would be great to get feedback from folks with more experience working with Radioactivity on the merits of these approaches.

A) For each incident on a node in a group, also create an incident for the group.

Benefits
- Rasy to implement
- Radioactivity manages group radioactivity value for us.

Possible drawbacks:
- We would be creating and processing at least double the number of incidents for each event that happens on the site. If a node is in 3 groups, we'd be creating x + 3x incidents for each event.

- We'd probably need to offset changes in group radioactivity when nodes are reassigned between groups. For example:

There's a heated conversation in the Design group on a post, "What
makes a great designer in NYC?"

It has a lot of comments and likes, and so its level of activity is
high. As a result, the Design group's activity is high.

However, because of the heated nature of the post and because it's
specific to NYC, people agree to move it out of the Design group and
into the "NYC Designers Only" group.

It would likely be counterintuitive for that historical activity to remain in the "Design" group and not transfer to the NYC group. We could potentially work around that by subtracting the current radioactivity value of the post from the former group and adding it to the new one.

B) Update group radioactivity periodically:

In this approach, we'd create a separate process that manually assigns a Radioactivity value to each group based on the sum of values for nodes in the group.

Benefit:
- We don't create duplicate incidents on a per-group basis.

Drawbacks:

- This approach has its own complexity: We'd have to calculate the radioactivity for a group based on the current value of each node in the group
- We'd have a Radioactivity field that would be unique from all others in that we're manually assigning a value to it.

Comments

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

I like A without the offset. The biggest reason is that I think there are some group specific energy calculations (user joins, user leaves, group node is viewed, group node is upvoted, node of type x is posted into group, comment is posted on node in group) and I think it will be hard to calculate those inside of scheme B.

Also, if the performance drawback of A becomes a real issue I think the right way to solve it is to queue the incident and process the energy of it in the background. That's the more general solution which would be helpful more...generally.

ezra-g’s picture

ezra-g commented
Status: Active » Fixed

Greg's example seals the deal for me. I think option A (without or potentially with an offset) makes the most sense.

Automatically closed -- issue fixed for 2 weeks with no activity.