Adjust Like/Dislike -- include an option to request a response to a comment and a way to see that stats

[swcurran]

We recently received a "dislike" with a valid comment that I would have liked to respond to, but there was no email address available. As well, it would be nice for users to be able to just Like/Dislike without getting a "make a comment" box that they have to cancel. I recommend the flow be:

1. Offer the "Like/Dislike" as today.
2. On click, record a record of the click -- like/dislike and date/time.
3. Change the Like/Dislike to "Submit a comment/suggestion" and have that as the footer for the remainder of the session. This would prevent submitting multiple like/dislikes in a session.
4. If they click to submit a comment/suggestion, take them to the "normal" request page that includes the being able to make a comment/suggestion with an email address so we can respond.

We also need to document how we can see the like/dislike history. Perhaps a secret URL that we can bookmark that shows a summary (all time, last year, last 30 days, last 7 days) with counts?

[wadeking98]

Sure, from my understanding the like/dislike data is just sent via email so we will likely need to either a) add a new endpoint to aries VCR to store and query the data or b) use another sort of telemetry service to log likes/dislikes and make them accessible. Do you have any preference for either option @swcurran?

[swcurran]

My own preference is to store the data and query it later, as I don't understand the long term history we would get with using, for example, the API Metrics for this. I feel like that wouldn't adequately track the data we would want.

@WadeBarnes -- do you think the API Metrics are sufficient for this or does it make sense to record the data in the database.

[WadeBarnes]

We can see the feedback endpoint called in the API metrics (see screenshot below). The metrics only track the number of calls and the names of any parameters used with the calls, but not the value used for a given parameter. We could use the metrics to track like/dislike by calling the endpoint with either a like or dislike parameter with an arbitrary value. That said the endpoint itself then becomes a no-op that relies on a metrics implementation to be put in place for it to be of any use to anyone.

I think storing the data in the database and having a way to retrieve the information would be the better option, but then we'd need to determine a way to limit abuse.

[swcurran]

Regards the abuse. We can address it in the Web App context -- but is your concern the exposed API -- that someone could create a bot to hit the API continuously? Is there anyway to prevent that?

[WadeBarnes]

My concern is the API. Perhaps rate/ip limiting.

[swcurran]

@wadeking98, please work with @WadeBarnes and @amanji to settle on a solution for the open issue and then get this implemented.

Priority for cleanup.

[wadeking98]

just to clarify, we need the ability to query like/dislike metrics but not the comments/suggestions. We need to control for abuse in the like/dislike functionality but we aren't concerned with the comment functionality since that goes to email instead of the database. Is this correct @swcurran ?

[swcurran]

Yes. We are basically looking for two features that are linked. Like/Dislike flags for people to vote, and access to that information. From either, the ability for a person to submit a tracked comment via email, as we do in the "contact" section.

[WadeBarnes]

@amanji has found another solution that is worth exploring. It would only impact the frontend and use the GDX analytics to collect the statistics. Since the orgbook-bc-client and the GDX analytics are both BC specific implementations this makes sense, we're not imposing BC's implementation on the rest of the community. It might require the GDX team to update the reporting, but there may also be some additional beneficial information collected along the way.