Reorganization. There, I said it.

Stop screaming in terror, and come back here! These are not the painful experiences you may have been led to believe. Dust off your compromising skills, and you may discover you actually like the end result better than you initially thought.

Reorganizations occur for various reasons. They can be minor. They can be major. And Robozilla will come stomping through same as always. Minor reorgs can be as simple as renaming a cat to a more general term (e.g. Shopping/Clothing/Lingerie becoming Shopping/Clothing/Undergarments, allowing for better @linking and further sub-categorization. Major reorgs are more complex (e.g. Kids and Teens), as they can sometimes require a complete overhaul. Overall, reorganizations are about recognizing a need and fulfilling it in a cohesive, logical manner.

Several steps to follow that can make the whole process easier:

1. Determine that there is a need for reorganization.
A few examples:

  • 50+ slightly overlapping categories on various aspects of the same topic spread throughout multiple Trees is a pretty good indication. The costumes discussion is one such instance.
  • Submitters are taking advantage of the system? Maybe different formatting within the cat can solve internal overlap. (e.g. Real Estate)
  • Current layout is confusing. Sites sit in unreviewed because there are several possible cats where they almost fit, but at the same time aren't quite right.
  • There is a clear overlap. Many of these cases are handled in the Ontology forum.
  • A determination has been made that sites of certain nature belong in a specific Tree. The best example here is of merchant and vendor cats moving to Shopping.
2. Establish major discussion points.

Create a proposal on how to resolve these problem areas.

3. Begin a thread in the forum.

Outline the information you've collected, problems, and all possible resolutions including pros and cons.

4. Locate and contact affected Editors.

For minor reorgs, contact those most closely affected. For major reorgs, it's best to contact everyone in that tree branch and/or the closest affected editors. Briefly tell them why they're being contacted, and point them to the forum thread.

5. Give the thread and editors some time to percolate.

While you may have a clear picture of where things go, don't forget that your ideas are new to others and they need time to evaluate the situation. Depending on the subject matter and editor activity level, there could be several responses in a couple hours, or two responses in a week's time. ODP time is completely relative.

Staff has recommended that for minor reorganizations, you should allow at least a week or two for people to respond and discuss your proposal. For major reorgs, you will probably want to allow more time for comment and discussion. Either way, refrain from setting artificial time limits, since some editors are more active than others. Because you login everyday, doesn't mean your colleagues do. Allow a week or two for people to respond to your notifications, and allow the discussion to progress until there is some kind of consensus on a compromised solution.

Most important: be willing to compromise. Just because discussion was initiated does not mean you are the 'know all, be all' of the topic. By maintaining a too narrow focus it effectively shuts out editors who have valuable information and reasoning to share. There's no faster way to kill a "discussion". The possibility also exists that an idea has been tried previously without success. When that circumstance arises, accept the situation gracefully.

Keep in mind that many people are resistant to change. They feel the status quo has always worked, and operate on the rule of "if it ain't broke, don't fix it." Your questioning how things operate may draw some fire. Keep a cool head, and do your best to remain on the topic of the reorganization. After all, if the system always worked, you wouldn't be stumped on placement issues in the first place.

When people approach you for input on a reorganization, take a few minutes to go over the proposal and make a coherent reply. 'Yes, I agree' or 'No way' help to a certain extent, but leave little room for finding alternate solutions. There is nothing more frustrating than to arrive and discover 'responses' that have little or nothing to do with the subject matter in question. It's difficult to hold a discussion when the only person commenting on the reorganization is the initiator. Then again, you might be the one to say, 'we don't need to do a reorg, and here's why...'. In these instances, pointers to relevant forum threads and category charters defining the whys can go a long way toward clearing up confusion. Be ready to back up your statements, just as you would in Real Life.

6. Once a proposal has been made, the key is to see discussion and implementation through to the finale.

This may or may not include all the suggestions made along the way. And once consensus has been reached, everyone needs to abide by the decision.
On occasion editors have launched reorgs only to have things turn out less than they could be. Sometimes by doing a little research people learn that the Big Reorg that happened six months ago -- remember, ODP time is relative -- is actually a thread consisting of a mere 6 posts. So if someone should ask to readdress the situation, keep an open mind. Again, you may very well find the end result an improvement.

Reorganizations should never be undertaken lightly. If you feel as though you can't continue to lead discussion effectively for whatever reason, locate another person to carry the torch on. In some instances it may be best to have two or more moderators working together. Look what happened when Regional editors pulled together in a collaborative venture. Just goes to show how effective team effort can be.
- Mngolden