Closed Bug 459841 Opened 11 years ago Closed 11 years ago

Add "solution to problem proposed" status to forum thread

Categories

(support.mozilla.org :: Forum, task)

task
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: djst, Assigned: ecooper)

References

Details

(Whiteboard: sumo_only)

In order to get better metrics on the % of threads that are actually responded to by our contributors, we need to separate between things like "me too" replies, spam, clarifications of the problem, and finally "solution to problem proposed" -- when contributors post a response that is actually an attempt to solve the OP's problem.

For this, we need:

- A new status of the forum thread (similar to the "solved" status we're using for threads that are verified as solved by the OP or a moderator)
- UI when posting a response to a thread. Ideally a checkbox just above the Submit button saying e.g.:

[x] This reply is a proposed solution to the problem
I don't think this is ideal. This is another step.

If we really want to distinguish between these types of posts what we want is multiple reply buttons.

"add more information" "I'm having this problem, too" "suggest a solution"

However, how many contributors reply to threads with me too? I think we can assume if a contributor has replied that it was an attempt to solve the problem whether it's asking for more info or a proposed solution.

This is adding complexity that is probably going to be less reliable than just tracking whether a contributor has replied.
(In reply to comment #1)
> However, how many contributors reply to threads with me too? I think we can
> assume if a contributor has replied that it was an attempt to solve the problem
> whether it's asking for more info or a proposed solution.

We can't assume that, which is already obvious. Many contributors ask for more information. That's not a proposed solution to the problem. We want to be able to tell how many % of our threads are actually "solved" (including "solution proposed").
no, it's not a proposed solution, but it *is* an attempt to help find a solution.

Having a solution proposed isn't the same thing as being "solved" which is why Jason was resistant to anyone but the OP being able to mark a thread as solved.

What's the benefit to distinguishing between a contributor saw the thread and tried to help, and contributor got far enough along to propose a solution?
Assignee: nobody → smirkingsisyphus
Target Milestone: 0.8 → 0.7.3
The main benefit is that we don't have any way to separate out "this probably solved it" vs. "there was information lacking here"

I now wonder if it'd make more sense to have "response type" as a required field for contributors (two clicks doesn't seem painful in the scope of a response).  Then we could have:

* More Information Required (when more questions are needed to provide a potential solution)
* Solution Proposed (solution posted to user)
* Issue Resolved (for responding to users who forgot to mark as solved)

This means that in all three cases, we know what the last touch by a contributor was.  It'll also give us the potential for some deeper analysis, like "is there a correlation between time to request more info and resolution rates for those threads?"
Ok, I've talked to both Mike and Nelson on IM and established the following clarifications and additions:

- The status should be per-post, not per-thread. This is a requirement in order to e.g. highlight the solution to a thread, or give karma to the contributor who solved the problem (both of which are already future plans).
- There is already support for per-post status in the forum db (actually, the thread status is just the status of the parent post in the thread), so this shouldn't complicate the implementation much, since there is no need to add new db table fields.
- The "Issue Resolved" status that Mike proposed should not be available as an option when posting a response, because we don't want the person posting a solution being able to mark his/her own response as the solution to the problem. [1]
- The "More Information Required" is a good idea. This should be the default status for posts from contributors that are not marked as "solution proposed".
- Posts from non-contributors should probably have a third status available that would correspond to the default status used today for posts, e.g. "Adding a pointless 'Me too' post" or whatever. :)
- To keep things simple and to ensure we don't hurt perf, the status of the thread should still correspond to the status of the parent post. Whenever a "solution proposed" reply is posted in a thread, the parent post would copy that status. Similarly, when a "needs more info" reply is posted, the parent post would copy (unless the parent post is already marked as "solution proposed" in which case that status would be kept). This means we'll still be able to filter or browse forum threads in the same way as we're doing today.

[1] Marking a thread as solved is something that will be possible from the e-mail notification, but that's not part of this bug. In the future, we want an obvious way to mark a reply as the solution to the problem from the actual thread (not the e-mail notification), but that's also a separate bug.

Proposed UI for the status selector would be radio buttons:

Select purpose of your response:
 ( ) Requesting more information
 ( ) Proposed solution to problem
 ( ) None of the above


..or a drop-down list:

_____________________________________
[ Select purpose of your response |V]
__________________________________|__
 | Requesting more information   |
 | Proposed solution to problem  |
 | None of the above             |
 |_______________________________|


The "None of the above" option here would only be shown for non-contributors, and is really the "Adding a pointless 'Me too' post" option I mentioned above, but phrased in a more diplomatic way. :) It would be the default status we use today in the db. By including it in the list for non-contributors, we might get a nice side-effect of discouraging people from posting in a thread if they don't intend to either ask for more info from the OP, or propose a solution to the problem.
(In reply to comment #5)
> The "None of the above" option here would only be shown for non-contributors,

Actually, it should be shown for contributors as well, since there might be other reasons why you'd post in a thread, e.g. to say "I'm closing this thread because it's gone off-topic" or whatever. So, all three options should be shown for everyone.
Depends on: 462829
Marked as dependent on bug 462829.

If someone wants to cook up special thread icons for the new types (displayed to the left of the thread in tiki-view_forum.php), they can. Right now they just use the normal "page" icons.

Also, picking "None of the above" currently doesn't change status. If someone chooses "Proposed [...]" and then someone adds a "me too" sort of post, the thread status should remain as having a solution proposed.

The patch also allows you to view only threads that have solutions proposed or that are requesting more info in addition to the solved/unsolved filtering.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
OK, sorry for this late response (this one slipped my radar) but I have a couple of remarks:

* The drop-down defaults to a choice, which makes it too easy to skip the step. Can we default to a blank choice and force people to choose?

* The UI feels a little misplaced there at the top. Can we move it under the big text box instead of above the toolbar?

If this is not possible to do within this short timeframe, let's file a separate bug and squeeze this in for the next release.
I can post a small patch to update this tonight.
(In reply to comment #11)
> I can post a small patch to update this tonight.

The 0.7.3 release is tagged already so let's aim to get this adjustment in by 0.8. Eric, do you want me to file a separate bug for that?
Might as well so it's clear what's happening and what's being fixed.
Filed bug 468613. plzkthx.
Whiteboard: tiki_feature
Whiteboard: tiki_feature → tiki_feature, tiki_depend
Whiteboard: tiki_feature, tiki_depend → sumo_only
You need to log in before you can comment on or make changes to this bug.