Everyone probably noticed that, for the past several weeks, I've been posting a series of proposals to the site. The bulk of these have been successful additions to site policy, and it was requested by several users that I explain the process by which I create a policy for discussion and implementation on the site. The following is a short guide that I wrote to help administrators, mods, and operational staff create their own policy proposals.
The Germ of an Idea
Almost all policy is reactionary. We perceive a problem, and we sit down and consider possible solutions to that problem. I strongly suggest that, rather than acting in a bubble, you talk to your fellow staff members about possible methods of solving the problem. At the same time, I don't suggest an open discussion in staff chat. Staff Chat is a great way to find the problems, but there's a lot of talking, and a lot of people, and a lot of distractions that can very quickly make it impossible for both your own ideas and other staff ideas to actually be heard and interpreted in full.
To be honest, my best ideas have always come as a result of listening to someone else complain about a problem. I cannot begin to tell you how many times Moose has started ranting, and I've had a "brilliant" solution. In fact, the Team System — arguably the site's biggest policy shift — came from Moose having a legitimate complaint and me being willing to listen. Working together, we crafted the current version of Staff Structure that we use on the site today.
What I'm trying to express here is the idea that the most important thing about making changes to the way we run things around here is communication. Not just listening to problems, but also talking about them with others to try and come up with a solution. Tossing up an idea on O5 completely blindly is a good way to get it shot full of holes. Coming up with an idea and sharing it with staff members privately first is a good way to crystallize a nebulous thought into a legitimate concept.
Effective Communication
An effective policy suggestion contains three things:
- An Explanation of the Observed Problem: This sounds utterly obvious, but there are many times when the perceived problem isn't one, and half way through typing up a document suggesting a change, you stop, realize how silly it all sounds, and abandon the project. I've done this more times than I care to recollect.
- A Suggestion for Fixing the Problem: Again, utterly obvious, but this lays out the beginnings of the discussion. If you provide multiple possibilities here, people will rapidly begin building their arguments and thoughts based off of the suggestions you make here.
- A Request for Discussion: Always make sure that you're presenting your policy as a suggestion (which it is) rather than an impending change which must be done. If things are already shown as 'decided', then you're going to lose the chance to get feedback which could be useful or change the policy dramatically.
Quick Example:
There are way too many spiders currently invading the site. These spiders are scaring the regular users, building webs at places to catch easily preyed up smaller users, and have started mass downvoting (brigading) all articles which are not 'spideriffic' or 'spiderlicious.' Our user base is dropping like proverbial (literal?) flies, and incidents of 'inappropriate pedipalping' have risen dramatically.
I would like to propose that we counter this by immediately banning all 'spider users' who are currently abusing our system. I suggest that we do this by one of two methods:
Option One: All spider users have eight eyes, so we can clearly identify them by asking them how many eyes they have, then proceeding to the banning phase. This avoids offending spiders by directly asking them if they are, in fact, spiders, and it keeps us from looking instantly bad. (Spider-Culture Tolerant Option)
Option Two: Step on the spiders. A much harsher method, but we currently have enough staff members to brutally crush the current number of spiders if everyone is willing to perform a percentage of the work. (Anti-Spider Option)I'd like to get the thoughts and feedback of staff members to see if this policy change could work for them or if there's some major issue that isn't being addressed properly.
The reason the effective policy posts are presented this way is because we want to spur discussion about the way we do things. It also helps iron out all the problems that might be present in your policy. For example:
- There is no pro-spider option here. The bulk of the spiders present on the site have a good track record with not devouring site members.
- This policy assumes that staff members have the right to ban someone based entirely on their spiderhood rather than their contributions.
Mind you, this is an 'over-the-top' example meant to help demonstrate the reason we pursue this method of discussion. It generates conversation rather than discouraging it. It gives you the chance to defend your policy to other members of Staff, and if you can't do that, then you probably don't need to implement it.
When you post your discussion, include a timer (usually, 48 to 72 hours). This lets people know when you're closing the discussion and opening a vote. It also puts a deadline on things (for yourself, more than anything else) to continue to the next step. Furthermore, it also means that discussion can't drag on into an endless back-and-forth where nothing gets accomplished. Feel free to dig into the forums and look at all the discussions that never finished — and all the decisions that were never reached.
Please Note: If it's a change to the way you're running your own team or projects, consider the impact that change might have on other site members, staff members, or staff/member relations. If the impact is minimal (such as changing the formatting of the image boxes, with the team handling images), then it probably doesn't need a discussion (much less a vote). If the impact is anything that can have a greater effect on the site beyond your scope of control, then you definitely need to bring it up with others.
Voting Threads
Any change to staff structure, site-wide policy, or the site charter usually needs a vote. Depending upon scope, you can expand/limit the vote as necessary, but often, the policy of 'Operational Staff and higher' should be observed, as well as Active or Active/Reserve.
If discussion is fairly mild, lacking much contention, you can simply put up a vote to support or oppose. If, at the time that the discussion, there is a division over what the exact text of the policy should be in some way, this is your chance to include a voting option. As an example, take a look at the discussion thread for Staff Censure and the voting thread. This was one of our uglier votes—not because people strongly disagreed, but because of determining the extent of the effect.
Be as even handed in your voting thread as possible. Look at what the real discussion is and pay attention to what people actually want. You don't need options that were unsuggested, and obviously partisan vote options (such as omitting options that other staff desired) that blatantly attempt to sway voting may be cancelled by administrative fiat.
During the voting, in spite of how thorough the discussion might have been, there may be some complaints about the actual text of an implemented policy. If this happens, then small changes can be made, but if these changes alter the content or spirit of the policy to a great extent, a new vote should be held. This is largely because checking to make sure that everyone who already voted continues to support new wording leads to a logistical nightmare, and it's easier to just notify everyone that a new vote is taking place.
Implementation
This is where most people mess up. If you suggest a policy, guess what? You have to handle the implementation. It's amazing how often people make grand suggestions, then expect them to get done, just because the suggestion was made.
It's not a bad idea, when suggesting the initial policy, to ask if the person reading would be willing to help you implement the policy as well, but usually, plan to work on your own if necessary to get things done—even if it's as simple as changing one page's text or re-writing a series of documents.
Take a look at discussions on O5 over the years. Take a look at how many of them seemed to arrive a conclusion, but nothing was ever done. Then promise not to do that with your own policies.