When should we consider adding a default migration path?

Question

When users vote or flag to close a question that should be migrated to another site on the network, they usually can only choose to migrate to meta:

Occasionally we get requests to add a new migration path, which can only be done by employees. Typically we reject such requests because migration is often misused. It's also possible for moderators to migrate if notified with Flagging > Closing > Off-Topic > Other. But sometimes there are sensible migration paths and we do create them. Here's my evaluation process:

1. Sanity check: If there's zero overlap in scope and very little opportunity for honest confusion, then the chance of a good question being asked on the wrong site is small...

   • Lego Answers probably doesn't need a migration path to Seasoned Advice.
   • Just about every site on our network occasionally gets programming questions, but most don't need a path to (or from) Stack Overflow.
   • Brand new sites that have not yet solidified their topic space should not be the target of a migration path.
   • Sites that get very few questions should not have outgoing migration paths as a rule.
   • Etc...

   If a proposed path seems blatantly unlikely to result in productive migrations, then we politely decline the request and recommend flagging a moderator for those occasional exceptions.

2. Gather statistics: You can find out how often a migration path is used by looking at the 10k tools: https://stackoverflow.com/tools/posts/migrated/stats, for instance. The "away" migrations are the important ones. If a site doesn't have many or if they are often rejected, that's a reason to not create the path. (And yes, this is a chicken and egg problem. Once again, it's always possible to ask a moderator to migrate questions with a custom close vote or flag.)

   There's no "right" level for establishing a migration path, but tens or hundreds of migrations with a single digit rejection rate seems safe. Single digit migrations in the last 90 days and/or rejection rates that can order a drink without ID are signs that the path will be a waste of time to establish.

3. When in doubt, we reject requests for new migration paths because they are often a source of conflict between communities. Readers of this meta are likely to understand both the target and source sites well enough to reliably suggest migrations. But that's not true of all users.

Is there a better (ideally objective) way to evaluate migration path requests?

Answer 1

Almost never.

These paths have a place when two conditions exist:

1. There is a clearly-defined topic that is wholly inappropriate on one site and wholly appropriate on another.
2. That topic is asked about daily on the former site.

This is pretty rare. Especially if the first site isn't Stack Overflow.

Background

The migration system was created for the trilogy was created from Stack Overflow: three sites that covered complementary topics, where relatively few questions would be on-topic on more than one site. Suddenly, a whole lot of questions previously asked on Stack Overflow or Server Fault needed to be moved to Super User (and then later Meta) - so migration paths were created to allow this and wired into the closing system. There were rough edges, but mostly it worked.

...Skip forward six years, and there are a lot of sites. Way more than three. And the connections between them are a lot more complicated... DBAs ask a lot of the same questions as programmers; Network Engineers don't want questions about your Belkin router any more than system administrators do. Sites are defined much more by their membership than by their stated topic; I dare anyone reading this to compose a one-sentence summary of Server Fault's scope that doesn't boil down to, "stuff sysadmins aren't bored with yet".

The migration system that remains is Mike Mulligan's steamshovel; not really designed to be the furnace we need now, but... We still can't get it out of the basement...

Killing Mary Anne

Truth is, migrations are not often particularly necessary. It's usually just as easy for the asker to re-post his question on a new site as it is for 5 close-voters or a moderator to migrate. There are better tools available for those rare occasions when a new site is actually carved off of an existing one, and that's primarily what the current system was designed to handle anyway!

If we really wanted to make this work, we'd consider either folding migrations into site-specific off-topic reasons or separating it from closing entirely, as an alternative to deletion. Although there are some other ideas floating around too.

Until then, I'd want to see a veritable deluge of good but blatantly off-topic questions on a site before I'd consider adding a migration path.

Answer 2

I applied the above principles on a suggestion to open a path between Christianity and Biblical Hermeneutics (a path I know well as it turns out). Some feedback:

1. The rejected stat only measures the moderators' ability to migrate questions when there is no default path. Certainly we shouldn't consider a path if these especially knowledgeable users struggle to migrate successfully, but that doesn't necessarily tell us how well a path will work. What would be more enlightening is how often moderators reject suggestions to migrate questions. We don't track this statistic.

2. People who use the close vote menu aren't necessarily aware that their votes can result in automatic migration to other sites. Nothing in the menu copy explains that this type of close is any different than other closes which just show the reason in a banner.

This suggests to me two potential changes to modernize the migration system:

The radical solution

Instead of migrating questions when closed as belonging on another site, the question will be closed with a banner that reads:

Closed as off-topic by @users $date

This question seems better suited for $other_site our site for $description. Please read their on-topic guidance before asking there.

If this question can be reworded to fit the rules in the help center, please edit the question.

At that point, the question will be closed just like any other. If anyone (including the OP) wants to ask the question on the other site, they certainly can do that manually. In extreme situations (such as site closure), an employee can still migrate questions with great answers that would be lost due to deletion. For practical purposes, Mary Anne would be decommissioned.

Under this system, the moderators can pick which sites are listed or we could let users pick from all of our sites. There would be minimal chance of a site exporting its problem questions if migrations are not possible.

The complicated solution

If we can't quite bring ourselves to forcefully retire migrations, we could try data-driven migration paths. Here's how it might work:

1. Moderators can nominate migration paths, just like they can nominate custom close reasons. If a second moderator approves the path, it will be listed in the flag/vote-to-close menus.

2. When a new path is used, it works as usual for X days.

3. After the trial period ends, the number of successful migrations per day and rejection rate is calculated. Based on those numbers and thresholds we establish, the path is either made permanent or revoked.

I'm pretty sure this solution is too complicated to be worth the benefit. There are also a bunch of edge cases I haven't addressed:

• Can moderators revoke the path after they have approved it?
• Do we ever revoke the path after it's established?
• What about meta <-> main migrations?
• Should the thresholds take into account the question rate on the destination site? What about the source site?
• Etc.

Please feel free to flesh out either solution as a full feature-request.

Answer 3

One option would be to be much more liberal in trying out migration paths, and then just revisit the decision after a few months. As long as the topic overlap looks plausible and there is room in the list of migration targets, try out the path and see how the community handles it. After the testing period, take a look at the volume and rejection stats and decide if the pathway is worth it.

I also wouldn't be concerned as much about a low volume path. There are many low volume traffic sites in the network, as long as the quality of the migrations is good I don't see a huge issue if there are only a few of them. Of course they could be handled by the mods (with the caveat that flagging for migration isn't entirely obvious), but there is also no big harm caused by a low-traffic migration path as long as it doesn't take away a place from a better one.

I'm not entirely convinced this is a good idea, but I think it's worth considering it. There's still the fundamental problem that the users deciding on the migration are not necessarily the users qualified to assess if the question is appropriate for the target site. A more fundamental change to the migration system would be needed to fix the general problem, but so far I haven't seen any truly convincing idea. Restricting the migration paths is a rather crude way of preventing users from performing bad migrations, but as long as we don't have a better idea it is probably necessary.

Answer 4

Almost never.

I've answered this before, but my thinking has evolved slightly since then. I've seen the amount of times people suggest re-posting on a different site - badly.

Allow migration only when requested

Some sites like being a migration target. Others... don't. Instead of having this argument continually, all across the network, let each site determine who they want to be a migration target for. To quote myself, it might work something like this:

• Each site's moderators jointly, or through a meta question (and so the community), decide which sites they want their site to be a migration target for. The arguments for and against are kept to each sites meta.
• They can change this at any time based on migration failure rates; whatever the current "perception" is; falling numbers of new users due to lack of migrations or whatever reason they can dream up.
• The migration list on each site becomes that site's meta plus the top 4 sites who want to be a migration target (I'm not certain how you would determine "top" but by size/number of successful migrations for example; this list would be dynamically updated and so the target sites could change according to the success of the migrations to those sites).

Make it easier

Where migration has been suggested allow the OP to make a decision. Give the OP sight of the target site's on-topic help page to see whether the believe that their question is on topic on the suggested site then let them move it - unilaterally.

Remember that the target community actually wants these questions.

Stop all other migrations

Yup, stop them. It's quicker and easier for person to manually copy and paste than it is to wait for a mod to get around to moving them. Some questions spend in-ordinate amounts of time waiting for a migration, which is an extremely poor experience for the user. I like your "radical solution" for this part.

Answer 5

Disclaimer: I'm mostly active at chem.SE.

Chem.SE is categorized as a science site. We do often get questions that need to or should be migrated to physics.SE and biology.SE, and very rarely EarthScience.SE. In the approximately one-year time I've been active there, we never encountered a question that was ultimately migrated to any other science-categorized site.

Furthermore, IMHO the technology topic is so crowded and diverse, it's reasonable to imagine a couple of sites with no overlapping scopes, like for instance, TeX.SX and Ask Different. The same argument holds for Life/Arts; like Academia and Seasoned Advice; and Culture/recreation; like RPG.SE and Bicycles.SE.

That being said

I'm not suggesting anything against the current (messy?) grouping (Technology sites are about technology, even though dispersed at a broad range of topics); but how about a bit of tidying up; making some kind of sub-groups? However, for obvious reasons, one site should be able to be in more than just one of these groups.

For example; in the science tab:

• Chem.SE, physics.SE, and Biology.SE
• Math.SE, Stats.SE, physics.SE and MathOverflow¹
• Theoretical Computer science and Stats.SE

as the three groups available. Now, as betas graduate (or whatever that process is now called after that meta post) they'll be added to these groups; either through a meta post and the community's decision, or through the new elected mods.

Migration paths could be set by default between the members of these sub-groups. If migration is misused in a specific path more than an arbitrary amount of times (like when the migrated post gets closed as OT on the target site), then the path'll be removed.

The final question: How should these groups be defined?

I find posting a meta discussion on per site metas and tracking people's ideas is a good way to do so. If that's too much work, you might consider speaking with the sites' mods (after all, they are expected to know their own site's scope better than other members) and reaching a conclusion on that.

---

1: I'm not aware whether any of these processes are applicable to MO.

Answer 6

This is always going to depend on the site. Security has a wide range of overlaps, so currently our migration options are:

And these have been very sensibly based on successful migration statistics, which required stringent vetting from the moderator team on all those requested.

The only one we are missing, that actually gets a fair percentage of migrations, is Cryptography, and that is because it is only just graduating now. If we could have that as well, we'd have 98% of all our migrations covered.