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. :)
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). Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org