drupal.org has grown a lot. A lot a lot, and it's very difficult for me to provide support for users, especially when they post on the forum. Here are my suggestions for simple rearrangements (no new features) to project module that would improve this greatly:
1) Remove the 'support forum' link from the list of support links on the project page.
2) Add a 'view support issues' much like we have view bug reports.
3) Add a 'post support request' link.
4) remove 'support requests' from the default searches so that they don't inflate the things we use to look for actual bugs.
My reasoning for wanting this is that I can't keep up with the forums at all anymore, and the issue queues actually work a lot like forums in many ways, with even a few bonuses like being able to specify versions and the like (though with support requests those are a little less necessary).
With the right search, we can make it easy for people who want to provide support to look for all open support requests, too, which would make the life of people volunteering easier, which is always important too.
If we do our best to treat the support requests like a forum that happens to have status information (active/fixed) I think we can improve our ability to provide support to users and lessen the amount of time we need to spend on the infrastructure of providing support.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | project-support.patch_2.txt | 5.11 KB | dww |
| #9 | project-support.patch_1.txt | 4.12 KB | dww |
| #5 | project-support.patch | 2.39 KB | webchick |
Comments
Comment #1
merlinofchaos commentedIf we wanted to go a step further, we could reduce the number of gadgets that appear on the 'request support' link, on the assumption that many of them don't matter.
I would suggest to leave out category, priority, assigned and status, lock project so it appears but isn't changeable.
That basically leaves:
Project (visible, not changeable)
Version,
title
description
attachment
Allow everything else to default to something reasonable. Priority is iffy, but honestly that should probably be set by support volunteers. If they feel something is high priority they can up it to high in a followup, but users don't understand priority flags, usually, and allowing them to set it initially will cause it to never be meaningful.
Comment #2
webchickFor now, 1, 2, and 3 seem like really easy things that could be implemented quickly.
I'd recommend making 4 a separate feature request for "per-project configuration of what the default issue view shows"
and I'd recommend moving the stuff from #1 to a separate feature request as well, since according to dww, "word of warning: the issue and issue followup forms make baby jesus cry..." ;)
1, 2, and 3 would already be huge steps above and beyond what we have now, and kill a long-standing usability issue about that support forum link.
Comment #3
dwwFYI: this is basically duplicate with: http://drupal.org/node/10596 which is itself a continuation of http://drupal.org/node/2426. ;)
(i've been cleaning out the d.o maintainance queue recently and stumbled upon these relics).
Comment #4
merlinofchaos commentedWow. I find it *very* disappointing how little attention this topic has gotten over the last 3 years. And as we grow exponentially, I find this to be an even bigger issue than it ever was.
dww: In your copious spare time (heh) I say we work out a complete plan for how to do this, where step 1 is as little work as possible but makes changes that will get the ball rolling, step 2 involves educating users on the transition, and step 3 involves any additional widgets/bells/whistles we think would be necessary to make it as smooth as possible.
Step 1, in my mind, is fairly obvious: Make the support links more obvious, and make it easier to browse just the support requests. Step 3 involves making adding a support request easier (because that part includes effort).
Comment #5
webchickHere's a patch that does 1, 2, and 3.
Comment #6
webchickComment #7
dww2 items:
1) if we're removing a setting, we should have a db update to remove it from {variable}
2) all the links to add issue nodes should be wrapped in user_access()
rerolling now...
Comment #8
yktdan commentedPerhaps there would be fewer support requests if one of the links always present was to the documentation for the project, e.g. a handbook page, what does it do, what does it depend on, setup instructions, etc.
Comment #9
dwwComment #10
merlinofchaos commenteddww: +1, that is a very good start.
Comment #11
dww@yktdan: if the project *has* documentation, there's already a link for that. ;) that's a completely separate issue.
merlin suggested a "View all support requests" link that shows you *everything*, even closed tickets. this is a lovely idea. so, this patch adds that, and implements support for 'states=all' in the URL for issue queries. ;) while i was at it, i renamed "View all issues" to "View all pending issues" to be more accurate (since that link still does and should only show the default states, not all).
Comment #12
merlinofchaos commentedI think phase 1 here is ready.
Comment #13
dwwok, phase 1 is now committed to HEAD and installed on d.o. thanks folks. ;)
setting back to active for phase 2 issues.
Comment #14
catchMy plan this year is to steal hundreds (thousands) of d.o. users away from the forums, into the issue queues, and get at least 10% of those testing patches. This is a major part of moving people in that direction.
+1, subscribing etc.