Brainstorming redux

[jennifer]

I've read through the comments to the brainstorming post and these are the most popular requests I'm seeing:

- ability to preview and/or edit screened responses
- adjustment of point assignments
- approval links on a given answer instead of having to use the drop-down
- better tracking of when a request was last touched and in what way (screened answers, ICs)
- responding directly to other responses (threaded comments)
- improved filtering/sorting/tagging
- view of all requests a given user has sent in
- view of all requests a given user has answered
- per-request notifications
- better wording for support email notifications
- linking of support requests to Zilla bugs with access to relevant stats
- ability to reference multiple FAQs

That sounds like a pretty heavy overhaul, but I think if we work on a chunk at a time, it'll get done!

If there's no objection I can open a Bugzilla item for each of the bullet points I've listed above. Any additional discussion about implementation details can go in comments to this post for now.

Comments

[denise]

Are we wedded to using the existing system? I think we might want to just scrap it all and start over, honestly, instead of trying to patch each of those things into the existing code; rearchitecting it from scratch might make more sense.

[afuna]

I think that makes sense, too, and we'll probably end up churning up new ideas as the new system, whatever it is, takes shape.

(I'm excited! Hah!)

[jennifer]

Depends on how soon you want to see results. I imagine writing a new support system from scratch would take longer than the WTF split, which still isn't done yet, or the payment system, which has eaten all of Mark's free time for the better part of two months.

Given a week, I could probably implement about half of the suggestions above in the current system. That week won't be this week, of course. :)

[denise]

Let's go over the above list and see what would be a minor effort -- whatever you can implement in said week (not this week) can go, anything that will take longer can wait for a total redesign.

[pauamma]

I would favor a redesign from scratch, personally. Currently, it isn't nearly as bad, codewise, as some other subsystems I will not mention by name (you know which ones I mean), but once it gets patched to do some of the stuff I've seen discussed here, it would likely be a serious contender for placing.

Brainstorming

[cesy]

Totally off-topic, but I always thought we were meant to avoid the term "brainstorm" these days, because it means something else to epileptics. Is that just an urban legend?

Re: Brainstorming

[jennifer]

That's news to me. I can certainly avoid the term in the future if it makes anyone here uncomfortable.

Re: Brainstorming

[cesy]

Well, it doesn't bother me personally, but I was always told at school that we weren't allowed to use it, so I was curious to know if that was because it actually is offensive, or just overly-PC-paranoia (which is entirely possible). Maybe I'll go ask in dw_accessibility or somewhere.

Edit: A quick Google tells me that various National Socities of Epileptics don't mind the term; it's mainly paranoia among diversity advisors. Thanks for driving me to look it up rather than just relying on the myth!

[aveleh]

view of all requests a given user has sent in

Unless I'm misunderstanding, the above already exists, it's just only available to SHs and relies somewhat on username/email combinations.

http://www.dreamwidth.org/support/history.bml?user=
http://www.dreamwidth.org/support/history.bml?email=
etc, etc.

One advantage of an actual overhaul could be to better organize tools associated with priv packages.

[jennifer]

Now that I look, I see the email address displayed on a support request is a link to history.bml. I had assumed it was a mailto.

The request was for a user to be able to see a list of their own requests, not just the support crew.

[wyntarvox]

it's just only available to SHs

Yeah, one of my suggestions was to make it more widely available, or just remove the priv requirement. At least for the username version. Email version should probably stay where it is (which I think is finduser or supportclose?), since people obviously have different privacy settings for their email address.

[pauamma]

Why shouldn't it follow the user's email display setting? Or maybe only a subset, eg "if public, display and allow search for everyone - if not public, limit to people with suitable privs" {the restriction being in case Alice trusts Bob to see her email address, but not Carol - if Bob doesn't know that, and esp. if he's used to the way LJ does things, he may let it slip)