Where we are today
One of the rules of migration I was taught was "don't migrate crap."
Moderators have a way of pinging the moderators of other sites via a chat interface, and typically this is how I handle migrations:
- Let the question asker know that there is another site that might be more on-topic, and that I'll look into migration (this has the side benefit of introducing them to the other site)
- Ping the moderators of the other sites through moderator magic, and ask if they would be interested in the question
- If I get no reply, check the site rules and try to make sure it's not going to be immediately closed/deleted upon migration
If the question passes this "migration check" I migrate. If not, I try to let the asker know this.
This seems to be a common procedure among multiple sites (I've been pinged in this fashion on several occasions) and I think it's a pretty good way of making sure questions end up where they should be without moving a lot of poor quality questions around.
Other ways of approaching this
The subject of changing this procedure has been brought up, and one suggestion is that instead of moderators pinging moderators, we should let the source site's moderators bring the question to the community in some fashion. (For us, that would likely mean The Bridge). The openness of this suggestion is nice, but I don't think the methodology scales well.
To explain why, let's reduce this to a more generic system.
In this system, we have a network of datastores (Q&A sites). Each datastore has its own format, communication protocol, and rules for what data is allowed. (FAQ/chatrooms/Meta) The data is policed by a set of intelligent "agents" (elected moderators and high rep/high activity community members) who learn and shape these rules over time.
Now, say we wish to migrate a record from one datastore to another. (Question migration)
The constraints are:
- The destination datastore's agents will have to validate this record against the existing rules at the time of the migration. The goal is that source and destination datastores should avoid migrating data that will be rejected by the destination as much as possible. ("Don't migrate crap.")
- As many agents as possible should be able to evaluate the new record. ("Be as open as possible")
- This process should complete quickly, although individual agents may be slow to respond ("Less red tape and inefficiency")
- The rules of the destination datastore are subject to change without notice to the source datastore's agents. ("Meta policy/FAQ changes")
- The source datastore's agents may understand some percentage (or even a high percentage) of the destination datastore's rules, as they are intelligent agents. ("Cross-site expertise among users or moderators from experience or direct involvement")
- Updating a source datastore's understanding of the rules and data format of a destination datastore is challenging and slow. There is no formal process besides learning from mistaken record migration. ("Few cross-site standardized procedures exist, and communicating new procedures/best practices, even ones that come from SE directly, is a slow process")
The agents on the source datastore choose a likely destination datastore. How and what should they involve in the migration process?
The method that has been suggested is that a source datastore's agents should understand the current protocol for migration preferred by each destination datastore, and follow this procedure. ("People migrating to Arqade should post their questions on The Bridge")
However, this has some drawbacks:
- If a procedure changes on a destination datastore, updating the source datastores is going to be tricky. Each of their agents has an understanding of the procedure that would require updating. (Say we decide that The Bridge is the wrong place, and we should have a special Migration Room - how do we communicate that to the moderators of every other site? What if the procedures are different on another site that we infrequently migrate to, how do we learn them?)
- This doesn't scale well when we add more nodes to the network. Again, the slow propagation of the rules among agents at different datastores hampers the system's ability to cope. (Even established moderators are ignorant sometimes, and do things that don't follow the procedures, because often the procedures are subject to change or are unclear. There's not a lot of centralized documentation, and some of these procedures get used so infrequently it's easy to forget.)
If you were trying to code this system with a network of databases, and you opted for this method, your programmers would probably revolt. "You're duplicating the protocol systems of each destination datastore on each source datastore. That's a lot of extra copy/paste code, and it's a pain to maintain!" they might say. That's with computers, which you can program, update, etc, and have pretty good faith that they're going to do something consistent each time. Our system is primarily composed of humans, and they are notoriously difficult to code for...
An alternative way to approach this would be to standardize on a communication protocol. Have a high level "broker agent" (moderator) on the source datastore take the record, and convert it to some generic, stripped down data format that is passed to a broker agent on the destination datastore, as a "pre-migration" check. (One-boxed chat link w/a ping) Once on the destination datastore, the broker agent can consult the local agents to evaluate the record, and then reject it if that check fails.
These broker agents can be updated much quicker, as there are fewer of them to train in datastore-specific knowledge. ("Arqade mods, we agree we're going to post potential migrations in The Bridge before accepting.") They have the capacity to learn as well, so they might be able to make decisions regarding migration as either a source or destination broker agent. ("Game-rec is off topic on Arqade, so I shouldn't even bug their mods about this one, they'd just say 'no'")
The disadvantage here is that there are more steps (source mod -> dest mod -> community) so migrating records takes longer. We could train the broker agents to do this job behind the scenes, but then we lose openness and fewer agents review a record prior to migration. (That's the system we have today, essentially)
Migrate ALL THE THINGS!
Since our system's agents run periodically and frequently over incoming records, we could just say "migration is the same as inserting a new record" and let all the agents handle it as if it was no different than anything else. The advantage here is that the system is very fast (the moderators/broker agents make quick decisions) and we maximize destination agent exposure (far more people watch the question feed than hang out actively in chat).
The downside is, of course, that the incidence of rejected records goes up. If we wanted to reduce it in this system, we'd have to rely on the source broker agents learning more about the destination system, which is kind of looping back on the disadvantages of the previous system. This laissez-faire approach is certainly the easiest answer, though.
I could keep going, but this is too freakin' long already
There are probably other solutions that are better than the ones I can think of off the top of my head. Some of the constraints, too, are potentially mutable. If we had a better system of disseminating information, for instance, so that agents could train much, much faster, that would certainly change the dynamics of the system significantly. Or, we could figure out a way to open the broker agent's protocol to outside observation (move migration talk out of a private area and into a common network-wide room - somewhere visible to the communities).
When I look at the potential solutions on offer today, I think we're already doing a pretty good job of handling these special case migrations. They're infrequent, and the outcome of success or failure is pretty minor. I don't see a significantly better system given the constraints we have today.