dw_support | Brainstorming

Editing. At least pre-approval (or possibly during-approval for admins), since otherwise there's the danger of trolling via correct answer edited to offensive one.

The ability (for SH/admin) to contact a user about a screened, either for "plz fix X" or "here's why you weren't approved" or for "omg this is awesome"

Point-splitting.

Also, possible the ability for admins to adjust point values.

maybe converting pseudo-IC screeneds into ICs?

Some trace of when the request was last updated (def. comment/answer, option of screened/IC)

Getting notifs for things in the YR filter, or being able to individually subscribe to particular requests

possibly, user-facing answers have a datestamp reflective of when it was approved? (maybe with appropriate priv levels seeing both times)

... will add more as I think of them ...

Edited 2009-05-21 02:54 (UTC)

Editing. At least pre-approval (or possibly during-approval for admins), since otherwise there's the danger of trolling via correct answer edited to offensive one.

Also, redacting, for those requests that can't stay public due to sensitive personal information, but have no one able to answer them or work on them with access to a private category.

I remember, before I knew how support worked, being annoyed and confused that an answer to my request appeared above my last comment to that request. Can approving a screened somehow move that screened down to below the last visible comment? Though that might mess up a useful order of internal/screened things, hmm.

The ability for requests to default to "closed" when an answer is approved, and to become reopened if/when a user comes back to add something – the thing I've noticed that has been getting to me is that sometimes requests are marked "answered, awaiting close" for days because a user doesn't give some kind of response (although it is possible that I'm wrong and people do have closing privs; I've been awake too long and can't remember, and I have never opened a Support request on DW or LJ myself!) ... and the ability to close things like that would also stop from a "thanks!" reply turning the request into a "still needs help."

I wonder if that even made any sense!

Also, a thing about points that has confused me: in certain instances I've seen one volunteer give an excellent answer, get it approved, and have the user return and say "yes, that worked! and now it's doing X unrelated thing," and someone else replying to X unrelated thing. The second volunteer is the only one who gets points for this; is there a reason that the person who fixed the original problem is also not getting some level of point value? We're not competing, so it doesn't really matter overall, I'm just wondering if it might not be better to give everyone with an approved answer at least a point, as in that particular circumstance (and it would probably be specific to that circumstance), the first volunteer did fix the original problem.

Just to clarify, if a user doesn't close a request (by clicking on the close link given to them in email when an answer is approved), someone (currently me) does come through and close the request. I generally close once a week or so.

(This is also related to the points thing: support points are horrible and broken; when an answer is sent out, if the user says "yes, this helped me", the person who left that answer gets the points.)

Regarding your last point, this is just how the system works. Currently only one answer can be credited with points, either by the person who opened the request or by someone with the supportclose priv coming along and closing the request. Isa mentioned point-splitting as a suggestion, which is something that's been thrown around a whole lot. Basically the user and/or supportcloser can assign points to multiple answers.

Filtering or sorting "You Replied" by the type of touch you made.

Make username-based support history available to some level under supporthelp (or everyone?).

Someone (sorry, I forget who!) mentioned in IRC the ability to mark answers as good, even if they weren't approved. So first right answer gets approved, but answers 3 and 5 are marked as a approvable had they been first.

"Approve this answer link" that automatically selects that answer in the "Approve Screend Response" select element and drops you down to the bottom of the quest.

Similar to Isa's first point: Ability for admins and/or supporthelps to edit screened answers. It sucks to have to pass over someone for something like they accidentally picked the wrong FAQ or they typoed "Dreamwidth". May be a slippery slope though ("Why didn't you completely rewrite my answer and approve it??")

Are the supportstats still available here, or were they part of the LJ code that didn't get brought across? In any case, supportstats (either the old incarnation or a possible new one) opened up so that anyone can see their own, admins and/or supporthelps can see their category. (Maybe this is how it worked and I just don't remember.)

On that note, maaaybe do away with the whole category-specific priv system (or rather, don't bring it across). Keeping track of who has what privs where and is at what level of training where is sort of a logistical nightmare. The level of training bit in particular, since it can't really be tracked quantifiably anywhere (/admin/priv can be used to track privs, but really even it isn't perfect). I can definitely see both sides of this coin though. And I guess this is procedural (rather than code-related) and out of the scope of this post. *ramble ramble*

Support stats are, unfortunately, ljcom, not livejournal. But a good stats package will be part of the overhaul, definitely.

Preferrably open to all volunteers, for their own answers?

reformat the support e-mails to be more sense-making
AJAX magic to make the BBB cat show up when someone selects a cat for their request. So like... if someone picks importer, there'd be a thing that'd show up that was like "oh, are any of these your issues?"

reformat the support e-mails to be more sense-making

+1!!! (that's one thing that has always been too "minor" for anyone to fix, but I think it would really help make the support process more friendly, if this were fixed)

I'm not sure if this goes under support or somewhere else, bt on livejournal reporting a suicide threat is very counter-intuitive. If I wasn't told a while back that you have to make an Abuse report and then click the appropriate category I might have never know abut it. Is there anyway that could be more prominent or easy to d?

I think these are things that are not doable now, but no worries if I'm wrong:

Be able to select multiple FAQs at once, when more than one is relevant to the user's question.
Be able to switch the support category and answer the question at the same time
Be able to preview one's answer

* A way for a user to see all their own requests.

* A way to be able to see the last few errors the user saw, page they were on, etc

* Wishful thinking, but could be useful for webby/freaky stuff -- a page the user could visit which would print out information about their browser: browser string (for when they've opened from a different browser), cookies for site scheme (versus what's in their settings), etc?, which they could copy-paste to us. Basically an easier way to get information that we'd otherwise have to walk them through... hm though I can't think of anything except cookies that we'd easily get

* Search or bookmarking of requests would be nice; currently possible through other means, but very manual

* Actual tagging, instead of [tag] in the title (easier to search, potentially less confusing?)

* Ability to associate a request with a particular bugzilla bug, with the ability to track down how many requests are associated with each bug (could be helpful in tracking which issues get requested the most but remain unresolved; easier than hunting through ICs for a bug number; may help find older discussion, though ideally, a summary of any investigation which went on in ICs could make their way to the bug reports)

* Finer-grained request states, such as: "answered, awaiting close", "answered, awaiting user response", "answered, awaiting further investigation or a decision made elsewhere, before we can respond properly to the user"?

* Actually, looking at my last couple of suggestions, I suppose what I want is having various internal metadata associated with requests, heh!

* Oh yeah, in terms of approving answers, there's a script drifting around, which lets you select a response to approve by clicking on a link in the response itself, instead of having it in a dropdown. This would be good to build in; easier than hunting matching response numbers in the dropdown.

* Link to the admin console from the request, or a way to run admin console commands (with user's username suggestible?) while viewing the request, for convenience

A better-explained, more intuitive way to show a private category, especially when something's been moved, including a better explanation of who can see it and what general classes of requests get moved (requests with sensitive information, or that require staff/senior support response).

Ability to easily apply themes, for accessibility and shiny.

Ability to allow claiming, perhaps, so multiple people don't think that no one else is working on a request and duplicate efforts rather than combining them.

Nicer priv interface.

Ability to tag (that is not just in the title).

Few more suggestions for tweaks:

* make the faqs relevant / most used in the current category the request is in easier to find? Duplicate them at the very top of the list, perhaps, so you don't have to scroll all the way down to the bottom (or worse, search in the middle!) to hunt down that FAQ

* when viewing the requests in a list, some way to tell which requests you've already replied to, and which you've ICed on?

* if we're still keeping the list of styles at the top, print out the layout name, instead of the layout number, for system layouts

A better server-side filtering system of requests. Status + cat isn't enough, especially when the status choices are incomplete and you can only pick one category at a time. I want to be able to get a list of tickets that are in Cat1 OR Cat2, have unapproved screened answers on them, and were submitted more than 24h ago, for example!

FAQ insertion - with which I mean something where I can select an FAQ and it inserts the URL. Very handy for referencing multiple FAQs.

more than one category of ICs -- one for what they're used for now, and one that newbie support people can see as well, to leave pertinent but not confidential information, like what steps somebody has gone through in debugging the problem.

maybe add faq numbers to faq dropdown. after a while i'll remember the numbers better than the titles, and if they're in order, that would make them quick to zoom to.

a way to see, on the board, which reqs already have screeneds and which ics (so if an SH wants to work on hard stuff that day, or wants to approve answers but not write their own, they'll know without opening the reqs individually).

plus, if we could mark stuff 'unapprovable' (or whatever) so people would know, 'well, that got passed over so i should write my own answer' - vs 'no admin has looked at this yet'. all subject to different priv levels, possibly.

There was a huge list compiled on LJ, which may be relevant. (I dunno if you ever saw it?)

Anyway, here's one: creating/editing support categories with a browser-basaed UI.

Do you know where the list is?

Better ability to forward problems to someone relevant who is not in support. If somebody brings up something that should be addressed by styles or be addressed by accessibility, I'd like to just be able to check something to cc them a notification.

Can you define what you mean by "not in support"? There's nothing in the Dreamwidth code that says "this user is in support, that one isn't", so (if that distinction matters at the design and code level, which isn't necessarily the case), it needs to be clarified. Do you mean a Dreamwidth user, an email address not associated with a Dreamwidth (or OpenID) user, or something else?

I don't actually mean necessarily "Not in support" so much as "shunted off to styles team" or "shunted off to accessibility team" or, heck, "shunted off to coolhunters"

At this point, things that are bugs are getting added as ICs, but sometimes things are ideas that some particular committee should think about.

/me is working on a mockup (with code, no less) which includes lots of this plus items from conversations with zarhooie, just FYI

Please oh please, can I get my own replies to queries e-mailed to me?

As long as it's an individual option. It used to be that way on LiveJournal (notify=all meant your own too, no opt out), and it drove me nuts. :-)

Hmm... Good point. I would like *options* to be added to the support emails.

Also, I would like the support emails to tell me who did what (like who made the IC).

If suggestions are still being taken several days later... I find that out of all the FAQs, there are just a few that I reference on a regular basis. This is a minor thing, but it'd be nice if it was easier to find these in the list.

It could be as simple as tacking the FAQ number onto the beginning of each line so that typing will bring you to the right place, but that assumes that people will memorize the numbers.

Spam-handling, to be integrated with the anti-spam team's anti-spam system.

I think some things could be automatically filtered into spam--a lot of our spam isn't very smart and has subject titles like "cgzsQrDLswySMJSYZ", which could be pretty easily detected by something like letter tri-grams.

Brainstorming

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Re: Brainstorming

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject