Support Feedback
Introduction
From time to time, issues or conflicts arise in support channels. We should have a documented process for listening to feedback and acting on it where possible.
This document is oriented to irc support (specifically the #fedora support channel), but could be expanded to cover other support areas (mailing lists / forums).
Current #fedora feedback
The current method of feedback is via irc, in the #fedora-ops channel, and after that in email to the irc-support-operators group in fas.
The current setup for feedback of support in #fedora has a number of problems:
- It's not really documented at all.
- Feedback is done right after events that raised the issue, so everyone is emotional and "hot" about it.
- Both the person wanting to provide the feedback and possibly people they wish to provide feedback about are in all these avenues, possibly leading to back and forth and heated exchanges between them.
- Since feedback is done directly, there is no way to just pass along a lessons learned or high level view of the issue.
- The irc-support-operators is only a alias and has some issues due to that (SPF), also CC'ing various other people for input becomes difficult.
Positive things we can do
- We should have a means for praising good behavior or good helpers.
One possible way of doing this would be to add the Karma plugin to supybot, seeing as ops have an amount of bot-privs, this may be motivational/rewarding to helpers.
- We should be able to take feedback and come up with a high level way to learn from it and try and prevent it from happening again.
- make sure people know their feedback was heard, even if no action is taken.
If a triage system was implemented - the reporter would get feedback, and mostly the feedback would be after they have 'cooled down'
- Mediate disputes and try and get both sides to reach some accomodation
Negative/enforcement things we can do
- Ask someone to take a break for $timeperiod
Would it be appropriate for an alias on fedbot to pm the user in question, warning that their behaviour is not acceptable, and may be rewarded with a kick/ban. The alias could also include a link to the op conduct wiki page, so the user knows what an ops course of action might be?
- Ban (for $timeperiod)
- remove status (cloaks/channel privs/other)
Possible ideas for implementation
(in no particular order)
- email alias for feedback
- trac setup for feedback
- setup small group of ops to triage/boil down feedback for everyone else.
To me, this sounds like a very good idea. the feedback requests could potentially be in large numbers, and get overlooked. I for one (dcr226) would be happy to act as triage, forwarding valid issues to more senior operators for a decision on the action. I do _not_ think that triagers should make and decision as to any course of action.
- support mailing list for feedback (public/open to community)
- setup small group of irc savvy trusted community members to triage issues and provide feedback and recommendations.
- come up with formal rules for doing any of the above actions.
- tie into the idea of a community working group? (see board list for more discussion)