Move responsiveness into user/tokens/views so we can pester using it

[rfay]

We should be able to send email to people based on responsiveness. That just requires a bit more work on the responsiveness rating to move it into user object as first class field.

Probably the responsiveness is not what should go there, but rather the received count and the answered count. That way we could filter people that had received a lot of messages but who didn't typically answer.

[gregh711]

Is there anyway that W/S can mail a letter or survey to people on W/S and ask them to update there info and why they are not responding to requests

[rfay]

We can email any set of people. That's what we do every January. However, we try to keep emails to a minimum so we wouldn't want to email the 63% who are responding, or those who are not available for hosting.

This issue would allow us to select the unresponsive people.

[gregh711]

This true but some of them may have changed there email and did not update it on W/S I was thinking more on as a survey with a update in it. The survey could be about have you hosted and if so how were your guest. And have you updated your in on the W/S web page. That way you don't upset the ones how have been keeping it updated. Just a thought

[rfay]

It's really hard to reach people who have changed their email :-) We delete those annually. Appreciate your thinking!

[gregh711]

Thank you Rfay

[kalpaitch]

Hi Randy, your solution seems to be a good one, to store the user's responsiveness rating in the db as a first class field.

However, might I propose an alternative option in making the responsiveness property a pseudo-field (d7) and then exposing this to views and tokens. Two main reasons - 1) This way you're not storing the record set and the calculated data as two separate pieces of data, I'm looking at this as a kind of duplication of information which could conceivably get out of sync (does the responsiveness rating change if a pm that hasn't been responded to is deleted? We'd need to consider all actions which would re-trigger calculation). And 2) It wouldn't need any batch jobs to be run on current users. #thinkingoutloud.

[rfay]

I would figure that calculation would always happen whenever a message was accessed. We could certainly use a pseudo-field, but it's a fairly expensive query (which amazes me that we get away with it at view time). So it's really performance that argues for storing in the db. I agree we have to be careful, and probably have to make a recalculate option or something. And really every message hook needs to recalculate.

I don't really want to do this one while we're doing D7 because nothing forces it and we're as always trying to contain scope, but if you want it when we get farther you can take it on! It shouldn't be that bad. And will be a big step forward.

[rfay]

@kalpaitch Here is the list of items I had going for responsiveness work: https://www.evernote.com/l/AA-3g9hfxBJDH4QBZifOHQA25MyuXPMSj_s

[kalpaitch]

Thanks Randy, really helpful as always, hope we can do all this someday soon.

[GeertDD]

+1 for access to responsiveness stats through the API. Could use it for my map with colorized markers.