Keep track of which WordCamps each profile has spoken at and organized

[iandunn]

There's a design flaw in the Profiles association handler which may be contributing to bugs like #681 and #683, but will definitely cause other bugs at some point, even if those two tickets turn out to be caused by something different.

We're assuming that a profile is only going to be associated with a single WordCamp, which will cause problems if certain situations. For example,

1. Jane Doe is added as a speaker for WordCamp Boston 2014. She hasn't been a speaker before, so when the association notification is sent, the Speaker badge is added to her profile.
2. Nine months later, she's accepted as a speaker for WordCamp Boston 2015, and another notification is sent. The badge already exists, so nothing changes.
3. A month later, she has to cancel, so the notifier sends a request to remove the association for Boston 2015. At this point she should still have the badge, because of her association for Boston 2014, but the badge is removed because we're not keeping track of how many camps she's spoken at.

The same situation applies to organizers.

When adding a profile to the Organizer and Speaker groups, we should store the WordCamp ID associated with that action. Then, when we remove an association, we should check if they have other associations before removing them from the corresponding group.

[Otto42]

Question: When the removal notice is sent, does the profiles site basically just remove the activity associated with the initial add notice? So, if I am a speaker, and then not a speaker, does any record of being a speaker remain in the activities list?

If so, then instead of adding/removing from the group, could we not simply select across the activity log to see if any speaker activities still exist at all? If the removal removes it, then they will continue to have the badge because another exists that was not removed. This could be a very simple select to display the badge or not, and eliminate the group need.

[coffee2code]

@iandunn: Unfortunately, the BP groups feature does not have membership meta. However, the removal request could include the wordcamp_id as had been sent for the add-activity request (assuming the id represents a specific year WordCamp). handle_wordcamp_association() could be modified to check the activity stream to see if they were added as an organizer/speaker for a WordCamp != wordcamp_id. If they aren't reported as being an organizer/speaker for another event, remove the association.

@Otto42: The association handler is pretty straightforward: if the service requests a user add or removal from an association, then it simply does that. Handlers are custom per-service, so the WordCamp handler could definitely be customized (as I noted to Ian).

Could the badge be based solely on the activity log query you suggest rather than a group association? Sure, but we go down the path of having more custom run-time badge determination querying and logic. Will that query scale for how immense the activity log will get, or scale for handling of similar custom badge querying? Maybe. One goal I had was to prevent run-time determination of things that are known and relatively unchanging.

Another way to approach this is to have the WordCamp activity handler also handle the association management. If we added the ability to send a remove (or undo) activity, then an previously reported activity entry could be removed from the activity stream and group association could be re-evaluated.

All the suggestions mentioned heretofore presume we know the full organizer/speaker activity history (or that we retroactively add them).

[Otto42]

@coffee2code Main reason I asked was that I figured we were already pulling the activity log for a user when displaying the profile, so maybe a check on the data there wouldn't be an extra query. But I assume that we're not pulling the full log, just the most recent, so yeah, that might not scale.

[coffee2code]

Or, the association handler could remain simplistically as-is and the activity notifier (i.e. the WordCamp side of things) could be modified to not blindly make the association removal request. It can more ably and reliably determine if the user in question should no longer be considered an organizer/speaker.

[coffee2code]

@Otto42: Yup, a user could have thousands of various activity records which won't all have been already queried for since we'd only be getting a paginated subset for display. We'd have to specifically query the log for an instance of this specific activity. Which is definitely valid, but could be more efficiently done in the activity handler instead of the profile page.

[Otto42]

I did think of having wc not send the removal there, but really I think it's more work that way. It would need to check every separate blog on that network (1 per camp per year), which might be a lot more effort and also doesn't scale. Additionally, it's sending the fact of association with this wordcamp at this year, which is something we'd still want to add/remove from the activity list regardless, so the message probably still needs to get there anyway.

I agree that having the handler check before adjusting the badge group is a better plan.

[iandunn]

When the removal notice is sent, does the profiles site basically just remove the activity associated with the initial add notice?

The handler doesn't support removing activity, only associations, so the notifier doesn't send a request to remove activity, only one to remove the association.

...the removal request could include the wordcamp_id as had been sent for the add-activity request (assuming the id represents a specific year WordCamp)

The WordCamp.org notifier is already sending the wordcamp_id for removal requests, and it's unique to city and year. It's the site ID in the multisite network; e.g., 364 => 2014.sf.wordcamp.org

[iandunn]

I agree that having the handler check the activity log, and having the WordCamp.org notifier check all sites, will both have scaling problems, and seem to be more complicated than necessary.

I was picturing that the association handler would store a usermeta field with a multidimensional array for all associations that are based on multiple values. e.g.,

array(
  wordcamp_organizer => array( 230, 317 ),
  wordcamp_speaker   => array( 72, 158, 238, 407 ),
)

When the handler receives the notification that a user is speaking/organizing a camp, it pushes the ID onto that array, then removes it when it receives notification that they stepped down from the role. Before actually removing the badge, it checks if there are any IDs left in the corresponding subarray.

That approach could also help if we want to build more automation around team participation. e.g., X number of handbook edits within Y months automatically makes you a member of the Docs team, and we store a page_id => timestamp entry in the subarray. (That's a simplistic example and probably makes lots of objectionable assumptions; I'm not suggesting that exact scenario, just illustrating the possibilities.)

The usermeta approach wouldn't fix things retroactively, but we could manually fix the small number of problems that get reported, or build a script to populate the array once based on the activity logs.

Does anyone see any problems with that approach?

[iandunn]

Actually, now I'm thinking that Scott was right in comment:6, it makes more sense to handle this on the notifer side than the handler side. The notifier has direct access to all the relevant data required to make the decision on whether the association should be removed or not. If the notifier tells the handler to remove an association, it doesn't make sense for the handler to try and figure out if what the notifier asked it to do is correct or not.

Checking if a given username has spoken at/organized other camps is an expensive query, but we don't need to run it each time a speaker|organizer is added|removed, we can just build an index once a day that contains the number of camps each user has spoken at/organized:

Array(
    [23430] => Array(
        ['spoken'] => 5,
        ['organized] => 3,
    ),
    [3523423] => Array(
        ['spoken'] => 0,
        ['organized] => 2,
    ),
    [n] => [...]
)

When they're added|removed from the speaker|organizer post, we can update the index and then check it to see if the speaker|organizer still has a positive value, and send the removal command based on that.

I'd have to run some tests to see how large that array would be; maybe it'd eventually get too big to store in wp_options, but if that's the case we could probably stick it somewhere else.

[SergeyBiryukov]

Replying to iandunn:

Array(
    [23430] => Array(
        ['spoken'] => 5,
        ['organized] => 3,
    ),
    [3523423] => Array(
        ['spoken'] => 0,
        ['organized] => 2,
    ),
    [n] => [...]
)

...
I'd have to run some tests to see how large that array would be; maybe it'd eventually get too big to store in wp_options, but if that's the case we could probably stick it somewhere else.

Wouldn't it make more sense to store the spoken/organized numbers in user meta? That seems like exactly the kind of data user meta is generally used for. It also wouldn't need to be refreshed daily, only when someone is added or removed as an organizer or a speaker.

[vedjain]

Fixed in r8907