5

A game recommendation question was recently migrated from RPG.SE to Arqade, which was promptly closed and deleted since game-rec is off-topic. We've had situations like this before and the end result is normally that we pop on over to the migrating site and let them know the question is off-topic on our site.

However, one of the RPG.SE mods, @mxyzplk, raised the point that migrating and then closing can be better than not migrating at all since it can result in:

  • New users being introduced to Arqade
  • Reworking a borderline question into a good question
  • Less chance of an acceptable question not being migrated

When Arqade goes to migrate a question we normally make a point to ask the target site first if they want the question, and only migrate it if they say it's okay. Would we like other sites to handle migrations to Arqade the same way, or would we prefer them to just migrate the question and let us deal with it?

2
  • Um, since when was asking the other site Not the step to be taken? – James Oct 29 '12 at 23:57
  • @James: I assume that's how this discussion will end, but since we've never had a meta on it before I figure making one was a good idea. – Wipqozn♦ Oct 30 '12 at 0:03
9

Given that we actually have a reasonably active public chatroom, it seems like that would be a much fairer place for people to check in with us instead of behind closed doors. The users on the Bridge are mostly veterans to the site. They know the ins and outs of what's acceptable to the same degree as the moderators do (which makes sense, considering moderators are an extension of the community's decisions). There are also far more of them available at any time than there are moderators.

So, when it comes to questions where it is questionable if it does or does not fit here (anything outright written at the top of our FAQ should be understood to be on-topic or off-topic as appropriate), it wouldn't hurt for people of other sites to poke into the Bridge and solicit the community's opinion.

12
  • 2
    While I like the public idea, I think the "ping the destination site's mods" is a standardized procedure across sites, and for simplicity's sake it might be best to keep this standard practice for arqade as well. Perhaps we (the arqade mods) could drop the question in The Bridge as part of our procedure for handling incoming (non-obviously-bad) migration requests? – agent86 Oct 30 '12 at 13:01
  • 3
    I think that putting red tape and potential inefficiencies into the process in the name of "standardization" is, well, inefficient. Why stack this as a moderator-only responsibility when the community is equally apt to handle the task, and by their numbers and presence may handle it swifter? If anything, we could herald ourselves a paradigm for new "standards", from the current closed door means to a more open public process. – Grace Note♦ Oct 30 '12 at 13:11
  • 1
    @grace It's not like i understood what the point of this discussion is anyway, given that we have no control on what the other 250 moderators do :) – badp Oct 30 '12 at 13:20
  • Quite true, @badp, and since this sits on our Meta it's not as if they'll be browsing here for tips. That said, I did feel the need to do some digging, so for the record, the Arqade moderators have been pinged all of 13 times in the past two years about migration potentials in the mod room. – Grace Note♦ Oct 30 '12 at 13:21
  • 1
    I don't know that this would work network-wide though, since not every site has a large, typically populated chatroom. (Or that we all know which one would be the correct one to drop into at a given time) Pinging other site's moderators also has the benefit of being a bit more trackable - what happens if it's a dead time on the bridge and nobody notices the migration request? I think of it less as "inefficient red tape" and more like "a process that's easy to remember and implement across sites" – agent86 Oct 30 '12 at 13:26
  • 1
    Like @badp notes though, this is largely a moot point. There are so few migrations, and we don't really have any sort of control over how they're handled anyway (since we can't really approve or reject requests...). If this was a bigger part of the job or a real big problem, I'd probably suggest some new features in the system for handling it. – agent86 Oct 30 '12 at 13:27
  • +1: when I was a mod, if we knew a destination site had an active chat room (Security.SE comes to mind), we asked there instead of pinging the mods in TL. – user3389 Oct 30 '12 at 13:44
  • My only suggestion for improvement (as I said in my original comment) is let the destination mods (rather than the source mods) be responsible for communicating to their community. One would tend to assume they'd know what the best route is. (I can provide my reasoning for this if needed, but it's too long for a comment) – agent86 Oct 30 '12 at 13:56
  • 1
    @agent86 Given the existence of moderators as enforcers of the community's will, it seems odd for our moderators to need to double-check migrations as "Is this okay, on-topic?" on a regular basis with the community. Exceptional cases make sense. Past that, y'all were elected to be representative of the community as a result of synchronicity with their will and regulations. If the community knows the best route, so too should the moderators, as such. I don't think that the moderators need an extra check on this process, if anything that seems to bulk the process worse than either route here. – Grace Note♦ Oct 30 '12 at 14:56
  • @GraceNote, sorry for the delay. My extended thoughts have been edited into my answer and hoo boy are they extended. Sorry :( – agent86 Oct 30 '12 at 15:42
  • @agent86 I've found using mod chat for this to be pretty terrible and not very trackable. If a mod isn't around when they're pinged and come back to see the static transcript, it's a major hassle to see whether it's been answered by another mod in the interim. I do hope the network gets proper migration queues at some point or (better yet) that mods get informed about the destination site and don't ask permission. Mistakes will still be made, but fewer that can be easily dealt with. More or less what badp says in his answer. – Matthew Read Oct 30 '12 at 22:45
  • @MatthewRead, I think in general there's just a lack of centralized, easy to reference, updated, "required reading" or "best practices" for moderators. Even if we managed to make the perfect solution, people would still bork it up by not knowing how to use it. I'd pretty much back any solution, but I think there's a low likelihood of success on any solution where mods have to learn/remember something that is specific per-site. (Even if that's just remembering/finding the most populated site room to drop migrations) – agent86 Oct 31 '12 at 12:55
8

I'm finally home to write my two cents on this particular line of reasoning:

However, one of the RPG.SE mods, @mxyzplk, raised the point that migrating and then closing can be better than not migrating at all since it can result in:

  • New users being introduced to Arqade
  • Reworking a borderline question into a good question
  • Less chance of an acceptable question not being migrated

I've seen plenty of times where users were "introduced to Arqade" by people who clearly haven't taken the time to read the site FAQ. Actually, most of the failed migrations could've (should've?) been prevented by reading the FAQ and the fact this discussion took place means that some part of the equation (perhaps the FAQ) can improve.

At any rate, no, there's no value to introduce people to Arqade when they present it as a place to host "Why don't games have hunger, thrist and constipation meters?" questions (I'm not making this up, but I'm paraphrasing). Being introduced on false terms is a problem, not a feature.

Also, you don't need to migrate questions to fix them and (removing the double negative) I don't see how having more chances of migrating an acceptable question is a good idea: network policy is to migrate only questions that are actively off-topic where asked and keep questions that can work on multiple sites where they were asked.

In general, especially from the perspective of a new user, a failed migration is pretty much a disastrous turn of events; it feels like the worst of bureaucracy where your request idly jumps between offices until it lands in the queue of somebody who can't pass it on. Yet, we're all humans and sometimes shit happens.

Now to talk in more positive terms. While I've made a personal point to super-ping mods of receiving sites before hitting the Migration button, I don't see why it should be a requirement. Contrary to popular opinion, most moderators are gifted with the ability to read and they can easily and independently form an idea of whether or not a question is likely to be accepted here or not. When I (as an Arqade moderator) green light a migration I still can't guarantee that we (the Arqade community) won't close the question anyway!

Shit happens. It's okay.

6

We usually get asked in the super secret moderator chat room that does not exist.

I prefer it that way (us getting asked first), but it's not really a problem if we don't in every case because we can deal with them.

3
  • I didn't realize you had answered. Please ignore my deleted answer (which pretty much says the same thing as yours, minus the top secret mod stuff). – Niro Oct 29 '12 at 23:51
  • 1
    What top secret mod stuff? – juan Oct 29 '12 at 23:52
  • +1 This is my feeling on the issue too. I prefer them to ask us first (either in the super secret moderator chat room that does not exist or the bridge), but it's not difficult to deal with the questions in the event they are migrating. Migrations are rare occurrence after all. – Wipqozn♦ Oct 29 '12 at 23:52
1

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?

GraceNote's Suggestion

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...

agent86's counter-proposal

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).

tl;dr/Conclusion

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.

2
  • +1 There has been more than one occasion where a question has been bounced around multiple sites until it finally landed on the right door step. The simple act of asking can help to avoid this. – Wipqozn♦ Oct 29 '12 at 23:54
  • 1
    @wipqozn Migration chains are no longer supported and kind of forbidden really. – badp Oct 30 '12 at 13:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .