Confusion over what "Answered" button means

[glynnbird]

If a user is triaging a SO ticket and finds that the question has already been answered by a non IBMer, they may be tempted to click the "Answered" button because it has been "Answered".

The intention of the "Answered" button is to record the fact that the triaging user answered the question. This is causing the stats to get skewed.

The solution is to rethink the UI a bit to make it unambiguous.

[terichadbourne]

Just to clarify the issue, when I'm on triage duty, there are 5 I might need to do, and 3 buttons with which to accomplish them:

• Assign the ticket to someone else --> select their name and click "Assign"
• Reject the question as inappropriate for our team (or not detailed enough to be answered, etc., --> record a note about the reason and click "Reject"
• Answer it myself --> record the time spent (if we still want to do that), and click "Answer" (at the moment I do not have to assign to myself first, apparently the system assumes it's me who took the action in SO )
• Mark it already answered by someone on our team (who apparently forgot to use the dashboard) --> Process unclear - I assume I have to first use "Assign" and then "Answer" - I don't recall if the record automatically closes after the assign, in which case I'd need to go back out to the search results, change the query to include all questions, find it again, and then click "Answer" - I have no idea how long it took them so couldn't answer that part
• Mark it already been answered by someone else --> Process unclear - I assume I have to first use "Assign" to select Other from the dropdown and then click "Answer" - I don't recall if the record automatically closes after the assign, in which case I'd need to go back out to the search results, change the query to include all questions, find it again, and then click "Answer" - how long it took to answer is irrelevant since it wasn't our team's time being spent

The user doesn't know how the data is being captured and used. For example, they don't know that clicking "Answer" makes the system assume it's them who answered it, just that it marks the question as answered so we can all ignore it moving forward. They also don't know that the system is tracking how many questions people have answered on SO and getting that wrong if they don't follow the correct procedures for assignment while marking something answered.

As I understand it, there are two ways we could pull stats on how many questions each person on our team has answered:

• from the SO dashboard (which would require improving the UI so we all use it the same way and update assignments before marking questions answered)
• from the SO API (in which case this GH issue is irrelevant and it's fine for us all to assume the button means a different thing)

[glynnbird]

For the record, the structure of documents in our database look like this: https://github.com/ibm-watson-data-lab/sodashboard/wiki/Repository-document-structures

• when you assign a ticket to someone, the document gets assigned: true and values set in assigned_by, assigned_by_name, assigned_at. Code here: https://github.com/ibm-watson-data-lab/sodashboard/blob/master/public/js/sodashboard.js#L487-L514
• when you reject a ticket, the document gets rejected:true and values set in rejected_by, rejected_by_name, rejected_at. Code here: https://github.com/ibm-watson-data-lab/sodashboard/blob/master/public/js/sodashboard.js#L515-L536
• when you answer a ticket (or click the answer button), the document gets answered: true and values set for answered_by, answered_by_name, answered_at. Code here: https://github.com/ibm-watson-data-lab/sodashboard/blob/master/public/js/sodashboard.js#L537-L557

[lornajane]

I've updated the wiki instructions for SO duty to clarify that when a question is answered, we just just click the answered button; we'll pull data about who answered what from the API.