Event tracking

[enrico-ghidoni]

Discussion for how the attendance tracker should work.

The django-roster uses a complicated way of parsing an list of attendees through Steam's API every X time during a scheduled event (Tuesday and Friday). We could greatly simplify the logic, pasting Discord convo between myself and @milivojm.

1. Define the concept of community event and make it editable by someone (i.e. Tuesday and Friday events with start and end time). This means defining something like ArmaEventRecurrence that should be editable by users to identify community events that we want to gather attendance data of.
2. Have something kick off an event tracker at the start of each event, essentially starting a recording of what happens on the server. MassTransit can handle scheduled domain events (i.e. ArmaEventStarted) and it already works for handling the recruitment stage.
3. Have a set of code that constantly (i.e. every minute) checks who is online through Steam's API and matches the retrieved usernames with the members of the community (from Roster). The frequency of polling Steam API can be arbitrarily changed and should be included in a setting. Do we keep data in memory (dangerous if the service breaks) or do we store it in the DB (slower)?
4. Once the event has finished, the tracking script should update the attendance for said event in a streamlined format (i.e. only username and attendance ratio, like what percentage he/she/they were logged with respect to the event duration). The attendance service could raise a storm of ArmaEventAttended with information regarding Nickname, Ratio, ArmaEventId and consumers can then store the data in the DB.
5. Take it from there on the domain level to check attendance (i.e. attendance over 50% means event attended). On the domain level we can issue a EnoughEventsAttended event for recruits when they attend more than the required amount of events within 8 weeks and a MemberWarning event for existing members (Reservists and above) if their attendance ratio drops below the minimum required.

[milivojm]

This one will probably wait, we will cheat around by peaking into old roster's table.

[milivojm]

Right now end user can use a form action to explicitly state member has attended enough events. This one might be really too much for MVP?

[enrico-ghidoni]

From the discussion on Discord reported here, we also have to deal with the annual hiatus period. During this off time, attendance should be ignored. This could be achieved by simply removing the scheduled community events that we will base attendance recording on. For example, Tuesday's and Friday's missions would be set in stone but every year member with SSgt rank should tell Roster the start and end date of the hiatus period.

For this purpose I suggest we shape the whole event management, attendance tracker and rank assignment system with the following layers:

• EventManagement stores data on community events (Date, StartTime, EndTime) and collects attendance information from Steam's API by using the mechanism described in the original post (point 4)
• AttendanceMonitor consumes the event storm generated at the end of each community event and checks the different conditions for every ArmaEventAttended and the linked member's rank. This layer should fire events if a member needs promotion/demotion and is thus responsible for checking all the scenarios
• RankManager consumes promotion/demotion events from AttendanceMonitor, updates the rank for a member and fires MemberPromoted and MemberDemoted events accordingly. (Note: a MemberPromoted event already exists, I suggest either splitting the event into MemberPromoted and MemberDemoted or changing the name to MemberRankUpdated in order to better reflect the domain)

---

Considering the complexity of this module I agree it's too much for MVP. Let's keep discussing how the end result will work but in the meantime we could do with a simple rank selection on a member's page. Not really sure how we could show attendance data before it all gets automated though.

[milivojm]

Solution seems viable with one problem. Ranks are in Roster context and Roster context is responsible for changing ranks and firing MemberPromoted events (acting as source of truth). That's why I suggested some different event which would indicate "hey man, this member has enough events to be promoted". Not sure about naming though. :)

[milivojm]

Silly me.

Event management context could send commands like PromoteMember and DemoteMember. That can trigger changing ranks, so it could work.

Event driven architecture consists both of Events but also Commands.

[enrico-ghidoni]

I would still separate the attendance data collection from the promotion/demotion logic. The latter could be still part of Roster.Core right?

[milivojm]

Definitely separate.

[enrico-ghidoni]

Okay then, it was mainly in response to your reply on the layer draft. What I mentioned as RankManager could very well live inside Roster.Core IMO

[milivojm]

We agreed to make a small a client Steam API - fetch users from server. We should introduce a Hiatus concept.

[milivojm]

Main loop

One tick is 5 minutes. I didn't go into details of PromotionService because it's algorithm.

Interaction diagram

Class diagram

[milivojm]

Use case diagram

[milivojm]

Slightly refined class diagram without cluttering infrastructure interfaces (repositories). Since there are many types in here, implementation tasks will be type-based, not interaction based to prevent conflicting commits.

[enrico-ghidoni]

Quick question about the event scheduling part. What happens if the community wants to change event schedule mid-year? For example, if Tuesday is abandoned in favour of Monday? I know it has never happened so far but just out of curiosity how would Roster handle that?

[milivojm]

Good question. Maybe it would be better to remove Year and instead add StartDate and EndDate for Schedule. That would basically make schedule as time limited entity.

[milivojm]

Tentative list of tasks (story points estimate):

• initialize project - 1pt
• create empty database EventManagement - 1pt
• connect to event bus via MassTransit - 1pt
• create skeleton (without implementation) for foundation types IServerAdapter, EventMonitor, Event, Schedule, IPromotionStrategy, Member, Attendance (lead engineer) - 3pt
• implement aggregate tasks:
  • Event - 1pt
  • Schedule - 2pt
  • Member - 1pt
  • Attendance - 1pt
• create and implement repositories using generics and Entity Framework (see Rooster Core for inspiration) - 5pt
• implement PromotionStrategy - this one is arguably the most difficult task - 8pt
• implement IServerAdapter - 2pt
• glue it all together in EventMonitor - 2pt

12 tasks altogether, 28pts.

This epic should be done in two iterations:

1. Promote/Demote members - basic functionality for event tracking, no user interface
2. Schedule Arma events - user interface included for changing schedule, viewing attendance, announcing hiatus

[enrico-ghidoni]

Maybe it's the wrong place for this, but how do you think of implementing the Tick()? Recurring event on the bus?

[milivojm]

All hosted services are running in an async loop. All you need to do is insert a Task.Delay(5 minutes) in that main loop.

https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.delay?view=net-6.0

[enrico-ghidoni]

Right-o