Thread: [srvx-devel] Support Additions
Brought to you by:
entrope
From: Mike K. <ka...@gl...> - 2002-01-23 01:33:52
|
What we'd like to see added to srvx for support reasons, is a 2 level = helper system. Level 1 would restrict them to #support, meaning, they = cant use their god mode unless they are in there. Level 2, would be as = it is now, they can use their god mode anywhere, we'd label these as = level 1 =3D Support helper, and level 2 =3D Network Helper.=20 If you need the reasoning behind that, ask me. Another thing id like personally, is a way to get a hold of logs on = demand, esp override. Like !sendlogs. It would allow me to follow up on = abuse complaints far faster than trying to retrieve a net admin to get = the logs for me.=20 I'll keep you guys posted on any new ideas that arise, but those are the = most solid, and agreed upon ideas as of right now. ---- Kaz (Ka...@Ga...) GamesNET Support Admin Http://www.GamesNET.net |
From: R. B. S. <de...@vt...> - 2002-01-23 04:54:33
|
I think it would help the design process a bit if we knew your reasoning = for that. We could have alternative suggestions that you may not have = thought about that would work even better. -def ----- Original Message -----=20 From: Mike Kaczmarczyk=20 To: srv...@li...=20 Sent: Tuesday, January 22, 2002 8:34 PM Subject: [srvx-devel] Support Additions What we'd like to see added to srvx for support reasons, is a 2 level = helper system. Level 1 would restrict them to #support, meaning, they = cant use their god mode unless they are in there. Level 2, would be as = it is now, they can use their god mode anywhere, we'd label these as = level 1 =3D Support helper, and level 2 =3D Network Helper.=20 If you need the reasoning behind that, ask me. Another thing id like personally, is a way to get a hold of logs on = demand, esp override. Like !sendlogs. It would allow me to follow up on = abuse complaints far faster than trying to retrieve a net admin to get = the logs for me.=20 I'll keep you guys posted on any new ideas that arise, but those are = the most solid, and agreed upon ideas as of right now. ---- Kaz (Ka...@Ga...) GamesNET Support Admin Http://www.GamesNET.net |
From: Zoot <zo...@pl...> - 2002-01-25 17:20:36
|
Looking at this from the technical standpoint, implementing the scheme you suggested should be easy, but I wonder if this is really the solution to the general problem of keeping helpers in line. Currently, helpers with security override have virtually the same access to ChanServ as full opers, yet most handle a relatively small set of problems: users want general IRC or GamesNET help, they want their handles opened so they can authenticate, or they want to register a channel. Perhaps the level one helpers could have access to only the commands necessary to handle those problems, while level two helpers have full security override. I don't want to tell the support committee what to do, but I think it's a reasonable suggestion. A hierarchy of helpers would be great. I'd like to point out that as helpers climb the ladder, they shouldn't simply be given more permissions and yet be responsible for the same old, routine duties. Helpers might start out in #support, but they should be given new and different jobs as they advance; for example, they could be appointed to police channels that request a helper's presence. (Say, busy channels that suffer lots of lamers, or release parties/events, etc.) A hunger for power can be a healthy motivator, but I'm not sure that we want people whose only motivation is to get that O:line. A better motivation is that they enjoy what they're doing. (I know I like working on srvx, for example -- if all I was getting out of it was the hassle of an O:line and a front row seat to network politics, I'd be gone in a second.) I'm sure there are lots of interesting aspects of network operation that the helpers would really, truly be happy to handle, given the appropriate helpers get the job. Heck, I'm sure every committee, including routing, development, web, services, PR, has some work or project that hasn't been getting attention for lack of time or people: let the helpers apply for the job! They can get the sense they really are contributing. Right now, it seems this needs immediate fixing. If we'll be kludging up a quick fix, we would need to know what each level does and doesn't have access to. For 2.0, I'd really like a more general solution that doesn't require new code to implement new and different access control schemes; new "levels" of helpers could be created and existing levels modified, and authorization would be completely unified across all services. I'll be writing up a proposal later today. I'm sorry this turned into another essay, oops. # Zoot |