I see we have a partially-implemented activity log. I'd like to explore this a bit more because I think a lot of community information lies in the actions we take "behind the scenes" — not necessarily who is talking, but who is "keeping the house tidy" and curating. I believe there's a lot of "context collapse" in ongoing discussions when we cannot fully see what is happening within the medium we're talking and it leads to misunderstandings. If we're intentional about what we log and how we show it to add context, we could create a much richer collaborative experience.

There's two types of 'logs' in my mind: system logs and application logs. The former is for technical observability of the system, like error logs and when things changed for troubleshooting. I believe this is covered with the Server Admin -> Logs feature. The latter is informational for all members using the application to understand a timeline of events. I see partially-implemented 'Activities' but it doesn't appear to do much or have any UI today. That's what I'd like to focus on here.

There are a few contexts application activity could happen in:

1. Site
2. Group
3. Discussion
4. User

I'm breaking out 'discussion' as its own (but not 'map' or 'calendar') because I think it uniquely needs per-resource context that the others likely don't necessarily due to volume of changes and user experience. In other words, it's fine to log 'Edited an event' at the Group level, because it's unlikely the volume is high enough to matter. Conversely, if we log every comment edit at the Group level, it'll be too high-volume and difficult to understand.

For each context, we'd want to define (likely in this order):

1. What is helpful to know, and why? (data)
2. Where is it helpful to show that activity? (UI)
3. How will we filter, sort, or search it? (architecture)

That will inform how we design it in the product, which will inform how we collect & store the data. Once we have a nice set of these, we can start to look at whether it's best to use an existing tool (e.g. spatie/laravel-activitylog), do something bespoke, or something in between. My quick look at existing tools suggested they are better at system logs than in-app logs, but we'll see!

Lastly, I wanted to list a few things Activity is NOT (in my mind):

• Revision history ("it was X and now it is Y" — this is a separate feature)
• Audit trail (this is a system log)
• Immutable ("once recorded, it is forever" — e.g. maybe we want to combine activities retroactively for ease of use)
• Trigger ("if 3 activities of X are recorded, do Y" — this is a separate feature)

I think if we keep this focused on communication it will be a great tool, but if we try to make it responsible for many other concerns, it will quickly balloon into a difficult feature to implement & maintain.