-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-06-29 22:34, Jim Henderson wrote:
On Tue, 29 Jun 2010 10:33:25 +0200, Carlos E. R. wrote:
Makes sense to me - though in the online world, I find that as front line support goes, there tends to be very strong technical expertise when you operate as a meritocracy. Those who give good help continue to do so, and tend to acquire a lot of knowledge and be able to solve a lot of problems.
In the "real world" this does not often happen, because those in that 1st line are under-payed and unmotivated, in my experience, so that they seek a different post, or even better, a different company, going away as soon as they can with their experience - lost. In my circle of friends we call them "flower pots", because attempting to solve a problem talking to them is like talking to pottery. Very nice pottery when it is not phone, but human. Usually young girls hired for events. Thus the term: flower pots. Not trying to demean them, I have been a flower pot myself, of the rough kind ;-)
Oh, sure, in the real world, front-line support is typically (but not always) low-paid, entry-level positions. But we're talking about the online world here; that kind of escalation is quite popular, not just in the Novell forums, but also the Microsoft forums and other online communities. The "front line" there are the NKPs (for Novell) or the MVPs (for Microsoft) - and many stay there for years, completely unpaid (there are usually other perks, conferences and the like). As I mentioned earlier, I was one of those volunteers for more than a decade for Novell. :)
Ah, I have never seen that, personally, it is new to me.
I think it could; the developers have the same constraints whether they're paid to develop or not, and the technical people answering the questions (in my experience) have been volunteers. I used to be one myself in the Novell forums years ago.
The primary difference with an open project is that of accessibility to the "back line" and to the developers. But the mechanism of filtering those escalations is something that I see as equally valid regardless (not talking about 'proxy bug reports' here, just the filtering of the "I can't print" type posts from backline/development level assistance unless there's an actual problem that needs to be fixed).
And it would make for faster solving. It is discouraging to find that the first answer on a bugzilla that took many hours to investigate and report is not written till several months later. Perhaps better "triaging" (is that the word?) would help.
Triaging would apply to coding a quick fix; it would be additional troubleshooting before a bug is raised. The ideal workflow, I think is:
1. User reports problem (through forums, MLs, whatever) and asks if it's been seen before 1a. User perhaps also searches bugzilla 2. User works with a 'front-line' SME to determine if it's a bug, configuration issue, or training issue (ie, the user didn't know what they needed to know). 3. If the problem is a bug, then the bug is reported by someone who has seen the problem (ie, the original poster or someone who has reproduced it) in bugzilla. 4. If the bug is a duplicate that just couldn't be found, the bug is flagged as a duplicate; otherwise, the bug is assigned a priority and put in the queue for a fix.
I've probably missed a few steps here, but this is the high level view of what I see as an 'ideal' flow (largely because it's the flow I tend to use myself).
I was rather thinking on the line of a group of people reading all new bugzillas, doing a fast assessment, asking for the typical logs or whatever is missing, all at most 36 hours after the initial report. Then advise the reporter about what is the typical response time on that kind of problem considering the current backlog. And forward to the proper team of people that handle that particular type of problem, if known. Sometimes I have reported a problem and then, 6 months later I get asked (first answer) to add some info or a log or whether I also had that other symptom. By that time I don't remember! Plus it is very discouraging for a reporter not to get a simple feedback in months. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkwxxSUACgkQja8UbcUWM1y71QEAnSi9iDWtx6wIZO2SZ7jzVjWF dixoEyAAfNVSKr0kdhcA/A4n55gICBMf7k8EkzWDbQHio4Gag1aIvs0S+IGcycfl =wmR2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org