|
From: Nick C. <ni...@cl...> - 2003-01-15 09:11:38
|
On Tue, Jan 14, 2003 at 07:25:09PM +0000, Dave Cross wrote: > Thanks for all your comments. Rather than reply to each point individually > here's an idea of what I'm now thinking. > > I'd hate to lose people like Nick Clark from the devel list. He might not > say much, but when he does it's always worth listening to :) So I agree > that closing the devel list is a bad idea. > > Support - I still like the idea of having people whose responsibility > it is to answer support emails on a rota system, but I do agree with > what Nick and Simon said about even our worst efforts being better than > Matt's current level of support. So how about this: > > 1/ Some sort of SLA on the web site saying that we intend to respond to > all emails within 24 hours. Sounds fair. > 2/ The individual script owners still assign a support rota within their > group, but that person has the job of "mopping up" - that is checking > for emails that haven't been answered in 18 hours and posting a reply > (even if that reply is "the expert on that problem will be back online > in 12 hours". Sounds reasonable. The same 18 hour timeout could be used for the person coming onto rota to take over ongoing conversations between users and the person previously on rota, if the previous person doesn't reply. > 3/ The script owners need to ensure that more people in their group > are skilled enough to answer support emails. Yes, definitely. > 4/ The script owners can decide on their own rules about how to avoid > the multiple reply problem for the scripts they are responsible for. > For example Nick Cleaton might say, "no-one should answer a question > on formmail or tfmail in the morning (uk time) until I've got to work > and posted all they replies I drafted on the train". Surely that won't be an issue if there's a rota, because the person on front line support that $timeperiod will be the only one to reply anyway. [SNIP] > And Nick, I think your modular ideas are great. Once we've assigned all > of the "team leader" roles, can you please start to talk with them about > how the other scripts can use your ideas. Yes, OK. That reminds me: the user customisation scheme for these modules makes it impossible for us to rename the methods in the modules without the risk of breaking scripts that include customisations. So now is the time to spot methods that could be better named and areas where code could be better divided into methods. Once there's a release from this branch, it will be too late. -- Nick |